How does the Scene Graph decide to relate objects/nodes?

General Discussion
1

I have poured through both the jME3 docs and the source code on GitHub, and am trying to understand how the Scene Graph actually works, as a data structure. My understanding of the Scene Graph is that it represents everything that is visible on the screen/viewport. It represents all the physical relationships between objects such that when an upstream/“parent” object changes, its downstream/dependent/“child” objects also change as well. So if my understanding is intrinsically wrong, please begin by correcting me!

Assuming I’m more or less correct in my understanding, then I’m specifically interested in how these parent/child relationships work. Looking at the code, I see that a Node is the base class for all on-screen objects. Futher I see SceneGraphVisitor, SceneGraphVisitorAdapter and SpatialUtils classes that all seem to comrpise the Scene Graph, but I’m just not seeing any true visitor/operational logic in those classes that explains what I’m looking for.

Say I have an indoor scene where there are 4 walls, a floor and a ceiling, and loads of objects all over the place. Perhaps one of the walls has a painting on it. Perhaps there is a wood stove positioned on the floor, with an exhaust pipe that goes up and “through” the ceiling. Perhaps in the middle of the room there is a table with a bunch of stuff on it. How does the Scene Graph organize and represent these objects as related nodes? Is each wall/surface its own node? Would the “painting node” be related (graph-wise) to the “wall node”? Would the “table node” be related to the “floor node”? What’s the root node?

Again, I’m just interested (as a programmer) how this is all working under the hood; I understand that normally I wouldn’t need to know this as a jME3 game developer/end user. I’m specifically interested in how the Scene Graph decides to relate all the visual objects as nodes on a graph.

2

http://wiki.jmonkeyengine.org/doku.php/jme3:scenegraph_for_dummies

http://wiki.jmonkeyengine.org/doku.php/jme3:intermediate:best_practices

And in general

http://wiki.jmonkeyengine.org/doku.php/jme3

3

jMonkeyEngine doesn’t actually dictate how you should structure your scene within the scene graph. So your approach would work.
With that said, the most efficient scenes are ones that are spatially organized, e.g. objects that are close together should be under the same branch, whereas two objects that are far away from each other should be on different branches. This is referred to as bounding volume hierarchy (BVH) and 99% of 3D scene graphs are using this concept including jME.

4

Thanks @normen and @Momoko_Fan, that slideshow was particularly helpful. But I’m still not seeing the “forest through the trees” in one major area here.

How about going back to my original example. We are inside a house, with four walls. One wall has a painting on it. There is a wood stove connecting the floor to the ceiling, and there is a table on the floor. On the table are, say, a pen and a piece of paper. How might this particular scene graph be organized?

house/
    wall_1/
    wall_2/
        painting
    wall_3/
    wall_4/
    floor/
        table/
            pen
            paper
        woodstove
    ceiling/

Here’s the root of my question: the wood stove connects to both the floor and the ceiling, so which parent node should it be a child of?

5

As you want but given that you might want to batch a bunch of walls anyway probably per room. Check out the “usecase” videos. You could have it all in separate nodes, theres no in-game connection coming from the fact that they’re both in one node, you define what happens with single objects. Maybe you just go ahead and play around to see how stuff works.

6

You are thinking about things as “connecting” and in my opinion that is completely wrong.

The scene graph organizes “containment”… specifically transformation containment. Because if the table is not a moveable object, I’d personally consider everything to just be “inside the room” and be done with it. Actually, I’d do the same if it was a moveable object because then presumably some physics is in play that is already causing table + pen and paper to interact in some way but that’s also mixing things.

house
->room
-roomGeometry (probably batched)
-roomObjects

Also note: these are not “game objects” but only visualization. Mixing the two will cause you no end of trouble down the road. See pen and paper concept above. Spatially there is probably no reason to have pen and paper be a child of table unless that are going to be transformationally locked forever or nearly forever.