weird simulation

General discussion about Box2D tutorials
klemen
Posts: 11
Joined: Fri Feb 20, 2015 8:27 am

weird simulation

Post by klemen » Fri Feb 20, 2015 8:34 am

Hi....

... so... i've been dealing with box2d problem for a while now. I cant get pass this point, so i hope someone can help me.

I've created simple scene in RUBE editor, export it via json, import it in my game and renderd it with Polycode game engine. (I'm using OSX 10.10 btw)
Objects appear to move and rotate correctly, everything seems to work just fine. At this point im positive, that im drawing and updating my sprites corretly.

But... if I build more complex scene (multiple joints, bodies...) ... still everything works fine in RUBE editor simulation.
If i import this scene to my game, strange things begin to happen. Bodies connected to joints begin to act weird. Simulation just isnt right. Outcome is completely different, than the one in RUBE editor (RUBE editor simulation is perfect). If i make bodies as bullets, then simulation gets realy realy weird. Sprites begin to have invisible edges, they begin to stuck in eachother, weld joints dont keep up....

I should mention, that the time step, iterations, gravity... are the same in my game and in rube editor. And ofcourse i use fixed time step.
Here are the other things that i tried, without success:
- different box2d versions + liquidfun version
- recompile box2d with different optimizations
- export scene to raw cpp file
- multiple different steps per second and iterations ( results vary, but there is allways a lot worse precision in my game)

In a week or so, i will try to see if i have same problem on a Linux PC...

I'm desperate at this point... so... if someone has a clue, what might be going on.. please help.

best regards to you all,
Klemen

iforce2d
Site Admin
Posts: 860
Joined: Sat Dec 22, 2012 7:20 pm

Re: weird simulation

Post by iforce2d » Fri Feb 20, 2015 11:59 am

Seems to me that you just need to figure out what the difference is between your simple scene and your complex one - ie. add things bit by bit to the simple scene and see where the problem fist appears.

Apart from that suggestion, it sounds like maybe you are not looking at the debug draw display (since you mention sprites having invisible edges). In my experience, trying to figure out what's happening without having the debug draw display to look at is a waste of time. Chances are if you saw the debug draw, it would quickly be obvious what's happening, or at least you would be in a better position to investigate.

klemen
Posts: 11
Joined: Fri Feb 20, 2015 8:27 am

Re: weird simulation

Post by klemen » Fri Feb 20, 2015 1:38 pm

Thank you for your answer.
I will try to use debug draw and see what happens... i'll post my results....

bye,
Klemen

klemen
Posts: 11
Joined: Fri Feb 20, 2015 8:27 am

Re: weird simulation

Post by klemen » Sat Feb 21, 2015 8:04 am

Hi.

I've tried debug draw. Simulation works the same as in RUBE editor, if warm start, time of impact and sub-stepping is set to true.

So... obviously something is wrong with my program. So i decided to check everything again. And I found nothing. Then i tried to play with SetContinuousPhysics. I found out, that if I set ContinuousPhysics to false AFTER import from json file, everything works as expected. :)
If i set ContinuousPhysics to false BEFORE import from json, i get this weird behaviour.
Its strange, because i looked into b2dJson code...
worldValue["continuousPhysics"] = world->GetContinuousPhysics();
world->SetContinuousPhysics( worldValue["continuousPhysics"].asBool() );

and it seems, that everything is OK here.

The main thing is, that now everything works. :)
Thank you again for your help.

best regards,
Klemen

klemen
Posts: 11
Joined: Fri Feb 20, 2015 8:27 am

Re: weird simulation

Post by klemen » Sat Feb 21, 2015 3:26 pm

hm... I was to quick with my verdict about this.

Of course if you turn off continuous physics, you also disable bullets. So i am at the beginning again.

Current status is:
If i disable continuous physics, simulation works nice. Sprites rotate and change position, as they should. Joints behave as expected. But... those bodies are not bullets. Their position is not calculated with CCD. So i get tunneling with those bodies.

Is there any reasonable explanation for this?

bye,
Klemen

iforce2d
Site Admin
Posts: 860
Joined: Sat Dec 22, 2012 7:20 pm

Re: weird simulation

Post by iforce2d » Sat Feb 21, 2015 4:21 pm

It's a bit hard to diagnose anything given vague descriptions eg. bodies act "weird" etc. Now that you are looking at the debug draw, can you see any reason why the sprites might have had (previously) invisible edges? Did you try gradually adding complexity until it ran as you expected?

klemen
Posts: 11
Joined: Fri Feb 20, 2015 8:27 am

Re: weird simulation

Post by klemen » Sat Feb 21, 2015 4:48 pm

Thanks for the answer....

At the http://www.klapa.eu/continuousYES.gif you can check what i mean by the weird behaviour. Here is continuous physics enabled.

At this example http://www.klapa.eu/continuousNO.gif there is continuous physics disabled.


This is how i call update in both cases at 60Hz:

this->_physicsWorld->Step(60,100,100);
and for each sprite:
_entity->setRoll(_body->GetAngle() * RADTODEG );
_entity->setPosition(_body->GetPosition().x,_body->GetPosition().y);

I'll dig myself into debug draw again... and try to resolve this.

thank you for your help.

iforce2d
Site Admin
Posts: 860
Joined: Sat Dec 22, 2012 7:20 pm

Re: weird simulation

Post by iforce2d » Sat Feb 21, 2015 8:01 pm

Is that debug draw? Static bodies should be green, dynamic bodies red etc if implemented properly.

klemen
Posts: 11
Joined: Fri Feb 20, 2015 8:27 am

Re: weird simulation

Post by klemen » Sat Feb 21, 2015 8:27 pm

No. This is from my program. Debug draw simulation with continuous physics works ok.

iforce2d
Site Admin
Posts: 860
Joined: Sat Dec 22, 2012 7:20 pm

Re: weird simulation

Post by iforce2d » Sat Feb 21, 2015 10:02 pm

The point is to look at the debug draw in the situation that does not work ok, then you might see some clues. The display from your program may not be showing you exactly what is happening.

Post Reply