New InstanceManager: Instancing done the right way

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
Post Reply
User avatar
sparkprime
Ogre Magi
Posts: 1137
Joined: Mon May 07, 2007 3:43 am
Location: Ossining, New York
x 13
Contact:

Re: New InstanceManager: Instancing done the right way

Post by sparkprime »

I think if I have a bucket for each size of freeness, and have a list within that bucket of free areas that is ordered from left to right along the buffer, then just picking the first thing of the appropriate size might be OK.
User avatar
volca
Gnome
Posts: 393
Joined: Thu Dec 08, 2005 9:57 pm
x 1
Contact:

Re: New InstanceManager: Instancing done the right way

Post by volca »

Yep, and should be faster than linear search through a big list too.

I see - you don't use an index buffer? You could skip portions of VBuf by using index buffer, dunno what the performance would be then - practically any change to VBuf would mean partial or full IBuf rebuild - I can afford that since I really generally display only a small portion of the VBO which is quite static. Anyway rebuilding IBuf every frame (to show/hide certain meshes) may be a tactic of questionable effectivity, although the other option would be to build VBuf every frame, which means more data transfers - vertex seems always larger than a single 16/32 bit index. I guess this depends on the usage...

Do I understand it right your target is a sort of a "dynamic static geometry"?

Oh - and sorry for the offtopic! :oops:
Image
User avatar
sparkprime
Ogre Magi
Posts: 1137
Joined: Mon May 07, 2007 3:43 am
Location: Ossining, New York
x 13
Contact:

Re: New InstanceManager: Instancing done the right way

Post by sparkprime »

Yes it's dynamic static :) The first cause of dynamicness is streaming in and out of vegetation, while keeping everything batched together. The second cause is for things like skidmarks and decals were you lay down quads from time to time. In both cases, there are usually not updates every frame, but every... 10 frames maybe. However there are some extreme cases of updates every frame. I try to minimise the size of the upload I think too. In fact I think I do an upload for each contiguous set of triangles.

It is also possible to move things around and update texture coords etc but I don't use that except for a kind of stippled LOD fade.

The index buffer: It is obviously wasteful to repeat vertexes but the waste is quite small as you point out. Typically for vegetation you have a lot of quads that do not share vertexes anyway. For skidmarks I will be wasting a few. Using an index buffer I think should not present a performance *problem* but it is more complex to keep the buffers maintained. One obvious approach is to share vertexes only between a single instance, i.e. to use the index/vertex buffer of the original mesh. Fragmentation in the vertex buffer is of course perfectly OK when using an index buffer, since unused vertexes are simply not referenced by the index buffer (there may be some cache effects actually, I have no idea). But fragmentation of the index buffer itself will obviously occur and give the same kinds of problem, i.e. drawing extra (zero area) triangles for the places in the index buffer where the indexes are all zero due to being unused. I think also maintaining an index buffer without fragmentation is a problem that is solved by the same techniques that we have discussed for maintaining a fragmentation-free vertex buffer. So generally I think this is possible, I just haven't done it. I would definitely use a triangle list though.
LBDude
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: New InstanceManager: Instancing done the right way

Post by LBDude »

Dude you kick so much ass! I'm going to use this for my project!
My blog here.
Game twitter here
LBDude
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: New InstanceManager: Instancing done the right way

Post by LBDude »

How do you apply this patch? I first tried patching 1.7.1 stable. That didn't work. Then tried patch latest off Mercurial. This didn't work. Then I tried going to revision 2301 using revert in Mercurial. Did not work. Can you provide some hints?

Update:

I tried using the hg file (I'm new to mercurial) with hg pull hgfile. Then followed by hg merge. Which did something. I'm getting compile errors now. I'm going to try reverting to revision 2301.

Update #2:

Hey I got it to build (well still waiting on it. But libOgreMain got build.) Problem was probably because I'm using Linux G++ 4.4 and you are using something else. Had to add some headers and a small fix with constants and friend class key. That's about it. THanks.
My blog here.
Game twitter here
LBDude
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: New InstanceManager: Instancing done the right way

Post by LBDude »

I'm not sure whether it's you or Ogre latest, but setting the any compositor (actually I trid Bloom and some other. So not sure if it crashes on all of them or what)

Code: Select all

Texture: spot_shadow_fade.png: Loading 1 faces(PF_R8G8B8,128x128x1) with 5 generated mipmaps from Image. Internal format is PF_X8R8G8B8,128x128x1.
SampleBrowser: /home/beyzend/projects/ogre_merc/ogre/OgreMain/include/OgreSharedPtr.h:160: T* Ogre::SharedPtr<T>::operator->() const [with T = Ogre::Material]: Assertion `pRep' failed.
Aborted
It crashes in both my own code and the Sample compositor code.

Should I submit a bug report or do you think this is something to do with what I did in order to compile?
My blog here.
Game twitter here
LBDude
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: New InstanceManager: Instancing done the right way

Post by LBDude »

Any idea why

Code: Select all

WARNING: material MyInstanceMgr/InstanceBatch_0/VTFMaterial has no supportable Techniques and will be blank. Explanation: 
Pass 0: Vertex program VTFInstancing_vs cannot be used - not supported.
Just a guess maybe I need to have the latest cg toolkit installed? I only have what's in Ubuntu 10.04's repo. Although when I look at the log, the VTFInstancing material parses, while the shader instancing cg shader err out.

I have an ATI 4870x2. I'm pretty sure VTF works because I have another project which also uses VTF. THanks. Was trying to go for a quick win tonight to test this. Disappointed that I didn't get the quick win lol.

Update:

Nevermind about cg. I have 2.1 which should support dx10. That's strange. Tomorrow I may try this on windows.
My blog here.
Game twitter here
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: New InstanceManager: Instancing done the right way

Post by dark_sylinc »

LBDude wrote:Any idea why

Code: Select all

WARNING: material MyInstanceMgr/InstanceBatch_0/VTFMaterial has no supportable Techniques and will be blank. Explanation: 
Pass 0: Vertex program VTFInstancing_vs cannot be used - not supported.
I have an ATI 4870x2. I'm pretty sure VTF works because I have another project which also uses VTF. THanks. Was trying to go for a quick win tonight to test this. Disappointed that I didn't get the quick win lol.
Yeah: You're in Linux and with an ATI.
The Cg code uses the vp40 and fp40 profile to work on OpenGL, which is NVIDIA specific.
AFAIK, the only way Cg supports working with advanced OGL shaders (i.e. VTF) with ATI is by using GLSL, which OGRE doesn't support (using GLSL through Cg). If someone says the opposite I would be glad to be wrong :)

The solution is to write a GLSL shader which is in my TODO list.
In windows using Direct3D9 plugin should work ok.
LBDude wrote:I'm not sure whether it's you or Ogre latest, but setting the any compositor (actually I trid Bloom and some other. So not sure if it crashes on all of them or what)

Code: Select all

Texture: spot_shadow_fade.png: Loading 1 faces(PF_R8G8B8,128x128x1) with 5 generated mipmaps from Image. Internal format is PF_X8R8G8B8,128x128x1.
SampleBrowser: /home/beyzend/projects/ogre_merc/ogre/OgreMain/include/OgreSharedPtr.h:160: T* Ogre::SharedPtr<T>::operator->() const [with T = Ogre::Material]: Assertion `pRep' failed.
Aborted
Should I submit a bug report or do you think this is something to do with what I did in order to compile?
That doesn't look like a bug related to my submitted code.
Is there any reason that makes you think/suspect so?
LBDude wrote:How do you apply this patch? I first tried patching 1.7.1 stable.
Had to add some headers and a small fix with constants and friend class key. That's about it. THanks.
I'm interested in hearing your little changes to make it compile with GCC :) Thanks in advance.
Edit: Nevermind, fixed them for myself. I guess you can blame precompiled headers for this. Also strange MSVC didn't spot a const-correctness compiler error.

Cheers
Dark Sylinc
LBDude
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: New InstanceManager: Instancing done the right way

Post by LBDude »

dark_sylinc wrote:
LBDude wrote:Any idea why

Code: Select all

WARNING: material MyInstanceMgr/InstanceBatch_0/VTFMaterial has no supportable Techniques and will be blank. Explanation: 
Pass 0: Vertex program VTFInstancing_vs cannot be used - not supported.
I have an ATI 4870x2. I'm pretty sure VTF works because I have another project which also uses VTF. THanks. Was trying to go for a quick win tonight to test this. Disappointed that I didn't get the quick win lol.
Yeah: You're in Linux and with an ATI.
The Cg code uses the vp40 and fp40 profile to work on OpenGL, which is NVIDIA specific.
AFAIK, the only way Cg supports working with advanced OGL shaders (i.e. VTF) with ATI is by using GLSL, which OGRE doesn't support (using GLSL through Cg). If someone says the opposite I would be glad to be wrong :)

The solution is to write a GLSL shader which is in my TODO list.
In windows using Direct3D9 plugin should work ok.
LBDude wrote:I'm not sure whether it's you or Ogre latest, but setting the any compositor (actually I trid Bloom and some other. So not sure if it crashes on all of them or what)

Code: Select all

Texture: spot_shadow_fade.png: Loading 1 faces(PF_R8G8B8,128x128x1) with 5 generated mipmaps from Image. Internal format is PF_X8R8G8B8,128x128x1.
SampleBrowser: /home/beyzend/projects/ogre_merc/ogre/OgreMain/include/OgreSharedPtr.h:160: T* Ogre::SharedPtr<T>::operator->() const [with T = Ogre::Material]: Assertion `pRep' failed.
Aborted
Should I submit a bug report or do you think this is something to do with what I did in order to compile?
That doesn't look like a bug related to my submitted code.
Is there any reason that makes you think/suspect so?
LBDude wrote:How do you apply this patch? I first tried patching 1.7.1 stable.
Had to add some headers and a small fix with constants and friend class key. That's about it. THanks.
I'm interested in hearing your little changes to make it compile with GCC :) Thanks in advance.
Edit: Nevermind, fixed them for myself. I guess you can blame precompiled headers for this. Also strange MSVC didn't spot a const-correctness compiler error.

Cheers
Dark Sylinc
No I do not suspect it's anything with your code. I simply was thinking maybe it has to do with what I changed (as one of those automatic responses without thinking), but I don't think that is the case because I didn't' change much. I will try reverting back to before the patch and see if that makes the problem go away.

As for the cg problem, I was thinking of trying to download the latest Cg toolkit which has a profile called glslv and glslf. Which I assume means it will output to GLSL (I don't really know how Cg works, just assuming here.) I'm not sure though whether Ogre will automatically detect this. I was going through the logs and sure enough, the output didn't say I support vp40 and friends. I will download Cg toolkit anyway, and hopefully I will get a quick win :). I mean I have my code all setup and ready to go lol :). And if this doesn't work then I will try converting your Cg code to GLSL.
My blog here.
Game twitter here
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 58
Contact:

Re: New InstanceManager: Instancing done the right way

Post by CABAListic »

Don't bother. Months ago I tried to incorporate the glsl(v/f) profiles into Ogre's Cg manager, and I even managed to get them "working" which required some semi-hacks. The problem, however, is that the GLSL code which Cg produces is incompatible with the way that Ogre sets up the shader variables. A particular problem are matrices, and I found no way to make this work. So the only thing I got was visual garbage.
The hlsl(f/v) profiles worked fine, though :roll: Of course, they aren't really useful. Go figure.
User avatar
sparkprime
Ogre Magi
Posts: 1137
Joined: Mon May 07, 2007 3:43 am
Location: Ossining, New York
x 13
Contact:

Re: New InstanceManager: Instancing done the right way

Post by sparkprime »

Yes CG is pretty much useless for non-nvidia cards on Linux as a result of this. There is arbfp1 and friends but they are far too primitive for modern shaders.

One option I considered is to write code in glsl and then use CG to compile the glsl to ps_3_0 and friends on d3d9, just using the untransformed glsl in gl. However I never got around to it, currently ATI cards only work with d3d9.
LBDude
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: New InstanceManager: Instancing done the right way

Post by LBDude »

I did a quick-n-dirty conversion of the cg shaders to glsl. I now see the robots, but they aren't being translated (stuck at origin.) I'm guessing it may be due to glsl requiring normalized texture coordinates. I'm not sure. I gtg for now will try to figure it out later.
My blog here.
Game twitter here
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: New InstanceManager: Instancing done the right way

Post by dark_sylinc »

Getting all the meshes centered at the origin can also mean the vertex shader isn't working (i.e. compiling errors)

By the way, I just discovered a major bug in the batches. The batches are supposed to share geometry, but due to a bug introduced somewhere, they weren't!
Memory usage was skyrocketing, plus leaving memory leaks.
But here's the most important: My ATI HD Radeon now performs at steady 38fps in VTF when looking at 10.000 meshes! (vs 10fps without instancing and 20fps using ShaderBased)
The NVIDIA keeps throwing same results (VTF ~45, ShaderBased 18fps, No instancing 7fps)

I guess I was either messing ATI drivers who couldn't handle so much memory at the same time or I was exhausting memory bandwidth (The ATI has 1GB VRAM vs my NVIDIA's 512MB, so memory ammount exhaustion was not the cause).

I've also implemented a defragmentation function :)

I'll upload the updated tests and patches later.
I'm happy to see VTF is reaching my initial expectations :D

Cheers
Dark Sylinc
LBDude
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: New InstanceManager: Instancing done the right way

Post by LBDude »

Well, the shaders compiled, at least that's what it said in the logs. The only thing I'm doing different in GLSL is instead of a matrix3x4 I'm using a mat4 (which is 4x4) because then the shader wouldn't compile with mat3x4. I don't think it makes a difference but who knows ( m x n * n x 1). Another funny thing is that even though they are stuck at origin, they do seem to rotate. Although it's rotating in place, but still rotating.

Anyway, I GOT IT WORKING on my Nvidia box (Nvidia 8800gt; AMD 64 3800+ single core; Ubuntu 10.04) using Cg. Still getting the same thing using the GLSL shaders though. As for performance, I did a little comparison (on my Nvidia box) running my OpenCL crowd code (it's using the CPU OpenCL devices right now) with the old shader instancing method (InstancedGeometry*) and your code. Your code is maybe about 10% faster? I didn't really do a hardcore scientific test hehe. My metric was looking at the console at the FPS output :P.

My Nvidia box (single core):
Number of entities: 1600.
Old: 10fps.
Your method: 13-14fps.

Number of entities: 560.
Old: 20-30fps.
Your method: 30-40fps.

My Quad-core box (ATI 4870x2):

Number of entities: 1600

Old: 20 fps.
Your method: NA

Number of entities: 560

Old: 50fps.
Your method: NA.

....

Okay, I've yet to try this on Windows. I expect to add about 20-30fps to the results from above because I usually get that, when running stuff in Windows.

Also, perhaps another bottleneck is the scene graph and animation update code. When running my crowd code with the old InstancedGeometry without animation (i.e. batching size of 80) I get massive FPS even when running 6000+ entities.

Laters. Let me know if I can help you with anything (I will try at least). This is some great stuff!
My blog here.
Game twitter here
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: New InstanceManager: Instancing done the right way

Post by dark_sylinc »

Was that with VTF? What is the number of instances per batch?
(It's specified at mSceneMgr->createInstanceManager(), last parameter)

I've uploaded a more recent patch + a the updated test.
It's the same thing, but with the bug fix that caused ATI cards to slowdown with VTF.
LBDude
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: New InstanceManager: Instancing done the right way

Post by LBDude »

yeah, I'm using VTF. Batches per instances I set it at 220, same as in the test. All the tests I've done is with your new InstanceManager with batch per instance set at 220.

I will get it working under Windows and tell you how that goes.

Oh forgot, another reason with the high FPS when running the "old" shader instancing thing may have something to do with me using Barrel.mesh. This mesh has a much smaller polygon count than Robot.mesh. Not sure though.
My blog here.
Game twitter here
User avatar
boyamer
Orc
Posts: 459
Joined: Sat Jan 24, 2009 11:16 am
Location: Italy
x 6

Re: New InstanceManager: Instancing done the right way

Post by boyamer »

Would be nice if you split this things from Ogre InstancedGeometry and maybe create a demo and showcase it,
just an idea. :)
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: New InstanceManager: Instancing done the right way

Post by dark_sylinc »

Phewww!!!!!!
Worked like crazy on this:
  • GLSL shaders
  • Defragmenting capabailities. When you've trashed too many instanced entities, InstanceManager::defragmentBatches( bool ) makes magic for you. If the boolean is true, it will also arrenge for optimal CPU culling performance given the current position of all instanced entities in scene.
  • Flags to achieve optimum instances per batch count, such as IM_16BIT (ensures batch count * vertex < 65535) and IM_VTFBESTFIT (reduces wasted unused pixels in the vertex texture)
The flags often will limit the batch count, so you'll have to measure and profile whether you want to streess the GPU or the CPU, and hence the usage of the flags will be turned on and off.

Also you can have finer control of the instance count using InstanceManager::getMaxOrBestNumInstancesPerBatch which allows you to know which are the max values (or recommended if you use flags) instead of guessing arbitrarily high numbers or hardcoding them.

ShaderBased techniques give significant less performance using GLSL than using Cg (Direc3D or OpenGL).
I got the same result in both my NVIDIA and my ATI cards (though, on the ATI I can't try OGL Cg of course, but DX Cg works)

The test app was updated to reflect these changes. I guess it should run on ATI cards using Ubuntu now.
Also VTF performance was improved when nothing in the batch has changed, by avoiding updates to the vertex texture.

Ok I'm done with the interface (though only using SubMesh(0) out of the whole mesh is the last major missing feature) it's time to do 2 samples for the sample browser: one technical and tutorial like similar to the one we have now, and a mind blowing one in a more real world scenario.

Hardware Instancing will come in the future I guess.

Cheers
Enjoy the update
Dark Sylinc

PS: By the way, each time I touch GLSL, the more I hate it. I guess it's a necessary evil. Version 1.5 looks decent though, but needs OGL 3.x.....
LBDude
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: New InstanceManager: Instancing done the right way

Post by LBDude »

cool. I've downloaded your latest patch and got it built on my Windows Vista box. When I'm running your test, I get around 70+fps for 10,000 entities (this is kick-ass). When I run it with my crowd code I get 16fps for about 1600x2 entities. Without doing a full profiling, I tried to see where there could be some bottlenecks. What I found was that if I disable "rendering" in my update loop, where I iterate through each scene node to update them with new positions and orientation, I can get 120fps with 1600x2 entities rendered. If I enable this update, my frame rates drop down to as before, around 16fps. So the question why is it taking so long updating these entities. My Crowd update code averages to about 0.0007ms. So the bottleneck is probably due to iterating through the scene nodes and updating them. In the previous InstancedGeometry class, I didn't have attach them to the scene nodes, nor did I have to iterate through the scene nodes. Perhaps some of the frame rates I'm seeing is because of what is happening when updating the scene nodes. I'm not sure what you are doing with the culling and stuff. I will take a look at it :). This is awesome work. I can't wait until this thing is finished!

P.S: I will try your GLSL code in Ubuntu here in a bit.

Image
My blog here.
Game twitter here
LBDude
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: New InstanceManager: Instancing done the right way

Post by LBDude »

Maybe I'm using it wrong. If I have N number of entities, I'm supposed to create N number of InstancedEntities and attach them to N number of scene nodes?
My blog here.
Game twitter here
LBDude
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: New InstanceManager: Instancing done the right way

Post by LBDude »

I also got it working on under Ubuntu using GLSL. My GLSL script was getting the texture coords from gl_MultiTexture* and vertex from gl_Vertex. Plus I was doing a matrix column vector multiply instead of row vector matrix multiply, which wasn't what I expected. I was assuming in the usual sense of a column vector / right-handed system transformation...
My blog here.
Game twitter here
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: New InstanceManager: Instancing done the right way

Post by dark_sylinc »

LBDude wrote:Maybe I'm using it wrong. If I have N number of entities, I'm supposed to create N number of InstancedEntities and attach them to N number of scene nodes?
Yes that's the intended usage.

If you repeat the same mesh, you should have a single InstanceManager, N InstanceEntities, and N SceneNodes

Also see what myInstanceManager->getMaxOrBestNumInstancesPerBatch( IM_16BIT ); returns and use those numbers, so you have the highest possible instance per batch count for 16 bit indices (or you use your own number which is very high, if you find out the GPU is idle and has spare power).

Ultimately, you will have to profile your code I'm afraid.
Otherwise we're going blind.
LBDude
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: New InstanceManager: Instancing done the right way

Post by LBDude »

Are the sources in InstanceTest/src up to date? I noticed that in there you have 300, followed by IM_USEALL.

Code: Select all

		/*InstanceManager *instanceManager = mSceneMgr->createInstanceManager( "MyInstanceMgr", "robot.mesh", ResourceGroupManager::AUTODETECT_RESOURCE_GROUP_NAME, Ogre::InstanceManager::TextureVTF, 300, IM_USEALL );
		//InstanceManager *instanceManager = mSceneMgr->createInstanceManager( "MyInstanceMgr", "robot.mesh", ResourceGroupManager::AUTODETECT_RESOURCE_GROUP_NAME, Ogre::InstanceManager::ShaderBased, 80, IM_USEALL );
But then I look at the constructor to InstancManager it says this instead:

Code: Select all

InstanceManager( const String &customName, SceneManager *sceneManager,
						 const String &meshName, const String &groupName,
						 InstancingTechnique instancingTechnique, uint16 instancingFlags,
						 size_t instancesPerBatch );
It seems the instancingflags and instance per batch are flipped. That's what I went by inside my own code when creating the InstanceManager. So that means my InstancePerBatch is set at 3 (which is the value of IM_USEALL).

My code

Code: Select all

 _instMgr = _scnMgr->createInstanceManager("MyInstanceMgr", "robot.mesh", ResourceGroupManager::AUTODETECT_RESOURCE_GROUP_NAME,
      Ogre::InstanceManager::TextureVTF, 300, IM_USEALL);
When I flip them around the robots are stuck at the origin. I still haven't gotten the recommended function to work. Also, I noticed that in your test that the robot at origin is rotated incorrectly. Basically he is facing down.
My blog here.
Game twitter here
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: New InstanceManager: Instancing done the right way

Post by dark_sylinc »

Use the SceneManager to create the InstanceManager, don't do it manually. You shouldn't be using InstanceManager's constructor.
The constructor and scene managers' are flipped by mistake. But they behaver properly.
Otherwise batch counts in Shader Technique and VTF Technique couldn't be so low, since it would be 10000/3 for both.

In the test one of the robots (the last created) is facing down because it's testing death animation at second 0.451
This helps me spot bugs when I break skeletal animation in any of the instancing techniques.
LBDude
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: New InstanceManager: Instancing done the right way

Post by LBDude »

oh yeah my mistake. I'm not using the actual constructor. I'm using the scene manager but was looking at the InstancedManager constructor instead. Also, I can't get the recommended thing to work.

When I use the recommend function:

Code: Select all

size_t recommendedBatchSize = _instMgr->getMaxOrBestNumInstancesPerBatch("BlueVTF", 80, IM_USEALL);


I get:

Code: Select all

OgreInstanceBatch.cpp:54: Ogre::InstanceBatch::InstanceBatch(Ogre::MeshPtr&, const Ogre::MaterialPtr&, size_t, const std::vector<short unsigned int, Ogre::STLAllocator<short unsigned int, Ogre::CategorisedAllocPolicy<(Ogre::MemoryCategory)0u> > >*, const Ogre::String&): Assertion `!(meshReference->hasSkeleton() && !indexToBoneMap)' failed.
Since I can't get the recommended size, I'm tried all the IM settings with instance per batch set at 300, and I'm still getting low FPS. Have you tried updating your entities in the Test? Looping through the scene nodes and updating them. I remember reading about someone profiling their code and one of major bottlenecks was the scene node update.

I will try messing around with your demo to see what updating scene nodes look like there.
My blog here.
Game twitter here
Post Reply