Advice

[kevinsbro]

I currently have a system made where you make a physics node and then add mesh nodes or whatever to follow the physics node as it interacts with the environment. I'm concerned that this may be inefficient since it requires two nodes for one simple physics object. should I be at all concerned about this? does it really cost a lot to add nodes?

Also, I find that rendering just 300 cubes on my screen causes a slowdown to the point that I don't like. 300 doesn't seem like a lot to me. Is there some way to make it more efficient?

Any advice would be very very appreciated. Thank You.

[Radikalizm]

I don't think it's possible to give you a clear answer to your first question, you should set yourself a desired performance level and you should create a good system for benchmarking your code, that's the only way to check whether your code is inefficient. Besides, without knowing any exact implementations we couldn't tell you an answer anyway

The rendering of the 300 cubes is the very common draw call problem, you're issuing 300 drawcalls for a tiny amount of geometry data per call, you should batch your cubes together into larger mesh buffers so you can draw them in a smaller amount of draw calls

[kevinsbro]

Thank you for your help so far.

I understand reducing the draw calls by combining the meshes would help speed things up but is that a reasonable approach when they're all constantly moving due to physics.
I guess I would e able to create a new combined mesh every frame, but would this sounds like it wouldn't help. Any ideas to how to approach this?

[sudi]

Well the next thing you have to consider is if all 300 boxes are really moving and have to be drawn each frame. If they do then yeah you either have to issue 300 draw calls or combine the meshes each frame...another thing is instancing. there you only upload the mesh once to the videocard and then push a big array of transform matrices to draw a certain ammount. with different transforms. But first you should start by sorting out the boxes that are not drawn at all. Irrlichts standard culling isn't the fastest and can be done way better with octrees for example.

[kevinsbro]

Thank you for the help so far. I've researched all of this and have run some tests. I used the amazing mesh combiner from Lonesome Ducky, dumbed it down to strictly combining multiple instances of the same mesh (no texture details). I found that combining the meshes (600 in this case) every frame doesn't help with rendering at all. In fact, it cuts down the frame rate from 215 to around 30... So if anyone is wondering, combining meshes should only be used for static objects.

The next thing to try is instancing through a vertex shader. I feel very optimistic about this one and will post my results as soon as I get it all up and running.

[REDDemon]

Vertex shader is the only possible solution for your problem. GPU skinning is used massively in modern strategy games for moving hundreds of units on the screen every frame.

[kevinsbro]

So I have successfully integrated shader instancing in my code. Although it doesn't boost my FPS as much as I'd like I am getting about 40 more fps (200 to 240). I have seemed to notice however, that openGL gets a bigger frame boost from shader instancing than directX. I don't know if others have seen similar results but I seem to like directX over openGL so I'm a little upset. If enough people want I could possible release my code, but its not much more than what people more skilled than me on this forum have done.

[Mel]

GPU skinning isn't that great in Irrlicht, you have to sort a lot of caveats to get anyhing decent (if you want normal mapping, that is...) And you need extra draw calls if you want to have a good bone setup, (but that's my opinion).

Anyway. I feel that if rendering 300 cubes is slowing you down (12x300 = 3600 triangles), it must be also that your cubes aren't stored on the video card statically (vertex and Index buffers) so, try to set the meshes to stay always on the video memory (set hardware mapping hint).This cuts the data transfer between calls, which is also something that slows down a render. The drawback is that the batching can't be done dynamically this way, but should help a bit. Is that dramatically slow a drawcall?

[kevinsbro]

Its actually a 30 by 20 stack of cubes with working physics. And the cube models I'm using have rounded edges at about 40 triangles each. My main goal here is to just make sure I pack in the most amount of FPS as I can. My next mission is to integrate the instancing into Xeffects for shadow mapping.