I have some random questions. I’m asking for best practices rather than precisely how to do it.
Lets say I have a complex inventory, multiple bags containing multiple items and some items can further be configured. Should I store this information in the scenegraph? And how? Should I subdivide the information into nodes and userdata? Or should I build a saveable class that contains the entire inventory?
If I have ufopedia like information that is generated per game, as in it is game relevant, and cannot be considered external data, should I store this in the nodes aswell?
Should an AI that is not embedded in a particular object but rather controls a series of objects be stored in the scene graph?
In short for the previous three questions is there a rule of thumb of what to store in the scenegraph?
I implemented a Roam algorithm. It requires a per frame update with access to the camera, and modifies a mesh. What’s the proper way to attach it to the scenegraph? Via a Control? Or is it better to override the geometry class and implement it’s updateGeometricState?
Is there a CollisionShape that responds properly to such a per frame recalculated/changed mesh? Right now I’m recalculating the CollisionShape per frame which drops performance significantly.
If my scenegraph contains a galaxy, meaning the distances between objects and sizes of objects are huge. Will I get double/float precision errors? And if so, is there a standard way to work around this? In other words, can I have two objects about a lightyear apart and still have centimeter accuracy around both objects?
I note that textures are saveable. So if I have 15 geometries using the same texture in my graph, are the IO routines smart enough to detect that it is the same texture? Or will the texture be stored 15 times in one file? (And I’m better off storing assetkeys in the graph)
4) Anything that modifies scene graph data (meshes, materials etc.) should either be a Control or an AppState, yes.
5) The collision shape is a separate object hence you have to update it separately
6) Yes and generally you don’t want to store a whole galaxy in the scene graph, it would be separate data that you assemble to objects on screen based on the player location and view.
7) Textures that reference files directly are efficiently cached, yes. Their path basically defines their “id” and they do not get loaded twice.
Could you elaborate points 1 to 3 ? How does it depend on the game? Is there any gamestate related data that typically should not be stored in the scenegraph? Now that I figured out how the scenegraph works, I think it’s such an awesome structure, that I want to put EVERYTHING including the kitchen sink in there! I know myself, I’m likely to overdo it. So I’m trying to figure out the limits. Documentation is no help, it explains how to do it, not what to do and what not to do. So I figured I’d just ask the experts.
As an example, an intergalactic email service. The player’s inbox messages. It should be relatively easy to stuff them in a data node in the scene graph… But should I? The advantage is that it get’s saved and loaded without further effort. It’s accessible everywhere. And the downside is that I’m restricted to a specific data format. The potential big disadvantage is that I’m abusing the scenegraph for things it’s not intended for and thus possibly causing problems in other unrelated areas.
If I don’t use the scenegraph, and the scenegraph can be saved and loaded in one go. Should I save other game data to other save files and just store them together in a directory? Or is there something I missed some way to save and load gamestate that includes these ‘extras’?
5. Is it realistic to roll my own CollisionShape? I have a heightmap class for lumpy spherical planetoids, basically if you give it a direction vector it will give you the vector in that same direction pointing at the surface. Checking collision towards any point is trivial if I do it myself. Just see if the vector is smaller than the height vector. But I have not been able to figure out how to implement my own collision shape so I can integrate it with jmonkeyengine. I have not spent much time on figuring that out though, and you don’t need to spell it out if you tell me it’s feasible I’ll figure it out myself. I expect that if the internal structure of the collisionshape is a static mesh type object then I’m probably in trouble.
6. I was thinking along the lines of a level of detail approach towards both rendering and updating logic. I am going to have to update logic for things on the other side of the galaxy anyway so some references to things a galaxy away is going to be stored in memory. I noticed you can override the logic updates method. And thus update logic only every interval (every other second or every minute).
6.a Is it sensible to have a controller on a node which culls one of it’s childnodes depending on distance, (billboard or mesh)?
You’re saying: It’s smarter to swap them in and out of your scenegraph and use the scenegraph not as a leading data structure but as a separate structure which only contains what is necessary for what is currently visible or nearly visible?
7. That’s awesome, does this apply equally to “multiple references to the same instance” of a saveable that contains a huge string map? In other words, could different instances of an AI have local access to the same scripts and still save that script efficiently? This could simplify the code but it’s not worth it if the saveable is duplicated by the amount of NPC’s using the same script. I had not spotted the “ID” in saveables yet. Saveable is an interface which does not refer to any ID how does this mechanism work?
The scene graph essentially is “stuff you might be able to see”. Anything else put in there needs to be carefully considered.
There is a reason the Model-View-Controller model is popular - it works very well. Similar models can be applied to the 3d gaming world as well so I recommend you at least look at and think about how you might want to apply that model in this case.
1-3) If you have no better idea yet, sure, store it in the scenegraph. It depends on your code and game style, its somethng that is not “defined” hence I can’t tell you “do it this or that way”
5) There is a collision shape that uses a heightmap, if you update both the terrain and that you’d get deformable physics terrain.
6) Yeah, think like “If that planet is super far away a simple particle os enough to represent it”. With such vast structures yo do not want game object = spatial, the visuals should be dynamic and the game should work without tze scenegraph at all.
7) Why scripts, just use java, it has a classloader
Ok, I get you guys are strongly in favor for using the scenegraph only for what is visible now. That model/view/controller is what I’ve been doing up until now. Problem was that my physics ended up a separate system from JME. And when I looked deeper into the scenegraph it’s kind of a model/view/controller all on it’s own. I’ll just go and find a different solution for that physics problem. Thanks for the information
5, The HeightfieldCollisionShape class is intended for flat terrain it should not even be rotated, I imagine it’s perfect for flat terrains but since I’m using spheres it’s of no use to me. I downloaded the code and read the CollisionShape and HeightFieldCollisionShape and note that they work via native bullet routines… Does this mean there’s no way to get bullet to work with my heightmap? If I want to know for any point if it’s inside the planet I can answer that cheaply. (I’m already doing that since the large polies tended to allow my very small spaceship to fly right through them collision detection or not.) But if you ask me to produce a heightmap or mesh for every spot on the planet every frame in the format requested here then that’s going to be expensive.
7. My point wasn’t the use of scripts, my point was whether or not large saveables are also effectively referenced in the scenegraph so having the same huge saveable twice in two different spots does not duplicate the data in the save file.
Let me get this really straight, even though my heightmap is spherical, meaning that at some angles up is literally down. You’re saying I can still use the HeightfieldCollisionShape ? I’m totally missing how I would be able to do that. Do you know of any examples out there I can look at?
Will do!
Thanks for your patience in answering these questions
“the game should work without tze scenegraph at all”
This is an excellent rule of thumb, I’ll make sure this is true for my project!
if you tell me it’s feasible I’ll figure it out myself. I expect that if the internal structure of the collisionshape is a static mesh type object then I’m probably in trouble.