Forward Vector from normal flipping SOLVED! (sorry don't know how to mark it as such officially)

SOLVED! (sorry don’t know how to mark it as such officially)
Long story short, omni-directional gravity and the requirement to rotate in line with that. Issue is when the sign of an element of a normal (used to calculate axes) is switched, it reverses the direction of the forward or right vectors (depending on the normal).

Example
Normal Vector is x = 0, y = 1, z = 0
Everything is fine.
Normal Vector is x = 0, y = -1, z = 0
Forward vector is flipped

I’m currently calculating the vectors as so
Up vector = normal
Forward Vector = cross product of normal with Up Vector
Right Vector = cross product of Forward Vector with Up Vector

I’ve solved this problem is the past but at the time I had a very specific use case that gave me an obvious workaround (I could modify the direction by taking into account velocity). This time round however I’m stumped.

Visual Aid:
Vector output performing correctly.


Vector output reversed

I feel like the answer to this is staring my right in the face and not finding it is maddening.

Here is the code in case text wasn’t clear.
image

1 Like

About Normalizing: If magnitude is 0 the gods of maths cry.

I cheat when i have to vector flip, by adding a teeny tiny amount of velocity just before i normalize, “use case”.

Have you tried breaking vector before Normalize and flipping forward V there, make new V for Normalization?

Hi, thanks for the reply, fortunately this is not a problem. The normal of a surface can never be 0 (afaik) unless the hit result comes back false. I do take into account if it is 0 already to calculate whether I should set the gravity vector or keep the old one.

I’ve managed to narrow down the issue since I posted. But unfortunately it’s also led me to the realization that this behavior is actually something I’d want in many cases. traversing a loop. The issue arises at poles and when standing on surfaces that would flip the vector. So Honestly I’m in even more of a bind than when I started.

I had a similar issue with gimbal locks on an older project, pole = 0.
If approaching a pole or at a pole you can make a slight adjustment to that 0 as so you are never dividing/multiplying by 0.

I think either you’re talking about something I don’t understand or we’re not on the same page haha

Either way I’ve found a temporary fix with some trade offs. I had to dip into the dreaded realm of quarternions but it works. Answer was about as simple as I feared. If y < 0, rotate the rotator by 180 degrees along its relative yaw axis.

While you may have not directly given me the answer here I have to thank you for tickling my brain enough to make me attempt something weird at the ungodly hour of 05h30 haha.

1 Like

if y = 0 then y = y + .0001 based on the tolerance you set in your normal. Before the normal though, as it will not normalize if it is not safe to do so.

Gets a normalized unit copy of the vector, ensuring it is safe to do so based on the length. Returns zero vector if vector length is too small to safely normalize.