Low performans after loading big mesh

[lenchis001]

Is it possible that performance will be increased in future?

[Mel]

I guess that is always the intention XD Blender uses a diferent approach, and is focused entirely on OpenGL, unlike Irrlicht, so they use workarounds that maybe aren't possible on irrlicht to speed up the rendering.

Can you check how many materials give you the scene node that you use to render the tank? That gives a measure of how many draw calls does the tank use.

[lenchis001]

Yes - 68 (model must be corrected). I think, need delete support of DirectX, if this decreases performance in OpenGL. But this is of course up to you.

[CuteAlien]

Hm, Blender is indeed slightly faster - strange (Blender has here 25fps with that model while in Irrlicht with static model I get 18fps). Can't really explain without doing some profiling. Meshbuffers cost a little, but 60-70 meshbuffers just shouldn't be that expensive (did some test recently with thousands of objects and the cost of drawcalls did make some difference, but not really that much to explain this). Maybe I'll profile it in some more depth next time I work on profiling Irrlicht. But in the end - even if we get a few more frames - 1.5 million polygons are too many polygons if this is for a game.

For now I'll continue figuring out the trouble with cyrillic filenames *sigh* (got closer over the last hours - seems the filename is now converted twice due to some other fixes in the file-open dialog).

[lenchis001]

Okay, how many polygons can i use for standard model in game?

[CuteAlien]

Pretty hard to give exact numbers (depends on all kind of factors). Experiment! But I don't know if there are games out there using a model with more than a million polygons. I think modern racers (which often don't use general 3d engines but hardcode all they need specific for their game) sometimes use models with more than 100.000 polygons. In other games models are rarely above 10.000 polygons. If you need lots of tanks in your game (full army of tanks for example) then you might have to reduce it to under 1000 polygons.

[lenchis001]

Okay, thank you very much for support!

[Mel]

68 draw calls are still a bit high. Not only for Irrlicht, but for real time 3D engines in general, if you're not rendering a whole scene, 68 draw calls on an object are many. Chances are that the model isn't being really stored in the video card and is flushed down the system bus (aka memory-videocard transfer) every frame, eventhough it was marked as static. Try getting the vertices welded on export, you're almost sure of that when you can see the surfaces in Blender smooth, not flat shaded. Use a format that supports vertex and index lists (use Alias Wavefront .obj, not 3DStudio .3ds) 3DS exports the meshes per triangle, and when it is imported, it generates a mesh that is full of adjacent vertices that are exactly the same, but because of the format, they're not welded, missing some of the video card optimizations when it comes to vertex accesses. Word of caution though, i think the OBJ importer still uses 16 bit meshes only D:

Games cheat a lot. They're on the premise that the fastest polygon is that which isn't rendered.

[lenchis001]

This is result of loading model from OBJ file

[Mel]

That was an expected result... shows inability to load larger than 64K vertices in OBJ models. Then, you could split the model into smaller parts (less than 65536 vertex each) export them separately, and build them inside Irr. But really, unless you are certain you need a 1.5M triangle tank, you better go for a lower resolution model.

The rules of thumb for fast meshes are:
-Store the meshes in the video card statically.
-Use 16 bit indices/ less than 65536 vertices per material
-Use the least materials possible.
-Organize the vertex and index access patterns so they maximize the vertex/index cache hits of the video card. I think Irr is capable of doing this as well, but i don't know how automated is this process yet.

And pretty much, that is almost all you can do.