How can i use hardware instancing in Beta2?

#41

Quote:
Instancing should "just work" with it being transparent to the designer/artist as much as possible.

it should "just work" only for objects the developer wants. why not let us decide what objects are instanced? this would make testing and optimizing much easier. that seems like the most reasonable solution rather than some algorithm behind the scenes deciding it for us.

Quote:
For now if your scene doesn't see a benifit from instancing... disable it.

very true. in fact, the most useful aspect of this new feature is the ability to disable it.

#42 Sadly, this just confirms some discussions I've seen at gamedev forums: DX9 instancing on PC hardware isn't that much of a holy grail. The results will vary across different scenes *and* across different hardware (on some GPUs instancing will actually degrade performance). The behavior is much more consistent in DX10/11 and in console hardware.

#43

Quote:Instancing has inherent overhead in packing instancing data into a dynamic VB and send it to the card. If you have smaller batches then building instancing data can be more overhead than just doing multiple draw calls.

Instancing should "just work" with it being transparent to the designer/artist as much as possible. A solution for these small batch cases is to have a "minimum batch size" at which the objects are not instanced.

If set properly you get all the benefits of instancing without any overhead from small batches.

The question is will i have time to implement that for beta 3... not sure. For now if your scene doesn't see a benefit from instancing... disable it.

That's some really interesting info, Tom! Good to know the workings behind the mesh instancing.

Sure, an X number of instances as a minimum to use mesh instancing sounds really good.

#44 Perhaps a good compromise would be to use the algorithm to make the instancing work as efficiently as possible and then provide a flag that could be set on a mesh by mesh basis to exclude them from the batch instancing?

#45 FYI.

So i'm doing a few optimizations for instancing.

First i found that i was passing 4 more floats for items in the forest than i needed which reduces the instancing data to pack and for the GPU to unpack.

I'm also currently sending a full matrix to the GPU for each instance transform. Assuming i can count on all Torque meshes to be orthogonal i can reduce the current 16 floats sent to 10 (xyz position, rot x axis, rot y axis, and z scale) and recreate the transform in the shader. For that matter... we could do this same optimization for non-instanced meshes, but i'm unsure if its a clear performance improvement.

Aside from that i'm gonna try to add a triangle limit to instancing. Meshes with more than 1000 triangles don't instance very well... they eat up more GPU power in the vertex assembly stage than you win in reducing draw calls. In theory this is more importaint than the number of instances rendered... so i want to try that as our metric.

An old but still the best info on instancing performance is Cem Cebenoyan's presentation from GDC 2005.

I'll report back as i have results.

#46 Cool stuff!

What do you mean by orthogonal meshes?

#47 How can I disable this on a single mesh or mesh instance?

#48 @Oscar - What i ment there was that the x,y,z rotation vectors in the transform matrix are orthogonal... no warping/shearing. I can't say i've seen any case in Torque where an object transform needed this.

@Chris - There isn't any setting exposed to do that.

#49 Well it seems that mesh instancing might be responsible for my bug here

I figured out that when I make one of my materials emissive it works, disabling hardware mesh instancing with the console variable has no effect though.

Is there something else with materials that is not getting disabled?

#50 @Chris - If you disable the mesh instancing feature and your bug isn't fixed then its highly unlikely for it to be related to mesh instancing. I suspect its some other issue.

Also its hard for me to spend time debugging resources and why one or another doesn't work in the new beta... we have 1000s of resources... its just not possible to do.

In the case of a resource like this the author or an interested party needs to debug the problem and if it turns out to the a bug in T3D report that.

#51 I didnt ask you to debug thousands of resources, I described a specific problem that we are having while porting our game to beta 2. This problem hurts us quite a bit and I have worked for many hours reading through code and debugging.

It is very suspicious that soon as another model shows up they both share the same material but soon as it goes off the screen things go back to normal. Also setting one of the materials to emissive makes them not share when it comes on the screen.

I have stepped through all the code, read everything between setting the material and rendering things and I can't find it or lack the understanding, its not like I had a problem and just posted expecting someone else to do work because I am lazy or something we just need help fixing this issue.

#52 @Chris - My only suggestion would be look at the batching within the RenderMeshMgr::render(). I would setup a test case with nothing in the scene but the two meshes that exhibit the problem then look at how the call to newPassNeeded() breaks the batch.

#53

Quote:Instancing should "just work" with it being transparent to the designer/artist as much as possible. A solution for these small batch cases is to have a "minimum batch size" at which the objects are not instanced.

If set properly you get all the benifits of instancing without any overhead from small batches.

The question is will i have time to implement that for beta 3... not sure. For now if your scene doesn't see a benifit from instancing... disable it.

Tom, were you able to implement this in Beta 3? Thanks!

#54 @Oscar - No i didn't get the time to do so and will probably not happen until after 1.1. My suggestion is to disable the mesh instancing if your game doesn't see a benifit from it.

#55 "happen until after 1.1" .....:-)

Great clue and looking promising with concern for the future of Torque!

b.r.
kaj