Better to have many scene nodes, or one giant map mesh?

[3DModelerMan]

Is it better to make on giant map mesh with all the static objects in it? Or make the map mesh with the bare minimum amount of static objects, and use scene nodes?

[slavik262]

Combine as many static meshes as you can, maybe using something like Lonesome Ducky's Mesh Combiner. There's a fixed cost involved for each draw call (e.g. drawMesh, drawIndexedTriangleList, etc.) Because of this, the GPU renders faster if it has fewer draw calls per frame.

[Virion]

is there any possibility in the future irrlicht would be able to automatically combine meshes that are flagged as static mesh?

[hybrid]

Not really. Because these would have to be static in more than one sense. You cannot even move them as a whole, once given a position relative to all the other parts. So it's much easier, and usually also more efficient, to do this manually with simple solutions such as the mesh combiner.

[devsh]

actually that is not the truth, making one whole mesh will not make a giant level run faster, the less draw calls and bounding boxes you have the least objects you can discard from drawing. You send too many vertices and models needlessly to run through the vertex shader.

It is good to combine your meshes, but only if you combine them and then split them into cells, or so called OcTrees. For example you can split meshes by using one vertex buffer but many index buffers

one vertex list and separate index buffers

[slavik262]

actually that is not the truth, making one whole mesh will not make a giant level run faster, the less draw calls and bounding boxes you have the least objects you can discard from drawing. You send too many vertices and models needlessly to run through the vertex shader.

It is good to combine your meshes, but only if you combine them and then split them into cells, or so called OcTrees. For example you can split meshes by using one vertex buffer but many index buffers

one vertex list and separate index buffers

I never suggested one whole mesh. I just suggested combining smaller static meshes into large ones, as this increases performance.

[3DModelerMan]

What about the q3 map example? it uses a large static mesh. But it renders it as an octree.

[Lonesome Ducky]

The most optimal solution would be using both. You can combine the meshes, and then turn it into an octree! This way, you can cull unneeded triangles AND send it in one draw call. I hate to toot my own horn, but you can create an octree mesh node from a mesh created by my mesh combiner and it will do exactly that.

[3DModelerMan]

Cool, I can just export from 3D World Studio to EditIrr, and then write a quick export feature and export to giles.

[Mel]

And does it represent much cost to draw several times a single, simple, meshbuffer given you aren't drawing anything else, before you switch to another meshbuffer? each render uses the same textures, the same shaders, same index and vertex buffers and the only thing that changes is its position, rotation and scale.

The scenario i am trying to draft is that in which you try to render a crowd of characters which they share the same mesh, but their positions and rotations must be diferent, animations aside.

[Lonesome Ducky]

And does it represent much cost to draw several times a single, simple, meshbuffer given you aren't drawing anything else, before you switch to another meshbuffer? each render uses the same textures, the same shaders, same index and vertex buffers and the only thing that changes is its position, rotation and scale.

The scenario i am trying to draft is that in which you try to render a crowd of characters which they share the same mesh, but their positions and rotations must be diferent, animations aside.

It will be faster than constantly having to switch textures, but not as fast as sending it in one chunk. You may be looking for instancing, where a huge group of vertices is sent to the gpu, and then they are transformed according to their separate transformations. This way, you can render around 60 objects at a time, all with different transformations. I remember someone having written an instancing shader around here, but I no longer have the link

[slavik262]

I remember someone having written an instancing shader around here, but I no longer have the link

http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=39680

[Mel]

That looks definately interesting good job! and thanks for sharing it!

[devsh]

Haha so did I, but I actually used the proper instancing

http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=38748

[slavik262]

The "proper" instancing? That's kind of antagonistic and rude. You do realize that shader instancing such as my implementation is a well-known and respected technique that is used regularly in games, right?