The MVC pattern would be good, that’s true - the “Just In Time” construction of spatial would solve many of the issues but would add a lot more too.
Thanks for this suggestion I’ll take this into consideration.
About the documentation of “updateGeometricState”:. I will contribute if I will know more about this method, currently I’m not sure about every aspect of it.
Yes, think of the model-view-controller pattern.
Model - keeps track of the state of your world, updates everything meaningful.
View - the 3d view
Controller - controlls/app states/etc that update the view to match the model.
Controllers and AppStates are the tools to use to provide the “controller” bit of MVC.
Especially if you have 13000 objects to update “game state” every frame, traversing the scene graph to do it is extremely inefficient. This is the kind of thing that entity systems are perfect for but even beyond that just having 13000 game objects in an array would be faster than going through some node hierarchy to update controls.
…but a full data driven design (like an ES) would be even better in this case. Then just let the scene graph worry about the visual things.
Also, moving to a data driven architecture where game objects are separate from visualization objects will let you more easily take advantage of batching… this will improve your performance more than any single thing discussed in this whole thread. And it will make your GPU+bus breathe a sigh of relief.
Well, yes, it came to my mind already but that is a really big thing and I’m afraid of the overhead of code that will be required for objects creation/destruction validation of certain rules that makes them fit within. Also I’m not sure about the models themselves. What I mean is that there are very complicated things in my code, like travelling curves and assigning a child nodes to a “GameObject” so that obstructions can be calculated by checking world bounds. This all things could be solved probably. This is a very tempting idea, yet a very advanced and hard task to remake the whole thing to an entity system.
One thing that keeps concerning me about your profiling results and something that makes me want to tease this out a little more…
If the updating of geometric state for the leaves is a no-op then it makes no sense why this is taking so much longer than the updating of logical state. Because of the control updates, I’d expect this to always take longer since effectively they are doing exactly the same scene graph traversal but the logical state updates will also be running controls that are presumably doing work.
This makes me wonder if something else is also in play. It’s hard to tell for sure from the stack traces but it seems like a lot of work is being done on the updates. Are you by chance updating the positions of your game object every frame even if they aren’t moving? That would force the bounds and stuff to be recalculated every frame for everything.
@luke1985 said: Well, yes, it came to my mind already but that is a really big thing and I'm afraid of the overhead of code that will be required for objects creation/destruction validation of certain rules that makes them fit within. Also I'm not sure about the models themselves. What I mean is that there are very complicated things in my code, like travelling curves and assigning a child nodes to a "GameObject" so that obstructions can be calculated by checking world bounds. This all things could be solved probably. This is a very tempting idea, yet a very advanced and hard task to remake the whole thing to an entity system.
Seriously consider it, though. I can only guess the type of game you are making from your posts… but it sounds similar to some kind of RTS (terrain, lots of objects, etc.)… and those are ideally suited to data driven designs. An ES is just one of the more logical ones.
What you are doing now as your work around is kind of akin to paging. You are manually “paging” in and out entire nodes but you are keeping them in the tree just to update your game objects.
For example, if you kept all of your 13000 spatials in a list and then manually ran the controls using that list then you could get away with attaching/detaching the spatials instead of just culling them. That’s a kind of clear indicator that something is a bit off in your current approach… and potentially a stepping stone on the way to something more game object centric. (For example, the logic to attach/detach is the same whether the source of that condition is a spatial or a game object.)
All of your other code: obstacle avoidance, path following, etc. would be better served dealing with game objects anyway. Many opportunities for simplification down that road depending on how you do that stuff now.
If you have a large number of objects like trees take a look at how forrester works. You don’t realy need to have a node and geometry for every single tree in your level, you can merge those into a node that contains point where the trees are and draw them in view when needed (if they are not in view the information that a tree is at that spot is probably enough anyways, no need to know if it has dew on it’s leafes and all that eyecandy).
Like kwando said a good aproach is to create the game logic entirely in java objects. What i have done a few times is first just create the game without any viewable components other then a few debug outputs to console, then put a simple 2D view on it using simple jFrames and its paint methods. You don’t need anything fancy here, Height is the colour shading of your green background, trees are just brown dots, buildings are red quares, cars are smaller blue squares etc. That way you can iron out a few other elements of the game logic that you need a visual view to spot for. Then you can wrap a 3D view arround it.
When putting the 3D view arround it just have elements in the scenegraph that are realy visible, the rest of the game still runs in your previously coded game logic, for the objects you see on the sceen the scenegraph takes over control (here you can then work with “real” collisions, physics and all that wich is not realy neccesary for stuff the player doesn’t see anyways).
This is more work at first, but in the end you are doing yourself a huge favor by going a way like this. You have better understanding of the mechanics behind the scene if you first code it without view and can spot bugs more easily. Also it is much easier to add more elements to it because you have a cleaner structure.
For the problems like pathfinding along curves and similar stuff you don’t realy need that if the player does not see it. You can calculate the path and the ammount of time it takes for your cars to follow it by simple A* algorithms or somehing like that. Even if your car is not exactly on the street this way who cares ? If the data is correct they don’t need to be unless someone sees it. Once the player is able to view such a car you can allways correct its position and calculate its movement path with more detail.
Allways think about how much detail you REALY need for the game logic, most of the time a very abstract level of detail is more then enough to make the logic run.