ZToWorldPos

ZToWorldPos belongs to Fusion's Position toolset. Its job is to translate between two technical descriptions of a visible point: Z depth describes depth relative to a camera view, while a World Position Pass stores XYZ position in scene world space.

The old simplified article missed a critical topology detail: this is not a single generic Input filter. The documented node has a required Image input, a required Scene Input carrying a 3D Camera, and a standard optional Effect Mask.

Image carries different technical data depending on Mode. Z to WorldPos expects an image stream with a valid Z channel; WorldPos to Z expects a World Position Pass.

A grayscale depth-looking RGB image is not automatically a real Z channel. Before building the conversion, verify where the source depth actually lives and whether Fusion sees it as technical Z rather than ordinary color brightness.

Scene Input accepts a Camera3D or a 3D scene containing one or more cameras. A camera is needed because the relationship between image-space depth and world-space XYZ is defined by that camera's projection and view transform.

The connected camera must correspond to the render, depth, or WPP being converted. An arbitrary Camera3D can produce formally valid numbers that are spatially wrong.

If several cameras exist in the connected scene, Camera selects the intended model. It is a source selector, not a depth-strength control and not a creative scale knob for World Position.

In Z to WorldPos mode, the tool uses Z plus the camera model to reconstruct where each visible pixel belongs in world space. Conceptually this is a back-projection from camera/depth representation into scene XYZ.

Reconstructed World Position quality is limited by source Z quality. Noisy, quantized, incomplete, or temporally unstable depth becomes noisy, incomplete, or unstable world coordinates; the converter does not recreate geometry that was never measured.

The documented tracked-footage workflow is especially useful: per-pixel Z from 3D tracking, together with the solved 3D Camera, can be converted into WPP data for Position tools such as Volume Mask and Volume Fog.

WorldPos to Z performs the reverse relationship. It evaluates a World Position Pass against the selected Camera3D and produces the corresponding camera-relative Z channel.

A World Position Pass is not a beauty image. XYZ values can be negative and can extend far beyond the normal display range because they represent scene coordinates rather than display-referred color.

World Position should preserve 32-bit floating-point precision. Normalizing or clamping XYZ into 0-1 may create an easier preview but destroys the exact coordinates needed by downstream Position tools.

WPP is often visualized by thinking of XYZ as RGB components: X maps to R, Y to G, and Z to B. That visualization is diagnostic; grading the map as ordinary color changes the spatial values.

Fusion Position tools expect a World Position Pass in World Space. Eye or Camera Space and Object or Model Space are different coordinate systems even if their colorful previews appear superficially similar.

Scene Input may receive a Camera3D directly or a larger camera-containing 3D scene. When multiple cameras are present, the Camera dropdown is how the intended render camera is selected.

Effect Mask is the standard optional mask input. It can limit the tool spatially, but it does not carry Z or World Position data and it never replaces the required camera Scene Input.

Empty WPP regions need special attention. Pixels without real geometry can end up initialized as position (0,0,0), which downstream Position tools may interpret as actual geometry at the world origin.

For 3D-render workflows, the Fusion documentation recommends a bounding sphere or box when meaningful distant position values are needed in the background instead of empty world-origin values.

For tracked live-action workflows, the same principle means foreground-only depth may be insufficient when downstream processing needs a valid spatial background. Missing depth samples do not appear automatically after conversion.

Keep technical WPP separate from a display-friendly preview branch. Normalize or tone-map only a diagnostic copy while the production branch stays full-range floating-point data.

In WorldPos to Z mode, the WPP and camera must share the same world coordinate system. Matching resolution alone does not make data from a different scene or transform valid.

Pixel correspondence matters as well. Z/WPP values belong to specific samples, so unsynchronized crop, resize, warp, or pixel-aspect changes can break the relationship between image data and camera projection.

A Z to WorldPos to Z round trip is a useful diagnostic for camera mismatch, precision loss, and damaged technical data. It should not be treated as a promise of bit-exact identity after resampling or reduced precision.

When caching or exporting, choose a format and settings that preserve the required floating-point precision and technical channels. A visually acceptable RGB preview does not prove that Z or WPP survived the file round trip correctly.

Temporal QC matters whenever Z or the camera is animated. Camera-solve jitter, depth flicker, and holes become drifting world positions and unstable downstream spatial effects.

A reliable production order is: confirm Image plus matching Camera3D, choose Mode, inspect the raw technical result in full-range/float form, then connect Position/depth-aware downstream processing, and only afterward create a display-friendly preview.