Understanding physics simulation timing

[microdot]

Hi all,

First off let me start by saying I do and I don't understand the idea behind this process. What a paradox. Let me explain.

Regardless of 3d rendering engine or newton wrappers for whatever language you're writing in - when you issue a .Simulate() to Newton (can't recall off hand Newtons internal call for this), you're specifying a rate at which the physics engine must update versus your scene.

Originally I was using a simulate with fps_elapsed_in_seconds * by a factor. Really stupid but good enough to play around. Of course, the more bodies you put into a scene whether they are phsyics bodies or scene meshes - your frame rate's going to drop. Along with that - your simulation rate.

So I did what every good developer does - I decoupled my physics simulate from the framerate itself, basically as:

Code: Select all

float fRemainingDeltaTime = 0;
        void SimulateFixedStep(float fDeltaTime, float fFixedStepTime)
        {
            fDeltaTime = fDeltaTime + fRemainingDeltaTime;
            while (fDeltaTime > fFixedStepTime)
            {
                physics.Simulate(fFixedStepTime);
                fDeltaTime -= fFixedStepTime;
            }
            fRemainingDeltaTime = fDeltaTime;
        }

and executed as:

Code: Select all

physics.SimulateFixedStep(myfancyengine_noreallyitis.GetTimeElapsed() * 0.001f, 1f / 60f);

<-- *.001f to get to seconds and 1/60f for 0.0166 fixed step time (FPS is actaully locked to 60FPS).

So why this long labourious post. Well in decoupling physics from fps, I could render many more physics bodies without frame rate impact. In doing so however... their simulation rate has slowed down the point of not being fast enough nor accurate enough.

What am I not understanding about simulation rates that's messing me around here?

Oh and to top it all - using Newton 1.53 (and for very good reasons which I'll elaborate on should this be half the problem).

[microdot]

To illustrate what I meant earlier about accuracy here is output, meters per second covered by the physics body. The output is rendered on the render pipeline (fps determine) but still - should not be this erratic during constant velocity applied:

Code: Select all

0.01
0.03
0.05
0.07
0.09
0.11
0.14
0.14
0.16
0.17
0.18
0.18
0.22
0.23
0.16<-- #1
0.24
0.26
0.25
0.29
0.29
0.26
0.33
0.31
0.39
0.42
0.3<-- #2
0.43
0.42
0.45
0.48
0.49
0.48
0.51
0.52
0.51
0.57
0.6
0.59
0.94<-- #3
0.67
0.73
0.73
0.78
0.58
1.23<-- #4 I think this enough example, the others are a bit more difficult to see.
0.65
0.92
0.85
0.94
1.02
1.03
1.08
1.12
1.17
1.1
0.99
1.5
1.02
1.53
1.45
1.4
1.28
1.78
1.44
1.92
1.94
1.35
1.95
2.01
1.89
1.9
1.05
3.27
1.05
3.55
1.08
3.55
1.07
3.23
2.04
2.08
2.26

If I revert to a non decoupled version of code (FPS driven physics update) with 1 body, the output is linear and predictable.

I've tried with SOLVER 0 and SOLVER 1 but not with 2, 7 or 10. Not sure which is meant to be used either.

[Julio Jerez]

what are those values? displacement on every step?
if they are the delta displacement, then it means the drag coefficient is no zero.
if a body is moving with a const velocity, if the drag is zero, then the velocity displace should be const.
set the drag to zero, and the will be constant.

also use Newton 2.33 not 1.53, the way you can step in the code and check that is not doing anything nefarious, is is a just plain a simple Euler simplextic integration.

[microdot]

Those values are m/s covered from point A to point B every frame. The trouble is I cannot migrate to Newton 2.0 - the engine I am using is for 1.53. To add more details I am talking about vehicle bodies too. I am not sure of this engines implimentation of vehicles whether multibody or raycast (TrueVision engine).

Let me poke around the code. What should be my simulation rate too, because vehicles are moving very slow now

[microdot]

No. There is nothing I can see that would be doing this.

I've modified force to be 100 and this is result - problem is clearer.

Code: Select all

0.47 <-- expected at rest
2.62
3.4
3.89
4.24
4.63
4.36
4.76
4.61
5.01
6.01
3.88 <-- as if sudden friction
5.09
5.57
5.93
4.14 <-- again
5.4
5.23
5.46
5.22
5.38
5.2
5.16
5.22
5.61
5.73
5.76
5.7
4.9 <-- again
5.02
5.66
5.83
5.5
5.56
5.61
6.01
5.84
3.04
9.73
5.54
5.61
6
2.95
8.68
5.59
6.03
6.01
6
3.21
5.19
10.12 <--biggest differences
3.12
9.95
3.11
9.33 <--biggest differences
6.19
6.11
3
10.47 <--biggest differences


My question is now, even though render and physics are seperate, if frame rate falls below certain amount, does it affect simulation at all? Perhaps my timer inside this engine is wrong! (not Newton, truevision)

[microdot]

Okay, I've played around with damping, if I set to 0 for all four wheels, results are even worse, what should damping be set at (in other words what does it represent in real world units).

Another question of mine, i've stuck to real world units through out my code. But weight, I kept as real life kg for the chassis. Should this be something else?

[microdot]

Wait - I've just realised I am basing distance over time on distance / elapsed frame time. This is COMPLETELY frame rate controlled...

I don't think it's Newtons updates doing this, perhaps there is another hi res time I can use (another method)

[Julio Jerez]

the engiene is open source, from file dgBody teh code that integrate the velcity is this

Code: Select all

void dgBody::IntegrateVelocity (dgFloat32 timestep)
{
...
   //   IntegrateNotUpdate (timestep);
   m_globalCentreOfMass += m_veloc.Scale (timestep);

   m_matrix.m_posit = m_globalCentreOfMass - m_matrix.RotateVector(m_localCentreOfMass);

}

and the code that integrate the accelration is this

Code: Select all

void dgJacobianMemory::ApplyExternalForcesAndAcceleration (dgFloat32 tolerance) const
{
   dgFloat32* const force = m_force;
   const dgJacobianPair* const Jt = m_Jt;
   const dgBodyInfo* const bodyArray = m_bodyArray;
   const dgJointInfo* const constraintArray = m_constraintArray;
   dgFloat32** const jointForceFeeback = m_jointFeebackForce;
   dgJacobian* const internalForces = m_internalForces;

   dgVector zero (dgFloat32 (0.0f), dgFloat32 (0.0f), dgFloat32 (0.0f), dgFloat32 (0.0f));
   for (dgInt32 i = 0; i < m_bodyCount; i ++) {
      internalForces[i].m_linear = zero;
      internalForces[i].m_angular = zero;
   }

   dgInt32 hasJointFeeback = 0;
   dgFloat32 accelTol2 = tolerance * tolerance;
   for (dgInt32 i = 0; i < m_jointCount; i ++) {
      dgInt32 first = constraintArray[i].m_autoPairstart;
      dgInt32 count = constraintArray[i].m_autoPaircount;

      dgInt32 m0 = constraintArray[i].m_m0;
      dgInt32 m1 = constraintArray[i].m_m1;

      dgJacobian y0;
      dgJacobian y1;
      y0.m_linear = zero;
      y0.m_angular = zero;
      y1.m_linear = zero;
      y1.m_angular = zero;

      for (dgInt32 j = 0; j < count; j ++) {
         dgInt32 index = j + first;
         dgFloat32 val = force[index];

         _ASSERTE (dgCheckFloat(val));
         jointForceFeeback[index][0] = val;

         y0.m_linear += Jt[index].m_jacobian_IM0.m_linear.Scale (val);
         y0.m_angular += Jt[index].m_jacobian_IM0.m_angular.Scale (val);
         y1.m_linear += Jt[index].m_jacobian_IM1.m_linear.Scale (val);
         y1.m_angular += Jt[index].m_jacobian_IM1.m_angular.Scale (val);
      }

      hasJointFeeback |= (constraintArray[i].m_joint->m_updaFeedbackCallback ? 1 : 0);

      internalForces[m0].m_linear += y0.m_linear;
      internalForces[m0].m_angular += y0.m_angular;
      internalForces[m1].m_linear += y1.m_linear;
      internalForces[m1].m_angular += y1.m_angular;
   }

   for (dgInt32 i = 1; i < m_bodyCount; i ++) {
      dgBody* const body = bodyArray[i].m_body;
      body->m_accel += internalForces[i].m_linear;
      body->m_alpha += internalForces[i].m_angular;

      dgVector accel (body->m_accel.Scale (body->m_invMass.m_w));
      dgVector alpha (body->m_invWorldInertiaMatrix.RotateVector (body->m_alpha));
      dgFloat32 error = accel % accel;
      if (error < accelTol2) {
         accel = zero;
         body->m_accel = zero;
      }

      error = alpha % alpha;
      if (error < accelTol2) {
         alpha = zero;
         body->m_alpha = zero;
      }

      body->m_netForce = body->m_accel;
      body->m_netTorque = body->m_alpha;

      body->m_veloc += accel.Scale(m_timeStep);
      body->m_omega += alpha.Scale(m_timeStep);
   }
}

Basically it adds the internal forces calculated by the joint solver to the external forces applyed in force and torque callback,
the result is divided by the mass of the body to get the acceleration, in you case both internal and external forces are both zero.
therefore the net acceleration soudl be zero too, and soudl no modify the velocity when integrate by the time step

body->m_netForce = body->m_accel;
body->m_netTorque = body->m_alpha;

body->m_veloc += accel.Scale(m_timeStep);
body->m_omega += alpha.Scale(m_timeStep);

and after the what followed in the integration of the velocity, is something is changing the velocity it must be that you are calling with a variable force, or you are printing some wrong variable.
Even if the time step is variable the velocity should be more or less const, and I see that it is an increasing quantity in your listing, even when is goes down, the next print recover, so somewhere the value is being saved.
these functions are used in all version of Newton, so I do no know what could be causing that, I do no even have 1.53 anymore.

[microdot]

Thanks Julio!

I'll play around a bit more my side until I get this working better

[Stucuk]

Code: Select all

float fRemainingDeltaTime = 0;
        void SimulateFixedStep(float fDeltaTime, float fFixedStepTime)
        {
            fDeltaTime = fDeltaTime + fRemainingDeltaTime;
            while (fDeltaTime > fFixedStepTime)
            {
                physics.Simulate(fFixedStepTime);
                fDeltaTime -= fFixedStepTime;
            }
            fRemainingDeltaTime = fDeltaTime;
        }

The problem with that code is that some frames you could do multiple "Simulate" calls while other frames you only do one(So some frames would be slower than others). So you can get moments of "Lag".

[Julio Jerez]

The problem with that code is that some frames you could do multiple "Simulate" calls while other frames you only do one(So some frames would be slower than others). So you can get moments of "Lag".

that is where the smoth interpoltion come it to help, it real fix the Lag problem.
That with runing on seprate thread makes amost perfect.

Maybe we should make that part of newton 3.

[microdot]

Really thank you guys! I appreciate the feedback, I was thinking tis a lag problem but could not be sure. Could the two of you recommend a way to get around this from outside the newton engine (in other words anything I can change in Simulate to interpolate newton updates somehow).

Thank you in advance and apologies if sometimes my explinations are not too clear.

[Stucuk]

Having the NewtonUpdate on a separate thread can help. But the problem with that is you then have to make your code thread safe. With a separate thread for the NewtonUpdate your nearly 100% guaranteed to have it update at the same interval each time.

[microdot]

Let me try this report back asap.

[microdot]

Okay frame rate bumped up a lot performance is excellent and values have started to look closer each simulate. Not like before. Trouble is simulation is stable but slow. To best explain if I apply 100 or 1000n of force the vehicle moves the same speed, the difference comes in when taking a corner, the vehicle at 100 remains on track, the vehicle at 1000 rolls.

All of this is happening in slow motion. I am sending through elapsed time in seconds and a value of 1f / 60f for timestep.