How can I make a smooth rotate to object? this is the code that i'm using Code (csharp): var localizeobject : Transform; var localize = false; function Update () { if (localize == true){ transform.LookAt(localizeobject); localize = false; } else { } } function OnGUI () { if (GUI.Button (Rect (10,100,150,100), "Localize Object")) { localize = true; } } This causes a instant rotation to the object... how can i make this rotation smooth?
try this: Code (csharp): var targetObj : GameObject; var speed : int = 5; function Update(){ var targetRotation = Quaternion.LookRotation(targetObj.transform.position - transform.position); // Smoothly rotate towards the target point. transform.rotation = Quaternion.Slerp(transform.rotation, targetRotation, speed * Time.deltaTime); }
Do you have a smart way of detecting if the camera finished the movement? So that I can take away control of the camera while it's doing the smooth look at but give it back once it's done looking at that certain object.
It's workin great! I think this is a great solution, I'm agree with Ineno; i need to know when the rotation finish to stop this automatic rotation and make the manual rotation again.
Code (CSharp): public GameObject targetObj; public int = 5; void Update() { Quaternion targetRotation = Quaternion.LookRotation(targetObj.transform.position - transform.position); // Smoothly rotate towards the target point. transform.rotation = Quaternion.Slerp(transform.rotation, targetRotation, speed * Time.deltaTime); }
you can use a raycast to determine if you are pointing to the desired object and so to know if the rotation is finished (maybe wait 0.2s (depends of the rotation speed) to let it looks at the center of the object)
I think I am pretty late maybe, but instead of raycast, u can turn this into a coroutine and then know if it has finished, something like this Code (CSharp): IEnumerator RotateTransform(float dur) float t = 0f; while(t < dur){ t += Time.deltaTime; float factor = t / dur;//use this for lerping yield return null;//basically wait for next frame } print("Rotation Finished"); }
I think the answer provided in the 2nd post is not correct. Code (CSharp): transform.rotation = Quaternion.Slerp(transform.rotation, targetRotation, speed * Time.deltaTime); If I'm not mistaken (and I could be!!), this will never actually resolve. The 3rd parameter should be between 0 and 1, where 0 will return transform.rotation and 1 will return targetRotation.
Anyone have a clever way of returning the LookAt control smoothly back to an animation clip that was running? I've got a scenario where an animated rigged object needs to have the LookAt relinquished without snapping back to the looping animation that was controlling the bone to start. So far, I don't see a way of reading the clip's key values at runtime. Maybe a potential way of creating another state to transition to, but the SetLookAtPosition is only for humanoid rigs afaik. Any ideas? It would great if the LookAt function had a weight to it, like the SetLookAtPosition has available.
That is not a linear movement tho. It'll get slower and slower at the end because it is always lerping (slerping in this case) with percentage and it is modifying the start position constantly. Also it is better to do these stuff in FixedUpdate. You can either use a temporary rotation variable: Code (CSharp): public Transform target; public float speed; private Quaternion targetRotation; private Quaternion startRotation; private bool cached; private void CacheStartOnceBefore() { if (cached) return; targetRotation = Quaternion.LookRotation(target.position - transform.position); startRotation = transform.rotation; cached = true; } private void FixedUpdate() { CacheStartOnceBefore(); transform.rotation = Quaternion.Slerp(startRotation, targetRotation, speed * Time.fixedTime); } Or you can use RotateTowards: Code (CSharp): Vector3 targetDir = target.position - transform.position; targetDir.y = 0.0f; transform.rotation = Quaternion.RotateTowards(transform.rotation, Quaternion.LookRotation(targetDir), Time.deltaTime* speed );
Stop using Lerps (or Slerps, or whatever) with speed * Time.deltaTime or whatever, for movement or rotation. It is a horrible thing and will behave differently depending on framerate, don't do it. This isn't the the way to use interpolation, no matter what Unity tells you, they also don't know any better.
It's a note, on a really old thread with really old advice that has people calling the original solution genius. The note is : "this solution is bad, please look elsewhere" and it's supposed to urge people to research this further (and stay away from Unity's tutorial's, since they do this themselves and are a big reason why people keep misusing lerps). I think that has value of being in this thread. You obviously don't, demonstrated by your misquoting me, but I don't think that's my fault.
It has zero value. You're not pointing to anything. What is the alternative? https://www.google.com/search?q=unity lerp alternative These guys thanking for an example use for Slerp. A basic Unity method openly available in docs. Think about that. I didn't misquoted you, that is exactly what it is.
If you want to drink bleach, surely I can say "don't drink bleach" without having to provide alternative things to drink. And I didn't say don't use Lerp and Slerp, I said don't use it with things like speed * Time.deltaTime, as that makes the results framerate dependent. Maybe that wasn't clear in my original post, or you were too busy misquoting me to notice. https://www.google.com/search?q=time+deltatime+lerp
That is not a bleach, that is still water in a plastic bottle that everyone drinks from and told to do so by government. And you're saying hey don't drink that. The whole point was about your post that wasn't pointing to anything. And that was a good example to show that. Anyways, isn't deltatime supposed to make it frame independent? Or am I missing something here?
As AcidArrow pointed out! You should not use speed * Time.deltaTime as the t value of Lerp/Slerp functions! The problem is that you may never reach the final rotation/position in this way, and your framerate will also significantly affect the speed. I'll try to make a clear example: Let's say you want to go from Point A to Point B, and your game runs at 60 frames per second, equivalent to a 0.016666 deltaTime. For simplicity, let's use speed = 30. In the first frame, you will move from Point A toward Point B about t = 0.5 (0.016666 * 30), right in the middle between the two points, which will become your new Point A. Agin, next frame, you will also move right in the middle between your current Point A and Point B. As you can see, you are just reducing the distance between you and your final target at each frame, not really reaching it. And that's considering a constant target frame rate in every device you plan to use. Side note: You will eventually reach Point B because you reached the minimum float precision, and the value snaps to the target. There are many ways to fix this problem: One way is to add speed * Time.deltaTime to t (initially set at 0) and use a saved initial value of Point A and B.
Link? Because this statement couldn't be more wrong. Time.deltaTime is completely frame rate dependant, meaning that its value directly depends on the frame rate. What you probably mean is that you can use Time.deltaTime to make things frame rate independent, but that DOES NOT MEAN you can just shove Time.deltaTime into any function without thinking and it magically makes your math framerate independent.