[PhysX] Allow players to slide down slopes / Controller contact callbacks

Started by
2 comments, last by NumberXaero 9 years, 6 months ago

I know that PhysX already has a built-in function to allow character controllers slide down slopes, but I need a bit more control.

The problem is, with PxControllerNonWalkableMode::ePREVENT_CLIMBING_AND_FORCE_SLIDING it just seems to accelerate the controller more and more until it has reached the end of the slope. PxControllerNonWalkableMode::ePREVENT_CLIMBING on the other hand cancels out any up- or downwards velocity on the controller altogether, until the controller has left the slope.

I want the controller to be able to slide down, but affected by gravity.

To do that I need some sort of callback which allows me to retrieve whatever actor the player is standing on, as well as the normal of the triangle / surface.

Is there such a callback in PhysX, and if not, how can I achieve what I want to do?

Advertisement

The character controller description has a reportCallback member that can be set to an implementation of PxUserControllerHitReport. PxUserControllerHitReport has virtual functions

virtual void onShapeHit(const PxControllerShapeHit& hit);
virtual void onControllerHit(const PxControllersHit& hit);
virtual void onObstacleHit(const PxControllerObstacleHit& hit);

the PxController*Hit objects all derive from PxControllerHit which has members worldPos, worldNormal, dir, length, etc. Using these members and few dot products and vector math you should be able to slide the character downward according to your own gravity.

You didnt mention physx version, this is assuming some version >= 3.0 or so.

Thanks, that works, but I still need to get rid of the default behavior.

Setting the non-walkable mode to PxControllerNonWalkableMode::ePREVENT_CLIMBING_AND_FORCE_SLIDING prevents me from applying any up- or downwards force while the controller is on a slope, so I can't use that.

And as I've said, PxControllerNonWalkableMode::ePREVENT_CLIMBING_AND_FORCE_SLIDING applies some default force that can't seem to be changed and isn't linked to the default gravity.

These are the only two settings available though. I've tried setting the step offset to 0 or 90 degrees with both settings, but that didn't help.

What I need is essentially what PxControllerNonWalkableMode::ePREVENT_CLIMBING_AND_FORCE_SLIDING does, just without the force which seems to be applied from PhysX itself.

// Edit

Actually nevermind, looks like there's no force being applied from PhysX after all, it seems to be caused from something on my part.

// Edit²

I found the issue, not sure what I can do to fix it though.

In my test case the physics are simulated 33 times per second. My test object is simply moved downwards by 1 unit before every simulation step.

If there aren't any obstacles in the way, the object's speed after the simulation is exactly 33, which is exactly the way it should be.

However, if the object hits a slope, the speed actually jumps up, which doesn't make much sense to me. On a slope with an 45 degree angle, the object's speed jumps up to 51.421 (Shouldn't it slow down somewhat?).

The resulting speed is then used for the next simulation step and thus keeps increasing, which leads to the massive acceleration I've been experiencing.

So, once again, I'm stuck.

So the controller is sort of bouncing when hitting 45 degree slopes? If thats the case, I dont recall controllers ever being able to doing that without some sort of help from additional user side math, but maybe Im wrong, I thought they only slid or stopped.

Is that whats happening? Is the incoming hit dir vector coming from above the 45 degree slope or moving towards it? Where are you reading this acceleration from?

The controllers can be tricky to get right for complex interactions, but there are a few flags and callback points that can be used to tweak it.

In the future can we refer to controller objects as controllers (ctrlers) static or dynamic physics shapes as objects or shapes, and physx controller custom obstacles as obstacles, they all have different ways of interacting with the controller system, it will help make it clearer which interaction isnt behaving.

This topic is closed to new replies.

Advertisement