# Evaluate my Node/Geometry plan

I’m working on organizing the nodes/geometries of my game as the picture shows. For now, you could think of my game as a regular RPG kind of style. Each node/geometry will have the appropriate controls attached to them. I want to know what you guys think about this. Hopefully, you guys can save me from going down a bad path if this layout is unworkable. Thanks.

Looks sensible. You might want to have a node here and there based on position and not only type, but that would most probably depend on the game. E.g. you can cull monsters inside houses more easy when they are in one node, for example when the player is not inside the house.

Yeah, in a scene graph, spatial organization is often more important than logical organization.

For example, if your world was divided into zones or tiles or something then if the objects, NPCs, etc. were children of the zones then they would automatically get frustum culled with the zone. Under the zone you could organize them logically, though.

Although I’m not sure there is any real advantage in doing so. You will need a separate list of NPCs somewhere anywhere since iterating over all NPCs you wouldn’t want to go to the scene graph for anyway (or would you?).

I’d really think spatially on this one. Everything inside one vehicle is in one node. Everything inside one house another, etc.

This will greatly improve culling performance and also means that things like moving vehicles that move their content comes “for free”.

Great suggestions, thanks guys.

Have you considered dividing your scene graph into functionality instead game object types? For instance, pickables, collidables, etc. This way you use your scene graph to limit the number of objects any particular functionality will have to iterate through.

Example:

In your breakdown above, you will have to perform picking from the rootNode down to encapsulate both objects and characters. This will also include your scenery, which has the opposite effect of being helpful.

Definitely consider functionality before going with what you proposed.

My understanding is that the scene graph is built for optimizing geometric bounds calculations.
Arrange your node tree in ways that do not follow vicinity, and the higher-level Nodes will have bounds that cover the entire scene, preventing the engine from culling stuff early on and forcing it to look into a lot more Nodes than necessary.
Arranging by object type would be as bad as arranging by functionality. It’s probably of little concern if the scene graph is small; essentially, the speedup you gain is something like the ratio of total Spatials to visible Spatials, which would typically be “just a constant factor”. If you live at the edge of what current hardware can support, constant factors matter greatly; if you have lots of room to breathe, it’s less important and other factors might kick in.

That’s just my current understanding of how the engine works (and also my understanding how 3D engines in general work).
Somebody with more jME knowledge, please correct any misconceptions here

For picking it definitely makes sense to group by type, you reduce the amount of objects to check immensely when you e.g. look for collisions with “PowerUps” or “NPCs” or whatever.

That does depend however if yo use picking in jme or picking in bullet, as soon as you do the second it wont matter anymore ^^

But yes it dtrongly depends o what you are trying to archive with this and how many objects you plan to use.