PhysX 3.3: PxController::move possible bug


I just wonder how the elapsedTime parameter in PxController::move works,
every value even FLT_MIN and 0 and FLT_MAX is possible but has absolute no impact.
The PxController is independent of the PxScene, so you can use it even when you dont call
simulate() and fetch() and it works perfectly and collides with all shapes.

Is there any way to make all calls (and their impact) to PxController::move() - “a little bit slower”, not delayed, just the PxController should´nt move so fast. (A little bit like a slow motion movement, but not so slow, it should be adjustable via the elasped time I think…)

And I dont want to normalize the passed velocity and calculate it with a smaller value.
(Ok, just multiply (without normalization) with a smaler value does “almost the same”.)

  • I guess the elapsedTime parameter could handle this (with deltaTime*0.5) but it doesnt work.
    ( And no, I dont want to reduce the time I called PxController::move() - I need all (possible) contact
    information immediately.)

This is the PxController::move call:

I´ve looked into the source, the elapsedTime parameter is only used as incrementation of mGlobalTime,
its only used for Controller::rideOnTouchedObject - thus there is no “easy” way to handle it via the deltaTime. NVIDIA should describe it better.


OUCH: I did´nt saw the forest ahead, because there was trees everywhere… :D
Ok, enough coding for today XD
( And modify the deltaTime is a bad idea…)

I guess its only possible via:
//mVelocity.normalize(); // not really needed
mVelocity *= 0.5f; // or other values

and then call

-> Thus forces like gravity particullary jumpforces (gravtiy + acceleration) must be tuned.