UpdatePhysics() in demoSandBox

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

UpdatePhysics() in demoSandBox

Postby misho » Mon Feb 04, 2019 4:29 pm

Hi, everyone

I need a bit of help/clarification with what's going on in DemoEntityManager::UpdatePhysics() in demoSandBox project.

I have noticed that my rocket launch simulation is getting timing performance that is dependent on the FPS of my simulation - and that shouldn't be! I checked my code, and all the relevant code is placed correctly (as in, NewtonUpdate() and physics-related calls are in the event loop, while rendering-related stuff gets called on every new frame).

After making sure that I am calling everything properly, I zeroed in on UpdatePhysics(), which I implemented exactly as in the demo code. Just as a test, I skipped all the code in this function, and called NewtonUpdate() immediately. The result was - my sim behaved properly - the timing of events became independent of FPS. However, skipping this code broke other things (Physics seem not to re-set properly).

Just to clarify: When I mention "timing dependent on FPS", I mean, for example, that my rocket fuel lasts 5 minutes at 40 fps, and only 3 minutes at 20 fps. That, of course, is wrong - it should last the same amount.

So - what is the proper way of calling NewtonUpdate()?

Thanks!
Misho Katulic
CTO, FSX SpacePort
TerraBuilder
www.terrabuilder.com
misho
 
Posts: 673
Joined: Tue May 04, 2010 10:13 am

Re: UpdatePhysics() in demoSandBox

Postby Julio Jerez » Mon Feb 04, 2019 6:37 pm

If you call the physic update from within the graphics update, it will run at a fix rate only if the graphics update is much faster than the physics update. This is how it works in the sandbox.
In the example 40 fps make make more calls that 20fps.

You could make a thread that implement a timer and put the physics update there but that requires some set up. In general the graphic update is much faster so these complex setup is not necessary.

Some people solve that problem be running a physics loop to catch up the lost time, but that only works when the physics is not what makes the update slow. In the sandbox this is allow up to two frames.
The reason is that when both graph and physics take similar time, doing only one update can produce glitch updates in this case is best to move the physics one frame into the future by another frame.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: UpdatePhysics() in demoSandBox

Postby misho » Mon Feb 04, 2019 8:01 pm

Julio Jerez wrote:Some people solve that problem be running a physics loop to catch up the lost time, but that only works when the physics is not what makes the update slow. In the sandbox this is allow up to two frames.
The reason is that when both graph and physics take similar time, doing only one update can produce glitch updates in this case is best to move the physics one frame into the future by another frame.


Well - my setup, from the physics standpoint, is rather simple (compared to what Newton is capable of, I.e. no rag doll controller, vehicle with transmission, etc.). I haven't bench marked it, but my physics loop is running probably at around 300-400 cycles per second, while my FPS rate is anywhere between 30-60.

I thought I could let Newton run at whatever my CPU cycle is, and whenever a frame is updated, I fetch the Newton state and assign it to visual objects. Isn't that the proper approach?
Misho Katulic
CTO, FSX SpacePort
TerraBuilder
www.terrabuilder.com
misho
 
Posts: 673
Joined: Tue May 04, 2010 10:13 am

Re: UpdatePhysics() in demoSandBox

Postby Julio Jerez » Mon Feb 04, 2019 8:16 pm

misho wrote:I thought I could let Newton run at whatever my CPU cycle is, and whenever a frame is updated, I fetch the Newton state and assign it to visual objects. Isn't that the proper approach?

yes you should be able to do that with eassy. but if you fps is lower than 30 them you probably need to make a thread that execute at a fix update so that the physic run at a guarantee time step
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: UpdatePhysics() in demoSandBox

Postby misho » Mon Feb 04, 2019 8:27 pm

Julio Jerez wrote:
misho wrote:I thought I could let Newton run at whatever my CPU cycle is, and whenever a frame is updated, I fetch the Newton state and assign it to visual objects. Isn't that the proper approach?

yes you should be able to do that with eassy.


I think I found the "problem": I haven't changed the value of

Code: Select all
#define MAX_PHYSICS_FPS            60.0f


to what I'd like it to run at, say ~400. Will that fix the problem?
Misho Katulic
CTO, FSX SpacePort
TerraBuilder
www.terrabuilder.com
misho
 
Posts: 673
Joined: Tue May 04, 2010 10:13 am

Re: UpdatePhysics() in demoSandBox

Postby Julio Jerez » Mon Feb 04, 2019 8:49 pm

to make is clear you, if you set update at ya 60 fops but you call the physics update at 30 fps the will no work because the update is to low,

if you game loop run say at 30 fps thsi mean you will be calling teh update at 30 fps passin 1/60 does nothing.


if you want to run the physics say at 240 fps but updating at 30 fps the you can do this.
after you create the newton world you call
you calculate the number of steps to run at 240 running at 30 tha is
Code: Select all
m_solverSubSteps = 240 / 30 = 8

NewtonSetNumberOfSubsteps (m_world, m_solverSubSteps);

the in the update loop you call

NewtonUpdate (1.0/30.0)
this will update the physics at 240 fps provided you keep the update at 30 fps.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: UpdatePhysics() in demoSandBox

Postby Julio Jerez » Wed Feb 06, 2019 2:57 am

Misho, if you are reading this,
do you rembenber whe the made the demo of the long rocket 35 meter long with capsule connect at one end and was spinning fast? the capsule separated by about 5.7 meter.

I said that the change was delicate and I will do later. I partially fixed the problem with the joint separation. Now I added the one of the missing turn, and the separation now is about 0.9 meter.

The marginal separation can be further reduced if I add the center of mass centripetal and the Coriolis back again, but I do not want to add that just yet because that tun is highly non linear and can cause other joints to blow up.

can you please check it out and tell be is is ok?

to check the different beween before and after. what is committed is the Fix.

you check the before you can open file ../sdk\dgPhysics\dgBilateralConstraint.cpp line 453
and chnge the #if 1 to #if 0

Dave if you read this, if you sync and test if teh joint are still stable afte this tweak.
if you remember last time we tried the joint whe blown up. by now the are too soft, whe there is some appreciable angular velocity.


I think that if not other bug, for must cases this should work fine because you model is actually a extreme case. The rocket is 35 muter long, the payload is at one end, tha pace it 18 meter away form teh origin, since the payload is 2 meter long. then is spinning at 10 radians per secund.
thsi produce a centripetal accelration of 350 gravities.

thet kind of accelration is capable to rip off any attachment, I do no think any real rocket will spin that fast, but you let me know.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: UpdatePhysics() in demoSandBox

Postby Dave Gravel » Wed Feb 06, 2019 3:18 am

I can't test for now.
I work to prepare my plugin demos sdk for release it public this week-end.
I currently work to show on the demos plugin how to do some basic opengl & newton dynamics.
https://www.youtube.com/watch?v=XCOkYxG6G2I

I back to my normal stuff after this release, I can't run my old demos from this release I need to update some changes and fix from the plugin.
I have take a note for remember to comeback about this thanks.
You search a nice physics solution, if you can read this message you're at the good place :wink:
OrionX3D Projects & Demos:
https://orionx3d.sytes.net
https://www.facebook.com/dave.gravel1
https://www.youtube.com/user/EvadLevarg/videos
User avatar
Dave Gravel
 
Posts: 800
Joined: Sat Apr 01, 2006 9:31 pm
Location: Quebec in Canada.

Re: UpdatePhysics() in demoSandBox

Postby misho » Wed Feb 06, 2019 2:38 pm

Julio Jerez wrote:Misho, if you are reading this,
...
thet kind of accelration is capable to rip off any attachment, I do no think any real rocket will spin that fast, but you let me know.


Hi Julio, yes I am definitely reading this :wink:

You are correct - the rocket will fall apart and blow up spectacularly at much lower rates of spin - that's partially the joy of simulating rocket launches: watching them blow up spectacularly :wink:, however, I haven't implemented this yet. At the moment, when there is an engine failure, they drop back to the ground in one piece.

Sometimes, when I test things, there are cases (induced by me, not Newton) where the rocket stage spins wildly, and all of its attached parts separate, but not detach, as if they are connected with rubber bands.
Misho Katulic
CTO, FSX SpacePort
TerraBuilder
www.terrabuilder.com
misho
 
Posts: 673
Joined: Tue May 04, 2010 10:13 am

Re: UpdatePhysics() in demoSandBox

Postby misho » Wed Feb 06, 2019 2:49 pm

Julio Jerez wrote:to make is clear you, if you set update at ya 60 fops but you call the physics update at 30 fps the will no work because the update is to low,

if you game loop run say at 30 fps thsi mean you will be calling teh update at 30 fps passin 1/60 does nothing.


if you want to run the physics say at 240 fps but updating at 30 fps the you can do this.
after you create the newton world you call
you calculate the number of steps to run at 240 running at 30 tha is
Code: Select all
m_solverSubSteps = 240 / 30 = 8

NewtonSetNumberOfSubsteps (m_world, m_solverSubSteps);

the in the update loop you call

NewtonUpdate (1.0/30.0)
this will update the physics at 240 fps provided you keep the update at 30 fps.


Regarding this... FSX has a setting that limits the upper FPS threshold. I have that set at 61 FPS. However, (obviously), the FPS varies, from 61, all the way down to 15, depending on how complex the scene is (for example, if there are a lot of 2D FX to render, like smoke and cloud sprites). So, according to what you wrote, couldn't I do something like this:

Code: Select all
m_solverSubSteps = 240 / m_currentFPS;
NewtonSetNumberOfSubsteps (m_world, m_solverSubSteps);
NewtonUpdate (1.0/m_currentFPS)
Misho Katulic
CTO, FSX SpacePort
TerraBuilder
www.terrabuilder.com
misho
 
Posts: 673
Joined: Tue May 04, 2010 10:13 am

Re: UpdatePhysics() in demoSandBox

Postby Julio Jerez » Wed Feb 06, 2019 3:34 pm

If the graphic can get as low as 15 then you best solution is to make physics update run in loop until it catch up with the graphic time. Since your physics is so lightway, it does not affect the performance.
But the parameters are still the same.
Basically you each time to call a physics update you are saying.
At 1/240 of a second advance the simulation by 1/30 of a second.
If the graphics run faster that 30 God you get few graphics steps and one physics update.
When the graphics fall below 30 fps the tres will be more physics updates.
After you get it all set up, the you can move the physic update to an background asycnronus thread and you get the physics for free provided there are idle cores.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles


Return to General Discussion

Who is online

Users browsing this forum: No registered users and 12 guests