I worked a few hours to write down some ideas:
PDF-Version (half a megabyte):
http://lostplanets.de/files/SceneManagers.pdf
DOC-Version (smaller):
http://lostplanets.de/files/SceneManagers.doc
ODT-Version (smallest):
http://lostplanets.de/files/SceneManagers.odt
I would appreciate any comments on this.
Implementation of these ideas will be finished within 1 or 2 weeks…
8)
Sounds very interesting to me!
Since i'm implementing a Cell-and-Portal algorithm.
If I could help you with this, let me know! 
Are you thinking about a contribution to jME 2.1 / jME 3?
Or will it be a seperate project?
I will contribute the scene managers as open source to the jME-project,
because I think that this is a very essential and basic feature of
a scenegraph-based rendering engine.
OGRE for example has an automatic scene management…
Your help with cells and portals is very appreciated,
but first I will implement the helper classes,
octree and cubic dungeon.
I will contribute the scene managers as open source to the jME-project,
because I think that this is a very essential and basic feature of
a scenegraph-based rendering engine.
Same Opinion :D
How does the Scene Managers works?
Do they generate a List of visible Objects every frame?
Anyway, it's nice to have such features implemented in core!
If I can help in any way, let me know. ;)
Looks very interesting, I'll need to give this a good reading when I get a few minutes later today 
tim8dev said:
How does the Scene Managers works?
Do they generate a List of visible Objects every frame?
Yes, but not only "visible" objects but also "potentially visible objects".
For the calculation I will use objects like clipping planes, clipping cuboids, clipping spheres and so on - on the other side is the jME-scenegraph with the bounding volumes (I will reuse them - they are already in the engine).
A SceneManager will work as follows:
1)
In a first step (precomputation) the SceneManager will sort in all static and dynamic objects.
The static objects are supposed to stay where they are -
so they won't need updates (if the SceneManager itself is also static).
The dynamic objects can change the position - there will be an update function for every SceneManager, where you can give the parameters "name of object", "old position" and "new position" - the SceneManager decides whether to re-insert the dynamic object.
If you do not like tracking updates manually there will be convenience functions tracking the positions of the objects automatically each frame.
With a simple call to "Refresh" you will tell the SceneManager that it should re-insert all dynamic objects.
With a call to "RefreshAll" you can tell the SceneManager that static objects should be refreshed.
2)
At runtime the SceneManager will do the following:
It will calculate a list of "visible objects" (their bounding volumes are all "inside")
and it will calculate a list of "potentially visible objects" (their bounding volumes intersect the clipping objects).
If you like, you can combine different SceneManagers (enter the output of the previous SceneManager as input for the next SceneManager).
At the end you have a collection of Spatials (nodes and geometry) that you can send to the renderer of jME...
I think this sounds very simple, but as you can see in the document at the beginning of this thread, there are many complex classes to be implemented...
8)
That is very nice indeed! I look forward to see the product of this initiative.
+1…
sounds very simple and intuitive…
looking forward to seeing your progress…
My question is how this will provide better clipping than the camera based culling. I guess what helps here is the fact that some objects that camera faces should be taken into count to let the engine avoid rendering of objects behind. Am I right? Sounds very nice. I guess you're doing it in jme2.
I was wondering back when I started to use jme, that why isnt there such a thing already.
I was wondering back when I started to use jme, that why isnt there such a thing already.
Because it's hard to implement! :wink:
But nice work Ogli! Keep us up to Date!
timong said:
My question is how this will provide better clipping than the camera based culling. I guess what helps here is the fact that some objects that camera faces should be taken into count to let the engine avoid rendering of objects behind. Am I right? :) Sounds very nice. I guess you're doing it in jme2.
The built-in camera culling is quite good - but it doesn't automatically build a scene graph from basic objects.
The automatical scene management is the improvement.
What you mean is generally referred to as "Occlusion Culling" - an interesting topic, wich I am also working on...
current state of the project:
I started implementing today and analyzed before what there is already in the engine.
The thing that worries me most is, that all the math in jME2 is float-based. We live in a 64-bit world with processors that have good ALUs with support for double floating point numbers. And float is really not that good - especially when building large-scale worlds, the precision gets to low and errors occur...
Next info will be posted on monday (along with a link to the source).
I could need a little help with compiling to .jar instead of .class files in eclipse 3.5 - I've never done that before without a given ant-buildfile...
Okay, I didn’t really get that far in the last three days, but here it is - the source:
http://www.sternenschwarm.de/files/SceneManagersJAVA/src.zip
I am still working on the math lib that will be used by the SceneManagers.
Fortunately I have a lot more time now to program the code.
Because I really attach importance on correctness, almost all the code has been commented and all the interfaces were implemented correctly.
Have a look at the code if you like and tell me if something seems odd to you…
8)
Thank you very much for your document. Maybe you should mention whether you will do something to ensure your BSP trees stay well-balanced. Then, you should tell whether your implementation is recommended for very dynamic indoors. Why is it important that dynamic objects don't fly through walls? If an object is "in" a wall, it is considered as inside the cell; if it goes completely through the wall, it is outside the cell. Do you plan to implement occluders or anti-portals? I'm looking at your source code now.
Edit.: I see you mention concave polygons, why do you plan to support this?
gouessej said:
Maybe you should mention whether you will do something to ensure your BSP trees stay well-balanced.
I know what a balanced tree is from the lectures at the university, but I plan to import given BSP trees - so it will depend upon the imported tree if the tree is balanced or not.
gouessej said:
Then, you should tell whether your implementation is recommended for very dynamic indoors.
What do you mean by "very dynamic indoors"?
I distinguish dynamic from static objects and thus dynamic objects are considered to be taken special care of.
gouessej said:
Why is it important that dynamic objects don't fly through walls? If an object is "in" a wall, it is considered as inside the cell; if it goes completely through the wall, it is outside the cell.
Very simple:
The difference between "completely inside" and "intersecting" is used to check the child-nodes (bounding objects) - it may be that dynamic objects consist of sub-objects (in my master thesis I had such a case).
gouessej said:
Do you plan to implement occluders or anti-portals?
Why not - it is a simple inversion - everything inside the clipping object is culled.
The only problem is the calculation of the bounds of the occluder - I have asked a friend about that who has a little knowledge in this area.
gouessej said:
I see you mention concave polygons, why do you plan to support this?
Because it is easy - a concave polygon can be subdivided into convex polygons. I have implemented an algorithm for 2d-objects that accomplishes this task - I think it should also be possible for 3d.
I think on friday I will post the next source code package...
8)
Ogli said:
What do you mean by "very dynamic indoors"?
I think about the GeoMod feature used in the game "Red Faction". It is possible to break the walls, etc... Maybe some walls can be considered as dynamic objects in your scene manager if it is easier for you.
I've hat a short look at the source…
But I really got very less time for portal culling etc… since I've got what I need yet (though not what I WANT)…
And I'm fed up of school 
But as it seems to me, the clipping objects are very nice!
I really do need them!
Thanks very much for your efford!
gouessej said:
Ogli said:
What do you mean by "very dynamic indoors"?
I think about the GeoMod feature used in the game "Red Faction". It is possible to break the walls, etc... Maybe some walls can be considered as dynamic objects in your scene manager if it is easier for you.
Hmmm, okay - a good point. I think it should not be a problem to implement this.
I have also thought about this. If you read the paper you find a SceneManager called "CubicDungeon" - I want to create a space game where you can invade a spaceship and fire around with guns and explosives - these "dungeon levels" are supposed to be "very dynamic indoors".
Maybe I can adapt this idea in a more general fashion...
8)
So, the necessary math is almost completed:
http://www.lostplanets.de/files/scr2.zip
Now I can begin with the scene managers…
8)
Hi!
Ogli said:
Now I can begin with the scene managers...
What's up? What is the state of progress in your scene managers?
I have not intentionally found which library is used to compute cells and portals in JPCT, it might be interesting for you, it is called jKilavuz:
http://www.jkilavuz.com
I have read the tutorial and I have noticed several similarities between my implementation and the way its author introduces his library.
Finally, it would be fine not to duplicate efforts. I have spend a lot of time in implementing regular finite grids, irregular finite grids (work in progress), a general portalizer (work in progress), portal culling (the JME 2.0 implementation is still a bit buggy).