koobas.hobune.stream
Moving object breaks physics
I'm trying to make a prototype world for my 3rd person ball rolling game, I've finally fixed everything and have been given the chance to work on my world building. Only after attempting to make a spinning object as a test obstacle with an extremely simple transform.Rotate script, do I find that my collision physics don't seem to work with a moving object. I've looked around and can't find a fix.
Here's a video showing what happens:
https://imgur.com/a/bowtYYj
Along with my inspectors for both objects:
https://imgur.com/4qYjzGv
https://imgur.com/gKcU2wy
What kind of result are you expecting? It seems there is some kind of interaction between the ball and spinning object which suggests the physics engine is working correctly, however, there might be some additional things to consider.
1) Are you directly modifying the rigidbody's velocity? You should not do this as it can result in unrealistic physics simulations.
2) Discrete means Continuous Collision Detection is turned off for that RigidBody. What does that mean? Collisions for this collider will only be checked at the content's Time.fixedDeltaTime.
https://docs.unity3d.com/Manual/ContinuousCollisionDetection.html
have you tried testing with other types of collision detection?
Yes, it may seem saying my physics is broken was a bit of an overstatement, but basically I just want my ball to bounce back from the spinning object as it would a stationary wall, except with the added force of the movement from the object. The physics interaction that you see is only when I have the ball ram into the object at a decently high speed and it bounces back like it was a stationary object. What actually happens is no matter if I'm on the ground or in the air, when the object hits my ball it forces it either above or below the object, clipping the ground.
And thanks for pointing out the Discrete Collision detection, but I just tested it multiple times with all other options and I have the same outcome...
Oh, forgot to mention, no. I'm only using AddForce to control my movement, any direct vector changes I have in my scripts are for my different jump heights which are only used once my jump has been initiated with an AddForce.
Also apologies if I may seem amateurish, it is my second game after all...
@aronthepalmer Don't worry about if your question seems "obvious". Everybody has been in your position. So I think you might want to look into a physics materials. (https://docs.unity3d.com/$$anonymous$$anual/class-Physic$$anonymous$$aterial.html) or use a rigidbody on the spinning arm and rotate it's rigidbody, rather than rotating the transform.
This is misleading. AddForce(v, Force$$anonymous$$ode.VelocityChange) is exactly equivalent to rigidbody.velocity += v
Ah, didn't know that, only found that line on some random Unity video after deep diving YouTube. Thanks.
Annoying how some bits of information are hard to come by unless you look in some very specific location, takes ages to find these things the fist time, most of the time.
Oh absolutely. But yes, as long as you're not using a rigidbody's transform you're fine. Only exception is that setting a rigidbody's position is equivalent to a teleportation, not a move, and will mess with the interpolation and the collisions.
To make it work well, you should move your character by physics, and make the obs tacle moving by physics, too. if you just rotate the obstacle transform, his body never get the acceleration. it is just like if it was "teleported" with a new rotation.
(there is way to play and animation using the physiques too)
$$anonymous$$y player object is moved by physics, but I didn't know my rotating object had to be as well. Thanks, I'll go ahead and try to learn Unity Animations quickly to see if getting it to rotate that way will work.
The easiest way to do this would be to abandon animations (they don't mesh well with physics)
Ins$$anonymous$$d use a kinematic rigidbody with a script calling $$anonymous$$oveRotation every fixed frame, and the Continuous$$anonymous$$inematic interpolation.
I got it working a different way but I can imagine your way doing it better, I'll do some research and try it out.
Even others have already mentions it in comments to other answers, I want to stress it as a seperate answer: Any moving object has to have a rigidbody component if you intend to have any sort of interactions with that object. Objects that are driven by your script should have a kinematic rigidbody. Kinematic rigidbodies are not affected by other objects but can affect non-kinematic objects.
A much more general rule: Never move or rotate a collider without being part of a rigidbody. Also keep in mind that rigidbody physics is about simulating rigid bodies. That means if a rigidbody consists of several child colliders, those child colliders should never move relative to each other. They should be rigid. Only the rigidbody object as a whole (the gameobject with the rigidbody component) should move / rotate.
Yes thanks, of all the places I search for information, this is never mentioned, but now I know it makes sense. Even in school we were learning basics and they failed to mention it there. This is a home project because I so enjoyed making my first game.
It should still be easier to come by this base information for knowing how basic game elements should interact. $$anonymous$$aybe I didn't look hard enough, but hours were spent searching for answers...
Well, all I just said is perfectly explained in the Rigidbody overview, the collider overview and the rigidbody manual
Since a Rigidbody component takes over the movement of the GameObject it is attached to, you shouldn’t try to move it from a script by changing the Transform properties such as position and rotation
There are some cases where you might want a GameObject to have a Rigidbody without having its motion controlled by the physics engine. For example, you may want to control your character directly from script code but still allow it to be detected by triggers (see Triggers under the Colliders topic). This kind of non-physical motion produced from a script is known as kinematic motion. The Rigidbody component has a property called Is $$anonymous$$inematic which removes it from the control of the physics engine and allow it to be moved kinematically from a script. It is possible to change the value of Is $$anonymous$$inematic from a script to allow physics to be switched on and off for an object, but this comes with a performance overhead and should be used sparingly.
Static Collider
This is a GameObject that has a Collider but no Rigidbody. Static colliders are used for level geometry which always stays at the same place and never moves around. Inco$$anonymous$$g rigidbody objects will collide with the static collider but will not move it.
The physics engine assumes that static colliders never move or change and can make useful optimizations based on this assumption. Consequently, static colliders should not be disabled/enabled, moved or scaled during gameplay. If you do change a static collider then this will result in extra internal recomputation by the physics engine which causes a major drop in performance
Parenting
When an object is under physics control, it moves semi-independently of the way its transform parents move. If you move any parents, they will pull the Rigidbody child along with them. However, the Rigidbodies will still fall down due to gravity and react to collision events.
That said, there are some pretty amazing things you can do by breaking those rules. If you enable "animate physics" on an animator, you can get away with moving a kinematic rigidbody using an animation, and rigidbodies can now be children of another rigidbody, which allows for example easy moving platforms.
That said those things should not be done unless you understand what you are doing.
