Ok, I know that ODE itself is not capable of multithreading.
But is it possible to have to separate physicsSpaces at the same time?
We are getting the following exception:
ODE INTERNAL ERROR 2: joint and bodies must be in same world in dJointAttach()
Our scenario is the following:
We have two different windows in eclipse. At any given time only one should be displayed (simple reason: to avoid a hell of a lot of problems you get when trying to render to two different contextes).
So while one is selected the other one shouldn't be displayed but the world should keep running.
If we have two windows open we have one running renderthread and two running updatethreads. Each update thread has its own instance of the physicsSpace.
Is that possible and if it is possible does anybody have an idea why we are getting the above exception?
It should be possible. I never tested it, though. From looking at the code joints should automatically be created in the world of the physics space. You should check if you create the joints from the same physics space and if so, check the odeJavaWorld variable in OdeJoint:201 while creating your joint and have a look if anything goes wrong there…
I spend some time on that problem and it's pretty weird.
We are not using joints.
The methods that deal with joints are never getting called.
The 2 scenes I update have basically the same setup:
A static physics node with an attached node and a dynamic physics node with a box attached.
The dynamic box falls on the static box and bounces around.
I played around and finally found out the the seen crashes on a run of PhysicsSpace.update().
I debugged it to that point that I know that the update method always finishes. (System.out.println galore)
I guess the problem happens somewhere in the C-part (my wild guess).
After playing around with everything I finally realized that it is possible to have two physicsspaces at the same time but you MUST NOT update both at the same time.
I don't know why and right now I cannot investigate it further.
As soon as I got our next internal release done I hope to have some time to take a closer look and create a testsetup.
For now we are just pausing the whole scene when switching over to the other.
uh, right, parallel update is not supported. ODEJava uses static variables in the native part to store the contact information and thus collision detection and contact application is not supported in parallel sigh
This should be changed, of course, but I don't think I'll have the time in the near future. If you want to give it a shot, this is the problematic stuff in odejava.cpp (in odejava-jni module):
int floatContactBufChunkSize = FLOAT_CONTACT_CHUNKSIZE;
int longContactBufChunkSize = LONG_CONTACT_CHUNKSIZE;
static float *floatContactBuf = (float *) malloc(FLOAT_CONTACTBUFFER_SIZE);
static jlong *longContactBuf = (jlong *) malloc(LONG_CONTACTBUFFER_SIZE);
int contactBufCursor = 0;
This needs to be put in a struct/class and created/referenced seperately from the java part for all the collision detection functions...
Ok, as soon as I am done tinkering with the current release I will start working on this (but that will be some weeks).
Man, it's ages since I touched c++ code, expect stupid questions 