Manually moving Rigidbody with proper collision

OK, so help me out here. What is the recommended way to manually move a rigidbody around via script code and still have it collide with colliders correctly?

For example:

Let's say I have a room that I've defined using meshes with colliders. I want to have a ball fly around the room using sine wave functions. I want the ball (with a rigidbody attached) to be moved around entirely programmatically but I want it to collide with and slide along any colliders that it may run into.

I've tried a number of solutions that sort of, kind of, halfway work but I'm stuck as to what the "right" answer is.

 

I would either use rigidbody.AddForce(), transform.Translate() and raycast to check for collision when the ball is moving at high speeds.

 

Damn, so no way to simply ask the collision engine "I'm going to move this rigidbody now, please make it hit stuff properly, OK?"

Le sigh.

 

Maybe just change the rigidbody's velocity, and it will detect collisions.

Code (csharp):

1. rigidbody.velocity

 

Well, you do have a collider attached, right?

 

Yep, it's got a 'rigidbody' set to IsKinematic and a 'box collider'.



As for adding forces and velocities - I don't think that's going to do what I want since I won't have control anymore. The physics engine will. I just want to slide something around the world, under my control, and have it hit colliders correctly.

For example, I want to tell the ball to move towards a wall. It moves towards the wall and then refuses to go any further when it gets there because, well, the wall stops it. Is that possible without hacking around with ray casting?

I guess what I'm looking for is something like what Blitz3D has. You set up collision behaviors on objects and they "just work". There's no physics engine but the collision engine works great with zero effort required on behalf of the programmer.

 

That doesn't work because when you translate the object, it doesn't "slide" the object, it simply changes the value of it's position.

This means that you can make the position of the object be inside another one, and the physics will get all crazy.

Try using the raycast first to see if the amount that you want to move is ok, and then move it.

Regards,
Afonso

 

I understand that and I would love a "move" function that respects physics. Telling me to raycast and do basic collision checking on my own seems a little ... I dunno, lame for a $1,400 game engine. *shrug*

 

I don't get it. You have absolute control over the forces that act on the objects AND the ability to set the velocities etc. directly.

Sliding is exactly what the physics engine will let you do. It sounds more like you want to instantly jump an object from point A to B and *still* have it collide with things...a bit weird.

 

how about having an invisible collider-less object (that does the sine wave response to mouse movement) that your ball is attached to with a spring joint?

maybe i'm wrong but i think what you want has nothing to do with any engine limitation in particular and more with how physics work in general - to do what you want would require some sort of hack no matter what engine you use ; )

 

I'm pretty sure you'd run into the same problem in the latest Unreal engine. You want to price that out?

Raycasting isn't hard, by the way. It's about one step more than doing a translation. It's a reasonable step in the right direction.

Code (csharp):

1.  
2. if (Physics.Raycast (transform.position, direction, distance) == false)) {
3.     transform.Translate(direction * distance);
4. }
5. else
6. {
7.     //you could either find out where it hit and go there, or just stay still, etc.
8. }
9.  

You'd actually want to use the RaycastHit version of Raycast and use the returned RaycastHit to figure out the position, normal, etc.

 

It's not weird at all. I want this object to move from PointA to PointB and if there's anything in your way, stop. I'm not asking for the moon here.

 

It *IS* weird since what you want to do is directly, in the same frame, instantaneously move the object in the game world and still have it interact with the physics engine. Since you are doing something that isn't within the realm of physics, it's a contradiction. Which is weird.
You would want to hack that using for example the method described above.

If you actually do mean that you want to move the object (as in, have it maintain a velocity) and have it collide, use the excellent built-in physics engine.

 

Never mind.

 

That is AI, that is path-finding. The only place where you will probably find something like that implemented is if you are doing a MOD of a game.

If you are designing the game, you are the one that has to take into account all of these factors.

Regards,
Afonso

 

Holy hell. Never mind, you guys are way off the track now.

 

Can you post maybe a screenshot.

Not sure but have you tried adding physics material to the objects like bouncy or metal or rubber?

Ray
Edit; maybe check your collider as IsTrigger and if the ball collides or enters that trigger do something to the ball.

I'm interested to learn how you gonna solve the prob.

 

If I understand this scenario correctly, you want to have scripted control over an object's position, but you want it to react to collisions?

I think I need you to explain more about how you want the object to interact with others.

If you want this ball to push away other physically-controlled objects, then you use a Kinematic Rigidbody with any primitive collider attached.

If you want this ball to REACT to collisions, you will have to somehow disable the scripted positioning of the ball when it collides with something else. You cannot have scripted control of an object's position AND have it react under physics together. You have to choose one at a time, but you can switch between them.

The third option would be to script the ball's position using forces instead of setting the transform.position. This is possible, but harder to do.

So please explain a little more about what you mean by making the ball interact with physics.

 

In re-reading this thread, I think I understand what you want to do.

Moving a ball around a room, if you come in contact with a collider, don't move into the collider.

Probably the quickest way to do this is use a kinematic collider for the moving object and a static collider for the other objects, none of them triggers. Using OnCollisionEnter and/or OnCollisionStay, use the Collision.contacts array to figure out how far inside the bounds you are, then move the position manually to the outside of the collider.

This might be easier if you are using transform.Translate() instead of setting transform.position.

 

Thanks Ulognep, that's about what I figured.

For a future version of Unity, it would be great if this stuff could be somewhat simplified. Like I was mentioning earlier, in Blitz3D (which is ancient old) you set up the collision reactions at the top of your program and you never have to think about it again. Stuff just collides and slides and it's all magic like.

 

It is the same in Unity. But you can't expect a body to both react without you telling it to and follow exactly what you tell it.

The most important part of scripting your own physics is the creating reactions.

 

this thread has me thoroughly confused! if you move a rigidbody with a primitive collider and it hits another collider, it will either bounce off, stop or slide along the surface depending on your mass, drag, incidence angle, blah blah blah... it works fine. always. what exactly is the problem? i don't get it.

 

I think the idea is to move objects not under control of the physics system and still get collisions somehow. If I'm right, then the reason that this has generated quite a bit of confusion is that you're wanting to override the "just works" collision detection system but still have, well, a "just works" collision detection system even though you're overriding it.

Thing is, if you're directly positioning objects, then Unity is going to try to put them there, because you said so, regardless of what else might be there. This is expected and desired behavior (Unity can't read minds...maybe you want to do that for some reason). So you either want to 1) work with the system and use forces instead of absolute positions, or 2) ignore the system and implement your own collision detection using raycasting or whatever.

--Eric

 

So does anyone know what happens when you have a keyframed animation, with rotation values, and then add a "lookAt() script to it? I havent tried it but Id imagine they are fully in conflict with each other...

Off topic sorry..
AC

 

OK, I understand now. You have to use the physics engine (velocity, forces, etc) to move objects and have any hope of collision happening. I wanted to do something else but to do so, I'll have to raycast and hack my own system into place.

I've got that. Please stop explaining it to me.

What I was asking for was a perfectly reasonable function where you could manually ask for an object to move from A to B and collide with stuff between. That's not an unreasonable request for a game engine.

However, I do understand that Unity doesn't have such a function.

Understood.

I brought up Blitz3D because it's default reaction set covers 99% of the cases in game development. The object will stop or slide along the collider. If you want something else, well, you have to work around it but those 2 reactions cover the vast majority of the cases.

Applying forces and velocities to objects doesn't give you a lot of fine grained control (unless I don't understand what's being said here), but if that's all there is then that's all there is. I'll deal with it.

Thanks.

 

And that's where we don't agree. Depending on how you set up the physics system, and how you apply forces and/or set velocities, you can have as much control as you would reasonably need. It's just a matter of working with it. It won't take you long to test either if you're reasonably skilled.

I think what got you many replies and explanations was your attitude that it's "lame" that Unity lacks the specific function you request, when it (AFAIK) in itself is a quite uncommon approach to the problem. Normally, you either want physics or you don't.

 

This is incorrect in my experience but this argument will get us nowhere.

Thanks all!

 

Thanks Muriac, nice to have some confirmation that I'm not insane.

 

Hi Willem,

As Muriac has very well explained, CharacterController does exactly what you are asking for. You don't need physics and you don't need RigidBodies.

Simply add the CharacterController component to your ball (and get rid of other collider components that might already be there, like mesh collider). To move the ball in script, call controller.Move(Vector3), documented here (as you probably already know):

http://unity3d.com/Documentation/ScriptReference/CharacterController.Move.html

The parameter to the Move function is the intended ball motion for that frame as if it weren't going to hit anything; that would be the sine wave motion you want in that frame. If the ball comes into contact with any colliders during the Move function, it will stop and/or slide along them. It's all very simple and straightforward.

All objects in the scene that you wish the ball to collide with must have a collider component attached to them, such as a mesh collider. This is also well documented. Neither the CharacterController nor the Colliders need to be triggers.

It is a bit unusual that forum members didn't point you in the right direction sooner. Good luck, and ask more questions if needed.

 

Look at this. Is this what you want to do?

 

My apology if that's how I came across. I simply objected to the practice of calling something "lame" simply because it doesn't do exactly what you want in a specific way.

 

Thank you Daniel.

Willem, I think the frustration on here is that you actually didn't try any of the several suggestions that do work. Instead, you just discounted them all, because it wasn't the way you imagined it.

You can't get much more simple than Daniel's one line command in a fixed update using exactly his own suggested method. It was the second reply to your posts.

In case others want to know without downloading the package, it's this tiny script attached to a sphere with a rigidbody. That's it.

Code (csharp):

1. var speed = 3.0;
2.  
3. function FixedUpdate ()
4. {
5.     rigidbody.velocity = Vector3 (Input.GetAxis ("Horizontal") * speed, 0, Input.GetAxis ("Vertical") * speed);
6. }

 

Aaron

We're past this now. You're back to arguing something that's already been resolved. Let's get on with our lives.

 

Oh, didn't know it was resolved. I assume you found a satisfactory solution, then?
Glad we're past whatever "this" is.

 

Gee... I really don't your tone of voice, people here are trying to help.
I used Blitz3D for years, made 2 good games with it, but I thought it was very limited in...well...a lot.

You'll find the same behaviour in other engines because this is the way it works with modern engines that are based around physics engines.

If you move a physics object by positioning it directly, there's never a chance for Ageia physics to register collisions. There's no "time" in the simulation to register collisions at all.

The character controller suggestion was a good one. Not bad for a $1,400 game engine I'd say!

 

Just wanted to note the more simple and more appropriate solution of changing the velocity of the rigidbody directly. The CharacterController is a bit overkill for what Willem was looking for, IMO, and changing the velocity is almost exactly what he was looking for. I wouldn't want someone to miss that reading this thread.

Willem was frustrated. Please get over it, everyone.

 

I totally get you Willem, I have wanted to do something very similar many times, here in the future(2019) there still isn't a function exactly like what you want. But even in your time there was a way.
One way of the top of my head and it involves a bunch of calculation but should be fine, is have an dummy sphere follow the real sphere and check collision with it, of course it need a rbody and you need to calculate with vectors and stuff how much velocity is needed to reach the real sphere it's following, basically moving it manipulating it's velocity perfectly.
The other way that i have used to have very fast objects detect if they have moved passed something is by creating duplicates of their colliders, moving them to positions between the last position and current(using lerp because you can move ir percentage wise) and checking collisions with all of them. It's not simple or pretty and there is a whole lot more to it but it worked for me.

 

Well, now (in the future) there are more solutions to do exactly what Willem wanted, but in that time there were solutions too. Willem wanted to move a ball through a sine wave path and have collisions with objects in the way. What Willem didnt understand is collision detection systems are limited (and they will always be). Discrete detection mode for example detects collisions by frame, if an object is fast enough to go through another object in one frame this mode will not detect any collision. Continuous detection mode will calculate if there is any object in the path between 2 frames, so it will detect an intermediate object even if it is infinitelly thin, but to do that it needs position, direction and speed of objects to calculate the path the object will follow in the middle of the frames. If you teleport an object using transform.position = newLocation, it has speed 0 so no path will be calculated. Willem was told this. I dont know if the functions rigidbody.MovePosition and MoveRotation existed in 2007 but you can teleport objects and collision detection will work using those functions at least using lerp and isKinematic=on, I tested that myself. I didn´t try a distant teleportation with MovePosition to check collisions, but I can´t think a situation where you would need this behaviour either, Willem didn´t need that, so MovePosition with lerp would actually work for him. And if he wanted to use transform.position = newPosition he could do that by using raycast as other mentioned, or even using dummy objects as you said, in the sine function he wanted to use just place a dummy in the next time frame the ball is now and you know exactly where it will be. For example if you use sin(t) where t is the time, you use sin(t+time.deltatime) and you have the position on next frame. Now he can use kinematics rigidbodies with convex colliders and still use transform.position, but probably collisions wouldn't be perfect all the time, actually physix is not perfect all the time in a lot of circumstances.
But apparently, as other stated, what Willem wanted is to relocate an object through script and physics system to "guess" the collisions and object react to them, but that is impossible, now and in the future. I don't know what he was doing in Blitz3D, but he wasn´t doing THAT. Still if someone wants to do something nobody has done he/she can implement it him/herself, that's the good part of programming.

 

this is something that i also needed and could not find a proper way to do. in unreal engine if you use the ETeleportType::None flag while moving a kinematic rigid body, the collisions will occur(prevents penetrations) while moving the object just like the character controller in unity.
i tried to use the Rigidbody.SweepTest function to detect future collisions and resolve penetrations manually. it works for simple cases but not for a bit more complex ones where rotational movements are involved. SweepTest only requires a direction as input so you can not detect collisions that may occur during a rotational movement.

 

I have the same thing where I want a pile of cards to be pushed together in a pile without cutting into each other. I would try using ConstantForce, and the script changes the constant force in your case to the tangent vector of the position on the sine wave.

 

ok..so... funny thing is, Willem, I totally get you. I've been boggled by the system as is, and finally, because there was no practical other way to do it, got it to work.

I have also read other people's suggestions about applying forces, and only moving things through the physics system. Yes that will work, but that isn't what I, and probably you needed. I have read to use MovePosition and MoveRotation as methods to move something and have all of the collisions get triggered ...and yet this doesn't seem to do the trick.

Obviously just setting collider position or rotation doesn't work, as that is a teleportation....

But I (and i think you), want to just move the object using your own function, and just have the system collide along the way either by trigger or through moving rigid body along the way.

In my case, it is having a collider attached to a table tennis paddle, which is being moved through a table tennis table. I want it to get hit by the table, but i'm not moving the paddle using the physics system...i'm not even moving it during fixed update. It works if it's slow enough, but fails when it's faster..regardless of what kind of interpolate or collision detection I use. In fact, the same exact thing happens if you try to move 1 collider through another using the unity scene window.

What everyone says is correct in the regard that - you won't get any collision in the physics system, unless you tell the physics system how exactly the object is moving..and not just 2 points.

So what i did in my case is to stop the physics system from automatically functioning and then manually called Physics.Simulate with the delta time step that my system would end up using anyway for the physics. I know where the paddle was at the start of the frame, and where it would be at the end of the frame. So the trick I figured out is to move the rigid body rotation and position to the values at the start of the frame, and figure out what the velocity and rotation rate you'd need to reach the state at the end of the frame. Then apply those to the rigid body and run Simulate().

Code (CSharp):

1. using System.Collections;
2. using System.Collections.Generic;
3. using UnityEngine;
4.  
5. public class PerfectCollider : MonoBehaviour
6. {
7.     Quaternion previousRot;
8.     Quaternion currentRot;
9.  
10.  
11.     Vector3 previousPos;
12.     Vector3 currentPos;
13.     public Rigidbody solidBody;
14.  
15.     void OnCollisionEnter(Collision collision)
16.     {
17.         Debug.Log($"Collision Happened!");
18.     }
19.     void OnTriggerEnter(Collider collider)
20.     {
21.         Debug.Log($"OnTriggerEnter Happened!");
22.     }
23.  
24.     private void Start()
25.     {
26.         Physics.autoSimulation = false;
27.         Physics.autoSyncTransforms = false;
28.         //Physics.
29.         previousPos = transform.position;
30.         previousRot = transform.rotation;
31.     }
32.  
33.     public void Update()
34.     {
35.         previousPos = currentPos;
36.         currentPos = transform.position;
37.  
38.         previousRot = currentRot;
39.         currentRot = transform.rotation;
40.  
41.  
42.         float delT = Time.deltaTime;
43.  
44.  
45.  
46.  
47.         solidBody.position = previousPos;
48.  
49.         //nope this doesn't work
50.         //solidBody.MovePosition(currentPos);
51.         //
52.  
53.         solidBody.rotation = previousRot.normalized;
54.    
55.         //nope this doesn't work
56.         //solidBody.MoveRotation(currentRot);
57.         //return;
58.  
59.         solidBody.velocity = (currentPos - solidBody.position) / delT;
60.  
61.    
62.  
63.  
64.         Quaternion rotationQuat = currentRot * Quaternion.Inverse(previousRot);
65.  
66.  
67.  
68.         float angleInDegrees;
69.         Vector3 rotationAxis;
70.         rotationQuat.ToAngleAxis(out angleInDegrees, out rotationAxis);
71.  
72.         Vector3 angularDisplacement = rotationAxis * angleInDegrees * Mathf.Deg2Rad;
73.         Vector3 angularSpeed = angularDisplacement / delT;
74.         solidBody.angularVelocity = angularSpeed;
75.  
76.  
77.         Physics.Simulate(delT);
78.  
79.         currentPos = solidBody.position;
80.         currentRot = solidBody.rotation;
81.  
82.  
83.         //this seems to work at the moment with and without this
84.         solidBody.angularVelocity = Vector3.zero;
85.         solidBody.velocity = Vector3.zero;
86.  
87.     }
88. }
89.  

The result is exactly what i want:
I can't move the collider through the wall no matter what I do....no matter how fast i rotate it, or move it, or how thin either collider is.

It is still important to set the rigid body interpolate attribute to interpolate, and collision detection to some form of continuous (not sure which is best, but it only fails at discrete)

maybe this isn't exactly what you wanted, but it worked for me..maybe it will show you the right direction.

 

For this particular problem with a sine wave there is a simple get around. The derivative of sin(x) is cos(x). This means that the “velocity” of the sine wave is cosine wave. So you could simply set rigidbody.velocity to a cosine wave. This will make the position a sine wave