Feel free to move this if it doesn't belong here, but I was just thinking about physics performance and it led me down a rabbit trail to "dirty flags" on changed scene-graph spatials. Would it be a good idea to add support for tying a dirty flag to spatials that have changed since the last rendering so the renderer knows what to re-draw? I would think this would give some significant performance advantages in rendering alone. However, like I stated at the beginning, that's not my ultimate purpose in suggesting the feature. Collision detection must cycle through the entire scene-graph to determine what is colliding right now. What if it were able to leverage an isDirty flag on spatials and would then only need to update the collisions based on objects that have moved since the last update? I would think this could drastically improve performance here as well and provide the ability create massive scenes with collision detection that doesn't cause a slow-down unless everything is constantly moving…in which case there's really nothing that can be done other than check them each time.
This would actually probably need to be some sort of event system though since multi-threading would throw a wrench into the loop as the dirty flag may be reset before the collision detection were to look at what has changed. This would also keep multiple things from having to walk the entire scene just to look for the dirty flag.
This raises another point that might be worthwhile to discuss. Adding an Event model to jME might be a very good way to asynchronously and/or synchronously handle things of this nature. For example, if you had rootNode that has several spatials you wanted to listen for the dirty flag being set on you could just do something like: rootNode.addDirtyListener(listener, acceptRecursionFlag, asynchronousFlag). If "acceptRecursionFlag" is set to true it would get events from all children of rootNode as well as just rootNode. If "asynchronousFlag" is set to true it would enqueue the event to be handled by another thread. Conversely, if the "asynchronousFlag" was false it would immediately invoke the listener in the current thread that caused the DirtyEvent to be thrown.
Have I gone off into the deep-end here? 
Physics (ODE) does that already 
Rendering itself should not be able to benefit from it as it must draw everything each frame.
But a dirty flag could benefit the update process of the scenegraph (that's why we discussed it in the past).
irrisor said:
Physics (ODE) does that already :P
Good to know my random thoughts aren't so far off base. ;)
irrisor said:
Rendering itself should not be able to benefit from it as it must draw everything each frame.
But a dirty flag could benefit the update process of the scenegraph (that's why we discussed it in the past).
If we make a better separation between the rendering queue and the scene-graph then the renderer would then benefit as the rendering queue could contain all the instructions for rendering each spatial and then clear and re-create the instructions when the dirty flag is set. We could then even drive FPS on changes so you could set a minimum time between frames (to keep the system from hammering with every little change) and have the rendering system only re-render when something has changed. If nothing is happening in the scene there's really no reason to render the screen again...this would give the system more CPU/GPU time to perform other things like physics, networking, AI, or all the crap running in the background if you're on Windows. ;)