Optionaloptions: OrthographicCameraOptionsBottom edge of the view volume in camera space.
Whether this node's own drawn shape clips its subtree (§67; R-23,
2026-08-21). Default false.
panel.clip = true; // children are masked to the panel's shape
panel.add(content); // …including everything below them
The mask is the node's own geometry, drawn with colour writes off, so a
§50 Shape clips to its path, a rectangle clips to a rectangle, and a
Sprite clips to its quad — §67's "path masks" and "UI overflow clipping"
with no second authoring surface and nothing new to build a region out of.
@fourjs/render's clip.ts states the tier and what it deliberately leaves
to a later packet (alpha masks, 3D clipping planes, true scissor
rectangles).
The clip gates this node's descendants and not this node, which is the
exact mirror of layers above (§46 gates the node and not its subtree).
That is what a UI panel needs — it paints its own background and border and
then contains its children — and it is why the two fields sit next to each
other with opposite scopes rather than sharing a spelling.
Nested clips intersect: a clipped subtree that contains another clip
draws only where both shapes cover. Eight clips can be live in one frame,
because a stencil bit plane is spent on each and every stencil buffer WebGL
2 can allocate is eight bits deep; the ninth is dropped with a §67
diagnostic, and its subtree spills rather than vanishing (see
ClipPlaneAllocator).
Two conditions make this field inert, both warned about in a development
build and both failing toward drawing rather than toward an empty screen:
a node with no geometry to draw (a plain Group) has no shape to mask
with, and a renderer whose drawing buffer carries no stencil buffer
(new WebglRenderer({ stencil: true }), R-7) has nothing to write a mask
into.
A plain field, like visible and layers and for the same reason: the
render list reads it once per node per frame and there is no value it can
hold that §85 would refuse.
Whether this node participates in simulation and updates (§6). Default true.
Distance to the far clip plane, same convention as Camera.near.
Which §71 hit-test strategy answers for this node, or null — the
default — for §71's own default rule: "the engine should select the
cheapest valid method" (A-11; the field ships with the analytic tier per
the adopted RFC 0005 Q3, 2026-08-29).
mesh.hitTestMode = "geometry"; // exact ray/triangle, never just the box
decal.hitTestMode = "pixel"; // a hit must land on a present texel
hull.hitTestMode = "bounds"; // the box alone, whatever data is attached
boid.hitTestMode = "gpu"; // the id-buffer pass answers, not the ray
The node carries only the choice; the data each strategy needs rides
the Pickable candidate (@fourjs/input may not import @fourjs/geometry or
a render type, plan §3.1 — the recorded reason picking takes a structural
candidate list). Under null, pick() runs the bounding-volume test and
refines it by whatever the candidate carries — triangles, an alpha mask,
or nothing — which is the cheapest method that is valid for that
candidate, and is byte-for-byte the pre-field behaviour. An explicit mode
selects exactly one strategy and requires its data (§85: a candidate
that asked for precision and silently fell back would pick where the
author said not to); "gpu" excludes the node from the ray tier
altogether, because RFC 0005's id-buffer pass is that strategy's
implementation and one pointer event must not resolve the node twice.
The mode gates this node only, not its subtree — the layers scope,
not the clip scope: every descendant is its own picking candidate with
its own mode, exactly as it is its own layer member.
§71's "custom" value is deliberately absent from the union: no
custom-callback strategy exists yet, and a selector value with nothing
behind it would be a silent no-op. It joins HitTestMode with that
strategy.
A plain field, like visible, layers and clip, and for their reason:
pick() reads it once per candidate per pick, and the union is the check —
there is no assignable value §85 would refuse (a §79 document's value is
filtered on read instead, restoring null for anything unrecognized).
ReadonlyidStable identity (§6). Engine-assigned at construction from a monotonic
counter, formatted node-<n>; ids are unique within a process and
ascending in construction order.
readonly, as §6 requires. §79 additionally requires that a deserialized
node keep the id it was saved with ("the engine assigns ids only to newly
created objects"): pass NodeOptions.id to restore one, which also
reserves it against the counter (2026-08-06, A-17 — the note that used to
stand here deferred this to the serialization packet, which shipped without
it).
ReadonlyinverseInverse of Camera.projectionMatrix (§47) — clip space back to camera space, the first half of unprojecting a pointer position (§71) or building a picking ray. Recomputed by Camera.updateProjectionMatrix, so it is never out of step with the projection it inverts.
Which §46 layers this camera can see (§47, R-38, 2026-08-08).
worldCamera.layers = layerMask("default"); // everything but the UI
uiCamera.layers = layerMask("ui"); // only the UI
A node is drawn for this camera when layersMatch(node.layers, camera.layers) — the two masks share at least one bit. Defaults to
ALL_LAYERS: a camera sees every layer until told otherwise, which is
what keeps a scene that never mentions layers identical to the one it was
before they existed.
This is the fallback, not the last word: §48 lets a viewport narrow it
further with its own layerMask, so one camera can feed two views that show
different slices of the same scene (Viewport.layerMask). A camera's mask
is per-camera state; a viewport's is per-view.
Node.layers (decision, R-38)There is one property, not two: §47 spells the camera's visibility mask
layers, and Node.layers — this engine's object-side membership mask,
which §6 does not declare — has the same name. Redeclaring the field here
narrows its meaning for cameras from "layers this node belongs to" to
"layers this camera looks at", and changes its default from
DEFAULT_LAYER_MASK to ALL_LAYERS.
That is safe rather than merely convenient: nothing ever reads a camera's
membership. A Camera is not a Renderable, so §64's list generates no
item for it whatever its mask says; it is not a picking candidate; and §46's
remaining consumers (physics groups, post-processing inclusion) do not apply
to a camera either. The alternative — a second field with a different name —
would contradict §47's declaration to preserve a fact no code can use.
One consequence worth knowing: applyLayers(scene, mask) walks every
node, so it rewrites the visibility mask of any camera inside that subtree.
Apply layers to the branch you mean, or re-set the camera afterwards.
Left edge of the view volume in camera space.
Free-form user data (§6). Its own object per node.
Human-readable name (§6); not unique and not an identity. Empty by default.
Distance from the camera to the near clip plane, along its −Z view direction (§47). A positive distance, not a Z coordinate (D8).
Opacity in [0, 1] (§6). Default 1. Not clamped here.
ReadonlyprojectionCamera space → clip space (§47). Written by Camera.updateProjectionMatrix; the instance is never replaced.
Right edge of the view volume in camera space.
Free-form tags, queried by Scene.findByTag (§46). Empty by default.
Top edge of the view volume in camera space.
ReadonlytransformLocal transform (§7). Never replaced — write into it.
Which system owns this node's transform (§42). Default "manual".
§42 spells this as a plain assignable field —
node.transformAuthority = "physics" — and that is exactly what it is:
read it, write it, one value at a time. Every value of
TransformAuthority assigns, "blended" included: it was guarded
by a FourError("NOT_IMPLEMENTED") between WP-2.3 and WP-7.3, because
nothing implemented §19's physics-animation pipeline and a node claiming
it would have been owned by a system that did not exist. PhysicsWorld
now runs that pipeline (@fourjs/physics, plan P7-4), so the guard is gone
and the value means what §42 says it means.
A "blended" node is driven by §19's pipeline, which needs two more things
this field cannot check for — a RigidBody registered with a
PhysicsWorld and a PoseTarget on the node. The first step that
tries to blend a node with no target throws FourError naming it; see
PhysicsWorld.step. Assigning the authority is never itself an error,
exactly as "kinematic" on a node no controller drives is not.
Enforcement lives in the writing systems (see warnAuthorityConflict), not
here: Node records ownership, systems honour it.
ReadonlyviewWorld space → camera space (§47): the inverse of this node's world matrix. Written by Camera.updateViewMatrix; the instance is never replaced.
Whether this node renders (§6). Default true.
Children in insertion order (§6).
The live array is returned as a readonly view rather than a copy, so
reading children allocates nothing on hot paths. It is a view, not a
snapshot: it reflects later mutations, and casting the readonly away to
mutate it corrupts the parent pointers this class maintains.
The components attached to this node, in attach order (§6a, 2026-08-06 A-15).
A live iterator over the registry's own map, so reading it allocates
nothing and reflects the node's current state; do not attach or detach
while iterating (the underlying Map would be mutated mid-walk). Copy it
first — [...node.components] — for a snapshot.
Enumeration exists for §79. Without it a serializer cannot walk what a node
has; it can only probe for what it knows about, and a component whose
type has no registered serializer is then dropped from the document with
nobody able to notice — a save that silently loses state, which is the one
failure mode that design could not warn about. @fourjs/serialization walks
this getter and refuses an unserializable component by name.
ComponentHost (§6a, @fourjs/core) does not declare it: the host contract
is what a component sees of its owner, and a component enumerating its
siblings is not something §6a sanctions.
This node's parent, or null when it is a root (§6).
Assignment is supported and is defined in terms of the hierarchy methods:
node.parent = other is other.add(node) (including its cycle check and
its detach-from-the-old-parent step) and node.parent = null is
oldParent.remove(node). It is never a bare field write, because a bare
write could not keep the two children arrays consistent.
Alias for this.transform.position — the same live Vector3, never
a copy, so node.position.set(1, 2, 3) and
node.transform.position.set(1, 2, 3) are one and the same write and both
run the transform's change hook (plan D3: the version bumps, dependent
caches invalidate).
The spec writes this spelling throughout — Four.animate(node.position)
(§15), camera.position.set(0, 2, 6) and label.position.set(0, 1.2, 0)
(§97) — while Transform is where the value actually lives (§7). This
getter makes both spellings work, resolving the WP-3.1 ergonomics flag
(TODO: Node.position/rotation/scale aliases onto transform.*).
Getter only, deliberately: Transform.position is a readonly property
holding a mutable vector — replacing the instance would silently drop the
change hook — and the alias mirrors exactly that contract. Assignment
(node.position = v) is not the API; write into the vector with
.set(...) / .copy(...).
Transform authority (§42) is unmoved by the spelling: a write through this alias is a write to the node's transform, and a system that is not the node's Node.transformAuthority must not make it either way.
Alias for this.transform.rotation — the same live Quaternion,
never a copy. Radians semantics per §7a; getter only, for the reasons
documented on Node.position (mutate via quaternion methods, never
by assignment). Writes through it bump the transform version exactly as
transform.rotation writes do, and §42 authority applies unchanged.
Alias for this.transform.scale — the same live Vector3, never a
copy. Getter only, for the reasons documented on Node.position
(mutate via .set(...) / .copy(...), never by assignment). Writes
through it bump the transform version exactly as transform.scale writes
do, and §42 authority applies unchanged.
Attaches nodes as children, in argument order, appending each to the end
of Node.children. Returns this.
Rules:
FourError("INVALID_SCENE_GRAPH"). Nothing is
attached for that argument.removed on the node before added fires.add silently reorder siblings and
emit a spurious removed/added pair; callers that want a new index can
remove then add.)Delivers event to the listeners registered for type in registration
order. Re-entrant emission of type is deferred (rule 4).
The attached component of type, or undefined (§6a).
Writes the world-space unit vector this node faces — its −Z axis — into
out and returns it (§7b's out-parameter convention; nothing allocates).
−Z is the engine's one forward direction, for every node rather than for
cameras alone: a camera looks down it (Camera.viewMatrix,
Matrix4.setPerspective), a directional or spot light shines along it
(§68), and Node.lookAt aims it. The inverse of lookAt, and the
cheapest way to ask where something ended up pointing.
World transforms are resolved on demand (resolveWorldTransform(this)),
exactly as Camera.updateViewMatrix resolves — O(depth), version-cached,
so the render path's prior resolve pass makes this a few comparisons. The
basis column is normalized, so ancestor scale does not stretch the
direction.
A degenerate node — zero scale somewhere up the chain — yields the zero
vector rather than NaN (Vector3.normalize's documented zero-length
behaviour): like a degenerate camera (§47), it poisons nothing downstream
and raises no error on a per-frame path.
Number of live registrations for type (diagnostics, §83).
Number of live listener registrations across every event type (§83).
Used by teardown diagnostics — a detached node that still holds listeners pins its subtree until those listeners are removed.
Turns this node so that its −Z axis points at target, with its +Y
axis as close to up as the aim allows (§44/§47's orientation helper —
"aiming a camera or a light" without hand-composing quaternions). Returns
this.
camera.position.set(0, 2, 6);
camera.lookAt(new Vector3(0, 0.5, 0)); // §7a's world +Y is the default up
sun.lookAt(target, new Vector3(0, 0, 1)); // a light is aimed the same way
target is in world spaceAlways, whatever this node is parented to (decision, R-36). A world-space target is the contract that makes the call mean the same thing when a node is later reparented onto a moving rig — the case §44's follow rigs and spring arms exist for — and it is the only one under which "point the camera at the player" is a single call. The local rotation is derived from it: this node's world position comes from its resolved world matrix, the world rotation is built from the aim, and the parent's world rotation is divided out
localRotation = conjugate(parentWorldRotation) · worldRotation
so a node under a rotated, translated, or uniformly scaled parent aims
correctly. A parent with non-uniform scale has no exact rotation to
divide out; Matrix4.decompose's closest-rotation reading is used, with
the shear it cannot represent left in — the same documented limitation
every decomposition in the engine carries. A parent with a zero scale
component decomposes to the identity, so the aim lands in world terms.
The node's own scale and pivot are irrelevant to the result: only the
rotation is written, through transform.rotation.copy(...), so the version
bumps exactly once (plan D3) and dependent caches invalidate exactly as
they do for any other transform write.
This is an ordinary application transform write: it always lands, the
same as node.rotation.setFromAxisAngle(...). A DEV build warns once if
Node.transformAuthority is not "manual" (warnApplicationTransformWrite);
production is silent. The write is never refused. A rig that wants to aim a
node every frame under a non-manual authority has the same obligation as
any other writer: claim the authority, or wrap with runOwnedTransformWrite.
FourError("INVALID_SCENE_GRAPH") is thrown, and nothing is written, when
target coincides with this node's world position (or either is
non-finite): there is no direction to face; andup is zero, parallel to the aim, or non-finite: the aim leaves the roll
about it completely undetermined — the top-down lookAt from directly
above with the default +Y up is exactly this case, and wants an
explicit up such as world −Z.Refusing rather than substituting is §85's "detect singular transforms"
applied at the point of authoring, reported under the same code
Node.add uses for §85's scene-graph rule so one catch covers both.
Silently picking a fallback up — the usual engine behaviour — would
rewrite the orientation the caller asked for and hide the mistake behind a
plausible-looking roll; leaving the node unturned would be indistinguishable
from a frozen rig. A rig that can reach a degenerate configuration (an orbit
at zero radius, a follow target that catches its camera) must guard the
call, exactly as it must guard a division by its own radius.
Allocates nothing: the aim, the world rotation, and the parent's rotation live in module scratch.
Removes the earliest still-registered registration of listener for
type. Removing a listener that is not registered is a no-op.
Registers listener for type. Returns a function that removes it.
The same listener may be registered more than once; each registration is independent and is delivered once per dispatch.
Registers listener for a single delivery. Returns an unsubscriber.
Detaches nodes from this node, in argument order. Returns this.
Removing a node that is not a child of this node is a no-op — no throw, no event (decision: removal is idempotent, so teardown paths can call it without first testing parentage).
Removes every listener, or every listener of one type. Used by teardown paths that must not leave detached nodes retaining listeners (§83).
Optionaltype: KDetaches component, running its onDetach; returns false when it is
not the component currently attached for its type. Detaching does not
dispose (§6a).
Calls visitor on this node, then on every descendant, depth-first in
insertion order (§6).
Children are read live by index rather than from a snapshot, so the walk
allocates nothing; the price is that structurally mutating the hierarchy
from inside visitor is not supported (removing the current node's
successor skips it). Collect first, mutate after.
Recursive, so depth is bounded by the JS stack — scene graphs thousands of levels deep are out of scope.
Rebuilds Camera.projectionMatrix from this camera's projection parameters, and Camera.inverseProjectionMatrix from the result.
Call it after changing any projection parameter — nothing recomputes implicitly (see the module documentation). Constructors call it once, so a freshly built camera already projects.
depthRange is the target backend's clip-space depth convention (D8) and
defaults to "negative-one-to-one". It is an argument rather than camera
state because it belongs to the renderer, not to the camera: the same
camera feeding a WebGL 2 and a WebGPU view differs only in this, and a
renderer that owns the value cannot get it wrong. A camera rendered by a
"zero-to-one" backend must therefore have its projection updated with
that argument — the backend does it as part of preparing the view.
Implementations write in place and allocate nothing.
OptionaldepthRange: DepthRangeRebuilds Camera.viewMatrix as the inverse of this camera node's current world matrix (§7, §47).
World transforms are resolved on demand first
(resolveWorldTransform(this)), so the result is correct at any point in a
frame, including immediately after moving the camera or one of its
ancestors and before any full resolution pass has run. That resolution
walks this node's ancestor chain only — O(depth), nothing below the camera
— and is version-cached, so when the caller has already resolved the scene
(the normal render path: §7 resolves before render-item generation, §64)
this costs one comparison per ancestor and no arithmetic. Callers that want
to guarantee that cheap path resolve the scene before calling; correctness
never depends on it.
Allocates nothing. A camera whose world matrix is singular — only possible
with a zero scale somewhere up the chain — leaves viewMatrix holding that
un-inverted world matrix rather than infinities or NaN, because
Matrix4.invert refuses singular input and leaves its elements alone. The
result is meaningless either way; the point is that a degenerate camera
poisons nothing downstream and raises no error on a per-frame path.
Orthographic camera (§47): parallel projection of a box-shaped view volume — the 2D and CAD workhorse (§48 lists "CAD orthographic views" among the viewport use cases).
The six bounds are given in camera space with +Y up (§7a), so a 2D scene showing world units
[-8, 8] × [-4.5, 4.5]isnew OrthographicCamera({ left: -8, right: 8, bottom: -4.5, top: 4.5 }).Defaults are the unit box
[-1, 1]²with the same near/far as PerspectiveCamera (decision, WP-3.1 — §47 and §97 pin no orthographic defaults;[-1, 1]²makes the default projection map camera space straight onto normalized device coordinates, which is the least surprising identity for a camera nobody has configured, and sharing near/far keeps the two camera types consistent).A degenerate box (
right === left,top === bottom,far === near) produces non-finite elements rather than throwing — see PerspectiveCamera.