Running Irrlicht Engine on secondary thread

[emanuel]

I'm trying to use Irrlicht for visualising some complex computer vision application.

For that purpose, I created a small class that spawns a worker thread. The worker thread initialises the driver, device, scene manager and gui environment, using code similar to Tutorial 1, except using OpenGL. Then, the worker thread starts running a draw loop, also similar to Tutorial 1. I'm taking care of synchronisation and made sure other thread than the worker thread calls any methods related to Irrlicht or OpenGL.

However, I can only see console output. No window is created. No error, crash, segfault or exception is visible.
If I invoke my code using the application's main thread, everything works fine.

How could I find/debug the issues here? What are the requirements of Irrlicht regarding the calling thread?

I'd like to emphasis, that I don't want to multithread Irrlicht in any way, I just want to execute it entirely on a different thread than the main thread.

Thanks in advance,
Emanuel

[CuteAlien]

Hi, if this is still similar to tutorial1 you probably have a quick example so we can reproduce it. Please post that.

[hendu]

On some platforms only the main thread can access windows and/or 3d. Why not do your calculations in the worker thread?

[emanuel]

Thank you both for the quick reply!
Hendu, sadly doing so is not an option due to the architecture of the program I'm trying to visualize.

CuteAlien, please find a minimal example below. I removed all return value checks for compact code. The interesting part here is probably the main function. I use an std::thread to execute code similar to tutorial 1 on a separate thread. Thy operating system I'm running is OSX El Capitan 10.11.2 Beta. The below code should compile with clang or gcc.

Code: Select all

 
#include <irrlicht.h>
#include <thread>
 
using namespace irr;
 
using namespace core;
using namespace scene;
using namespace video;
 
void runExample()
{
    IrrlichtDevice *device =
        createDevice( video::EDT_OPENGL, dimension2d<u32>(640, 480), 16,
            false, false, false, 0);
 
    IVideoDriver* driver = device->getVideoDriver();
    ISceneManager* smgr = device->getSceneManager();
    const IGeometryCreator* geoCreator = smgr->getGeometryCreator();
 
    IMesh* sphereMesh = geoCreator->createSphereMesh(1);
    IMeshSceneNode* sphereNode = smgr->addMeshSceneNode(sphereMesh);
 
    sphereNode->setMaterialFlag(EMF_LIGHTING, false);
    sphereNode->setMaterialFlag(video::EMF_WIREFRAME, true);
 
    smgr->addCameraSceneNode(0, vector3df(0,10,0), vector3df(0,0,0));
    
    float rot = 0;
 
    while(device->run())
    {
        driver->beginScene(true, true, SColor(255,100,101,140));
 
        smgr->drawAll();
        
        sphereNode->setRotation(vector3df(rot * 3, 0, 0));
 
        rot += 0.1;
 
        driver->endScene();
    }
 
    device->drop();
}
 
int main() {
    //Works Fine
    //runExample();
 
    //Does not show the rendering window. The render loop is running, however. 
    auto worker = std::thread(runExample);
    worker.join();
 
    return 0;
}
 

[chronologicaldot]

Thank you both for the quick reply!
Hendu, sadly doing so is not an option due to the architecture of the program I'm trying to visualize.

?? Why not change the architecture of your program? Couldn't you reverse the roles? i.e. Run Irrlicht in your main thread and have your "main" operations in another thread. After all, unless you're embedding or controlling Irrlicht in/with another GUI system (which has been done; see elsewhere), nothing else should need to control your main window, right?

[emanuel]

Couldn't you reverse the roles?

No, because I'm using it for debugging/visualisation of a rather complex SLAM application, that only kicks in on some cases. A reverse of control would be non-optimal at the moment.

The current solution for me is to block the main thread and run Irrlicht there until the window is closed. However, I'd prefer fancy real-time visualisation.

[CuteAlien]

I see nothing basically wrong in the code, so it's probably like hendu mentioned. You could test by using a software renderer like EDT_BURNINGSVIDEO for comparison.

[hendu]

How much data do you need to visualize? If it's not too much, you could spawn a separate process.

[thanhle]

Alternative is using

createDeviceEx();

and tell it to render to your DrawingSurfaceID (Win handle ID etc)

Regards

[Mel]

Irrlicht hardware drivers aren't thread safe, or at least, so far, you can enable the Direct3D9 with some thread safe setting, but i wouldn't warrant that it is going to work, so unless you use an entirely software driver, Irrlicht should always run in the main thread of your program

[Granyte]

DX9 thread safety is dependent on driver so don't trust it
how ever the dx11 driver in the shader-pipeline branch should handle being used in threads without issue at least last time i tested it if everything is happening in a single threads as long as it's always the same it should work

Beside the current example works on windows 10 visual studio 2015 and has no reason not to work properly.
Except your current OS i recently had to port a project to OSX and one of the things i found is OSX does not allow you to create windows at will so good luck with your issue but your platform may be limiting you.