Hello all, I am programming a game where the character is a bug that sticks to walls. The system works perfectly fine, until you go upside down. Once the character climbs to a point where a wall turns into a ceiling (at or very close to 180 degrees in the x axis) the character starts glitching up and rapidly rotating.
The following code has been modified to remove excess stuff, if the additional code is needed, I can paste the full thing of it.
I have tried changing the Quaternion.Euler values to other things but to no avail. After looking at the rotation values in the inspector, it looks like a combination of all 3 rotations are rapidly spazzing out as soon as it flips totally (or near totally) upside down. The glitch is incredibly disruptive because it limits me to designing courses that never go upside down, which is really a downer in a game that relies on sticking to walls. Some more information on the glitch is that the character seems drawn to go downwards. If you are on a sphere and position yourself and your angle such that you are going perfectly alone the equator of the sphere, it will quickly turn you if you go forward to draw you to the bottom. And the problem is, as soon as you reach the bottom of the sphere, I assume it is trying to continue downward when you are already upside down, so it just flips out. Any advice on how to fix the issue?
asked Oct 18 '11 at 02:21 AM
I managed to solve it. Although the character rotates along the world z axis when he jumps between opposite walls (a trait I find undesirable), he doesn't freak out when he is on the bottom of something.
Instead of using Quaternion.FromToRotation() I decided to create a point coming off of the normal and find the angle to reach it and use that.
This solves the issue of flipping out like a maniac quite well. If anyone has any ideas on how to keep him from rotating along the world z axis when he jumps between walls, and instead use his relative z axis, please tell me.
answered Oct 19 '11 at 12:46 AM
I'm thinking the problem is the extra degree of freedom in FromToRotation.
Imagine the normal is sticking out forwards and to the right (so the slope ahead is angled down and to the right.) In your mind, Q.FtoR should tilt you forwards (around x) then sideways (around z.) Technically, once you are lined up, the extra y-spin could be anything. But, it shouldn't add extra, so should have 0 y-spin and basically be facing forwards.
BUT, it might be quicker to first spin around y, to face the normal, then spin forwards on local x. In that case, the model is facing rightish. It's really worst than that -- quaternions aren't x,y,z spins and don't even understand the concept of "not changing the y-spin."
This snippet of test code (yours, stripped down) shows the problem (floor is a plane: tilt the plane in scene view. As it tilts more sideways, the facing squirms around on us as a y-spin becomes better. At nearly upside down, it is stable, but tiny changes affect y-spin):
Since we are tilting from Vector3.up, the best tilt tends to twist y slightly towards the normal, which is "down."
I would take advantage of that mystical "best combo of x,y,z" process. Instead of using
I think you'd have to redo
answered Oct 19 '11 at 01:41 AM