Low performans after loading big mesh

[lenchis001]

Hello everyone. I beginner programmer in Irrlicht. I write small code for loading static mesh from 3ds file. (I use function "addOctreeSceneNode") It works, but after loading big models (more 10-20 Mb) FPS become very low (8-11 fps, before loading 350 - 400 FPS). What need for high performance? Thank you. (Sorry for my bad english.)

[Mel]

20 MB looks like a large mesh indeed. For once, it isn't your fault completely. Irrlicht's octrees don't seem to be fully optimized (yet...) to make use of the hardware mapping hints, so far, i think it only optimizes the lightmapped meshes, so, besides the usual recomendations about batching and not using the octrees, you can store whole meshes in the video card via "SetHardwareMappingHint" from the IMesh interface, try that and use a regular IMeshSceneNode instead of the octrees, and see if things improve.

On the other hand, using an octree for a triangle selector is a really REALLY good idea. And it is possible to create an octree triangle selector while you still have a static mesh, so try these things and see if they help you.

[lenchis001]

Hello. Okay, i try. Thank you very much!

[CuteAlien]

If you load the model in the meshviewer you can see how many polygons it has (should show in title-bar). Do that as a first check so we have some idea about how large it is (polygons isn't the only value that matters, but gives some idea).

[Mel]

I have checked the octree node creator and seems it only maps to hardware the lightmapped meshes, i haven't checked it thoroughly though, so i can be very well mistaken, but seems that way. That would optimize the Q3 levels, but levels created on other vertex formats wouldn't benefit of octrees to accelerate their rendering at all.

[CuteAlien]

Yeah, octree rendering only improves speed in rather specific cases (when all the time lot's of it is not visible).
What should improve speed is marking the mesh as EHM_STATIC with IMesh::setHardwareMappingHint.

[lenchis001]

Hello. I tried it, but this not worked. (did not help)

[CuteAlien]

Can you post the mesh?

[lenchis001]

Yes



https://1drv.ms/u/s!Aq7kkKpJ9s6shZkFwoFRjj5za_F3DQ

[CuteAlien]

1.5 million polygons are too much for a realtime model. Try to reduce it to maybe 10.000 to 15.000 polygons or so (some console games might have 100.000 polygon models, but that's already getting tricky).

[Mel]

1.5 million polygons shouldn't be that hard to render. I've pushed 300.000 polygons on Irrlicht and i got around 50 fps on a laptop card. There must be something else, maybe it is loading too many meshbuffers and the drawcalls collapse the whole thing?

Try exporting the mesh with a single material. Irrlicht should do the conversion to multiple meshbuffers, or perhaps, is there a way to enforce a 32 bit index buffer?

On a slithgly related matter, how do you use 32 bit index buffers?

[Cube_]

I second what mel said - 1.5M tris shouldn't really be a problem, I can push 10M on my rather underpowered laptop at 2-15FPS depending on the specifics of the mesh - on my desktop the same code runs at a few hundred fps (note: I do not use octrees, they would slow me down by at least an order of magnitude for that specific use case, rather I use a binary tree model)

Rather, part of the problem is that the mesh is made of 195 objects.

That's 195 separate meshes, my 10M tris aren't in that many objects - intuitively I'd guess it may be drawcall starved at that many highpoly objects, try VBOs maybe.


Anyway, without the code I can only guess what you might be doing.


Also: it is possible that the file loader may not be optimal, my 10M mesh is built entirely via code and thus optimized as well as I can, given the limitations of my coding abilities.
The primary difference I see is 10.22M tris in 26 draw calls versus 1.5M in 195+ draw calls, and that's what my guess would be with the information at hand, optimize your mesh for fewer draw calls and see what happens.

[CuteAlien]

Well, I get 17 fps here in windowed mode with that tank. But 1.5 millions is still not a poly-count you should use for realtime models. I might check later if I can improve speed here, but currently busy with another bug which that file showed me. Seems I broke support for loading filenames with cyrillic characters in the meshviewer example in trunk *sigh*.

[lenchis001]

I try reduce polygons numbers to 10 000 - 15 000, but why Blender process this model without problems?

"Rather, part of the problem is that the mesh is made of 195 objects." - on screenshot loaded only 8 models - 23 fps

[Cube_]

but why Blender process this model without problems?

blender uses some extremely advanced rendering algorithms for rendering things very fast, I can't begin to explain how they work though (Because that'd imply I actually understood how they work).
Blender, as far as it matters when comparing to irrlicht, is made of black magic.