A place to discuss everything related to Newton Dynamics.
Moderators: Sascha Willems, walaber
by 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
-
- Posts: 673
- Joined: Tue May 04, 2010 10:13 am
by 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
-
- Posts: 12249
- Joined: Sun Sep 14, 2003 2:18 pm
- Location: Los Angeles
-
by 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
-
- Posts: 673
- Joined: Tue May 04, 2010 10:13 am
by 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
-
- Posts: 12249
- Joined: Sun Sep 14, 2003 2:18 pm
- Location: Los Angeles
-
by 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
-
- Posts: 673
- Joined: Tue May 04, 2010 10:13 am
by 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
-
- Posts: 12249
- Joined: Sun Sep 14, 2003 2:18 pm
- Location: Los Angeles
-
by 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
-
- Posts: 12249
- Joined: Sun Sep 14, 2003 2:18 pm
- Location: Los Angeles
-
by 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=XCOkYxG6G2II 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.
-
Dave Gravel
-
- Posts: 800
- Joined: Sat Apr 01, 2006 9:31 pm
- Location: Quebec in Canada.
-
by 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
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
, 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
-
- Posts: 673
- Joined: Tue May 04, 2010 10:13 am
by 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
-
- Posts: 673
- Joined: Tue May 04, 2010 10:13 am
by 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
-
- 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 11 guests