Collisions involving kinematic actors makes dynamics and kinematics do strange things

Gaming and Visualization Technologies APIs Physics Modeling (closed)
1

Hey guys, I am making a shooter (quake style) and I’m finding tons of trouble when using kinematic actors.

I have a collision manager that inherits from PxSimulationEventCallback and PxUserControllerHitReport. Once a certain hit has been detected I report the logic of the game through concrete interfaces.

There are certain entities in my game that are kinematic (such as rockets). So here is the deal:

  • I have defined my own filter shader to get notified whenever an onContact event has happened. So far so good. Whenever a rocket hits a player, onContact gets called. The problem is that when the rocket goes inside the shape of the player the player moves up. It seems like shapes act weird when they get trespassed by kinematic actors.
  • The same thing happened when I was programming the spectator mode. I wanted spectators to be able to go through players. To do this, I configured the interaction mode of the capsule descriptor of spectators as PxCCTInteractionMode::eEXCLUDE, but when I went through players they moved up.

A friend of mine told me that this didn’t happen with PhysX 2.x. I’m guessing that it’s just some configuration parameter that I am missing.

Any ideas?

P.S: Also, whenever a player gets hit, onContact ALWAYS gets called whereas onShapeHit just gets called sometimes.

Cheers,
Frank.

2

Hi.

First: Why should a rocket be kinematic?
You could create the rocket as a PxRigidDynamic actor, and set the gravity flag off and the
trigger flag ( of your shape ) on. Thus the rocket is non kinematic and you can move it
via addForce - to simulate a “starting” rocket - or something similiar which keep accelerating while
is flying. (if desired → and if it moves “slowly” so CCD must not turned on )

With the trigger shape its easy to do specific things which should happen when the rocket hits
a player or the ground etc.

It also fires an event when it enter a shape or leave it. Just play with it.
The best part of all is that the trigger shape needs an deactivated PxSimulationFlag - thus
your PxController wont move up when he is hit. And other good feature: You dont have
to call continuously setKinematicTarget() - just add force once and you are are done.

You can also set a filter flag for the rocket - and filter this inside your filtershader - but
I prefer the way with the trigger shape.

There is another option for the undesired behavior. You could raise some flags, or
using your filtershader to get the kinematic objects and set other flags for it, if you dont want
to change to trigger shapes.

I dont want to explain how you should do this - you should think about which way do you want to use.

Example: Look at the submarine source, the mines (and the chains) using trigger shapes too.

As I said in other posts before, the part where you updating your physics is very important.
Which timestep do you use? Fixed, semi fixed, … ?
With a wrong timestep everything should work fine, but sometimes (often while you have frame drops)
you have undesired behaivor like falling throu the ground / no collisions with items (no callbacks…) etc.

onShapeHit are called only when you called PxController::move().
Thus its not a good way to implement “hit code” when a rocket hits you.
When you stand and you got hit by a rocket - and didnt call move(), nothing happens.

This is another reason to use trigger shapes :)

Oh there was another question.
Hmmmm…

Why should you use a PxController for your camera?
You could also use another way to handle it - a trigger shape, a raycast … etc.
But okay. You want to use a PxController.
→ So your problem here is that your PxShape which is hidden in your actor which is created
by the PxController interacts with other controller. If you want to use the PxController -
you could set the PxController a filterflag which stands for: “never collide with other than the ground”. After you did this, you are done.

Or you set the PxShape to be an trigger shape - (but I guess the PxController can move trou the ground with that flag)

Another way is to create a simple cube and raise the trigger flag. ( lighter for the solver + slightly better performance )
(After you get a collision of the ground, you cant move deeper to it (raycast) )

Or directly usage of raycasts.
Or sweeps.

Depends what do you want to use it has different benefits.
Maybe for you its the best way to set a special filter flag, explainted above.
( Very very few code (changes) to implement this behaviour, but maybe not the best choice.)
I like raycast or a trigger shape. ← But it depends what do you want to achieve.

Of course, there are other ways to reach the goal - with other improvements.

I hope I could helped you a little bit.

3

Actually we have been using rockets as PxRigidDynamics without gravity for a while now; instead of making it a trigger we just check when onContact gets called.

What I am trying to find out is why kinematics go crazy when they overlap. It doesn’t matter if it is a kinematic rocket, a shape with a different filter shader or a capsule with a different interaction mode. The point is that whenever two different kinematic shapes overlap everything goes nuts.

All I want to know is why two different kinematics can’t overlap and how to fix it (if it is possible).

P.S: We weren’t checking collisions with onShapeHit, I just was curious to know why it didn’t always get called.

Thanks for the comment, it still was very helpful.
Frank.

4

Hi.

Could you explain why you dont want to use a trigger shape?
I guess it has benfitis when you use them.

I guess Kinematic shouldn´t overlap - they should touch themself but not overlap.
Kinematic actors supposed to move dynamic actors - but they also have a weird behavior.
Example: When a kinematic actor push a dynamic actor against a static actor, sometimes
the dynamic actor goes throu the static shape and its “lost”.
When I´m home, I could add a quote from the documentation, but I dont have the doc here.

Good that you dont use the onShapeHit callback for checking against “bullet” collisions.

5

One of the reasons is because we want to be able guide the rockets with the mouse. Yes, you could do that using a PxRigidDynamic and applying forces without gravity, but that would make it much more complicated than it needs to be.

6

"What I am trying to find out is why kinematics go crazy when they overlap. It doesn’t matter if it is a kinematic rocket, a shape with a different filter shader or a capsule with a different interaction mode. The point is that whenever two different kinematic shapes overlap everything goes nuts."

Two kinematics colliding should not cause a problem. A kinematic colliding with a dynamic will cause large forces on the dynamic. Could you please post a video and a repro?

Thanks,
Mike

7

Hi,

okay. I get the point. But I guess when you think about a trigger shape - you didnt know that even the
kinematic actor can be a trigger shape.

Kinematics can overlap - but when I do this in my game, no collision flags are raised (callbacks)
→ (yes, you can enable them when with PxSceneFlag::eENABLE_KINEMATIC_STATIC_PAIRS | PxSceneFlag::eENABLE_KINEMATIC_PAIRS and so on…)
I guess these flags have a little impact of the solver.
I dont need it in my gameplay - kinematic vs kinematic should´nt move (or go throu).
Thus I dont need to raise the flags.

8

I have solved the rocket problem using filters for the capsule descriptor (I used filters before but just for the underlying shapes). Still, if I go through a kinematic controller using eEXCLUDE interaction mode it gets moved upwards. I’ll try to make a video and upload it.

Thanks for the help.

9

Hi.

You have to set filter flags for the rocket and the PxController. After setting them, you need to modify your filtershader to let them throu.

Its easy to do it - look at the sample filtershader in the samples or in the PhsyXGuide.

Of course, as I said before, when you are using the rocket actor as trigger shapes you didnt have this issue.