Jump to content
  • Advertisement
Sign in to follow this  
skyfire360

PhysX: gravity not balancing out?

This topic is 3710 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm just getting started putting PhysX into my framework, but I've already encountered something strange: gravity doesn't seem to be affected by density. I'll outline what I've noticed, so feel free to stop me at any point where I'm wrong. Say I have a box with dimensions 1x1x1 and a density of 10. For the ease of unit conversion, I'm going to say it's 1m^3 and 10Kg. I've set gravity at -9.8m/s^2. If I run this simulation, it seems to work well and give results that are visually correct. Using the same scene, if I add a constant force of 9.8kg*m/s^2 to the box (same force as gravity, opposite direction) the box flies up into the sky! Shouldn't it stay in a static position, since gravity should be balancing out the vertical force? Now if I change the previous scenario of equal forces so that the box's density is 1000, it falls to the earth as if there was no upward force at all. If I change the box's density back to 10 and change the upward force to 0.98m/s^2, it still falls to earth, but much slower than without the force. What am I missing here?

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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))

Share this post


Link to post
Share on other sites
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 ;)*

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!