There isn’t much new math in here. Just some semi-practical things we can do with it.
It’s best to set the rotation from your own variables and not try to read back from a
quaternion. But sometimes you need to get the y-spin out of a rotation.
transform.eulerAngles.y might be correct, or it might be off by 360 (like -192
when you wanted positive.) Or, because of the two ways for each problem, it can be
off by 180 if x is spun over the top.
This reads the y-spin from a quaternion gets the correct 0-360:
Another way to get 0-360 y-spin is to take the forward z-arrow of the rotation, flatten it, and find the angle to due north. That’s correct if the real angle is 0 to 180. If the arrow points left (x is negative) you fix it:
A more trig-like version of that uses atan2. This seems better since it’s shorter, but it’s very easy to mess up:
RotateTowards and LookAt are great, but sometimes you just want to use a 0-360 y to spin something.
The first trick is to use your own float ySpin; as the master variable. Spin that however you want, and set your rotation from it:
Sometimes you want to spin to a certain rotation. Suppose you’re at 350 degrees and the target rotation is 10. It looks like you have to subtract 340 degrees, but 10 is also 370. You really to want add 20 degrees.
Doing that +/-360 math isn’t super hard, but Unity has a shortcut: MoveTowardsAngle. It pushes the first input to the second, not overshooting, using the shortest way. This uses it to always y-spin us towards where we say:
MoveTowards bases the result on the first number, adjusting the second. For example, MoveTowards(20,390,move) gradually pushes 20 to 30 (which is 390-360.) But MoveTowards(720,-10,move) gradually turns 720 into 710.
This is good. If you want to start at -200 degrees, you can without it jumping up by 360. And if you convert 361 into 1 in between uses, MoveToward will continue to work.
When a typical character walks over uneven ground they stand straight up. But sometimes we want something angled with the ground.
The way to find the angle of the ground is to get it’s normal – which way is “up” for that crooked section. To angle yourself with the ground: start standing straight up, find the rotation from real up to the ground’s normal, and use it to tilt yourself.
This next code plants a randomly spun tree, angled with the ground (pretend we already have the ground’s normal):
Remember the order matters. In the last line we can think of a real ground tilt, then adding our y-spin around the local y.
FromToRotation does the work here. It isn’t used that much, but it’s pretty cool
when it does.
Suppose we can’t start standing straight up. For example we have a LookAt that might also tilt us. We’ll use the same plan, but the ground tilt will be from our current up, transform.up:
More complicated, suppose we want to gradually spin to face some direction, always tilted with the ground.
The plan is to maintain and move a standing straight spin, and re-tilt it to the ground each frame:
The RotateTowards is sneaky here. It can rotate you in any direction, but with
these it keeps your head up and y-spins you since that’s the quickest.
We might want to only partly tilt with the ground. In the case, we can use Quaternion.Lerp to get a fraction of the angle. This gets a 30% tilt in the ground’s direction:
A simple orbit camera spins around us in a half-circle, always looking at us. Looking at us is the easy part – the Lookat shortcut will do that.
For the half-circle, the plan is to re-use the code making something spin around us. The old code spun us in a ring over a single axis, but there’s no reason we can’t use x and y together, to aim anywhere.
Since the camera’s “base” position is directly behind us, we’ll have the to-camera arrow start pointing directly backwards. So y=0 looks forward, and y=180 is in front of us, looking back at us. x will go from 0 to 89.
Simple code to do that:
A neat thing about using a backwards line is +x finally goes up.
We probably also want this to spin with the player. As the player turns, a behind camera should stay a behind camera. We can do that by adding the player’s rotation. A little trial and error says it goes as a global, so is in front.
This would go before we use qCam:
For real we’d add more math. Instead of using the player’s position, which might be at the feet or the center of the body, we’d compute a point near the head.
Instead of doing the LookAt to where we started, we might compute a point a
little ahead of the player. As the angle swings around to the front we might make the
distance to the camera longer or shorter.
There’s often a way for the camera to zoom inward if something is between it and us. When that’s gone, we don’t want the camera to suddenly snap out. We can do that by computing where the camera should go, then using a MoveTowards to go there
These two lines would replace the one theCam.position= line:
To get a line between two objects, take a length one line (like a plane or a cylinder.) Put it exactly between your objects, aim it at the second one, and stretch it to be as long as that distance.
The object you use should be set-up so its z forward axis is the stretchable part. For example a Unity cylinder stands up, running along +y. We’d want to use the parent trick to have it aim along +z. Stretching it then gives a nice, long tube.
This like goes from center to center. It might be nicer to start and stop at the edges of the shapes. Suppose the target ball has a radius of 0.5, so we want to stop that far away. And let’s go nuts and assume toWing is the local offset to where the line starts (it starts from our wing, just because):
It the line is just a flat plane this will have it pointing straight up, since that’s how lookRotation works. We’ll often be seeing just an edge. A common billboard trick is to z-roll so the plane tries to face the camera.
We can do that by giving LookAt an UP arrow towards the camera:
This is pretty much the math the built-in lineRenderer is using.
If you use LookAt or LookRotation to track a moving object, leaning all the way back can snap your head around, which won’t look very nice.
Here’s a short program showing the problem. It has us look at an airplane flying straight over our head:
LookAt likes to first y-spin us towards the airplane, then lean back, which will be
at most 90 degrees. When the airplane flies directly over, then goes behind us, we
don’t keep leaning backwards – we quickly turn around.
The fix is slippery, so I’ll just write it and you can play around if you want. Pick a
different UP for lookAt. Pick one where the object will never be. Suppose you only
plan to look at things above you. Using Vector3.back for the z-spin works
Adding it to the code above will have you lean back more and more, with no snapping.
Another use of the “change where up is” trick is to tell LookAt to respect your
current roll. Give it your current y-axis as UP, like this:
That always gives a smooth rotation, but looks pretty bad – it doesn’t
prefer head-up at all, so will gladly have you lying on your side or back.
Again, like a movie badguy trying to decide how to hold a pistol so it looks
An improvement is to read our previous UP, but gradually spin it to the real up:
It doesn’t work for the code with zz above (it can’t tell whether to twist left or
right,) but it will if you move the airplane a little left or right, like 0.01 for x. It gives
a nice effect.
We could also have it ease-in to the LookRotation. Suppose our target teleports and we don’t want to snap – we want a quick spin to the new facing. This uses RotateTowards to ease-in from the current rotation to the new one:
This version will also spin to be head-up, since the target rotation is
This RoateTowards trick will also help a moving object gradually tilt to the ground angle. Compute your ground-tilt angle as normal, then use the second-to-last line above to ease into it.
Suppose we have a block with certain marked spots where it can connect to other blocks. We usually mark the connection spots with an empty child . Its +z faces outward to show the “plug-in” direction. We call that a mount-point.
When we connect some other block, we find a mount point on it, face the
+z’s towards each other, and line up the y’s (the x’s will automatically be
This picture shows two identical blocks. They have mount-points A and B, rotated as shown. The second block is rotated 90 degrees left, connecting point B with point A on the first block. Notice how the z’s face each other and the y’s line up:
Assume block 1 is anywhere, spun however. The problem is figuring out how to place block 2 so the proper mount points connect.
Here’s just the set-up, finding the A and B mount point children:
The last line is cheating a little (but is legal.) Point A is a child of our block, and
is positioned using localPosition, but we can still look up its real position (and
also its real rotation.) So we’ll ignore block 1 from now on and start with
The next part is much harder. Point B from cube2 goes in the exact same spot as point A from cube1. That’s not so bad. It has the same rotation, except spun 180 on local y. Still not so bad.
The problem is we have to position and rotate cube2, based on where we know
point B needs to be.
Obviously, we just need to add one thing – mp2B.localPosition. That’s the arrow from cube2 to child B. But we want to go the other way, so have to flip it with a negative 1.
The last, hardest part is getting cube2’s rotation correct. Starting from A, we:
spin 180 on local y, then the opposite of B’s localRotation (it’s the rotation from
cube2 to B and we’re going the other way.)
This is all very tricky, and took me a few tries to get right:
This took a ton of testing. I finally realized I could set the rotation first, without
moving cube2, and could test to see if it worked.
An alternate way of doing all of that is tricking Unity into setting things for us.
We’d like to place point B in the right spot, rotated correctly, and have the rest of Cube2 be where ever it has to be from there. If we temporarily flip it so B is cube2’s parent, that will happen. Then we undo it. We still need to 180 flip on y:
This version might be easier to visualize. It’s not any faster – Unity has to do all of the math from the first version to set all the children.