Hi everyone, I'm developing a Irrlicht project (i guess pretty much everyone here is ) so I was wondering what Irrlicht-specific optimizations or performance stuff should be taken into account, and I couldn't find any similar post. Please contribute as much as you can. I'll start:
1) Enable backface culling (default) and sort your vertices/indices accordingly.
2) Try to reduce the use of trigonometric functions and square roots (i.e using getDistanceFromSQ(...) instead of getDistanceFrom(...))
Irrlicht performance tips
-
- Posts: 18
- Joined: Mon Apr 16, 2012 5:04 pm
- Location: Calabasas, CA
- Contact:
Re: Irrlicht performance tips
I haven't used irrlicht properly in a while, but from what I know of it
biggest suggestion i can make for improving performance with irrlicht:
Use as less Nodes as possible!
this includes:
- batching polygons to minimise drawcalls (each node is equivalent to a single drawcall at best!)
- only render what you need (cull nodes that are not visible)
- sort nodes by shader (or renderpass), followed by material (or textures)
- instead of using irrlicht animators, perform animations on GPU
other noticeable gains will come from trivial C/C++ optimizations like unrolling small For loops, using smallest possible variable types, const-correctness, etc
Ofcourse, it also depends mostly on WHAT game (or application) irrlicht is being used to make, because there would be a tonne of other performance optimising options available depending on specific requirements (such as transparency sorting, managing lights, LOD, terrains, etc)
biggest suggestion i can make for improving performance with irrlicht:
Use as less Nodes as possible!
this includes:
- batching polygons to minimise drawcalls (each node is equivalent to a single drawcall at best!)
- only render what you need (cull nodes that are not visible)
- sort nodes by shader (or renderpass), followed by material (or textures)
- instead of using irrlicht animators, perform animations on GPU
other noticeable gains will come from trivial C/C++ optimizations like unrolling small For loops, using smallest possible variable types, const-correctness, etc
Ofcourse, it also depends mostly on WHAT game (or application) irrlicht is being used to make, because there would be a tonne of other performance optimising options available depending on specific requirements (such as transparency sorting, managing lights, LOD, terrains, etc)
Re: Irrlicht performance tips
Use octrees for large static level-geometry. Consider recompiling Irrlicht and experimenting with the octree defines. Alternatively mark static meshes as such (set hardwaremappinghint to EHM_STATIC).
And always the most import rules of optimization: Profile first!
And always the most import rules of optimization: Profile first!
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
Re: Irrlicht performance tips
^ I second that. Do nothing unless your profiler tells you it's a bottleneck. Code for style, not for speed until it's time to profile.
Re: Irrlicht performance tips
There's no funny in optimizing code. First achieve nice results. Optimize only if needed and you'll make games.
Junior Irrlicht Developer.
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me
-
- Posts: 18
- Joined: Mon Apr 16, 2012 5:04 pm
- Location: Calabasas, CA
- Contact:
Re: Irrlicht performance tips
Thanks guys for the replies. I don't want to make my program faster (as of now), as you said that's what profilers are for. I just want to know stuff I should keep in mind beforehand, like overkill functions or features of Irrlicht, so I can design my framework properly and avoid refactoring huge amounts of code later. For example, using mesh buffers required to rewrite a large portion of my application.