Performance improvement for single mesh
-
- Posts: 9
- Joined: Sat Feb 18, 2017 3:51 pm
Performance improvement for single mesh
I have a question that came from my curiosity and maybe future improvements. Is there a way to improve performance of drawing a single mesh with a lot of meshbuffers for example like 5000?
Re: Performance improvement for single mesh
When it doesn't change (not animated and no other geometry changes) then use IMesh::setHardwareMappingHint with irr::scene::EHM_STATIC.
Other optimizations depend on the specific case. If you can for example never see the whole mesh (for example because it's the mesh of skyscaper and you are inside), then using an octrees scenenode might also help (although in my experience using the static flag is often better).
Other optimizations depend on the specific case. If you can for example never see the whole mesh (for example because it's the mesh of skyscaper and you are inside), then using an octrees scenenode might also help (although in my experience using the static flag is often better).
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
-
- Posts: 9
- Joined: Sat Feb 18, 2017 3:51 pm
Re: Performance improvement for single mesh
Except oclussion culling, static mapping, and other algorithms like greedy meshing are there any other ways? I just want to know if I already hit the cap without 'extern' algorithms.
Re: Performance improvement for single mesh
5k draw calls is a lot. You need to reduce that, that's your biggest slowdown.
Re: Performance improvement for single mesh
Yeah, to add to what hendu already said: You can do that sometimes by merging meshbuffers. The meshcombiner and the batchingmesh in irrExt are for example algorithms for that: https://sourceforge.net/p/irrext/code/H ... ene/IMesh/
(I can't tell which one works better, just try 'em both).
edit: Also - this are the easy optimizations. There is also always the hard way ... profile it. Which is hard with graphics as half the stuff happens on the graphic-card. I tend to experiment by changing one option at a time, like draw only half nodes, draw half the buffers, draw with empty materials and so on, basically what you need to know first is if the bottleneck is in the CPU, the GPU or in transferring the data to the GPU each frame. Sometimes you can also figure that out by doing more of something. For example if you do more stuff on CPU and frame-rate doesn't change at all - then CPU is likely not your problem. Or you send lots of data to the GPU which you don't even need for drawing and it doesn't slow down - then that is not the bottleneck. Figuring out GPU... I really am bad with that :-( (best I can do is modifying shaders line by line and wait for any changes, there's again several stages on GPU and you have to figure out which one it is). Generally - find out where your bottlenecks are exactly and try to work on those.
edit2: Also... one feature Irrlicht is really missing is instancing. Hendu wrote a patch once for our shader-branch, but that never got applied. DevSH will likely tell you his version can do that, so if you need instancing - his version got it. Or you have to use the power of open-source and modify Irrlicht for this one. You can use instancing if you have many identical meshbuffers which are only different by material and transformation matrix. So for example you if you write a Minecraft clone where all you have are the same walls - just with different textures. Then you can use that wall-mesh and instance it on the GPU a million times very fast.
(I can't tell which one works better, just try 'em both).
edit: Also - this are the easy optimizations. There is also always the hard way ... profile it. Which is hard with graphics as half the stuff happens on the graphic-card. I tend to experiment by changing one option at a time, like draw only half nodes, draw half the buffers, draw with empty materials and so on, basically what you need to know first is if the bottleneck is in the CPU, the GPU or in transferring the data to the GPU each frame. Sometimes you can also figure that out by doing more of something. For example if you do more stuff on CPU and frame-rate doesn't change at all - then CPU is likely not your problem. Or you send lots of data to the GPU which you don't even need for drawing and it doesn't slow down - then that is not the bottleneck. Figuring out GPU... I really am bad with that :-( (best I can do is modifying shaders line by line and wait for any changes, there's again several stages on GPU and you have to figure out which one it is). Generally - find out where your bottlenecks are exactly and try to work on those.
edit2: Also... one feature Irrlicht is really missing is instancing. Hendu wrote a patch once for our shader-branch, but that never got applied. DevSH will likely tell you his version can do that, so if you need instancing - his version got it. Or you have to use the power of open-source and modify Irrlicht for this one. You can use instancing if you have many identical meshbuffers which are only different by material and transformation matrix. So for example you if you write a Minecraft clone where all you have are the same walls - just with different textures. Then you can use that wall-mesh and instance it on the GPU a million times very fast.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm