My initial idea was: Gee, the client needs to initialize with a full scene graph anyway, why don’t I serialize the root node into a Message and have the client install it? (I know this won’t scale, but this is just the client initialization phase, where they do need the full scene graph. Well, maybe a stripped-down version.)
Except Node isn’t registered with the serialization mechanism. Which means that maybe I could register Node and serialize away, but probably that is going to be a nonstandard, i.e. potentially less well-tested and slower way than necessary.
Now I’m wondering: What’s the standard way to distribute the scene graph from the server to clients?
Should I write something that iterates over the nodes and collects the data to send?
I have no idea how much effort that would be, but I’m counting 19 subclasses of Spatial and don’t know how much code I’d need to serialize each of them. Plus, I might be reinventing the whell there 
Something else?
Is your scene dynamic or static?
If it is static, then simply save it to a file and include the file both in the server and client and have them both load the scenegrpah from file. you can then send message that synchronize the dynamic parts (e.g. players).
The scene is dynamic.
Static elements are limited to background art and such.
Think “space combat game”.
(There will be location-based culling, but that’s going to be sending subsets of the scene graph, so I’m back at wanting to somehow transmit a Spatial and children.)
Dont send grafic items, send logical objects, like spaceshipX at y, then create the scenegraph out of this on the client.
Well, don’t send the scenegraph, but send information about the scenegraph.
E.g., send the information spaceship of player p spwans at location x,y,z, using the model m. Then load the model m, and set it to those coordinates. Maybe lter the servers send you the message “Player p moved to position a,b,c”, so you just translate his ship to that position on the client.
There is little to no need to send the entire scene graph. you should instead focus an how it is logically build, send those build information, and then only send the information about CHANGES from the server to the client 
@EmpirePhoenix: Heh. “spaceshipX at y” is just the standard case. In battle, it would look more like “spaceshipX with turretA pointing in THIS direction, turrent B pointing THAT way, turret C a smoking wreck, a hull breach THERE with THOSE parameters for debris blowout etc.”.
That’s essentially a subset of the scene graph already. I might need some userData to keep the entire game data in the scene graph, and I wouldn’t need to construct the game world twice, as a logical data tree and as a scene graph.
(I’m assuming that stuff like meshes, materials etc. are not considered part of the scene graph; as far as I have seen in the source, the scene graph contains just the names, the assets themselves live in an asset cache.)
i agree it seems good idea to traverse the scene tree and print each node and its user data.
@Tr3kk3r: Yes, I have considered going the route that you mention in the last sentence.
To do that, I’d need to be able to do this:
- create a Spatial in the scene graph, modify it a gazillion time (I’m planning for weeks of continuous operation)
- create a new Spatial that is bit-for-bit equal to the above-constructed one.
Is this possible?
It would be easy if Spatials are essentially just “dumb bags of settings”. I.e. if there are no interactions between different properties: Calling setFoo() will never ever modify what you get out of getBar(), for whatever foo and bar properties any Spatial has. Alternatively, if there are interactions, I could adapt if these interactions are extensively documented.
Have any undocumented interaction, and recreation from scratch will be prone to bugs. It’s always possible to overlook an interaction. Even checking all interactions today won’t guarantee that this covers all interactions that tomorrow’s version of the library might have.
Of course, inspecting all properties of a Spatial so it can be reconstructed from scratch elsewhere is just another way to serialize it, so this is kinda full circle back to the initial idea.
The other approach would be to have two world models, a somewhat abstract logical model and the scene graph.
If the scene graph has no easy way to serialize it, that might still be the best route.
I’d just prefer if I could reuse the server’s scene graph.
The alternative would be to do away with the scene graph in the server and just keep the logical model.
Except I want to leverage JME3’s raycasting support for hit detection and such, which rules that approach out.
You will be much happier in the long run if your game objects are separate from nodes… and the nodes/spatials just become the view of those game objects.
At some point you will want to make your network messages as small as possible and trying to serialize a scene graph in any way is only going to hurt you.
Okay, going that route then.
Thanks.