Ball Physics vs CollisionTree Suitability

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

Re: Ball Physics vs CollisionTree Suitability

Postby Julio Jerez » Thu Dec 06, 2018 11:34 am

anothertime12 wrote:P.S. with careful tuning of movement speeds and taking three NewtonUpdate per game loop the 'rolling on curved surfaces' seems to be working quite well now.

that's what I though at first, but the you mentioned the object move very wildly and that confused me.

In general with a higher simulation rate it should work better, because the error in each step will be within the range of the contact penetration limit.
however you do not want the physics to delivery work in the penalty range, you want the system to work by the range where the physics contributions dominate the penalties to correct integration errors.

what you show in the picture to me is almost identical case to the Ship Simulation game i'd mention before, a large mesh that move kinematically.
for that the engine function
Code: Select all
 void NewtonBodyIntegrateVelocity (const NewtonBody* const bodyPtr, dFloat timestep)

that when set properly, it makes it works to near perfection.

The engine does not do it automatically, you need do some set up on your size, and I can help you, the reason is that it is up to the end user to decide how to convert displacement to velocities.
for this the engine provide the Listener manager.
there are few example in the Sandbox that you can look at.

so what you do is that you register a listener that contain a list of those animated bodies
then in the pre update you iterate over each body and you set the linear and angular velocity extracted from the desired velocity and angular velocity

this will instruct the engine that the surface of that object is movable, then in
post update you iterate over the list again calling NewtonBodyIntegrateVelocity on each body.

the only thing you need to do on your side is to extract the linear and angular velocity from teh delta translation and delta rotation. and thsi is the part the engine can not do.
if you do that currently, the result should be near perfect.

do not get fooled by the fact that, that is seem to work an accept that, in is in fact not working at all, it is simply prevention from interpenetration, because the player is not receiving the velocity of the surface.
in the absent of anythong that will be fine, an people will get use to it, but it will no resenble the effect of people inside a drumb, which is provided bu the motion of the surface.
In fact lot of Coriolis and centripetal accelration emerge from that naturally.
Julio Jerez
Moderator
Moderator
 
Posts: 10984
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Ball Physics vs CollisionTree Suitability

Postby Julio Jerez » Sat Dec 08, 2018 8:59 pm

anothertime12 wrote:It does however create a new issue that the game is in slow motion (ie, 5 substeps gives the impression of 20% speed). ….Should I be doing something else as well as this?


what do you knwo you were right there was a big bug there, that bug is about 15 year old, the calculation to keep the damping the frame rate independent was wrong,

I run the comparation and you were right, if feel proportional slower to the fps.
no sure why you get ot right bu doing your own loop, but it does not matter, I have it fix now for what ever is worth.
Thank for point that out not sure hwo it wene unnoticed for so long.
Julio Jerez
Moderator
Moderator
 
Posts: 10984
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Ball Physics vs CollisionTree Suitability

Postby JoeJ » Sun Dec 09, 2018 4:59 pm

I remember a guy with similar game and problem, for him it worked to increase the tesselation.
Maybe you need higher subdivision for physics that for graphics here, and performance might no suffer a lot - worth to try.

anothertime12 wrote:Setting steps to 5 makes the game run in slow motion with the maximum speed considerably lower than not doing this.


This is confusing. There are two settings i'm aware of:

NewtonSetSolverModel (newtonWorld, solverIterations)

and

NewtonSetNumberOfSubsteps (newtonWorld, substeps);

I assume the difference is substeps includes collision detection and solve for forces,
and solverIterations means how many iterations to solve for forces.

So you are likely more interested in the latter function, but none should cause timelapse behaviour.

Either your hardware is very slow or there is a bug about realtime <-> fixed timestep ration on your side i would guess.

But i think increasing tesselation would give the most benefit and investing performance here seems most promising.
User avatar
JoeJ
 
Posts: 1147
Joined: Tue Dec 21, 2010 6:18 pm

Re: Ball Physics vs CollisionTree Suitability

Postby Sweenie » Mon Dec 10, 2018 3:06 am

Higher tesselation usually works well. Another trick for extra smoothness is to normalize the contacts in slopes. I'm talking about realtime normalisation of the contacts here. Maybe it would be enough to smooth the normals of the treecollider, but i'm not sure about that.
Sweenie
 
Posts: 489
Joined: Mon Jan 24, 2005 7:59 am
Location: Sweden

Re: Ball Physics vs CollisionTree Suitability

Postby anothertime12 » Mon Dec 10, 2018 9:10 am

Increasing substeps works very well at the moment but I can see that under tighter level geometry additional work is probably needed.

To clarify the substeps issues - the original post that describes using that function suggested that I set it to '5' and then the engine would perform 5 internal steps. I would then call NewtonUpdate 60 times per second and the engine would expand this out to 5*60 being 300 steps. This doesn't happen, what actually happens is that everything runs at 20% speed (faling / moving etc).

I could however continue to run at 60fps and simply call the function 5 times each update which then worked a lot better (with a timestep of (1/5)/60).

The easiest solution however was simply to change the engine update from 60fps to 240 (as there's no AI or anything else really going on) and this has solved the problem. There's only really 3 dynamic bodies per level so using triangle mesh isn't causing any slowdowns even at this high a frequency.

The next issue is about rotating moving very complex triangle mesh shapes but I'm waiting for some new 3d models to test these.
anothertime12
 
Posts: 17
Joined: Tue Nov 27, 2018 11:28 pm

Re: Ball Physics vs CollisionTree Suitability

Postby JoeJ » Mon Dec 10, 2018 9:50 am

anothertime12 wrote:To clarify the substeps issues - the original post that describes using that function suggested that I set it to '5' and then the engine would perform 5 internal steps. I would then call NewtonUpdate 60 times per second and the engine would expand this out to 5*60 being 300 steps. This doesn't happen, what actually happens is that everything runs at 20% speed (faling / moving etc).


I share your assumptions, maybe Julio can clarify this? :?:

anothertime12 wrote:The next issue is about rotating moving very complex triangle mesh shapes but I'm waiting for some new 3d models to test these.


There are 2 options:

Use a kinematic body. But if you change its matrix, you also need to set velocity manually accordingly so collisions are aware of the movement. (Sounds like unnecessary extra work, but this way you can also make conveyor belts or racing track accelerators very easily for example.)

Or you use a dynamic body and control it with a kinematic joint.

I'd try the former option first because it's exact. (With the joint the rolling ball would still shake the level part a little bit eventually.)
User avatar
JoeJ
 
Posts: 1147
Joined: Tue Dec 21, 2010 6:18 pm

Re: Ball Physics vs CollisionTree Suitability

Postby Julio Jerez » Mon Dec 10, 2018 10:40 am

To clarify the substeps issues - the original post that describes using that function suggested that I set it to '5' and then the engine would perform 5 internal steps. I would then call NewtonUpdate 60 times per second and the engine would expand this out to 5*60 being 300 steps.

the last part is not right, I will execute 5 steps of each with the timestep = dt / 5
the will be if you simulate at 60 hetz, the teh physics will run at 300 hertz, not 300 steps
with the latest commit soul work now, you were right there was a bug but should be is fixed now.
Code: Select all
The easiest solution however was simply to change the engine update from 60fps to 240 (as there's no AI or anything else really going on) and this has solved the problem

this should do the same trick, with a little more overhead, I was just curios as to why the behavior was different and it turned out that indeed there was a bug that should be fixed now.


As for the moving platform. I just added a utility funtion to the sdk that you can use for achieve what you want. you do not need to worry about converting displacement to linear velocity and angular velocities, you soudl sync to get that last function.
Code: Select all
void SetKinematicPose(NewtonBody* const body, const dMatrix& matrix1, dFloat timestep)
{
   dMatrix matrix0;
   const dFloat OneOverDt = 1.0f / timestep;
   NewtonBodyGetMatrix(body, &matrix0[0][0]);

   dQuaternion q0(matrix0);
   dQuaternion q1(matrix1);

   dVector omega(q0.CalcAverageOmega(q1, OneOverDt));
   dVector veloc ((matrix1.m_posit - matrix0.m_posit).Scale (OneOverDt));

   NewtonBodySetVelocity(body, &veloc[0]);
   NewtonBodySetOmega(body, &omega[0]);
   NewtonBodyIntegrateVelocity(body, timestep);
}


as Joe said one trick you should use is, instead of using a static body by giving a mass = 0
make your platforms kinematic bodies, this is create like this
Code: Select all
   body = NewtonCreateKinematicBody(mWorld, shape, worldPose);
   NewtonBodySetCollidable(body, 1);


them you give the platform a mass like 1000, or something

what this does is that first internally the engine treat that body as if is was dynamics forming pairs.

because it has mass, any dynamic body colliding with it will ass as if is was colliding with a heavy body not as a infinity mass body, this is important because infinity mass body with velocity has infinity momentum and cause you body bounce with unrealistic velocity.
static body with infinity mass only make sence when the have zero velocity.
third, the integration of the body will be ignored but the integration.
basically in newton kinematic bodies are dynamics bodies that do not integrate.
this can not be done with either static of dynamics bodies hence that type

if you set that right it should be near perfect but and even is not quite right is goes along way to be
good enough that no one can tell the difference
Julio Jerez
Moderator
Moderator
 
Posts: 10984
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Ball Physics vs CollisionTree Suitability

Postby anothertime12 » Mon Dec 10, 2018 7:25 pm

Thank you for confirming the bug and for your work on the movement functions for level geometry. Once the modellers give me a few new level models to practice with I'll start testing this.
anothertime12
 
Posts: 17
Joined: Tue Nov 27, 2018 11:28 pm

Previous

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 1 guest