Multithreading?

[ColinGilbert]

First of all, nice job on this library! The 37 pages of documentation really makes it stand out.

I've looked at the source code (nice job on the cleanliness and modularity btw!) and noticed that there wasn't (yet) any multithreading for the solver/collision detection. Is this in the works for a future release?

[DanielChappuis]

Yes, multithreading is planned (probably using OpenCL on CPU and GPU) but not in the next release (version 0.6.0). Maybe in the next one.

[TrevorSundberg]

A question about multi-threading: I'm using your library for detecting collisions with tools on a CNC machine. I'd like to speed this up by taking advantage of multi-threading. I was assuming that if I made duplicate CollisionWorlds I could do this, but to your knowledge do you share any global or class static data that would prevent multi-threading like this?

I did a quick search through the code-base to find any non-const statics variables and the only ones I could find were on MemoryAllocator and Profiler. Obviously Profiler is optional, and looking closely at MemoryAllocator it seems that it only initializes the static data once (so provided I did this on the main thread before launching other threads it should be fine).

Also have to agree, very cleanly written!

[DanielChappuis]

Thanks for your feedback.

First, I am about to release the next version (0.7.0) of ReactPhysics3D very soon. In this new version, the collision detection is more robust and the speed of the library is faster. You can already try it by checking out the "develop" branch. Note that there are some small API changes with this new version.

Next, I will start working on multi-threading for the next release.

About your question, I do not know any static data that might be problematic (except what you said about the Profiler and MemoryAllocator) but I'm not really sure. The best way is to try it.