Creating game characters outside update loop

HI guys…
Im trying to implement a very large world game in JME :slight_smile: by just modelling the world tiles that are around the main avatar (hero)…
So As i walk around other characters are bought into the world, or removed from the world as the hero walk towards or away from them…
Now i notice my FPS dropping as these new characters are added to the world and i assume thats to do with the overhead of creating the character, and adding it to the rootNode.

now my questions

  1. will i benefit from creating a separate thread (out side the game loop) that creates the new character node to be added and keeps them in memory… Then in my app state with my update loop adding these new characters to the root node?

  2. Can this separate thread be just another app state? if i have multiple app states with there own update loop do they run in parallel? If one of them takes longer than other to complete will this effect the overall FPS?

thanks

App states are run on the main render thread. If you need to run something in the background then you will have to manage that thread.

And yes, loading things on a background thread may alleviate some of your slow down. But note if you are unfamiliar to threading then you should keep bandages and antiseptic on hand.

3 Likes

Just to expand slightly on what @pspeed said… in jME, once you call start() on your application, almost everything happens in the update loop unless you explicitly start and manage your own threads. The only exception to this that I know of is SpiderMonkey (jME’s networking engine), in which case all of your message listeners and connection listeners will run on networking threads and not in the main update loop.

You can start another AppStateManager in your own thread and attach some app states there, which might be useful if you want to, say, set explicit tpf value for them. At least it looked working last time I tried (long ago).

Do you still have that slow downs once the models have been displayed once?

You have two Problems here: loadModel and your Disk Speed vs uploading the data to the gpu.

The first one can easily be solved with multithreading but the latter requires quite some engine changes or workarounds like breaking the model in parts or idk anything you can imagine to only partially load a model.

@nehon I guess multiple render threads are a rather vulcan only Feature? Apart from the “queue and synchronized applying” approach

Well…tbh I don’t know what’s possible with Vulkan.
You can do multithreaded rendering with opengl, having several context and sharing resources between them.
Not sure it’s a good idea though… you may get more trouble than anything else…
Also this wouldn’t be an engine feature, it more a GL backend feature like lwjgl or Jogl.

EDIT: There is actually a donc on this OpenGL and multithreading - OpenGL Wiki

1 Like

yes i do… And im working on that as well. But I get a big lag when a character is added. My FPS goes down to almost 0 for about 1 second. Which is unbearable for game play… Im doing the multi threading now using

    public void simpleInitApp() {
            shecduler = Executors.newScheduledThreadPool(1);
            shecduler.scheduleAtFixedRate(characterFactory, 0, 2, TimeUnit.SECONDS);
...

which will create the characters needed every 2 seconds add them to a queue. THe main update loop will them add the ones created to root node…

will update you guys with the reults. When i have them

Assuming/hoping you mean one of the java.util.concurrent queues and not something home grown.

2 Likes

Both opengl and Vulkan support threading. To an extent. In opengl it was suppose to be fairly widely supported in the old days. HOWEVER drivers didn’t support it well and it quickly became a no no as much as you can avoid it (unless your on the quadro cards :D). Vulkan is more explicit on its threading limitations, for example you often have to wait a lot.

Long story short, its doesn’t really work well outside some very specific use cases. One of them is loading buffers in the background. PBufferes was the old way for this. Again there are a lot of do;s and don’ts. The opengl 3+ version of this i don’t know. What i do know that even on the newest hardware its quite a trick to get it to all work any better than in a single thread. MegaTexture on quake 4 or Rage or whatever is in fact really hard to pull off.

However all is not lost. For most of us. Loading resources from disk/network is probably the slow part. Doing all that in another thread is easy enough. Then pass it all over to opengl/Vulkan when you have the context in the update loop.