Is there some easy fixes we can do to allow for better mult-threading? Specifically, I'm talking about loading data in the background. Can we remove all OpenGL related calls to such things as model loading and terrain loading? Off the top of my head, the textures is the only thing that requires OpenGL during creation. Thoughts?
In other words: 
"Can we put in a better seperation between OpenGL related calls and jME scene graph data calls?"
It would help out, but I'm sure people will start doing other stuff too, like call attachChild() from a seperate thread which will then give "mystery" errors during render. Even with the code available for all to see many people really don't seem to check wether methods are thread safe or not. So I think most work would go in documentation here.
Maybe some code to run things in the jME thread could be included? Something like I just posted here: http://www.jmonkeyengine.com/jmeforum/index.php?topic=2449.new#new
That would also benefit people intergrating with Swing. Maybe even give them the ability to choose to execute Swing events in the jME thread in a similiar way. An alternative could be to make the render and update methods synchronized, so people can use their *Game class to synchronize with when doing such things.
Right I saw that which led me to this discussion 
Forgive my threading ignorance, but if that just queues things up and sends it to the main thread, where is the benefit of multithreading? Doesn't that mean it will still pause when the data is loaded. In the case of that example the loading of the box for instance. Basically, I'm thinking of dynamic level loading in the background. If your thread does that, then great, that's good enough for me, but if by sending the call to the main thread it pauses that thread from other game logic, then we might want to think of a better way.
And yes, you are right, when it comes to threads, people will break it no matter what we do. If we can make it so jME doesn't get in the way, though, I'd be happy.
Well, the idea there would be that you put everything you want in a seperate thread except things that have to run in the jME thread, eg. you can put them in an anonymous inner class that extens Runnable.
It's already a common practise that methods take a Runnable as argument, which is then called from elsewhere. My little bit of code there ensures you can make sure that gets run in the jME thread. Other than that you'd need Swing like "invoke" methods.
And uhm, going through the code, I notice you can already create (most?) geometry in a seperate thread, as long as you make a texture state in the main thread first. (eg. just call DisplaySystem.getDisplaySystem().getRenderer().createTextureState(); in simpleInit() )
mojomonk said:
"Can we put in a better seperation between OpenGL related calls and jME scene graph data calls?"
Yeah, we should. As you both said, especially loading in background would be nice. It's really a must for bigger games. And I think we are on a good way towards it.
Someone should write a little test for that....