I’m no expert on scene graphs, but I’ve done some experimenting with Xith3D and jME. Currently I’m considering using a scene graph based framework for a game engine. I’m doing indoor rendering, so I will use a algorithm similar to portals. How do you combine portal rendering with a scene graph API? Do you create graph nodes for each section of a map and if so how do you manage objects that are located in multiple sections? Any pointers to documentation on the net would be helpful.
I implemented a Portal/PVS type system with Java3D a while ago. I used switches to be able to switch out the visible bits and sharedgroups to handle pieces that were in both sets. However, this gave me problems in that multiple shared groups could be visible so I ended up with a slightly convoluted algorithm working out what was the “super set” of the bit and pieces and turning on multiple switches for a single set.
Kev
[quote]I implemented a Portal/PVS type system with Java3D a while ago. I used switches to be able to switch out the visible bits and sharedgroups to handle pieces that were in both sets. However, this gave me problems in that multiple shared groups could be visible so I ended up with a slightly convoluted algorithm working out what was the “super set” of the bit and pieces and turning on multiple switches for a single set.
[/quote]
Ok, you don’t happen to have any code you could share? Do you think using a scene graph library provide any benefits besides the abstraction of the OpenGL API and providing loaders for models? Those benefits are the reason why I’m at all considering using for example Xith3D over Jogl.
Fraid the code has gone the way of the dodo, along with my PC of the time.
The main adavantage as I see is it is the lack of donkey work. If you write a system of this type you will implement something similar to a scenegraph anyway. Might aswell not do ALL the work yourself 
Kev
Just following up on Kev’s info - creating a cells and portals style of scene graph optimisation is relatively easy to do on top of any reasonable scene graph. Other algorithms, such as BSP trees are much harder, and it’s far better off writing your own scene graph at that point in time, or finding a scene graph that allows the inclusion of custom culling algorithms in the graphics pipeline.
A question from a scene graph newbie ;): do you create each cell/room as a node in the scene graph with child nodes for the shapes in that cell or is the portal system created as just one node in the scene graph? The former solution requires that you can connect arbitrary scene graph nodes and have multiple connections to and from each node.
In general, I would recommend creating another layer over the lower-level scene graph as an application-specific layer. This will handle all cell management and a number of other things such as behaviours, navigation etc. The reason for this is that you really don’t want to put your entire level into the lower-level scene graph. While scene graphs are good for handling such systems, there’s also a finite limit as to how much you can store there in terms of memory, traversal performance etc. Use the low-level scene graph to do your basic graphics management, but have your application-level scene graph manage the higher level concepts.
Ok, but I’m still not 100% clear on how to implement this using for example Xith3D. 
If I understand correctly two possible solutions are:
-
Add each cell/room as a node in the scene graph and “switch” on/off nodes that are visible/not visible. These nodes don’t have to be connected to each other, just to a common parent node. This is bad memory wise?
-
Reconstruct the graph after each cell/room visibility check, adding only visible cells/rooms as nodes in the scene graph. Nodes could be added in visibility order.
Which one is gives better performance? Are there better solutions?
Objects in the rooms/cells can be added as shared groups to the room/cell nodes.
I guess its your normal memory <-> performance trade off. Having all the nodes already in the scene just not switched on would more than likely give you a smoother performance. Baring inmind that Xith isn’t as picky as Java3D about when you add things to a BranchGroup you could maybe just add them as you need them.
Kev
I think Xith3D can handle nodes being added and removed frequently without much of a performance hit.
Removing nodes is basically free, and your will get a speed increase from not having the nodes drawn. Adding nodes is slightly more costly, with probably the biggest cost is recalculating the localToVWorld coordinates. That said, I don’t think a few extra matrix multiplications are going to hurt.
I suggest running a test to see. Xith3D has some profiling code already in there - of particular note would be the “Node::updateLocalToVWorld” and “Node::setParent” calls.
Look at the setParent method code of com.xith3d.scenegraph.Node to see how it work behind the scenes.
My guess would be that adding and removing unneeded nodes would increase performance so long as it wasn’t excessive.
Will.
oooh…ooohhh don’t even beleave the scene graph hierarchy is going to do the trick…ha, been there and suffered. The problem is thta some actions may be more complex that display/not display. If I click a switch or pick up a key various parts/pieces of different rooms are enabled//displayed etc. Way to complex for switch statement.
For example in my game certain items are displayed based on whether or not the player has found certain things. I they don’t have a flashlight I do one thing if they do have one another.
Pressing a switch in room A may open a secret doorway in room B. This is more of a change in state of a viewed room than displaying/not displaying something
By handling they display of your objects manuallly you have gretare control
[quote]oooh…ooohhh don’t even beleave the scene graph hierarchy is going to do the trick…ha, been there and suffered. The problem is thta some actions may be more complex that display/not display. If I click a switch or pick up a key various parts/pieces of different rooms are enabled//displayed etc. Way to complex for switch statement.
[/quote]
But thats not the job of your visibility algo, thats the job of your gameplay/inventory code.
Trying to get a graphics scene graph to manage your game’s inventory is just a silly idea. :o
Yes, I’m just trying to create a generic portals system to speed up indoor drawing. Game logic, collision detection etc. is implemented in a higher layer.
Well that’s where we are suggesting something different - all of that portals stuff should be implemented at the same layer as the rest of your game logic. Game logic needs to be pretty close to the rendering API in use because there are many shared sets of data structures (eg terrain info is used for AI path finding, avatar collision detection, physics models etc). The game itself is then a layer on top of the engine system.