Hardware mesh instancing

#1 The performance improvement depends on how your scene is composed.

If you have alot of instances of the same static DTS model you'll see big wins. If you don't... it may not help you at all.

It doesn't work with animated models, non-DTS geometry, or multipass materials.

The implementation is spread between TSShape, MatInstance, ProcessedShaderMaterial, and RenderMeshMgr. No changes to your level or art is required to make it function.

#2 Thanks Tom that's very useful.
So for example trees and the forest editor will use it, and trees that are animated by the wind will still be classified as static models?

In the examples on the nvidia site they have a video of skinned instancing, an arena packed with animated models of characters jumping up and down, does this mean it will be possible to implement instancing with animated models in Torque 3d?

Quote:Skinned Instancing is an extension of regular instancing. It renders each character using hardware palette skinning. However, instead of the standard method of storing the animation frame in shader constants, we encode all frames of all animations into a texture and lookup the bone matrices from that texture in the vertex shader. Thus we can have more than one animation, and each character can be in a different frame of each animation.

developer.download.nvidia.com/SDK/10.5/direct3d/samples.html#SkinnedInstancing

developer.download.nvidia.com/SDK/10.5/direct3d/Source/SkinnedInstancing/doc/Ski...

I found a chapter in the online GPU Gems 2 (2005) on instancing which explains some of the technical stuff:
http.developer.nvidia.com/GPUGems2/gpugems2_chapter03.html

And more specifically a chapter on animated crowd rendering in GPU Gems 3 (2008):
http.developer.nvidia.com/GPUGems3/gpugems3_ch02.html

#3 I'm pretty sure I'll find out once I get 1.1, but will hardware mesh instancing affect the drawcalls generated by shadows? For example, let's say we have 100 identical models, and each of them generate 1 drawcall for shadows (so now it would be 100 DC for the models and 100 for the shadows, 200 DC total). With hardware mesh instancing it will mean just 1 drawcall for all the models, but for shadows? Will it be 1 drawcall for all the shadows generated by these models, or will still be 100 drawcalls in total? Thanks!

#4 @Oscar: From what I understand it will not do anything different as far as dynamic shadowing unfortunately.

#5 @Justin: hardware instancing skinned meshes is only applicable when using vertex shader skinning. T3D uses CPU-skinning, so each animated instance has a copy of the vertex buffer, and thus cannot be drawn with a single draw call.

The Forest trees are animated on the vertex shader (they don't use bones for their animation), so they can use instancing.

I'm not aware of any plans on moving skinning to vertex shaders, since it ups the minimum GPU requirements among other drawbacks.

@Oscar: This is the draw call break up when using AL and sun shadows:

- One draw call for G-buffer filling;
- One draw call for any shadows that need updating (if you're using Sun/ScatterSky shadows objects near the camera will generate 4 draw calls, one for each PSSM split);
- One final draw call for drawing the object to the screen.

So in a normal situation each object takes 6 passes close to the camera (aka: the object shows up in the first PSSM split) down to 2 as they get the furthest away (the object is outside the shadow range).

Right now 100 identical models (each one using only one material) will generate ~500 draw calls, depending on how distributed they are in regard to the camera. With hardware instancing they'd take ~5.

#6 "Right now 100 identical models (each one using only one material) will generate ~500 draw calls, depending on how distributed they are in regard to the camera. With hardware instancing they'd take ~5. "

That's Seriously cool !!! 8)

#7 Thanks Manoel, that sounds really, really cool :)

#8 Thanks for the information, looking forwards to seeing the results in the next beta release.

Would it be possible to animate some other objects using the vertex shader and without using bones in a similar manner to the way trees are animated?

Let's say for example I made a butterfly from just two polys, could I make the wings flap and the instancing would allow me to generate a cloud of butterflies with only one draw call?

#9 @Justin: of course it is possible... if you write code and shaders similar to what the trees use.

The trees are animated by a time-based function in the shader. Vertex colors are used to control how and how much much each vertex will sway.

With a butterfly, you could have a shader that rotates the vertices around the object's Y axis. The angle of rotation is calculated by passing the elapsed time (multiplied by some constant) through sin(), so you have a nice back and forth animation. Then you use vertex colors so the animation only happens on the vertices you paint with a specific color and to make the other wing rotate in the opposite direction.

You'll also need a custom renderable object class to feed the necessary shader constants (again, similar to what the trees do).

#10 Hey All,

just a quick one, will PhysX objects support instancing do you think? ie. If a crate was set up with full PhysX, would you be able to easily drop dozens of them in a scene without much more overhead than one?

#11 @Harvey

Quote:do you think?

Not exactly "static" though is it?

#12 PhysX works by updating the objects' positions and rotations. So yes, PhysX rigid bodies (not cloth) are eligible for hardware instancing.

When they say "static mesh" they mean "no deformable mesh". Vehicles, as example, can be hardware instanced as well. Forest Editor trees are deformed on the vertex shader, so they will also be instanced. Characters are deformed on the CPU, so they cannot be instanced.

However, in the PhysX case, you'll only remove the draw-call costs. Of course PhysX will still need to process each box individually.

#13 So a moving object can be deformed on the vertex shader, and with the wind emitter and trees the animation is relative to the individual object and not to the world?

#14 @Justin: the trees have world-related animation. Explosions will push the trees around it, as example. And I think you can setup local wind emitters (with a radius), which could be used to make flying vehicles flutter the trees underneath.

#15 But a moving object, say a bird, could be animated using the same kind of vertex shader based animation? In other words animated relative to the mesh, not to world space?

#16 Yes. The transform will be handled by the instancing, and vertex-shader deformations work on each instance. However, now I just remembered, since all instances are rendered with one draw call you'll need to pass any per-instance variable through the instance vertex stream (like the world transforms).