Performance Problem

mark01 · Post by **mark01** » Sat Sep 08, 2007 1:55 am

Hi,

Im a total Newbie to the Irrlicht Engine and also not to much into programming, so please excuse my stupid questions.
Im doing a project for my highschool in the moment, and therefore try to model the inside of the whole highschoolbuilding.
Ive decided to use Irrlicht for the presentation but now run into some big performence problems.

After finishing about a quater of the whole project and exporting it to irrlicht I got a Framerate of about 1-3 FPS

I found that enabeling Octrees is also not possible because if I add a OctreeSceneNode instead of a AnimatedMeshSceneNode the application hang on loading without getting any error message.
Enabeling FrustumCulling (node->setAutomaticCulling(scene::EAC_BOX);) also has no Effect.

The whole scene has about 500 Entities (this means really many polys and many different materials) but I cant believe that this kills the framerate like this.
What do you think is the reason for this horrible Framerate and what are my possibilitys for getting a better rate.

randomMesh · Post by **randomMesh** » Sat Sep 08, 2007 2:04 am

I really recommend to get the OctreeSceneNode working.

And irr::scene::EAC_BOX is enabled per default. Try irr::scene::EAC_FRUSTUM_BOX instead.

TomiZ · Post by **TomiZ** » Sat Sep 08, 2007 7:09 am

Try to replace quake map in tutorial 2 with your mesh and check FPS. You will see if it's problem in you code.

mark01 · Post by **mark01** » Sat Sep 08, 2007 12:13 pm

Try to replace quake map in tutorial 2 with your mesh and check FPS. You will see if it's problem in you code.

Yes, ive tried this allready and have the same problems there. Building the Octree really takes to long.
It took 1732010 ms to build a scene with 595078 polys. Then I get a Performance of about 30 FPS in the most areas of the scene but in some areas, e.g. at the stairs, it slows down to 1-3 FPS again.
Is there another way to improove the overall framerate?

hybrid · Post by **hybrid** » Sat Sep 08, 2007 8:28 pm

Separate the mesh into several scene nodes. That would reduce the number automatically via frustum culling etc. Maybe the octree does not cope well with this number of polys.
You should also check the number of mesh buffers. If the mesh buffers are only sparse, i.e. only some dozen vertices per buffer, frame reate will drop significantly.

mark01 · Post by **mark01** » Sun Sep 09, 2007 1:12 pm

What do you mean by seperating the mesh into several scene nodes?
Should I devide and export the scene in smaller pieces and load each in its own SceneNode or how will this be done?

Is there perhaps some example code for checking and arranging mesh buffers?

What about LOD? Im afraid there some objects in the mesh with unnecessary much polys. Is it somehow possible to reduce the polys afterwards.

thanks for the answers so far.

bitplane · Post by **bitplane** » Mon Sep 10, 2007 7:39 am

There's currently no LOD in Irrlicht meshes or mesh buffers, so you'll need to reduce the size of them manually before exporting.

1700 seconds is a very long time indeed. Like Hybrid said, it sounds like you have too many mesh buffers.
what does this show you?:

Code: Select all

IMesh* m = smgr->getMesh("yourmesh")->getMesh(0);
IMeshBuffer* b = 0; 
for (u32 i=0; i < m->getMeshBufferCount(); ++i)
{
    b = m->getMeshBuffer(i);
    printf("buffer %d: vertices= %d, indices = %d\n", i, b->getVertexCount(), b->getIndexCount());
}

Are you using an old version of Irrlicht? Irrlicht 1.3.1 contained a speed fix for octtree generation. Also, it would be cool if you could share your mesh for testing

kimgar · Post by **kimgar** » Mon Sep 10, 2007 12:47 pm

i'm also struggling with this. the fps is actually ok, but the enormous loadtimes are really not acceptable. i cannot lower the polycount anymore either, so some solution to speed up loading would be tremendously appreciated! at first i thought it was direct3d related as openGL loaded a LOT faster, that problem was fixed by installing the latest dircetX sdk - now they are both equally slow

bitplane, these are the results from your code:

Code: Select all

Meshbuffers Num : 280
Vertices Total : 1 087 334
Indices Total : 2 766 441
MESH LOADTIME : 88 742

i tried loading the mesh in irrlicht meshViewer, to check if if some of my code were messed up, but i got about the same results
...i guess one can argue that the loadtimes are to be expected at such polycounts, but i tried loading it in the meshviewer from the directX sdk and it loaded in 14 seconds!

what is it that makes irrlicht load at 88 secs. while directX meshviewer loads in 14?

i did notice these reports from the meshviewer, i have no clue if it can be related to irrlicht's long loadtimes

Code: Select all

Tangents and Binormals cannot be generated without a 2-element or greater texture coordinate at TEXCOORD0. Please use DXOps to UV-Atlas your mesh.
Binormals do not exist on mesh.  Attempting to calculate.
Tangents do not exist on mesh.  Attempting to calculate.

could whatever irrlicht is doing while/after loading be saved somehow to go around it the next time?

any input is appreciated, i am all out of ideas...

bitplane · Post by **bitplane** » Mon Sep 10, 2007 2:36 pm

this slow x loading problem is due to the binary loading being patched on rather than built in. the loader uses strings to identify the sections even in binary mode, so using binary doesn't give the speed advantage that it should.
for the moment try exporting your mesh in 3DS format (a static binary format with lots of exporters).
if you're also generating an oct-tree node plus oct-tree triangle selector, you may want to search out CuteAlien's patch for using COctTreeSceneNode's oct-tree in the triangle selector.

Also, does your mesh actually use 280 different materials? That sounds a bit excessive to me, even for a mesh with 1m triangles.

kimgar · Post by **kimgar** » Mon Sep 10, 2007 4:25 pm

ah, great stuff bitplane, thanks
i have not specified any octtree, just loading straight to IMesh...
about the binary, that doesn't mean that text mode should load any faster?
i did try text, and gained about a second or so - not very much to speak of...

and about the 280 materials, i am pretty new to this, i have a huge mesh with a multi/sub-object material containing 10 materials assigned to it. i divided the mesh in smaller parts to get below the 65.000 face limit...

3ds loads lighting fast! (50ms compared to 14000ms!), but i remember now why i didn't use that format, the mesh gets all screwed up:

i've tried normal modifier and no smoothing groups in 3dsmax and recalculateNormals in irrlicht but the mesh is still screwed, any idea what's causing this? if i could actually fix this 3ds i guess my loading problems are over

hybrid · Post by **hybrid** » Mon Sep 10, 2007 8:30 pm

I guess that you have too many indices in a mesh buffer (hmm, didn't 3ds autosplit because it does not support smoothing groups?). Anyway, you could share those meshes in order to get them fixed. The dev team already hosts a large number of test meshes which are used to test drive new loaders and optimizations.

bitplane · Post by **bitplane** » Tue Sep 11, 2007 3:03 am

hmm it looks like I was wrong, swapping the string access stuff out in the x loader didn't change much - they're not used as much as I thought.
I really should pay attention more. Hybrid just fixed the x speed bug, and mentioned it on IRC earlier - x loading times are now decreased tenfold

kimgar · Post by **kimgar** » Tue Sep 11, 2007 6:48 am

x loading times are now decreased tenfold

wooohoo! great work hybrid! salute!

it's for moments like this i chose not to go for an expensive commercial engine

only problem for me, is that i am on blitzMax with gMan's wrappers....anyways, your work is great nonetheless

i really appreciate all the help that has been given me, thanks! the problem 3ds and max file can be picked up here:
http://www.kimgar.com/_files/9230.vega.rar
it's a nasty mesh though, an old conversion from proE - the best i can manage to get from the client...but X does a good job with the mesh, i am a bit more worried with 3ds though, because of no smoothing and some strange crash happening when instancing mesh 3 times before trying to load another 3ds...

also i looked into my 280 materials

it does sound a *little* inefficient, but how to avoid it? when a mesh is split two sets of materials are created, and meshes without materials will not load in irrlicht...hmmm...hmm

hybrid · Post by **hybrid** » Tue Sep 11, 2007 7:18 am

Ok, this 3ds file also works with latest Irrlicht, but probably also with earlier versions. Seems that you might need to upgrade somehow...
BTW: What is this? Seems like some crane or platform?

kimgar · Post by **kimgar** » Tue Sep 11, 2007 8:24 am

what?

the mesh is fine at your side!?
oh no, i really did not want to hear that

and you used the 3ds straight from the rar? ouch, how to debug this one...

upgrade, hmm, i must admit that all the drivers, wrappers, physX and various releases are getting a bit out of hand, but as far as i can tell i am up to date.
here's the compile log from blitzMax:

Code: Select all

Building test01
Compiling:PhysX_func.bmx
flat assembler  version 1.66
3 passes, 134958 bytes.
Compiling:test01.bmx
flat assembler  version 1.66
4 passes, 52133 bytes.
Linking:test01.exe
Executing:test01.exe
Irrlicht Engine version 1.3.1
Professional Service Pack 2 (Build 3790)
Using renderer: Direct3D 9.0
NVIDIA Quadro FX 3500 nv4_disp.dll 6.14.11.6250

ps. the model is the second half of a subsea protection structure