I have a kinematic actor and capsule controller setup now, they seem to work. If the kinematic object is not moving, the controller can collide with it and move over it as though it were a static actor.
The problem Im having now is, if I use the kinematic actor method moveKinematic(PxTransform), while the controller is on it (move up), the controller slides through the kinematic actor. If I continually apply the controllers move(..., ..., ...,) method, and attempt to pace back and forth on top of it, the controller seems to stick for a while until I stop calling move(), then it falls through again.

Im aware of the PxSceneQueryFilterCallback argument to the controllers move() method, but Im not sure it how it can help, the situation calls for the kinematic actor to push the controller when not using move() (ie. simply standing on it and riding around). moveKinematic() has one argument relating to how to move.

Ive flagged eENABLE_KINEMATIC_PAIRS, for the scene. Im using this filter shader which pretty much the submarine demo implementation, Im not sure where else to look.

PxFilterFlags PhysXSimFilterShader(PxFilterObjectAttributes attributes0, PxFilterData filterData0, PxFilterObjectAttributes attributes1, PxFilterData filterData1,
PxPairFlags& pairFlags, const void* constantBlock, PxU32 constantBlockSize)
{
//return PxDefaultSimulationFilterShader(attributes0, filterData0, attributes1, filterData1, pairFlags, constantBlock, constantBlockSize);

//PxPairFlag::eTRIGGER_DEFAULT == PxPairFlag::eNOTIFY_TOUCH_FOUND | PxPairFlag::eNOTIFY_TOUCH_LOST
//PxPairFlag::eCONTACT_DEFAULT == PxPairFlag::eRESOLVE_CONTACTS

// let triggers through
if(PxFilterObjectIsTrigger(attributes0) || PxFilterObjectIsTrigger(attributes1)) {
pairFlags = PxPairFlag::eTRIGGER_DEFAULT | PxPairFlag::eNOTIFY_TOUCH_PERSISTS;
return PxFilterFlag::eDEFAULT;
}

if(PxFilterObjectIsKinematic(attributes0) || PxFilterObjectIsKinematic(attributes1)) {
pairFlags = PxPairFlag::eCONTACT_DEFAULT;
return PxFilterFlag::eDEFAULT;
}

// generate contacts for all that were not filtered above
pairFlags = PxPairFlag::eCONTACT_DEFAULT;

// trigger the contact callback for pairs (A,B) where
// the filtermask of A contains the ID of B and vice versa.
if((filterData0.word0 & filterData1.word1) && (filterData1.word0 & filterData0.word1))
pairFlags |= PxPairFlag::eNOTIFY_TOUCH_FOUND;

return PxFilterFlag::eDEFAULT;
}

Can anyone confirm that controllers are treated as kinematic actors? or that kinematic/kinematic actors can collide at all? In PVD the controller is seen as a kinematic object but even with the correct flags enabled I still get the same result.
Ive enable kinematic pairs in the scene description, enabled the swept bounds flag on kinematic shapes, and used the swept integration flag in the filter shader, but it seems to have no effect.
My controller still drops through kinematic shapes when they are moving slowly upwards under the controller. Id like to know if this is possible at all, or if Ill have to find another way of dealing with this, maybe without physx.

I sure hope its possible, certainly slowing my efforts. Others have had similar problems, with either no solutions, or hacky ones.

Old Nvidia forums 3 years ago
Ogre3d 2 years ago
Gamedev.net 1 year ago

A moving elevator/platform is a pretty standard object found in many games. I find it hard to believe that something (seemingly) so trivial cant be done easily by an SDK as capable as PhysX.
Static objects do what they should, stop everything. Dynamic objects do what they should, pushed/collide with static/kinematic other dynamic objects. Kinematic objects should not react to other kinematic hits, but should stop in their tracks when blocked by other kinematics. They certainly shouldnt penetrate, stopping altogether would be better.
The controllers walk on static and push dynamic, thats fine, but kinematics need to push controllers from the side and underneath, and be walkable. If they dont push controllers horizontally and vertically, then they would have to stop, in most cases this wouldnt make sense, a player would be able to block an elevator.
Controllers need to be controlled, sure, but kinematic objects should behave like static objects when controllers walk on them and controllers should act like dynamic objects when hit by kinematics. Controllers should be god objects, unless they meet other controllers or moving kinematics.

"Controllers need to be controlled, sure, but kinematic objects should behave like static objects when controllers walk on them and controllers should act like dynamic objects when hit by kinematics. Controllers should be god objects, unless they meet other controllers or moving kinematics."


That seems like a reasonable design. However there are other reasonable designs that other users will want, which don't work exactly like that. From what I've seen, character controller behavior is often highly tailored to a specific game. For this reason we supply the character controller as source code even for binary SDK users. In this way, if the desired behavior cannot be achieved through the functionality exposed in the SDK API, e.g. contact callbacks, collision groups, scene queries, etc., you can freely modify the controller source.

Thanks for the design advice! We will feed it into the engineering process as we improve the character controller in future versions.

--Mike