Locking nodes

[dart_theg]

I have ran into an issue countless times before where I create a texture or mesh, just to try to modify it in the next line and run into a crash where I try to modify the object before it is done 'loading' etc. in Irrlicht. Hopefully this makes sense. Any solution?

[CuteAlien]

Irrlicht doesn't do background loading, so modifying objects in the next line is fine. The crashes likely have other reasons. But can't help without a concrete example.

[dart_theg]

I think it's because I try to load meshes on another thread, but Irrlicht is designed to be synchronous...

[CuteAlien]

Yeah, that's not so easy.

One problem is that the mesh and texture caches are not thread-safe. So any access there while loading will be problematic.

But often the bigger problem is that textures are not just loaded but also create opengl textures - and opengl is not thread-safe (kinda possible to allow that, but that comes with costs which are often not worth it). So when loading textures in another thread that thread has to take over the opengl context. So something like this:

Code: Select all

irr::video::IContextManager* contextManager = device->getContextManager();
contextManager->activateContext(driver->getExposedVideoData()); // take over GL context
// load textures

 // thread releases GL context when it ends
contextManager->activateContext(irr::video::SExposedVideoData());

Which then means you can't do any rendering in the meantime. I'm not sure right now about other drivers like d3d or software.

There are some options, but they are a bit work. For meshes without textures you basically just have to avoid that the main-thread does any operations accessing the meshcache. Or you could use the meshloaders directly and add the meshes to the Irrlicht meshcache after the background thread is done.

For meshes with textures you have to prevent the texture loading and then set textures yourself later. You can prevent the usual texture loading for some formats if you are using the svn trunk version of Irrlicht by setting IMeshLoader::setMeshTextureLoader to your own implementation which doesn't load textures directly. Problem is the interface wasn't thought out well enough by me (sorry), so you can remember all textures you need in an own meshtextureloader, but you don't get the information to which materials those should be applied later (I needed that interface just to know about textures in formats without loading them, so I didn't realize this back then). Also not all formats support this interface yet.

So... in general means you have to add your own format file for texture-information (which mesh material and which texture-slot needs which texture).
Or figure out some patch to improve that meshtextureloader interface.

And then the trick to loading textures is probably to just load the images in the background thread (those don't need opengl context). And then create the textures from the images later in the main-thread.

So yeah... that's kinda the ideas I have about this. And I only realized how much IMeshTextureLoader interface is missing while writing this answer *sigh*