jME3 is similar to Swing in that, for speed and efficiency, all changes to the scene graph must be made in a single update thread. If you make changes only in Control.update(), AppState.update(), or SimpleApplication.simpleUpdate(), this will happen automatically.
Just wanted to clarify this for those who may be reading this but have not fully read about the subject.
Not to keep nit-picking but just to clarify a concern, jme does do this in that bullet can run parallel to the scene graph (because Normen made it that way) and AppStates are the shit. Concurrency, though, unless we’re talking “buy a load of plugins and call it a game” - is based on the person implementing it. Pauls IsoSurface demo for example comes built with concurrency all over the place. The scene-graph itself, though, occupies the primary thread and there’s nothing you can do about that as jmaasing explained. I’m not even going to pretend I could best what is already there.
Uh cool, I’ll check those patterns out. Sometime. I kind of just learnt how to properly use executors yesterday so I wasn’t planning to jump right into academic theories and advanced usages.
No, these are like your usual 3D models and textures. What I was reffering to is the page size which is what gets transferred onto the system bus once the HDD reads it.
Ah I see, welp there goes that. I swear I heard something about multithreaded rendering somewhere but I guess it doesn’t apply to opengl.
Is there anything that demo does not have? Time to check it out again 
Maybe. The thing is that each thread can have its own cache of data and anything outside of a memory barrier is not guaranteed to be in a consistent state. If you don’t really care about consistent state then the risk isn’t a big deal. If you care at all about consistent state ever then just never read the attached scene graph from a separate thread.
In a proper threading design, there is never a need to anyway.
Give the other thread what it needs to do its job. Fold those results back in as they get pulled off of a ConcurrentLinkedQueue or some other fast-but-safe concurrent structure.
Note: it sounds like your spatials are also your game objects and that’s going to be a constant hindrance in cases like this. It’s a convenient design but has several drawbacks… this one included.
As others have mentioned, there is a fundamental limitation… but these can be pretty trivially worked around with architectures like an ES, etc. where the different systems are already inherently thread safe and the ‘scene graph’ parts do very little.
So don’t attach/detach them all at once. Mythruna had this problem also, where if I tried to attach all of the newly loaded chunks at once you’d get massive frame drops. So I only attach one or two at a time per update(). 2 at a time, 10 chunks get added in 1/12 of a second and there is no slowdown.