SceneManager with octree support?

eis_os · Post by **eis_os** » Fri Apr 16, 2004 2:04 pm

Hi

I am trying to get a terrain based on objects (selfmade Scenenodes) to be drawn in Irrlicht.
A scenenode is a game object aswell, my problem is the perfomance.

Couldn't Irrlicht provide a octree SceneManager?
So all SceneNodes attached to it will be only drawn if they are visible.

I don't have a continuous terrain, so the current irrlicht based features are somehow unusable...

buhatkj · Post by **buhatkj** » Sun Apr 18, 2004 2:21 am

try making the terrain an octree, for other object irrlicht should automatically do frustrum-based culling i believe.
check out the quake3 map demo, that show how to do this with a .bsp, with any other supported mesh its exactly the same.
-Ted

eis_os · Post by **eis_os** » Sun Apr 18, 2004 12:07 pm

buhatkj wrote:try making the terrain an octree, for other object irrlicht should automatically do frustrum-based culling i believe.
check out the quake3 map demo, that show how to do this with a .bsp, with any other supported mesh its exactly the same.
-Ted

Not all stuff is a continous terrain you can put in a terrain scenenode.
But I don't have a mesh. I have alot objects with low polycount.
And even if I find a way for displaying the terrain stuff with a huge mesh I could load. The same problem will come back if I want to show alot vehicles.

The Octree SceneManager should keep track of these objects and show only really the needed nodes but alot faster than currently...

Because it doesn't need to check each and every node if it's visible or not...

Tyn · Post by **Tyn** » Sun Apr 18, 2004 12:25 pm

What you and I need are very simular, I think this is what you need also.

I have a 200x200 tile map, that's 2 poly's per tile so thats 80,000 faces before any objects get added. Octree only works on a one mesh basis so adding an Octree to each tile is pointless. What I need is a node culling algorithm rather than a face culling algorithm. For my tech demo I will only use a 20 x 20 map but I will need it myself. Being that it is just on a node by node basis I can probably write one myself and probably will if Irr doesn't support it when I need it, I'd imagine that others would find this useful as well soit would be nice to have it in the engine.

It is a bit harsh to expect Niko to do all this so maybe it could be a seperate module like the system SaiGumi set up a while ago? I'd be willing to work on it sooner rather than later if others are interested too.

eis_os · Post by **eis_os** » Sun Apr 18, 2004 1:10 pm

As you see, I am interested

A terrain I want to display aswell with these objects, so it looks like it's the same. Currently I draw my two polys via drawIndexedTriangleList. Currently my opengl testwindow with 75x75 simple terrain objects is showing with 18fps

Not very good compared to the screens taken with irrlicht

Tyn · Post by **Tyn** » Mon Apr 19, 2004 8:05 am

I will make it the next thing I look at then, but don't rely on me to get it finished. I work in my free time so I couldn't give you any kind of promise of a date but I will get it done as soon as I can and send you the code.

Tyn · Post by **Tyn** » Fri Apr 23, 2004 10:07 am

I've thought about how I will be doing it and I'll be approaching it exactly the same way as A* pathfinding. I'll get the distance from the camera and the angle from the camera and target, do a little modifier on both values, add the two figures together and cull nodes on a highest figure basis and choose which nodes to cull from this list. This means I will be implementing this the same time as A*, it could be a while so you may wish to either write your own or find an algorithm off the web. Sorry about that but I have to learn about binary heaps before I do that, at the moment I know very little so I am telling you for you not to get your hopes up of it being finished quickly.

eis_os · Post by **eis_os** » Sat Apr 24, 2004 8:02 pm

Hmm, looks like I need to write my own system

Niko? You don't have such a code already, I don't want to reinvent the wheel.

Krampe2 · Post by **Krampe2** » Fri May 21, 2004 4:32 pm

try making the terrain an octree, for other object irrlicht should automatically do frustrum-based culling i believe.

And even if I find a way for displaying the terrain stuff with a huge mesh I could load. The same problem will come back if I want to show alot vehicles.

Im confused

Im creating my terrain using different tiles for now... but i guess it would be no problem to create one single mesh with lots of triangles to get the same result -> so i could create this single mesh as an octree -> and irrlicht would do culling for all other objects? So this would solve eis_os's problem too? As i said.. im confused

Tyn · Post by **Tyn** » Fri May 21, 2004 4:52 pm

Octree is an algorthm for culling triangles that aren't being shown and only shows a certain amount of triangles of a mesh, done on distance ( I think ). What I need is something to do the same thing but on a node basis rather than a triangle one.

Krampe2 · Post by **Krampe2** » Fri May 21, 2004 9:20 pm

I think so, but thats no my problem? oO

eis_os · Post by **eis_os** » Sat May 22, 2004 9:38 am

Octree is only a datastructure, aka, you devide a cube to have 8 smaller cubes, guess what an Quadtree makes?

It's not limited by definiton to only be used with triangles.

Niko said he has an scenenode that culls the children somehow.
I don't know if it's static or dynamic, and how it culls it children.

Hopefully he will release it for public in Irrlicht and it can be used for moving objects aswell.
But I don't got an reply to my last mail yet...

-edit-

I got it now, and the system was for an different engine.
Niko said maybe he will add something like the scenenode in the future but it won't be in the next months...

Krampe2 · Post by **Krampe2** » Sat May 22, 2004 1:40 pm

Yeah, i know about quadtrees and octrees, thats not my problem. Im confused about your conflicting statements. And my questions are still open. Its more the automatic culling im after. You said i could create one big mesh as an octree, so it should run smooth:

try making the terrain an octree, for other object irrlicht should automatically do frustrum-based culling i believe.

so i could create this single mesh as an octree -> and irrlicht would do culling for all other objects?

Tyn · Post by **Tyn** » Sat May 22, 2004 2:27 pm

If it is all one big mesh then it will cull perfectly. It's just for people like me who have loads of smaller objects and not one big mesh. The rest of the game objects like trees and stuff will be culled by the far plane. For you it seems the Octree should work fine, for what I need it won't

eis_os · Post by **eis_os** » Sat May 22, 2004 5:13 pm

Let's sum up:
For most people terrains with only a bunch of extra nodes can use the normal Irrlicht Octree mesh for terrain and do the other stuff with the autoculling.

If you have a lot of nodes/objects you need a better autoculling in the scenemanger or something different.

I like nikos idea of a scenenode to do it because it's more portable between irrlicht versions I guess.

So an OctreeCullingNode needs to get the World/Box Size,
disables autoculling and do the culling their own.

Which means overloading add children so we know the children position.
Then sort them / add them in the Octree.

But how should a child say it's has a new location?

OnPreRender should be overloaded and only attach the nodes which we have in the right octrees. This should prevent nodes been drawn outside.

Then I guess we need interfaces to set how small the octree should get.
And how far the camera can look. And then clicking, aka NodeSelector should be somehow in it aswell, so the octree is used to get faster where we clicked

To be continued...

Irrlicht Engine

SceneManager with octree support?

SceneManager with octree support?

well you can make the terrain an octree

Re: well you can make the terrain an octree