Scene Culling Question

[andres]

I want to know if there is someone working in scene culling for irrlicht (or if is already implemented).
I know that exists an octree mesh type, but what about the entire scene? If i want to create a very big world
there is an scene culling technique in irrlicht like octree for scene (not for single mesh, but for entire scene, with
a lot of scenenodes)?

I've made some tests some years ago (http://irrrpgbuilder.sourceforge.net/fo ... ?f=3&t=236) and got
very good FPS increase. In 2010 i found a similar implementation (http://irrlicht.sourceforge.net/forum/v ... =9&t=38987)
but it seems to be unfinished until now.

My question is, there's interest of the community in a feature like that (maybe a sceneManager capable to manage the culling
using octree, to very big worlds) ? If yes we can discuss here the main objectives to create it.

[sudi]

In 2010 i found a similar implementation (http://irrlicht.sourceforge.net/forum/v ... =9&t=38987)
but it seems to be unfinished until now.

Actually it is finished. But of course with all code and programms it can always be improved.

[REDDemon]

that octree was actually very good. 1000 objects ~ 300 fps (800 fps without animation) for effectively 100-150 drawcalls, on a very old 2GHz computer single core (cpu bottleneck).

[andres]

Nice to know that the old octree was finished. More some questions:
- About Sudi's octree, you know if someone used it in real project?
- Native irrlicht has something similar to this?
- There are plans to integrate an octree scene manager in irrlicht? (i'm not sure, but i think Ogre3D has a feature like this)

We are looking for a oportunity to reasearch octrees here (university project), and irrlicht can be a very good platform to test algoritms (assuming that there is no native implementation). I'm thinking that can be a good project for us to build a new implementation, compare with native irrlicht and with Sudi's version.

[devsh]

we have an implementation in Build a World

we store occludion IDs directly with nodes, and we also carry out a velocity+angluar velocity adjusted reprojection

what this means is that we test against the previous frame's Z-Buffer

that makes occlusion queries almost free

because the areas of blocks are completely destructible, we cant afford the luxury of an occlusion mesh other than a box


your greatest enemy is actuallythe linear search carried out 3 times ... XD

thats more overhead than not having occlusions in trees