Sign in to follow this  
NiteLordz

Instancing

Recommended Posts

I have gone thru and implemented instancing as a tech demo. however, now i want to implement it within my engine structure. This however has lead me to a few questions.

1) when to accumulate the instances
-Level is running, and using frustum culling, i determine that one meshID is visible 10 times. do i build the instance buffer here, then pass that onto the renderer.
- this gives the benefit of only renderering the visible instances
- however, this is built on a per frame basis

2) should the level be pre processed, to determine that meshID "1" is rendered out 10 times, and build the instance buffer on load, then render all the instances every frame
- doesn't need to be built per frame
- renders off screeen meshes

thanks for any input

Share this post


Link to post
Share on other sites
It depends. Let's look at the second case: if you need to always send the offscreen meshes then the GPU is definitely going to cull them for you at some stage, but they will still consume bandwidth, some shader stages (primarily vertex shader), and some setup cost. Depending on how complex the meshes are, how complex the shaders are and how many meshes there are (proportionally offscreen versus onscreen) this may more than wipe out any performance gained from instancing. But then again it might not, and it's really down to your program and your data to influence that decision.

In the first case it may turn out to be very inexpensive to rebuild the per-instance data. You may be able to cache and reuse the same data over several frames (especially if your meshes are neither animating nor moving). The per-instance data may be very lightweight. Or none of these things might be true, and it may be a very expensive operation, again depending on your program and your data.

So there's no correct answer - you'll need to benchmark each and find out which is best for your own use case. (You may even end up implementing both for different types of mesh.)

Share this post


Link to post
Share on other sites
I would sugguest a mix. First off, subdivide your level into chunks (simple tiles, AABBs, quad/oct-tree), then create a list of instances with the same mesh id per chunk. This could be pre-calculated or determined and cached at run-time. Some considerations:
- Define a threshold at which you benefit from using an instance buffer instead of simply rendering the meshes.
- Join neighbor chunks if one chunk does not surpass the threshold.

Share this post


Link to post
Share on other sites
I wouldn't directly link culling-volumes to mesh-IDs. If there is no direct dependency between those two things, then you can connect them in different ways, such as having the ability to implement both #1 and #2.

If there are 10 instances of a particular mesh in one area, you can group them all under a single culling volume. If mesh instances are spread out, you can link each one to a different culling volume. You can even link many instances of [i]different [/i]meshes to a single culling volume ([i]off topic from instancing there though[/i]).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this