The Ceiling Paradox: Reconstructing Movement in Arbitrary Gravity

As gravity-shifting mechanics become a staple of mind-bending puzzle games and space simulators, developers frequently encounter the "Inversion Glitch." This occurs when a character walks on a ceiling or wall, and the camera-relative controls—which worked perfectly on the floor—suddenly flip or become unresponsive. This isn't an input bug; it is a Reference Frame Conflict. Traditional player controllers often rely on a hard-coded world "Up" vector ($0, 0, 1$), causing the math to collapse when gravity points in a different direction. To fix this, we must discard Euler-based rotations and rebuild our movement basis using vector cross-products relative to the local gravitational pull.

Table of Content

• Purpose: Universal Movement Consistency
• The Problem: Why Controls Flip on the Ceiling
• Step-by-Step: Rebuilding the Movement Basis
• Use Case: Walking on Spherical Planets
• Best Results: Projecting Input onto Planes
• FAQ
• Disclaimer

Purpose

Implementing a custom reference frame for movement is essential for:

• Six-Degree-of-Freedom (6DoF) Games: Ensuring "Forward" always feels like forward, whether the player is right-side up or sideways.
• Dynamic Gravity Zones: Allowing seamless transitions between floors, walls, and ceilings without the player having to relearn the controls.
• Physics Precision: Decoupling the camera's orientation from the world's global axes to prevent "Gimbal Lock" during orientation shifts.

The Problem: Why Controls Flip on the Ceiling

Standard movement logic often uses Camera.Forward and Camera.Right. However, when gravity is inverted (pointing at $0, 0, 1$), the "Up" vector of the character is now exactly opposite to the world "Up." If the engine uses a LookAt or Rotation function that assumes Z-Up, it may "spin" the character 180 degrees to satisfy the math, resulting in inverted left/right controls. To solve this, we must define Local Up based solely on the current gravity vector.

Step-by-Step

1. Define the Local Up Vector

In your player controller, identify the current direction of gravity. Your Local Up is the inverse of that vector.

Vector3 localUp = -gravityDirection.normalized();

2. Get the Camera's Visual Direction

Get the raw forward and right vectors from your camera. These are still world-space vectors.

Vector3 camForward = mainCamera.transform.forward;
Vector3 camRight = mainCamera.transform.right;

3. Reconstruct the Movement Basis

This is the critical part. We need to "flatten" the camera's forward vector onto the plane defined by our localUp. This ensures that even if you look at the floor, "Forward" moves you along the surface.

• Right Vector: Cross the localUp with camForward.
• Forward Vector: Cross the newly found Right with localUp.

Vector3 moveRight = Vector3.Cross(localUp, camForward).normalized();
Vector3 moveForward = Vector3.Cross(moveRight, localUp).normalized();

4. Apply Input

Multiply your movement axes (Horizontal/Vertical) by these reconstructed vectors.

Vector3 finalMovement = (moveForward  inputY) + (moveRight  inputX);

Use Case

An indie developer is making a 3D platformer where the player can walk inside a rotating space station (O'Neill Cylinder).

• The Action: The player moves from the "floor" to a side "wall" as the station rotates.
• The Implementation: The controller calculates localUp by casting a ray toward the station's center. It then uses the Cross-Product method to rebuild the movement basis every frame.
• The Result: Pressing "W" always moves the player toward the center of their screen, and "A/D" always moves them left/right relative to their view, regardless of which way the station is currently oriented in world space.

Best Results

FAQ

Why does my character spin when I look straight up?

This happens when camForward becomes parallel to localUp, making the Cross-Product return zero. In this specific case, you should use camUp as a fallback for the cross-product calculation.

Does this work with physics-based movement?

Yes. Instead of setting position, apply AddForce using the finalMovement vector. The logic remains the same; you are simply defining the direction of the force.

Can I use this for flying games?

In flying games (Zero-G), there is usually no "Up." In that case, you simply move directly along the camera's raw forward/right/up axes without the projection step.

Disclaimer

Custom reference frames can cause nausea in some players if the camera transitions too abruptly. Always include a "smooth rotate" function for the camera when gravity shifts. This approach assumes your engine (Unity, Unreal, or Godot) uses a standard right-handed or left-handed coordinate system. Calculation results may vary if your Cross-Product order is swapped. March 2026.

Tags: GamePhysics, CameraMovement, ReferenceFrames, CustomGravity