Issue with turning kinematic rigidbody into non-kinematic rigidbody

Unity Engine
1

THE SETUP

I have a rigidbody whose default state is kinematic. On collision with a certain trigger, I turn that rigidbody into a non-kinematic one and lift it off the ground with ApplyForce. When the object comes in contact with the ground again, I set the state back to kinematic. This all works perfectly in unity 2019.1

THE ISSUE

I’ve updated to 2019.3 (some team needs) and the above setup no longer works. Instead, on the collision with that trigger, the rigidbody no longer leaves the ground. I did a Debug.Log of the velocity and it’s (0, 0, 0). I did some testing and found that if I set the default state to non-kinematic (and never change the state), the rigidbody does act as it did in 2019.1. However, I cannot keep the object as non-kinematic throughout the whole scene.

Does anyone have an idea of what might be going on here? I saw unity made a statement about turning kinematic rigidbodies into non-kinematic rigidbodies.

When a kinematic Rigidbody is turned into a non-kinematic one, the physics engine will now re-insert it into the broad-phase structures for the purposes of collision detection. This will cause an extra OnTriggerEnter event.

but I’m not sure how to use this info, or if it’s strictly relevant. Thank you!

2

PhysX was updated to from 3.4 to 4.1 in Unity 2019.3. That’s probably related with the behavior change you’re experiencing. The PhysX release notes are here:

https://gameworksdocs.nvidia.com/PhysX/4.1/release_notes.html

Your problem might have something to do with this entry:

  • Switching a kinematic object to dynamic does not automatically wake up the object anymore. Explicit calls to PxRigidDynamic::wakeUp() are now needed.

So you may need to call Rigidbody.WakeUp() after clearing the isKinematic flag and before applying the force.

3

Thank you for the quick response! Unfortunately that doesn’t fix my problem :frowning:

I should clear something up. The force applied with ApplyForce is a vector that has a Y value, but also has a value in the XZ plane. Basically the trigger is a vacuum that attempts to pull a grounded object up and toward the nozzle of the vacuum.

That said, in my current situation, while the velocity does print (0, 0, 0), and I don’t get any Y motion (like I used to), I DO get some XZ motion with the correct direction but incorrect magnitude - smaller than expected.

Any other insight would be greatly appreciated. Thanks again!

4

In case anyone stumbled up on this thread. I did figure it out. This thread: Since when did Changing isKinematic fire OnTriggerExit? basically sums up the problem. Unity invokes an OnTriggerExit when the Rigidbody changes Kinematic states and then invokes it OnTriggerEnter right away. For my case, I was using the OnTriggerExit/OnTriggerEnter to change my kinematic state. In short, when ever my Rigidbody hit my trigger, it kept toggling between kinematic and non-kinematic.

my solution was to make a box-cast that encompassed the same volume my box-collider did. Kind of cumbersome, but at least it works.

5

Using a BoxCast is kind of overkill :stuck_out_tongue:

I had the same problem with a fear system, to get around it i simply used a boolean.

When the player enters the trigger, set the bool to true before changing the rigidbody to non-kinematic, OnTriggerExit is automatically called afterward and if the bool is true set it to false and return.

6

I tried a solution like that, it’s hard to explain why it wasn’t working - mostly cause I couldn’t figure it out myself.

With some profiling I didn’t find the boxcast to be a hit to performance. Are there other ramifications to switching to it?

7

Yeah it’s not heavy on performances, i was just comparing to a bool solution.

I don’t understand why you are using both OnTriggerEnter and OnTriggerExit to change the state, to set it non-kinematic and add a force you only need OnTriggerEnter, then on your ground collision it returns to kinematic, right?

Besides that, your ground collision is also using a trigger event on your player or just the collision itself?

8

ah gotcha. yeah it’s just the setup we’ve used from the beginning and we’re just too deep in now to go and change it all. it’s all a bit convoluted haha