ODE internal error

Hello, I am getting these errors randomly while playing in my game:



ODE INTERNAL ERROR 0
enabled body not tagged



ODE INTERNAL ERROR 2
invalid operation for geom in locked space (....odesrccollision_kernel.cpp:495)
OK



ODE INTERNAL ERROR 2
invalid operation for locked space (....odesrccollision_space.cpp:690)
OK



Any ideas on how to disable something (collisions?) and/or a way to fix this?

By the way, I saw in another thread someone saying:


You can modify the local vectors/quaternion where you want (before and after addition to a parent). But you cannot call updateGeometricState/updateWorldVectors without affecting ODE.


But I don't really understand the "without affecting ODE." part.
Does it mean that we cannot call these in the "updateWorldData" method?

Ok, I had some updateWorldVectors and I removed em all.

Still, I get these random errors :frowning:



We use updateGeometricState in an updateWorldData that we have overridden from Node. (We thought this was correct since the Node make calls to updateGeometricState too).

Looks like threading/concurrency problems. Make sure you're not updating physics stuff while the PhysicsSpace.update method is running (either use locking or just use one thread and do not call any update methods from callbacks).

There is only one thread (openGL) updating nodes. Is there any way to debug this?

Yes, attach a native debugger and put a breakpoint into those cpp lines :roll:



Double check those threads first. It is most likely a threading problem and fiddling around with that native debugger is not fun. You could suspend all threads but the GL thread in the java debugger and see if it still occurs, for example.

irrisor said:

Yes, attach a native debugger and put a breakpoint into those cpp lines :roll:

Double check those threads first. It is most likely a threading problem and fiddling around with that native debugger is not fun. You could suspend all threads but the GL thread in the java debugger and see if it still occurs, for example.


ahh yes that seems to be one of the errors i'm currently having i was suppose to create a separate thread for the physicsSpace I had thought that one was made when i intitalized the class. I would then lock the thread anytime i'm updating the space correct.

i got it to work every time by creating a boolean "STOP" putting it inside the class that makes and updates the physic space and setting it as:
if(!stop)physics.update(tpf*physicsSpeed);
if i load 20 models and do

   gameSingleton.get().stop=true;
                                /**
                                    *Load w/e i need
                                    */
         gameSingleton.get().stop=false;


is their a way to check if the physicsSpace is ever doing work and stop the update instead of having to change the boolean within the main class because if i was to load characters during run time the game 1 would have to pause b4 i would be able to add them and 2 i seem to re-exhibit the same problem if i put it at the beginning and end of the classes i call within   /***Load w/e i need*/
So i should really:
1.) a.)Create and handle the physics space within another thread
                                    or
     b.)should it be created within the main thread and any calls to it be handled by another thread(is this possible)?
                                    or
     c.)create two physics space one in main and one in another thread and then transfer construct and do everything for physics in the other thread and transfer them to main thread?
2.) figure a way to temporarily pause physics update while game is running without disrupting the players(most things that move in the app is by the physics engine)

how can i go about doing this anyone?
Empire Phoenix said:

As I said, it does not seem to be a multithreading problem.
Intresting is, that I cant find any error description on their website/wiki ...


me neither i do know its from loading to many things at a time because if i stop the physics update before i create anything and restart it after everything is created then its fine.(although each model loads one by one and hangs in the air until everyhting is created) however what if i wanted to generate enemies at a trigger in game it stops the game because the moving is handled by the physics i'm unsure of what to do exactly would I have to load everything that i would possibly need at start which sometimes causes issues(when i load around 20 models at once sometimes it stops and hangs at around 9) I was really planning on loading as needed any suggestions??

or should i simply create another physicsSpace and give the results to the original one and then destroy that space used to generate the physics but then again how would i get the loaded material from that physicsSpace into the next one anyone?? i've been stuck for a while now…

anyone?

I remind there was another thread about how to use multithreading with physics some time ago, with a working solution, but I don't know the title so you have to search manually, sorry

Empire Phoenix said:

I remind there was another thread about how to use multithreading with physics some time ago, with a working solution, but I don't know the title so you have to search manually, sorry


i've been searching the forums for answers for a while now but i guess i'll just keep searching because this seems to be the issue with all of the problems within my project.

Hey it seems tob e not a multithreading issue tho.



I now have it too  :x , and I tried everything over Callables in Update without any effet.

this might work:



create a threads of the physics with this update method:

    stop all thread;

    while(all threads not stopped yet);

    physics.update;

    resume all threads;



MIGHT work, not tested and not even sure if the theory is correct. As i know, calling a thread to stop will not stop it untill it finished it's update,call,whatever method it is doing right now! so you have to create a loop that will only stop as every other thread report thenselves as stopped!



will lose a lot of time waiting for the threads to stop every physics update, but might work!

As I said, it does not seem to be a multithreading problem.

Intresting is, that I cant find any error description on their website/wiki …

The creation might very well be possible, cause while my server only so far dies on stack overflows at the 770 test networked box, the clients frequently die as soon as they connect when there are more than a few of the testboxes around.



Since I create the CPhysEntity in the Update via a Callable I assume that it can't berunning at the same time however. (However it is very possible that more than one object is created in one update)

How would we create new physics objects without interrupting the current physics space update?

Well this seems a far lesser problemf or me, since I use FixedLogicrateGame as y base.



So when I create the Physic geometries in the Update via the Callable, it does not affect Framerate and Update speed very much, as long as it is faster than one Tick. However I'm of course not very happy with that as well.

just to make sure, how many triangles your models have? and you are using .generatePhysicsGeometry(true)?

im using a very complex model right now that have a lot of triangles and it generates it's own geometry. and i usualy get errors like those, it even crashes when things collide with the hi-polly model ;D

Guedez said:

just to make sure, how many triangles your models have? and you are using .generatePhysicsGeometry(true)?
im using a very complex model right now that have a lot of triangles and it generates it's own geometry. and i usualy get errors like those, it even crashes when things collide with the hi-polly model ;D


through small tests i've run i've found out that the tri count within the geom doesn't matter as much though i'm not completly sure. But let me ask are you creating more than one model in space and if so do they intersect by creation. Sometimes instead of forcefully flying away it returns an error.

and no i no longer use .generatePhysicsGeometry method