I have a system where an object orbits another object using trace calls to get the right position and rotation.
In my attached picture, the green cube is orbiting the white sphere. It all works good UNTIL the green cube gets directly to top, and right before it’s time to start heading down along the sphere, it promptly starts freaking out in that position, stops and just starts spinning.
I tried doing a check to see when the cube is at the top of the object (checking the y-value of the rotator > 90), and then negating some vectors, but nothing worked.
Can anybody help me out here to keep the object on the path as it’s heading down the sphere?
Try to bind your X/Y rotation to base object (white ball I suppose). And rotate only Z. But if you wish to tilt axis forward… Use “make rot from z” instead of “rotationfromx”. It works for me good.
Seems like almost like a gimbal lock due to using Make Rotator From X Vector. There is not enough information from that vector about the direction of your orbit as you approach 90 degree pitch, so what you should use is MakeRotfromXZ. Where the Z vector is your current X vector and your X vector is the direction the cube is facing perpendicular to your orbit.
That said this is a bit of a weird way to orbit an object. You could just parent the cube and add some offset and then rotate it to give a good orbit.
Thank you so much, getnamo - you were pretty much right!
The correct solution was to use a Make Rot from XZ, and feeding the Impact Normal vector from the Break Hit Result into the [X] and the Get Actor Up Vector into the [Z]. So you had them reversed.
I guess it was a gimbal lock? I still don’t 100% understand why it freaked out only when it reached a straight vertical position, but the solution of feeding the rotator more data makes sense.
Yes, I realize that it’s a weird way to rotate an object, but it’s for gameplay reasons.
I must’ve pictured your X/Z vectors differently than you had it setup, it depends on which direction you’re considering forward, I’m glad it works though!
As to why it freaked out, recall that Roll and Yaw are ± 180 degrees whereas pitch is ±90 only. To define a straight up position, pitch should be 90 or very close e.g. 89.9, then roll should be 0, but yaw can be anything. When you sample a vector (e.g. hit) and convert it using only one vector it will align the rotation (yaw) based on the orientation of the vector from vertical, so as you get very close to 90, any small perturbation will change the yaw drastically, giving you the result you see in the gif.
Whereas if you use two vectors to make the rotation, there is enough information to align the yaw of the orientation in the desired direction and it will pass through the vertical when animated without a problem.
