New Feature and potential new feature

If those methods could be deferred until render


Now we're talking about the same thing.  I haven't spent much time in the core of jME, I'm definitely not very knowledgeable in all the math this engine utilizes, and haven't read all the great books on how 3D engines should work.  Those things are what have kept me from pursuing trying to manage the conversion myself.  You would need the assistance of......well......pretty much any other jME developer. :)  I have great ambitions and I'm a good Java developer and those are the things I bring to this project.  :roll:

I think llama could be the best ally here as he's been great at assisting with other thread-safety aspects.

We could probably add in a check and set function that would check if the camera has changed and set it to opengl if it has to the camera.  Around the swap buffers call we could grab the current camera and call that function.  Camera.update() could stay in there as a way to force the change at any point in your code if you want and could also be what check and set calls.

I like it.  :smiley:

This sounds good to me, although like darkfrog I don't know the innermost workings of jME (yet?).



I'd still advocate adding the 'inRenderThread' part of my patch: http://www.jmonkeyengine.com/jmeforum/index.php?topic=3642.msg33181#msg33181

since it is still useful for people writing general multithreaded code, without adding any overhead for most users of jME.



You wouldn't actually need to add any calls to GameTaskManager.update() in the core code, though, which should satisfy those worried about overhead and dependencies.