Question

I am writing a 3D graphics application (using SharpDX) with static and animated (including skeletal animated) meshes. Some meshes will only be rendered once per frame, some will be rendered a large number of times. In order to speed up rendering I am planning to take advantage of hardware instancing.

Rather than implementing an instanced and a non-instanced rendering routine and selecting the correct one for each mesh, it has occurred to me that it will be easier to simply use instanced rendering for all meshes.

Assuming that the target hardware supports hardware instancing, are there any drawbacks to using hardware instancing to draw all meshes, even if they only occur once per frame?

Was it helpful?

Solution 2

I am thinking it could be a tad slower as you are introducing an extra buffer binding to set the instance buffer. So each mesh requires 2-3 buffers to be rendered (the Vertex buffer, the Instance buffer and possibly an Index buffer) instead of only 1-2 (vb and ib).

As always though, if it helps standardise your engine and you do not experience any noticeable drawbacks then there will be no need to optimise. The only way to know is to profile these two variants of your app.

OTHER TIPS

You will give a tiny bit more work to your input assembler while doing that, but just did a quick test with high resolution sphere and timestamp for instanced/non instanced i got pretty much the same results.

Please note I'm using a structured buffer in the instanced version (doing a little lookup to displace).

Also since you mention you will use skinning the potential cost will be minimized a lot in your case (since your vertex shader will have to do quite some work).

To avoid to add to the shader structs as per your comment, you can also use StructuredBuffers and do lookups using either SV_InstanceID or SV_VertexID, that's much more flexible than per instance vertex buffers (knowing you can also offset some work in Compute Shaders at a later stage much more easily).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top