I’ve been working to create some stuff with JME and now I want to subclass com.jme3.app.Application. When I look at the update method of SimpleApplication I see rootNode and guiNode and on both updateLogicalState(tpf), and updateGeometricState() is getting called. Now I’m guessing that U first need to call updateLogicalState(tpf) and then updateGeometricState(), Is this true?
Also I think it doesn’t matter if u first call it on the guiNode and then the rootNode or the other way arround?
The reason why I want to know is that I want to put some multithreading in my app. I’ll create a threadpool and give it some tasks every frame. That way I don’t have to worry about how many threads to create, it’ll just scale to the target machine 
I’ve also seen that a considerable amount of time is spent in those methods (particularly in updateLogicalState) so If i could make the updates for guiNode and rootNode run in parallel that would get me some easy performance
also is there any irc or other chat channel for JME?
You should not try to override Application to achieve multithreading in your application, especially when you dont understand whats happening. Make your ThreadPool somewhere and create an AppState for stuff that needs to be multithreaded. You can best multithread to read from the scenegraph while the rendering is running, so AppState has a method postRender() that is called where you could stop all your futures etc. to apply the data in the next update() call. Always remember when you deal with threads that you still have to care about the execution order of the update loop and by all means don’t try to multithread something thats happening in (Simple)Application. So for example you cannot modify the scene while its being rendered and should be careful not to modify the same objects when you multithread during the udpate() call.
I would extend from Application and use the stuff from SimpleApplication. I just want to change some stuff that SimpleApplication does. And instead of extending SimpleApplication I want to extend Application. Basically creating something like SimpleApplication but suited to what I want.
For multithreading I agree it’s not such a good idea to multithread the code in Application or SimpleApplication however my eyes just spotted the two different object of the same type that had the same methods called. I proceeded to profile it and it turns out that 2700ms of the 5200ms spent in the LWJGL renderer thread is spent in updateLogicalState(). So that would give me some more performance.
I would make sure these aren’t called before the other tasks have finished U’re solution is basically what I had in mind. Just run the tasks that update the scenegraph first, then the updateLogicalState() and updateGeometricState(), then rendering the same way SimpleApplication does and then in postRender I could get the processed input back from the tasks to apply in the next update() call
I have one more question though: Does JME work in lock-step with the GPU? or does it flush the commands to the GPU and continue on with the next update() call without waiting for the GPU?
btw: You said I don’t understand what’s happening and you are a bit right. But I’m pretty sure the updateLogicalState() off the rootNode won’t effect the guiNode and vice versa. However I just wanted to know if I’m right about that cause I need some way of verifying that my current understanding is right. Otherwise I won’t get very far in understanding the underlying magic
updateLogicalState() is where the Controls are being updated, this includes skeletal animation and particles, which are fairly intensive operations. Multithreading this part in some way is definitely a good idea, usually a Control only effects its own spatial but this does not have to be the case e.g. LodControl.
Updating guiNode and rootNode separately is perfectly fine, but it would yield very little benefit since the guiNode generally does not have any Controls in it (so nothing would happen there). All the intensive operations are always happening in the rootNode.
urndel said:
I have one more question though: Does JME work in lock-step with the GPU? or does it flush the commands to the GPU and continue on with the next update() call without waiting for the GPU?
JME does not wait for the GPU, as that would make double/triple-buffering useless
Calling updateLogicalState() concurrently is probably not such a good idea, you can make your own single controls threaded if you need to. You could probably multithread the updateXXX() of the gui and rootNode but I advise you not to do so because you might mess up the logic of possible controls that access data on both sides. We will add multithreading where its appropriate and possible e.g. particle animation (updateLogicalState() hog), but for now consider the update loop itself as a single thread. The frequency of the update calls is in fact the fps of the graphics output, if thats what you mean by “lock step”.
well with “lock step” I mean flush all the commands to the GPU wait till they are done and then call then do the next update() call.
I reall thought double buffering meant that the GPU is drawing to one buffer and that the screen displays the content of the other one. When done drawing flip a them around. And that’s not done for performance but for reducing artifacts.
But yeah JME probably doesn’t wait till the GPU is done before issuing the next update() call. It shouldn’t actually.