Hey. Me again.
So, now I need some tips on how to properly optimize my map geometry.
Currently I have it divided into chunks. Each chunk is about 64 by 64 units in size (just for testing) and contains one block. Now I could combine it all into one single mesh and use an octree buuuuuuut...
The main problem is I also want to manage lights per chunk (and since I need to have a lot of lights and NOT use deferred shading it's all the good ol' forward renderer) to have seemengly unlimited light sources per map (not really, but you get the idea).
I've been trying to come up with a culling algorithm for chunks (by the way, found a good blog posts on that: http://tomcc.github.io/2014/08/31/visibility-1.html). But I'm afraid the overhead here is using nodes for chunks. Since each node is a meshnode and has its own buffer, it will constantly change materials, which I previously avoided by combining everything into one single mesh (by the way, can someone explain why exactly I have higher framerate using pure Opengl while doing the same thing? I used drawElement and only changed textures on geometry. And had higher framerate than using nodes in Irrlicht).
Is there a way to manage lights per Octree node (which is generated by irrlicht when loading mesh)? Or maybe you have other good ideas on how to manage lights AND optimize rendering? Or will it also change materials when drawing all nodes?
Light management on Octree
Re: Light management on Octree
Looking at it's code I don't think you can have the lightmanager to act per chunk inside the octree. I think chunks with same material are drawn together, but I only spend a few minutes now going over the code, so not 100% certain.
My experience in the past was - having a single mesh with a static meshbuffer (hardwaremappinghint for buffer set to scene::EHM_STATIC) was faster than using octree. But obviously that kind of stuff depends on the scene and it's been a long time ago, so not sure how good my test was (for example if you ever have a situation where your camera can see the full scene, then octree becomes pointless and I might not have realized that back then).
Reason your OpenGL is faster likely because you avoid some state-switches. Irrlicht svn trunk got better there than 1.8, but unlikely will ever be able to beat pure OpenGL (as it's using that but has to be a bit more general sometimes to support multiple backends). Really can't tell more without profiling a concrete use-case.
Sadly we don't have grid or quadtree nodes so far which both are often better suited for large scenes (octree really shines when you use the full 3d space, which is rather rare in games).
My experience in the past was - having a single mesh with a static meshbuffer (hardwaremappinghint for buffer set to scene::EHM_STATIC) was faster than using octree. But obviously that kind of stuff depends on the scene and it's been a long time ago, so not sure how good my test was (for example if you ever have a situation where your camera can see the full scene, then octree becomes pointless and I might not have realized that back then).
Reason your OpenGL is faster likely because you avoid some state-switches. Irrlicht svn trunk got better there than 1.8, but unlikely will ever be able to beat pure OpenGL (as it's using that but has to be a bit more general sometimes to support multiple backends). Really can't tell more without profiling a concrete use-case.
Sadly we don't have grid or quadtree nodes so far which both are often better suited for large scenes (octree really shines when you use the full 3d space, which is rather rare in games).
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: Light management on Octree
Ah, I see. Thanks for clearing things up.