Mastering Local and Global 3D Transforms

Welcome back. Your shooting-range scene now has a floor, walls, and a directional light. You placed those room pieces by entering positions in the Inspector, but this lesson makes that action predictable: every 3D object has a transform that describes where it is, how it is oriented, and how large it is.

You will use transforms both as precise Inspector values and as viewport tools. More importantly, you will see why a child node’s position is not necessarily its position in the whole game world. This parent-child behavior will soon let us build a player whose body turns horizontally while its camera can look vertically.

---

One coordinate system, three transform properties

Godot’s 3D world uses meters. Its fixed, global axes are:

• X (red): left and right
• Y (green): up and down
• Z (blue): front and back

A Node3D has three editable transform properties:

Property	What it changes	Example in the shooting range
Position	Location	Moving a prop from one side of the room to the other
Rotation	Orientation	Turning a light so it shines in a different direction
Scale	Size along X, Y, and Z	Making a decorative box wider or shorter

The Inspector’s Transform section exposes these values. For normal scene building, entering exact values here is often more dependable than dragging objects until they merely look right.

The editor’s colored controls represent those same axes. The arrows are for moving, the curved rings are for rotating, and the cubes are for scaling.

The most useful shortcuts while arranging a scene are:

Action	Shortcut	Use
Move mode	W	Drag an axis arrow or a plane handle
Rotate mode	E	Drag a colored rotation ring
Scale mode	R	Drag an axis cube or the center for uniform scale
Frame selected node	F	Bring a distant selected object into view
Toggle local gizmo space	T	Align gizmo axes to the selected node’s rotation
Toggle snapping	Y	Use increments for steadier editing

Holding Ctrl while moving or rotating temporarily snaps the action. This is useful for rough room layout, but type exact Inspector values when the geometry must align exactly.

---

Local space: the coordinate system supplied by a parent

A transform is called local when it is measured relative to the node’s parent. In a scene tree, this is the default meaning of a node’s Position, Rotation, and Scale values.

Consider a DemoBlock that is a child of a Pivot node:

Main
└─ TransformLab
   └─ Pivot
      └─ DemoBlock

If DemoBlock has local position $(0,0,-2)$, that does not mean “two meters from the world origin.” It means:

Place this block two meters along the Pivot node’s local negative-Z direction.

If Pivot moves, rotates, or scales, DemoBlock inherits that change. Its own local values can remain unchanged even though its actual location and orientation in the world have changed substantially.

A node’s global transform is its final transform in the game world after Godot combines the transforms of every Node3D ancestor. Conceptually:

$$T_{\text{global child}}=T_{\text{global parent}}{T}_{\text{local child}}$$

You do not need to calculate that product by hand. Godot performs it whenever it draws a node, evaluates its collision, or provides a node’s global_transform to a script. The important design habit is to decide which behavior belongs to the parent and which belongs to the child.

For example:

• Move a parent when an entire assembly should move together.
• Rotate a parent when the assembly should turn together.
• Change a child’s local position when adjusting its offset within that assembly.
• Use a child Node3D as a pivot when an object should orbit or rotate around a point other than its own center.

This is not merely scene-tree organization. The tree creates a spatial relationship.

At the default rotation, local and global directions happen to line up. That agreement can hide the distinction. Rotate a parent by $45$ degrees around Y, however, and the child’s local negative-Z direction now points diagonally through the world. This is why a carefully structured hierarchy becomes so valuable in a 3D game.

---

Global space is the fixed world; local gizmo space follows the node

There are two related ideas that are easy to mix up:

1. Local versus global transform data describes how a node is positioned in the scene hierarchy.
2. Local versus global gizmo space describes the orientation of the editor handles while you manipulate that node.

Pressing T only changes the second item. It changes the gizmo display; it does not rewrite your node’s transforms or change the parent-child relationship.

Suppose you rotate a box $45$ degrees around Y:

• In global gizmo space, its red handle remains parallel to the world X axis and its blue handle remains parallel to world Z.
• In local gizmo space, the handles turn with the box. Dragging the blue handle moves the box along its own facing direction.

For a rotated prop, use local gizmo space when you mean “move it forward relative to itself.” Use global gizmo space when you mean “move it one meter right across the room,” regardless of its rotation.

The camera makes local direction especially important. Godot cameras view along their local negative-Z axis. A future player camera can therefore turn with its parent while always viewing “forward” in the camera’s own coordinate system.

For the range you built last lesson, the back wall is at negative Z. A player looking toward that wall will eventually use this camera convention naturally. For now, retain the simpler rule: negative Z is the direction a default Godot camera looks.

---

Build a small transform lab in your range

Rather than disturb the floor and walls, create a visible three-node assembly solely for experimenting with local and global transforms. It is a temporary scene-building tool, not a gameplay target.

In the Scene dock, select Main and add a child Node3D named TransformLab. Set its local Transform values in the Inspector:

$$\text{Position}=(0,1.2,3)$$

Leave its rotation at $(0,0,0)$ and scale at $(1,1,1)$.

Add a Node3D child under TransformLab named Pivot. Give Pivot this local position:

$$\text{Position}=(2,0,0)$$

Finally, add a MeshInstance3D as a child of Pivot, name it DemoBlock, and assign a new BoxMesh. Set the BoxMesh Size to:

$$(0.8,0.8,0.8)$$

Then set DemoBlock’s local position to:

$$\text{Position}=(0,0,-2)$$

Your tree should be:

Main (Node3D)
├─ Ground
├─ BackWall
├─ LeftWall
├─ RightWall
├─ RangeLight
└─ TransformLab (Node3D)
   └─ Pivot (Node3D)
      └─ DemoBlock (MeshInstance3D)

With no rotations or scales, you can calculate the block’s initial world position by adding the offsets:

Node	Local position	Global position
TransformLab	$(0,1.2,3)$	$(0,1.2,3)$
Pivot	$(2,0,0)$	$(2,1.2,3)$
DemoBlock	$(0,0,-2)$	$(2,1.2,1)$

The value shown for DemoBlock in the Inspector remains $(0,0,-2)$, because the Inspector is showing its local transform. Its computed global position is $(2,1.2,1)$.

Now select Pivot and set:

$$\text{Rotation Degrees Y}=45$$

The block should sweep around Pivot and rotate with it. Crucially, select DemoBlock afterward: its local Position is still $(0,0,-2)$. Nothing about the child’s own offset changed; only the coordinate system supplied by the parent rotated.

Next, move TransformLab along X using the red arrow in global gizmo space. The entire assembly moves. Then rotate TransformLab around Y. Both Pivot and DemoBlock follow because each is a descendant.

This little rig demonstrates the key rule:

Editing a parent changes the global transforms of its descendants. Editing a child’s local transform changes its placement within the parent’s coordinate system.

When finished, leave TransformLab in the scene for now. It is useful visual evidence while learning. You can remove it later once the behavior feels routine.

---

Resize deliberately: scale is inherited too

Scale is part of a transform, so it also travels down the scene tree. Select DemoBlock and set:

$$\text{Scale}=(1.5,0.5,1)$$

The box becomes wider and flatter. Its local scale says “stretch along my X axis, compress along my Y axis.” Because Pivot is rotated, that local X direction is not necessarily parallel to global X.

Reset the block’s scale afterward:

$$\text{Scale}=(1,1,1)$$

Then briefly set Pivot’s scale to:

$$\text{Scale}=(1.5,1,1)$$

DemoBlock inherits the widened X dimension because it is a child of Pivot. Reset Pivot’s scale to $(1,1,1)$ when you have observed the effect.

For simple visual decoration, node scale is convenient. For the physical room, however, preserve the practice from the previous lesson:

• Change the BoxMesh Size and matching BoxShape3D Size together.
• Keep the StaticBody3D parent at a scale of $(1,1,1)$.
• Avoid non-uniformly scaling a physics body just to reshape a floor or wall.

That approach keeps the visible mesh, collision boundary, and numerical dimensions easy to inspect. It also avoids later confusion when a player appears to collide with empty space or clip through a scaled object.

A final practical distinction: rotation changes direction; scale changes size; position changes location. Although the Inspector presents them as separate properties, a transform combines them. That combination is exactly why rotating a parent can change where an offset child ends up.

---

Key takeaways

A Node3D transform combines position, rotation, and scale.

• Local transforms are measured relative to a Node3D parent. These are the values you normally edit in the Inspector.
• A global transform is the final world-space result after parent transforms are combined with the node’s local transform.
• Parent transforms affect every descendant, making node hierarchies useful spatial rigs rather than mere folders.
• T switches the gizmo between global-axis and local-axis orientation; it does not change transform data.
• Use W, E, and R for move, rotate, and scale tools, but use Inspector values for exact placement.
• Scale visual objects freely enough for simple experimentation; keep physics room pieces sized through matching mesh and collision resources.

Next, you will attach your first GDScript to a node and use a function to change one of its properties during play. The transform lab provides a natural mental model: a script can alter the same position, rotation, or scale values you have just edited in the Inspector.