Creating entity on other thread

[L B]

I have managed to enable simple multi-threading by using a lock, or mutual-exclusion (mutex) system. Basically, I lock around all Leadwerks commands, so that none of them can be called at the same time, and forcing them to execute sequentially.

 

This works really well for all commands. Except for the ones which create an entity, be it a body, model, mesh, light, etc.I'm wondering why that occurs, but most importantly, how can I truly create an entity on another thread.

 

I know I could invoke the entity to be created on the main thread (using a delegate that gets executed at the next loop), and this is the approach I've used so far. However, for many reasons, I would like to create entities on other threads.

 

How can I *truly* create entities on other threads without Leadwerks crashing?

[L B]

Mm, it actually only seems to be models, now that I do more testing. Or perhaps loading in general.

[TheoLogic]

Strange, your approach with locking should work just fine... You could also use a concurrent_queue and load everything from your main thread. Just push_back everywhere you need it, and try_pop on the main thread.

[L B]

Strange, your approach with locking should work just fine... You could also use a concurrent_queue and load everything from your main thread. Just push_back everywhere you need it, and try_pop on the main thread.

You're suggesting C/++ methods to the wrong guy.

 

Besides, I did have a queue on the main thread to work so far, but that turned out limiting after a while. So I really need to actually load the models on another thread. No fake, no almost.

[Rick]

I thought this has been decided that it wasn't possible? I seem to recall many topics on this with that being the outcome.

[L B]

Mm. Josh never said anything about it though. His answer seems to be that we always have to call Leadwerks methods on the main thread - which is false, with proper synchronization, only LoadModel seems to be failing right now.

 

Maybe Mika could help us figure a workaround with the source?

[TheoLogic]

You're suggesting C/++ methods to the wrong guy.

 

Concurrency comes with .NET 4.0 .

[Josh]

It should work if you lock your threads at the right time, but it's a minefield of potential problems.

[Canardia]

The main problem seems to be that the other threads don't have an active OpenGL canvas or driver, so for example LoadTexture fails because the maximum texture size is 0 (instead of 8192 like on the main thread).

 

However, when I preload and free the models in the main thread first, then it works also on the other threads:

FreeEntity(LoadMesh("oildrum.gmf"));
FreeEntity(LoadMesh("mushroom.gmf"));

[L B]

The main problem seems to be that the other threads don't have an active OpenGL canvas or driver, so for example LoadTexture fails because the maximum texture size is 0 (instead of 8192 like on the main thread).

 

However, when I preload and free the models in the main thread first, then it works also on the other threads:

FreeEntity(LoadMesh("oildrum.gmf"));
FreeEntity(LoadMesh("mushroom.gmf"));

How did changing the memory structure as we discussed the other day work out?

[Canardia]

It had nothing to do with memory structure. It's just that OpenGL doesn't return anything useful on other threads if it's not done first on thread which creates the graphics window. Even when I hardcoded the maximum texture size to 8192, it still failed on the OpenGL compileshader command. Klepto2 said it has something to do with FBOs.

[Rekindled Phoenix]

It's amusing that both you and Metatron are attempting this simultaneously.

 

He's shown proof of concept, which means that it's possible for other languages (C#) to do it!

[L B]

It's amusing that both you and Metatron are attempting this simultaneously.

 

He's shown proof of concept, which means that it's possible for other languages (C#) to do it!

The modification(s) to be done is(/are) in the engine DLL, hence why Metatron has to do it. And then, from that point, any language could use it.

[Canardia]

It's amusing that both you and Metatron are attempting this simultaneously.

I tried multithreading earlier without mutex locking, but then it crashed on every LE2 command, so I didn't investigate further.

 

Now Lazlo showed that actually all commands work with mutex locking, except the one's which are using buffers/FBO's.

 

And those remaining commands work also when they are first used from the same thread which created the Graphics window,

so even in this state it's already useful, but the ultimate goal would be of course to have FBO's working on all threads without preloading.

[L B]

I tried multithreading earlier without mutex locking, but then it crashed on every LE2 command, so I didn't investigate further.

 

Now Lazlo showed that actually all commands work with mutex locking, except the one's which are using buffers/FBO's.

 

And those remaining commands work also when they are first used from the same thread which created the Graphics window,

so even in this state it's already useful, but the ultimate goal would be of course to have FBO's working on all threads without preloading.

Any update on this? I personnally humbly admit I cannot help at all.

[Canardia]

Nope, I think this is as good as it gets with LE2.

But it's quite nice, as now I can make an animated loader screen while the scene is loading, and I'll add that to my Guess A Number game too.