03-26-2021, 03:44 PM
The purpose of RenderablePrimitive objects is to issues one DirectX draw call. The RenderablePrimitive objects are organized in RenderingQueues. This allows to sort them and provide a very memory efficient (and fast) way to provide data necessary for the draw call.
Each MeshObjectNodes usually creates one RenderableMeshPrimitive (except when there are SubMeshes defined). This is done in the overridden CollectRenderableObjects method.
In this case there is no instancing - as said, each object is drawn with its own draw call.
When instancing is used, then one DirectX draw call provides mesh information and information about multiple instances - so one draw call can render many instances of the same mesh. To render instanced objects, the InstancedMeshGeometty3DNode in its CollectRenderableObjects method creates RenderableInstancedObjectsPrimitive objects and adds them to RenderingQueues.
The difference between RenderableInstancedObjectsPrimitive and RenderableMeshPrimitive is that the first one also defined the instance buffer that has the instances data and that the first one provides its own overload of RenderGeometry that calls DrawIndexedInstanced or DrawInstanced DirectX method to render the instances.
But behind the scenes, it is not enough that you only replace DrawIndexed call with DrawIndexedInstanced and provide instances buffer. The effect and shader that renders the scene also needs to support instances - in DXEngine the only shader that supports instances is StandardEffect and its SuperShader.
This means that only standard 3D objects with standard materials (StandardMaterial or WpfMaterial) can be rendered with instances.
The problem for your case is that you cannot use instancing with PBR materials. Even if you would create RenderableInstancedObjectsPrimitive with the correct instance buffer the instances would be rendered with standard material and not with PBR.
I am currently finishing the next version of Ab3d.DXEngine and Ab3d.PowerToys and will not add any new feature to this version.
But for the next version I have added a task to provide a new SceneNode object that will take DXMesh and InstancesData so it will be able to render instances data without MeshGeometry3D object (but still only using standard material).
But I do not plan to add support for instancing with PBR materials. The problem that I see with PBR material is that each PBR material requires much more data than standard material. With standard material usually one color is enough (and that color is part of each InstanceData) but PBR requires much more data and that data are usually specified by textures. So it would be hard to add that data to InstancaData struct.
But if you have a special case where this could be useful, then it would be possible to create a custom effect and shader that would support such case.
If you think that the current solution without instances is not fast enough (even with using multi-threading and DirectX commands caching) and think that you would really need a solution with instancing, then in the near future I could do some custom coding for you and implement PBR instancing for your case (but this is not free).
Please do a good profiling / benchmarking to check the performance of the current solution and if the problem is really in on the CPU because a lot of DirectX objects need to be rendered.
Each MeshObjectNodes usually creates one RenderableMeshPrimitive (except when there are SubMeshes defined). This is done in the overridden CollectRenderableObjects method.
In this case there is no instancing - as said, each object is drawn with its own draw call.
When instancing is used, then one DirectX draw call provides mesh information and information about multiple instances - so one draw call can render many instances of the same mesh. To render instanced objects, the InstancedMeshGeometty3DNode in its CollectRenderableObjects method creates RenderableInstancedObjectsPrimitive objects and adds them to RenderingQueues.
The difference between RenderableInstancedObjectsPrimitive and RenderableMeshPrimitive is that the first one also defined the instance buffer that has the instances data and that the first one provides its own overload of RenderGeometry that calls DrawIndexedInstanced or DrawInstanced DirectX method to render the instances.
But behind the scenes, it is not enough that you only replace DrawIndexed call with DrawIndexedInstanced and provide instances buffer. The effect and shader that renders the scene also needs to support instances - in DXEngine the only shader that supports instances is StandardEffect and its SuperShader.
This means that only standard 3D objects with standard materials (StandardMaterial or WpfMaterial) can be rendered with instances.
The problem for your case is that you cannot use instancing with PBR materials. Even if you would create RenderableInstancedObjectsPrimitive with the correct instance buffer the instances would be rendered with standard material and not with PBR.
I am currently finishing the next version of Ab3d.DXEngine and Ab3d.PowerToys and will not add any new feature to this version.
But for the next version I have added a task to provide a new SceneNode object that will take DXMesh and InstancesData so it will be able to render instances data without MeshGeometry3D object (but still only using standard material).
But I do not plan to add support for instancing with PBR materials. The problem that I see with PBR material is that each PBR material requires much more data than standard material. With standard material usually one color is enough (and that color is part of each InstanceData) but PBR requires much more data and that data are usually specified by textures. So it would be hard to add that data to InstancaData struct.
But if you have a special case where this could be useful, then it would be possible to create a custom effect and shader that would support such case.
If you think that the current solution without instances is not fast enough (even with using multi-threading and DirectX commands caching) and think that you would really need a solution with instancing, then in the near future I could do some custom coding for you and implement PBR instancing for your case (but this is not free).
Please do a good profiling / benchmarking to check the performance of the current solution and if the problem is really in on the CPU because a lot of DirectX objects need to be rendered.
Andrej Benedik