Having issue with getting physics to co-operate

Unity Engine
1

Pretty new to unity, just started messing around, and after sifting through samples, demos and endless religious debates on MovePosition vs velocity vs AddForce etc, I just made a simple scene with 7 capsules and drove them into a wall using the different respective method to try it out… Result: All 7 majorly failing, spiraling, twisting, shooting off into space. After some searching, my code is almost the same as this:

Then I tried running some demos, like Tanks!, and if I drive that simple little tank into a collider long enough, it also starts spiraling and going crazy. Add a child collider for the turret and its instant disaster. Why are they making demos out of MovePosition/Rotation with non-kinetic objects only to give you links to the very docs that say don’t do that. Hmmmm.

Package included and screenies. Would someone please have a look, hit play, and tell me what magic I’m missing. Even commenting out the rotations and it still goes nuts after 10 seconds or so. I must be missing something.

Edit: Added a physics material with 0 friction, everything works pretty much as I would expect it to. The slightest amount of friction, and everything goes to hell in a hand basket.

6900821--807782--Physics.jpg
6900821--807782--Physics.jpg996×507 46.9 KB
6900821--807785--Physics2.jpg
6900821--807785--Physics2.jpg994×523 46.8 KB

6900821–807779–PhysicsIssue.unitypackage (17 KB)

2

  1. Position
    You are using MovePosition on a non-kinematic rigidbody
    Unity - Scripting API: Rigidbody.MovePosition
    “Moves the kinematic Rigidbody towards position”

  2. Transform
    This is just teleporting a rigidbody around. Although see notes below on freeze constraints.

  3. Velocity
    Works as expected, but is stuck on the wall

You have a coding error in “Case MoveStyle.Force:” your final else is missing its braces so the final AddTorque line is applied to both ForceMode.VelocityChange and all other m_ForceMode conditions. I have corrected this for my further comments.

  1. Force-Force
    Your AddForce value is small as you are using your velocity value as a force. You add a relatively small force (20 N) in the local forward direction, once the rigidbody has completed a full circle it has received a net force of zero on it. Hence the slightly eccentric little dance.

  2. Force-Acceleration
    Your AddForce value is now using the velocity value as an acceleration, it then hits the wall.

  3. Force-Impulse
    Impulse is the velocity change scaled by mass, it’s more useful for impacts than controlled motion, but once again you can see you are applying it in the rigidbody’s local coordinate system, hence the whirling about.

  4. Force-Velocity
    Seems OK except of course you have the same issue with applying the translational force in the local coordinate system

Here are some general comments that might help:

If you set transform.positions you are teleporting the rigidbody about and physics will be broken.

If you use kinematic rigidbodies then use .MovePosition and .MoveRotation, otherwise don’t use them.

If you set velocity directly, associated physics calculations will be compromised, it is better to use the AddForce and AddTorque options and allow the physics engine to resolve these into actual velocities in the physics step.

Many of your problems seem to come from using transform.forward to control your translational velocity, thereby tying your translational velocity to your rigidbody orientation.

There are known issues with partially constraining rigidbody rotations. This can be greatly improved by switching the Edit → Project Settings → Physics → Solver Type to Temporal Gauss Seidel.

3

AITheSlacker, first off many thanks for taking the time to take a look and provide your thoughts. After reading your feedback I’ve made significant headway in understanding the issue.

1 & 2, Totally understood, just added all the types to compare and see the results, and are working as expected.
3. Good catch, I added the rots afterwards and didn’t notice the extra brace.
4. Does f=ma apply here, with the obvious losses from friciton etc? i.e., if I took the RB mass and multiplied by a factor of m/s, assuming my models were in m units, would I get an appropriate reaction?
5,6,7 All good.

“Many of your problems seem to come from using transform.forward to control your translational velocity”
Indeed, I can see now how that is really the biggest issue. Basically there are a number of floating point rounding errors, constraints, etc that will prevent the transform from maintaining a steady y pos or angular velocity, so by using that transform, I’m actually compounding the problem by continuing to build on it, causing more and more oscillations, etc… a feedback loop right? So my question is, what’s the correct way to add velocity in the direction of travel?

TL;DR: I’m trying to build a controller for basically the exact same thing in the Tanks! sample, W/S forward/backwards, A/D turn left and right. Every sample out there seems to use MovePosition/Rotation (as in the Tanks! sample) even though it’s not kinetic, or adjusting .velocity/.angularVelocity, as in the karting sample for example. In fact, every demo/sample I’ve checked out, in my limited experience, is “doing it wrong”. Not sure why they are violating their own doc’s suggestions in the majority of stuff they produce. Bottom line, it’s basically a 2D top-down down with a 3D perspective view on a slight angle, gas/brake and turn, and the players can ram and nudge each other around. Seems simple. How is there no rigidBody character controller included for basic movement. The built in one assumed kinetic if I’m not mistaken.

BTW, you mentioned modifying velocity can compromise physics calc. Does AddForce w/ Forcemode.Velocity effectively provide the same means without the comprimise?

RTL;DR: What’s the appropriate non-kinematic mechanism for MovePosition/Rotation? :wink:

TIA!

4

Hey, Sorry I won’t have time to look properly at this until Monday. But firstly, sorry made a false assumption - I thought you wanted them to move straight forward while rotating. There is nothing wrong with your approach of using transform.forward to drive them in the direction they are facing.

TRL;DR AddForce, AddTorque, but you need to think about how to prevent this from making them move forever… I’ll post something Monday…

5

Not easy to figure out someone’s intentions when all you have is 6 capsules doing a donut, ha. I was emulating a user holding W and D and testing which ones would do a nice turn radius on top of just visualizing the different methods, whilst also colliding with a wall or obstacle and seeing which ones would scrape along and continue on their way.

A lot of games implement fake physics, on purpose, as in my case, I want instantaneous velocity response on the keys, and then people get feedback that they are violating physics and should use X, Y, Z methods instead. Doesn’t necessarily make sense if your purposely implement a “game” that purposely implements unrealistic physics :wink: I’m only using RB to get pushing around the other players for free without having to compute and add force to the colliding players or slide along a wall, Need for Speed style.

6

I made a little demo, you will probably need to tune more for the behaviour you are looking for, but hopefully it is enough to get you started. I’ve put it on github as I added some terrain and set an additional physics setting. Try it out and let me know how it goes. GitHub - AlTheSlacker/Tanks: A short demo of how a player might control rigidbody movement