Hi, I'm reading about how threads are working (semaphores, mutex, etc.).
I know that it would be more than a lot of work to make all IRRlicht thread safe (I don't know if that would ever be possible).
But I was wondering if it would it be easy to use threads with the collision system? (RayCollisions, CollisionResponseAnimator)? Since all the data is loaded and we could pass the pointers to the thread and get the mutex (updating position, return the collision point, etc.)
The only thing that I think IRRlicht would need as running multithreaded, is the loading (anything) and collision management. I know that for loading it would be a real pain, as it would mean modifying all the loaders and block the scene manager to render a loading node untils it's completely loaded. But does the collision system have those types of constraints?
About threads...
-
christianclavet
- Posts: 1638
- Joined: Mon Apr 30, 2007 3:24 am
- Location: Montreal, CANADA
- Contact:
To be frank, Irrlicht's collision detection is fairly lightweight and is nowhere near as good as a full physics engine, such as ODE, Bullet, or PhysX. With good program design, it's fairly straightforward to run Irrlicht in one thread and a physics engine in the other. On that note, I'm in the process of creating a multithreaded engine which uses Irrlicht for graphics and Bullet for physics. I'll post more when I have something to show.
Yes, but it can get really tricky really fast. Guaranteeing atomic operations isn't easy.Simpe wrote:To be honest, if you want performant threading-communication you should leave semaphores, mutexes and other poor-performing threading-communications out of the context. Lock-free communication as far as possible is the way to go.
-
christianclavet
- Posts: 1638
- Joined: Mon Apr 30, 2007 3:24 am
- Location: Montreal, CANADA
- Contact:
HI, Thanks for the answers. How could you achieve "lock-free" when I think you need to sync with the scene manager to draw the scene. (Perhaps could be done with a return of data that give the collision point, but for a collisision animator, it updating the node position will require at least some lock operation to be in-sync with the application...
Anyway, I'm only asking to learn how it work. I don't have any plan to implement anything soon.
Anyway, I'm only asking to learn how it work. I don't have any plan to implement anything soon.
There's a lot of atomic operations out thereslavik262 wrote: Yes, but it can get really tricky really fast. Guaranteeing atomic operations isn't easy.
There really isn't too much tricky about it. You just have to solve it in a way that's more adapted for your demands rather than apply a general solution to a specific problem. The real question is what your latency-issues are. Besides, most modern compilers (well, all that I've used) provides an api for the common atomic operations (inc/dec/inc-and-read/dec-and-read etc).
/S
-
Cobra El Diablo
- Posts: 3
- Joined: Fri Sep 25, 2009 10:39 pm
- Location: UK
At the moment I am creating a content editor for use with Irrlicht, well a layer above it to be precise, and it is quite happy with having multiple threads, just make sure that you 'sync' the refresh rates (otherwise nasty texturing effects take place).
My application has it's own thread that deals with the windows gui interface which calls methods from a class within a seperate dll that has multiple threads (rendering, etc), it even deals with the handling of the messages destined for the 'owning' windows control that I am making Irrlicht use for it's rendering output.
Some screenshots.
Editor (netEditor only because it's being written as a C++ .NET application) and is being used as a container for the engine (OpenGSE) as a content creation tool for it.
Scene 0: http://www.flickr.com/photos/56603839@N07/5226983623/
Scene 1: http://www.flickr.com/photos/56603839@N07/5226983647/
as you can see from the screen shots is a still very much a wip
My application has it's own thread that deals with the windows gui interface which calls methods from a class within a seperate dll that has multiple threads (rendering, etc), it even deals with the handling of the messages destined for the 'owning' windows control that I am making Irrlicht use for it's rendering output.
Some screenshots.
Editor (netEditor only because it's being written as a C++ .NET application) and is being used as a container for the engine (OpenGSE) as a content creation tool for it.
Scene 0: http://www.flickr.com/photos/56603839@N07/5226983623/
Scene 1: http://www.flickr.com/photos/56603839@N07/5226983647/
as you can see from the screen shots is a still very much a wip
Cobra El Diablo
I'm really a newb to Irrlicht and to C++ (I switched from Java because of the lack of updated Java support). So if I happen to be talking mis-informed or naïve BS, I do apologise.
It seems to me that using threads for any kind of scene event would be overkill. Any event would have to be dealt with before the scene could continue, thus the calling thread would have to wait for the event thread to finish. Thus making the thread effectively the same as a direct function call.
It seems to me that using threads for any kind of scene event would be overkill. Any event would have to be dealt with before the scene could continue, thus the calling thread would have to wait for the event thread to finish. Thus making the thread effectively the same as a direct function call.