jMonkeyEngine.org

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.

Same Opinion

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.

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…

+1…
sounds very simple and intuitive….
looking forward to seeing your progress….

I was wondering back when I started to use jme, that why isnt there such a thing already.

Because it's hard to implement!

But nice work Ogli! Keep us up to Date!

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…

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…