rotation – Digital camera-dependent inverted motion with arbitrary gravity (reference body subject)

Query

I’m implementing a personality controller that helps arbitrary gravity, permitting the character to stroll on partitions and ceilings.

Gravity is outlined as a normalized vector G, and motion enter is expressed relative to the digicam orientation.
The controller works appropriately for many gravity instructions, however a particular subject seems when gravity is totally inverted.

Noticed habits

When gravity is:

G = (0, 0, +1)

(i.e. the character is strolling on the ceiling)

• If the digicam ahead vector is aligned with the world X axis, ahead motion behaves appropriately.
• If the digicam ahead vector is aligned with the world Y axis, ahead motion turns into inverted or swapped.

The enter itself is fixed (ahead = +1), and the problem is not associated to enter dealing with, however clearly will depend on digicam orientation and the way the motion path is reconstructed.

Present strategy (conceptual)

1. Learn a 2D motion enter vector (ahead / proper).
2. Use the digicam rotation to compute a ahead path.
3. Apply a gravity-dependent rotation in order that motion aligns with the floor outlined by G.
4. Use the ensuing vector because the motion path.

This strategy works so long as gravity will not be totally inverted, however breaks when G aligns with +Z, suggesting an invalid or unstable reference body when reconstructing the motion foundation.

Speculation

This appears to be a reference body / foundation reconstruction drawback, the place the chosen ahead/proper vectors turn into ambiguous or flipped when the gravity vector is colinear or anti-colinear with a world axis.

Query

What’s the mathematically right means to assemble a steady motion foundation (Ahead / Proper / Up) given:

• a gravity vector G (defining the Up path as -G)
• a digicam ahead vector C

in order that:

• motion stays constant no matter digicam orientation
• no axis inversion happens when gravity is inverted (ceiling strolling)

Specifically:

• Ought to the motion path be obtained by projecting the digicam ahead vector onto the aircraft orthogonal to gravity?
• What’s the really useful solution to deal with edge instances the place the digicam ahead vector is almost parallel to the gravity vector?

Notes

• The problem is engine-agnostic; the implementation occurs in Unreal Engine, however the issue is only mathematical.
• I’m particularly in search of a sturdy vector / foundation building, not engine-specific workarounds.