New InstanceManager: Instancing done the right way

[spacegaier]

I am pretty sure that it is already in the trunk (1.. The commit messages seem to back that up.

[Syphorlate]

I'll look into it. THX

[jacmoe]

They are indeed pushing to the default branch (upcoming Ogre 1.8 )

[dark_sylinc]

New Instancing has been pushed into trunk since a long time by now.

What Mattan hasn't pushed yet are a few of his changes. One of his latest changes introduced a severe performance bug, and we have the fix already but hasn't been pushed yet.

I'm using Revision 2898 and that one doesn't have this performance bug.

[Arkiruthis]

dark_sylinc: Firstly, thank you for your work on the new InstanceManager, I'm working with 1.8 and looking forward to implementing it (having built the new Instancing Sample).

A quick question:
In my game, all characters use the same mesh, but there are 4 different materials depending on allegiance. Am I best to have 4 InstanceManagers and update them (remove from one, add to another) whenever a character changes allegiance (i.e., needs a different material)?

I guess setMaterial() is out of the question per instance? (which is understandable)

[Klaim]

CaptainFlaps> Check this post's picture in this same thread : http://www.ogre3d.org/forums/viewtopic. ... 86#p433386

[Arkiruthis]

Oh! Interesting, thank you Klaim. I'll keep an eye on that. (in the meantime, I think I'll stick to regular entities and see how things pan out)

[edit - oh, haha, it was the same thread. That was embarrassing... ]

[dark_sylinc]

In my game, all characters use the same mesh, but there are 4 different materials depending on allegiance. Am I best to have 4 InstanceManagers and update them (remove from one, add to another) whenever a character changes allegiance (i.e., needs a different material)?

Yes. You nailed it. At least for now that's the only way.
So prepare your to code be ready to be able to swap the InstancedEntity pointers. Note that adding->removing->adding should be a very fast operation, since the InstancedEntities are already preallocated when a new batch is created, and then they're put to sleep when removed. It will be slightly slower if you just maxed out all batches, and a new batch needs to be created.

Furthermore, I don't think your units will be changing allegiance that often (i.e. once per frame). But rather once in a few minutes in worst case scenario.

I wrote InstanceManager with RTS games in mind. As for performance considerations, watch out for fragmentation (i.e. having instances from the same batch very separate apart) which is solved by periodically calling defragmentBatches() (it's slow, so be sure to not do it often; RTS users will be forgiving if the game stalls a few seconds every 15 minutes or so, don't push it; action gamers just won't forgive you) and of course the more different units the are, the more different InstanceManagers you'll need which will start negating the gains from Instancing.

All in all is just about trying what works best in your case, and do your best to design your game to take maximum advantage of your technical strongpoints, minimizing the weaknesses.

Cheers
Dark Sylinc

[Arkiruthis]

dark_sylinc: Awesome, thanks for that! I'll also figure in a periodic defragmentation (I have a routine that does 'housecleaning' every so often and can slot it in there). Early results from the New Instancing are most promising on my setup.

[Arkiruthis]

On the latest 1.8 mercurial sources, I had to add "OgreNode.h" to the top of "OgreInstancedEntity.h" in order to build 1.8 successfully on MinGW. Don't think this happened with Visual Studio 2010 though.

Seems to be because on line 252 in _getParentNodeFullTransform(), there is a call for _getFullTransform() (part of OgreNode class) and possibly MinGW needs to see the full OgreNode.h definition to compile it inline in a header file (VS2010 perhaps does things in a different order):

As I say, I just added "OgreNode.h" and the build went fine but didn't want to submit a patch because it might just be something on my setup or something specific to MinGW builds.

[mkultra333]

I have not been following this thread, and haven't been interested in instancing before, but now it's caught my eye. But I can't really tell what it can and can't do from this thread, when you should use it and when you shouldn't, what the downside is. I've looked up "instancing" and "instancemanager" in the wiki and nothing comes up, apart from some stuff from 2006 GSOC which I don't think is relevant anymore.

From what I gather, instancing allows you to have thousands of animated meshes at the cost of just a single batch, plus the CPU overhead for each of their nodes. If this is the case, why would anyone not use instancing? In a typical game where you're being attacked by 10 monsters, wouldn't you always chose instancing?

It seems as if it's just like hardware skinning only with unlimited bones. Not really any downside. All the instanced models can have their own animations, you can even move the bones manually. So for instance, I could explode one mesh manually, spreading it's bones over the map, while the other meshes ran about fighting.

Is that correct?

[Klaim]

In a typical game where you're being attacked by 10 monsters, wouldn't you always chose instancing?

If the 10 monsters are all different in meshes and animation, you just can't use intancing. Also I background wouldn't benefit from it.

But obviously, if you want to display tons of same pair and animation objects, it's clearly only benefits.

At least that's what I understand.

[mkultra333]

When you say "same animation," does that mean all the monsters have to be using the walk animation at the same time? So you can't have one monster dancing, one monster shooting a gun, and one monster running? I noticed something in the thread saying they don't have to be playing the same animation frame, so for instance if they're walking they won't all walk in lock-step. But do they all need to be playing the same animation track?

What about if you are manually controlling bones? Can you set each instanced monster to have a different manually controlled pose?

[Klaim]

Correct me if I'm wrong but from what I understand from this thread, they have to have the same animation "set". As I didn't use this feature yet, I'm not sure what it means in code, but I one of the improvements done recently is to allow different states of the same or different animations for the same mesh/skeleton. That means the position and animation informations are together in the instantiation data and rely on a set of animations available to those instantiation data.

Confirmation from the devs is very welcome

[dermont]

On the latest 1.8 mercurial sources, I had to add "OgreNode.h" to the top of "OgreInstancedEntity.h" in order to build 1.8 successfully on MinGW. Don't think this happened with Visual Studio 2010 though.

Seems to be because on line 252 in _getParentNodeFullTransform(), there is a call for _getFullTransform() (part of OgreNode class) and possibly MinGW needs to see the full OgreNode.h definition to compile it inline in a header file (VS2010 perhaps does things in a different order):

As I say, I just added "OgreNode.h" and the build went fine but didn't want to submit a patch because it might just be something on my setup or something specific to MinGW builds.

You should submit your patch, it appears to be gcc related since the same problem occurs here on Linux.

[dark_sylinc]

Yes, documentation is lacking and should be a greater priority. Sorry

The advantages and drawbacks can be found in many papers though.
You may find usefull the code documentation which is generated from the comments in files OgreInstanceManager.h OgreInstanceBatch.h OgreInstancedEntity.h

As for your questions:
The first requisit to get a perf. boost from instancing is to be CPU overhead. If you're GPU bound there's no benefit at all.

IFrom what I gather, instancing allows you to have thousands of animated meshes at the cost of just a single batch

Having a single batch is not a cost, it's a benefit. However, this lowers chances of doing CPU scene graph culling; which if there's a lot of geometry you're not looking at with the camera and you're almost GPU bound, it will affect performance.

In a typical game where you're being attacked by 10 monsters, wouldn't you always chose instancing?

Because the 10 monsters must have the same mesh, and same material. They can have any animation you want playing at any rate.
There's one instancing technique recently made by Mattan which imposes a limit on animations and then starts repeating it in exchange for massive performance improvements. You're not forced to use that technique, but it's very handy for i.e. crowds in an arena or stadium, or random people walking in streets.

Advantage:

• Major performance improvement (tipically ranging from 0.5x to 15x)

Drawbacks:

• Generally: loss of flexibility
• The more different materials you use, the lower the benefit.
• Not possible to switch materials to an instanced entity (there are workarounds, check a few posts before this one)
• Needs repetetive objects (i.e. rocks, particles, trees, leaves, grass, units in an RTS game)
• Not suited to all kinds of scenes. Best case scenario when everything is viewed by the camera, worst case scenario when only one instance is in the camera everything else is behind it.
• The render order is per batch, not per entity, therefore getting correct transparency (draw back to front) can be tricky.
• May actually hurt performance if GPU bound

Hope this answers your questions
Cheers
Dark Sylinc

[mkultra333]

Thanks dark_sylinc, that clears up a lot. I can't check the docs since I use 1.7.3. I was just wondering if I should update or not.

It doesn't sound like instancing would be a huge benefit to my project, the graphics part is mainly bound by lighting and shadows fragment shaders, and when I am cpu bound it's due to physics rather than graphics. Still, instancing does sound very interesting, and I might do something to try and take advantage of it in the future. The idea of 1000 robots running about on screen is just too tempting, and the implementation sounds very clever.

Oh, and when I said at the "cost of one batch", I meant that as a good thing, for instance as opposed to the cost of 1000 batches.

Edit: One more question. I use manually controlled bones a lot. You mention "They can have any animation you want playing at any rate." Can I also manually control all the bones if I want?

[dark_sylinc]

Edit: One more question. I use manually controlled bones a lot. You mention "They can have any animation you want playing at any rate." Can I also manually control all the bones if I want?

Yes. If it's not working, then it's a bug and post it here we'll fix it.

[11011001]

Has anyone got this working on OS X Lion?

[manituan]

Hi. I really appreciate your work.
I´m implementing your sample in my Ogre 1.8 project and I only see one mesh, but in the triangle count appears 9 million of them. The engine doesn´t show me them.
Do you know what it´s going on? Thanks.

[jonim8or]

does the triangle count also drop to almost zero when you rotate the camera so you don't see that one mesh?
Then I guess for some reason all the meshes are drawn at the same position.

Are you using one of the meshes+materials from the demo, or your own? The demo has special materials to do the techniques with.

For me some of the techniques are working, others are not. so you might need to experimetn with the different techniques.

[11011001]

Has anyone got this working on OS X Lion?

Has anyone else failed to get this working on OS X?

[m2codeGEN]

HI dears Ogre Contributors
Let me throw my 50 cents in the total sum. I use Ogre 1.8 RC1

1) Possible memory leak SceneManager::createInstanceManager.

Code: Select all

InstanceManager* SceneManager::createInstanceManager( const String &customName, const String &meshName,  const String &groupName, InstanceManager::InstancingTechnique technique, size_t numInstancesPerBatch, uint16 flags, unsigned short subMeshIdx )
{
   // m2codeGEN warning!!! first check for name unique, then create new instance
   InstanceManager *retVal = new InstanceManager( customName, this, meshName, groupName, technique, flags, numInstancesPerBatch, subMeshIdx );
   if (mInstanceManagerMap.find(customName) != mInstanceManagerMap.end())
  {
		OGRE_EXCEPT( Exception::ERR_DUPLICATE_ITEM, 
			"InstancedManager with name '" + customName + "' already exists!", 
			"SceneManager::createInstanceManager");
   }
   
   mInstanceManagerMap[customName] = retVal;
   return retVal;
}

2) Maybe it's worth to think about how to delete the old implementation of the InstancedGeometry. SceneManager and OgreMain have a lot of code.
3) Add a method SceneManager* InstanceManager::getSceneManager() const { return mSceneManager; }
4) I suggest to change the interface/or overload the interface InstanceManager::createInstancedEntity, InstanceManager::getFreeBatch, InstanceManager::buildNewBatch and send the material as a Pointer instead name, and do not perform a search in the resource group.
5) You can also change the storage method InstanceBatchMap with map<String, InstanceBatchVec> map<MaterialPtr, InstanceBatchVec>,
map<String, BatchSettings>::type BatchSettingsMap too. For a comparison of pointers is much faster strings.
6) void InstanceBatchShader::setupVertices you can use the overloaded constructor VertexData(VertexDeclaration* dcl, VertexBufferBinding* bind) and manually suspended flag VertexData::mDeleteDclBinding, and may in other types of batches too.
7) Add the call to the method MovableObject::_notifyManager in the constructor InstanceBatch we have InstanceManager *creator and we can call InstanceManager::getSceneManager()
It seems there is support for the relative rendering InstanceBatch::makeMatrixCameraRelative3x4, at the time when the method InstanceBatchHW::_updateRenderQueue throws an exception.

Regards,
Vadim

[dark_sylinc]

Hi! Thanks for the feedback.

1) Possible memory leak SceneManager::createInstanceManager.
3) Add a method SceneManager* InstanceManager::getSceneManager() const { return mSceneManager; }

Done. Don't know why would you need getSceneManager but I'm no one to judge. It doesn't hurt.

2) Maybe it's worth to think about how to delete the old implementation of the InstancedGeometry. SceneManager and OgreMain have a lot of code.

It's within my plans, but first it should be flagged as deprecated and leave it for a couple more versions before actually deleting it. I should start another thread with a poll & discussion.

4) I suggest to change the interface/or overload the interface InstanceManager::createInstancedEntity, InstanceManager::getFreeBatch, InstanceManager::buildNewBatch and send the material as a Pointer instead name, and do not perform a search in the resource group.
5) You can also change the storage method InstanceBatchMap with map<String, InstanceBatchVec> map<MaterialPtr, InstanceBatchVec>,
map<String, BatchSettings>::type BatchSettingsMap too. For a comparison of pointers is much faster strings.

You're right it would more efficient. Definately go with the overload, not the interface change option, since the whole idea is about the caller specifying the material he wants, rather than dealing with pointers. It's more "user friendly" (the user being the developer)
It's quite a significant change considering we're closening towards stable 1.8 release, so any changes regarding this should go to 1.9 default branch. Furthermore:

• The performance impact isn't that big. New batches aren't created all the time, in fact it's possible there will be less than 5 usually. Anything more means you're probably negating any benefit from using instancing.
• The actual places where look-ups are performed are in buildNewBatch & setSetting; due to the rarity in which they get called and the low number of different materials, the bottleneck is most likely somewhere else (ie. setting up new vertex buffers). Again, if buildNewBatch is called too often then you're doing something wrong or instancing isn't for you.
• I'm really busy this month, the next one, and in February I'm foreseeing to be in crunch mode. So don't expect to see these changes happening until March at least.

Because of the reasons above, it will be a low priority for me. If someone wants to submit a patch (as long as there are two overloads like in most Ogre code using strings & pointers) then go ahead.

6) void InstanceBatchShader::setupVertices you can use the overloaded constructor VertexData(VertexDeclaration* dcl, VertexBufferBinding* bind) and manually suspended flag VertexData::mDeleteDclBinding, and may in other types of batches too.
7) Add the call to the method MovableObject::_notifyManager in the constructor InstanceBatch we have InstanceManager *creator and we can call InstanceManager::getSceneManager()

Could you elaborate on that? I didn't understand it.

It seems there is support for the relative rendering InstanceBatch::makeMatrixCameraRelative3x4, at the time when the method InstanceBatchHW::_updateRenderQueue throws an exception.

There's a technical limitation in which camera relative rendering can't be supported when using InstanceBatchHW and setStaticAndUpdate( true ) was called. If you want camera relative rendering, use a different instancing technique or set static batches to false (the default value)

Cheers & Thanks for the feedback
Dark Sylinc

[m2codeGEN]

Thanks for the quick reply.
I planned upgrade PagedGeometry to use instancing without multi-threading. Therefore, the performance in render thread is expensive.

m2codeGEN wrote:
6) void InstanceBatchShader::setupVertices you can use the overloaded constructor VertexData(VertexDeclaration* dcl, VertexBufferBinding* bind) and manually suspended flag VertexData::mDeleteDclBinding, and may in other types of batches too.

Could you elaborate on that? I didn't understand it.

Lets see some code...

Code: Select all

mRenderOperation.vertexData = OGRE_NEW VertexData();
mRemoveOwnVertexData = true; //Raise flag to remove our own vertex data in the end (not always needed)

VertexData *thisVertexData = mRenderOperation.vertexData;
VertexData *baseVertexData = baseSubMesh->vertexData;

thisVertexData->vertexStart = 0;
thisVertexData->vertexCount = baseVertexData->vertexCount * mInstancesPerBatch;

HardwareBufferManager::getSingleton().destroyVertexDeclaration( thisVertexData->vertexDeclaration );
thisVertexData->vertexDeclaration = baseVertexData->vertexDeclaration->clone();

You destroy vertex declaration that was just created. mRenderOperation.vertexData = OGRE_NEW VertexData(); .... HardwareBufferManager::getSingleton().destroyVertexDeclaration( thisVertexData->vertexDeclaration );
Instead of this you can use the overloaded constructor VertexData(VertexDeclaration* dcl, VertexBufferBinding* bind) and manually suspended flag VertexData::mDeleteDclBinding.

Regards,
Vadim