New InstanceManager: Instancing done the right way

[Assaf Raman]

I didn't finish - but I made a backup commit of my work.
Note - you need to install GL 3.3 drivers for gl to work with glVertexAttribDivisor.
DX - should work out of the box.
I will finish this later this week - you can review the direction I am going for now.
Check that your VTF is still working as before.

[dark_sylinc]

Hi!

I saw your commits, pretty impressive.
I tried the New Instancing demo and crashed immediately, so I guess it's not working as before hehe. Debug mode is compiling as we speak.

[dark_sylinc]

The crash is caused because it's complaining that material "Examples/Instancing/Hardware/Robot" wasn't found.
Haven't you forgot to check it in?

Anyway this made me realize getMaxOrBestNumInstancesPerBatch() shouldn't crash on missing materials, since the purpose of that function is to safely (aka "exception-safe") retrieve whether a given instancing technique is supported, and how many instances per batch.
Crashing on the first sign of trouble isn't exactly what I had in mind.

Also I fixed a few "NUM_INSTANCING+1" issues. Plus, the non instancing comparision was sudenly gone.

Oh and by the way, the VTF implementation seems fine

[Assaf Raman]

Yes, I didn't check in Examples/Instancing/Hardware/Robot, I removed the reference for it for now.

[boyamer]

Would be fine if you made commit for Directx11 too.
There is already a DrawInstanced and DrawIndexedInstanced method..

Wait to see more

Nice work

[Assaf Raman]

No problem.

[Assaf Raman]

I added Instancing support for the d3d11 render system. Also added an option to control the instance data step rate for all relevant render systems. This is useful for the cases where instances of instances are needed.

[boyamer]

Nice..When i run the demo the Hardware Instancing doesn't work..Is this still WIP Assaaf?

I've run under DirectX 9

[Assaf Raman]

The demo isn't finished yet.

[andrewxie]

wow ,i really hope to see the HW instancing demo works

[Assaf Raman]

It is clear to you that it is going to have the same performance right?
Moreover - that demo as is going to have the same batch count - because the batches in that demo are limited by the vertex texture buffers.
I can't move the matrices to a vertex buffer - too many matrices - one per bone.

[boyamer]

So you mean that HW instancing has same performance of rendering with no instancing?

[Assaf Raman]

HW instancing doesn't help performance per frame, what it does is saves GPU memory.
The new instancing sample - is not the bast case for HW instancing, the reason is that in that sample the memory saved by not multiplying the geometry is nothing compared to the memory used by all the matrices for bone pos.

The best case for HW instancing is a case where you have a lot of entities without bones, like rocks, houses, asteroids, leaves, particle systems and such - that you want to multiply all over the scene, that case you will save memory and will not have huge vertex buffers.

[andrewxie]

hi , i want to use the HW instancing technique in my application, should i use the InstanceManager ?

PS:I have stepped into the HW instancing DEMO, but it seems there is no chance to call setStreamSourceFreq

[dark_sylinc]

Indeed, adding HW instancing won't make it faster than the VTF technique, it will only save GPU memory (which in some cases it mean a lot!).
On some GPUs with serious bandwidth limitations, there could be some performance improvement though.

Theoretically HW instancing makes a much better vertex cache utilization, however it has been stated that the DX9 model with a second buffer repeated per object isn't quite cache friendly (negating this effect), thus the InstanceID counter was introduced in DX10 to help with it.
But in practice it doesn't really improve much performance.

[cyrfer]

HW instancing doesn't help performance per frame, what it does is saves GPU memory.
The new instancing sample - is not the bast case for HW instancing, the reason is that in that sample the memory saved by not multiplying the geometry is nothing compared to the memory used by all the matrices for bone pos.

The best case for HW instancing is a case where you have a lot of entities without bones, like rocks, houses, asteroids, leaves, particle systems and such - that you want to multiply all over the scene, that case you will save memory and will not have huge vertex buffers.

Maybe I'm reading this out of context, but it seems to me that if you can draw many objects with a single draw call, performance should be improved. Also, my own implementation/use of HW instancing stores transform info in textures. One might notice that more memory is used, with the performance benefit of only a single draw call.

[dark_sylinc]

Maybe I'm reading this out of context, but it seems to me that if you can draw many objects with a single draw call, performance should be improved. Also, my own implementation/use of HW instancing stores transform info in textures. One might notice that more memory is used, with the performance benefit of only a single draw call.

You're confusing stuff. Assaff was comparing HARDWARE instancing versus NON-HARDWARE instancing.
What you're talking is about any kind of instancing vs not using instancing at all.

HW instancing and non-HW instancing are almost the same. The difference between hardware instancing compared to non-hardware instancing is that in the first one, the GPU repeats the same vertex buffer any amount of times you specify, while in the later, you have to build a vertex buffer large enough where you repeat the same vertices the same amount of times. This obviously, consumes a lot more memory.

HW instancing is like doing (in the GPU):

Code: Select all

for( int i=0; i<numInstancesPerBatch; ++i )
{
    for( int j=0; j<numVertices; ++j )
          runVertexShader( vertex[j] );  //-->notice how vertex holds only numVertices
}

While non-HW instancing does something like this (in the GPU):

Code: Select all

for( int i=0; i<numInstancesPerBatch * numVertices; ++i )
{
      runVertexShader( vertex[i] );  //-->notice how vertex holds numVertices * numInstancesPerBatch
}

This is the basic concept. HW instancing works with the concept of "frequencies" for individual vertex buffer sources, which also opens the possibility for other smart tricks unrelated to instancing.

[jonim8or]

I like to see this progress in the instancemanager, and am experimenting with it on my pc. I'd like to help in the development of it too. However, I have a suggestion about the public user interface. Would it be possible to hide the complex functionality a bit? That a simple use of it would be very simple, like

Code: Select all

sceneManager->setInstancingTechnique(InstanceManager::ShaderBased);
InstancedEntity* entity1 = sceneManager->createInstancedEntity("Robot.mesh");
InstancedEntity* entity2 = sceneManager->createInstancedEntity("Robot.mesh");

then the management of the InstanceManagers would all be done under the hood, and you only need it if you want to tweak the parameters.

[Assaf Raman]

Well, you need a shader for the instancing to work, so I guess that the best solution is some sort of integration with the RTSS

[dark_sylinc]

I like to see this progress in the instancemanager, and am experimenting with it on my pc. I'd like to help in the development of it too. However, I have a suggestion about the public user interface. Would it be possible to hide the complex functionality a bit? That a simple use of it would be very simple, like

Code: Select all

sceneManager->setInstancingTechnique(InstanceManager::ShaderBased);
InstancedEntity* entity1 = sceneManager->createInstancedEntity("Robot.mesh");
InstancedEntity* entity2 = sceneManager->createInstancedEntity("Robot.mesh");

then the management of the InstanceManagers would all be done under the hood, and you only need it if you want to tweak the parameters.

The current code is not much different than that really:

Code: Select all

//Call this ONCE at startup
mSceneMgr->createInstanceManager( "Robot.mesh.mgr", "Robot.mesh", ResourceGroupManager::AUTODETECT_RESOURCE_GROUP_NAME, InstanceManager::ShaderBased, 80, IM_USEALL );

//Then at any time...
InstancedEntity* entity1 = sceneManager->createInstancedEntity( "customMaterial", "Robot.mesh.mgr" );
InstancedEntity* entity2 = sceneManager->createInstancedEntity( "customMaterial", "Robot.mesh.mgr" );

OK, I've hard-coded the value '80'. You should use mSceneMgr->getNumInstancesPerBatch().
The custom material is required. Some integration with RTSS could be made, but I'm not really deep into it. Someone else would be much better doing it.

Note on old cards some instancing techniques won't be supported which may fail miserably and you should check getNumInstancesPerBatch returned something bigger than 0.
(If you try to create an instanced entity from an unsupported technique, createInstancedEntity will return a null pointer).

The name of the instancing manager is required because it replaces the name of the mesh (so, nothing is lost really), and allows having the same model using multiple instancing techniques at the same time.

Advanced users may want to bypass the SceneManager and work on the InstanceManager directly.

[jonim8or]

The current code is not much different than that really:

Code: Select all

//Call this ONCE at startup
mSceneMgr->createInstanceManager( "Robot.mesh.mgr", "Robot.mesh", ResourceGroupManager::AUTODETECT_RESOURCE_GROUP_NAME, InstanceManager::ShaderBased, 80, IM_USEALL );

//Then at any time...
InstancedEntity* entity1 = sceneManager->createInstancedEntity( "customMaterial", "Robot.mesh.mgr" );
InstancedEntity* entity2 = sceneManager->createInstancedEntity( "customMaterial", "Robot.mesh.mgr" );

OK, I've hard-coded the value '80'. You should use mSceneMgr->getNumInstancesPerBatch().

That actually does look quite similar. There are however two big differences with my proposal. The one is, as you mentioned, the material. An integration with RTSS would be good, but I'm not into the wrkings of RTSS either. The second big difference, is that I don't know in advance which entities will be instanced. So I need to check for the existance of an entitymanager, and create one if needed. Is there a method to check that? something like

Code: Select all

MovableObject* MyClass::spawnAnObject(String mesh_name, String material_name)
{
  if(!mSceneMgr->getInstanceManager(mesh_name + ".mgr"))
    mSceneMgr->createInstanceManager(mesh_name + ".mgr",mesh_name, ResourceGroupManager::AUTODETECT_RESOURCE_GROUP_NAME, InstanceManager::ShaderBased, 80, IM_USEALL );
  MovableObject* ans =  sceneManager->createInstancedEntity(mesh_name, material_name);
  if(!ans)
    ans = sceneManager->createEntity(mesh_name);
  return ans;
}

[chocoT]

I am really looking forward to using this new instance manager.

I tried the old one and I couldn't get dynamic shadows to cast between instanced objects. Will this new manager/approach support that?

When will patches get integrated into the main (compiled) distributions?

[dark_sylinc]

I tried the old one and I couldn't get dynamic shadows to cast between instanced objects. Will this new manager/approach support that?

If by dynamic shadows you mean shadow mapping, then yes, the new manager already supports that and the demo that ships with the SampleBrowser shows it in action.
If by dynamic shadows you mean stencil shadows, then no; that won't be supported any time soon (and probably never ever).

When will patches get integrated into the main (compiled) distributions?

The patch is already integrated. You'll see it when Ogre 1.8 gets officially released.
If you can't wait, you can get it by compiling the source from the latest mercurial repository. Guide to compile the sources (there are more in the wiki)

Cheers
Dark Sylinc

[chocoT]

I got the latest OGRE source compiled now and started using the new instance manager. However I have manually created meshes which use multiple material in multiple ManualObject::begin(). Can this new instance manager help me in this situation? I am stuck at this call and I don't know what the material name I should pass since I have multiple:

Code: Select all

InstancedEntity *ent = instanceManager->createInstancedEntity( "???" );

I just started learning 3D programming in my free time after work. Thanks!

[dark_sylinc]

I got the latest OGRE source compiled now and started using the new instance manager. However I have manually created meshes which use multiple material in multiple ManualObject::begin()

InstanceManager will only work for established meshes. If you really want to create one with code, I suggest you look at the generate mesh article.
But 99% of times you will prefer creating the mesh in Blender/Maya and exporting it. Personally I do that even for a simple debug cube or sphere. Saves a lot of time and effort.

Materials are usually defined through script, but you need to specify a material with a shader specifically written for the instancing technique you wish to use.
Look at the NewInstancing demo to see how it works.

If you want multiple materials for different parts of the same mesh, then I'm afraid that's not possible. Using multiple materials cuts the benefit from instancing anyway.
I'm looking forward to implement multiple submeshes support with multiple materials at some point (I'm thinking at repeated persons with one material for the body, another for the eyes, for example), but I don't think that will be happening in the next 3 months at least.

Although the purpose of this InstanceManager is to make instancing easy and accessible, it's still an advanced topic that one needs to be aware of it's trade-offs. If you're new to 3D programming, I wouldn't recommend it as a starting point.

Cheers