PhysX: gravity not balancing out?

Quote:

9.8kg*m/s^2 to the box (same force as gravity, opposite direction)

Say what? Force from gravity would be 98 newtons, not 9.8.

Quote:

Original post by Sneftel Quote: 9.8kg*m/s^2 to the box (same force as gravity, opposite direction) Say what? Force from gravity would be 98 newtons, not 9.8.

Well, yeah, but I'm mixing and matching units here because I can't figure out what's going on. Why does an upward force of 9.8 newtons cause the box to go flying into the sky?

gravity's acceleration = -9.8m/s^2
density = 10 kg/m^3
volume = 1m^2
mass = 10 kg
thus, Force due to gravity = -98 Newtons

If I change the upward force to be 98N, it rockets into the sky. Empirically, I've found that I can create a force that nearly balances gravity if I apply a force of 1.79N mBox->addForce(NxVec3(0,1.79f,0))

Try

float up = 98.0f / physicsRate; //physicsRate = 60 (for example)
mBox->addForce(NxVec3(0,up,0),NX_IMPULSE,false)

every time step


*EDITED AFTER TESTING ;)*

Quote:

Original post by jezham Try float up = 98.0f / physicsRate; //physicsRate = 60 (for example) mBox->addForce(NxVec3(0,up,0),NX_IMPULSE,false) every time step *EDITED AFTER TESTING ;)*

Gotcha, that seems to have worked. Is there any rhyme or reason why the force can't be applied as a conventional NX_FORCE and has to instead be applied as NX_IMPULSE?

It is the nature of fixed-timestep. You want to apply the force throughout delta-time, unlike a (unwise) variable timestep where you would apply it once at delta-time.

I guess you could even go one step further and apply it over each iteration, using NX_SMOOTH_IMPULSE. But I haven't tried that method. I guess you would then divide your impulse by whatever you set your max iteration count to, but that doesn't sound right does it! Probably the SDK would do the division for you?

Here's a list of force modes, taken from Nxp.h


NX_FORCE, //!< parameter has unit of mass * distance/ time^2, i.e. a force
NX_IMPULSE, //!< parameter has unit of mass * distance /time
NX_VELOCITY_CHANGE, //!< parameter has unit of distance / time, i.e. the effect is mass independent: a velocity change.
NX_SMOOTH_IMPULSE, //!< same as NX_IMPULSE but the effect is applied over all substeps. Use this for motion controllers that repeatedly apply an impulse.
NX_SMOOTH_VELOCITY_CHANGE, //!< same as NX_VELOCITY_CHANGE but the effect is applied over all substeps. Use this for motion controllers that repeatedly apply an impulse.
NX_ACCELERATION //!< parameter has unit of distance/ time^2, i.e. an acceleration. It gets treated just like a force except the mass is not divided out before integration.

Aaah, I see now. I changed the timing to SetTiming(0,0,NX_TIMESTEP_VARIABLE) and everything works as expected. Though I'm interested to know why fixed timesteps are better than variable ones... the PhysX tips page says:

# Trade off fixed timesteps:

* A lot of substeps: physics can be the bottleneck
* Few substeps: moon gravity effects

# Switch to variable substeps in certain cases

* Problems with determinism and behaviour [sic] changes (e.g. stiffness of softbodies and cloth, different effect of applied forces, ...)

I'm not familiar enough yet with the idea of fixed timesteps to know or appreciate the difference. I can see why fixed would it would be useful in situations where the framerate was very low, since the time derivative of any kinematics would be pretty large and could thus produce wonky results, but is there any logic to setting it at an arbitrary 60Hz, aside from that being a common refresh rate of monitors?

I'm surprised to see the "moon gravity" mention. If you call your fixed simulate() inside an accumulator loop, then there is no chance of that happening. Unless of course, the CPU/PPU can't keep up...but you would decide the min spec based on these things.

Variable is mostly bad as it's unpredictable, one example would be setting a scene to 'settle' the same way each time, another would be for use with instant replay. Variable also means actors will move in huge amounts, without CCD they will often pass through other actors.

60Hz is popular as many like to sync their physics call right before their render code...this is because the physics are automatically handled on a separate thread.
I prefer a minimum of 100Hz, and before I discovered NX_MESH_SMOOTH_SPHERE_COLLISIONS, I would go as high as 360Hz to get the desired results! If possible, as PhysX is for games and not really pure sims, I would aim to tweak down to 60...there's nothing worse than an accumulator loop causing a bottle-neck thus having to cap delta-time and we're on the moon again lol.