CubeMap

CubeMap lives in the 3D texture/material domain. Its purpose is not to create a pretty cube-cross bitmap for MediaOut, but to build a directional texture that a 3D shader can sample by direction.

The node has dynamic topology. Layout = Vertical Cross or Horizontal Cross exposes one CrossImage input; Layout = Separate Images exposes six directional image inputs for Left, Right, Top, Bottom, Front and Back instead.

CrossImage is an ordinary 2D image source. CubeMap extracts six square faces from it according to the selected layout and represents them as a cubemap texture.

Separate Images is useful when the six directions are already rendered separately. Blackmagic documents that mismatched or non-square face images can be rescaled into a common square face size, so production assets should preferably be normalized before CubeMap.

Vertical Cross expects an unfolded cube with a 3:4 aspect ratio. A source that does not match the expected layout may be cropped to the applicable aspect; Warn About Bad Dimensions is intended to expose this kind of problem.

Horizontal Cross expects a 4:3 unfolded cube. Do not confuse either cross layout with a normal 2:1 equirectangular panorama: a lat-long panorama is not automatically a cube cross.

CubeMap is therefore not a generic SphereMap or equirectangular-to-cube converter. If the source is lat-long, use an appropriate spherical/environment conversion workflow rather than merely selecting Vertical Cross.

The current Resolve Inspector exposes Convention = Positive Z or Negative Z. Treat this as the directional Z convention for the cubemap and verify interoperability with a labeled face test when exchanging maps with another DCC or renderer.

Coordinate System = Model evaluates the texture orientation in object-local space. This is appropriate when the cubemap should follow local object orientation.

Coordinate System = World evaluates the texture in global scene space. It is a useful baseline for an environment/reflection reference that should not simply rotate with one object's local transform.

Coordinate System = Eye evaluates the texture relative to camera/view space. This creates view-relative behavior and should not be mistaken for a world-locked environment.

Rotation Order sets the Euler order for the cubemap lookup orientation. With one active axis the order matters little; with compound X/Y/Z rotations different orders produce different final orientations.

Rotation X/Y/Z rotate the cubemap lookup itself. They do not rotate the geometry, camera or lighting rig, which makes them the correct controls for texture orientation after scene placement is already correct.

For a simple horizontal environment turn a single axis is often enough, but do not hard-code the assumption that one axis is always 'horizontal' without checking Coordinate System and Convention.

Texture Depth = Source keeps the upstream precision. int8/int16 force integer representations, while float16/float32 preserve a wider numeric range and finer gradients for HDR and technical texture data.

For HDR environments, float16 or a suitable Source precision is generally safer than int8 because highlights above 1.0 and smooth gradients can matter to reflections and refractions. float32 should be used when additional precision is actually justified.

Texture Depth does not create HDR information that was clipped or quantized upstream. It changes the representation of the resulting cubemap rather than restoring missing source range.

Texture Filtering Mode is split by OpenGL versus Software renderer and by LowQ versus HiQ. The same cubemap can therefore be sampled differently depending on render implementation and quality mode.

Nearest preserves texel boundaries and is useful for face-ID/debug maps, but it can look blocky on beauty textures. Bilinear is a sensible baseline for many normal environment maps.

Trilinear extends bilinear sampling for scale/LOD transitions, while Anisotropic can preserve more detail at oblique viewing angles. The real effect depends on the renderer/GPU path and should be checked on the delivery path.

OpenGL LowQ/HiQ and Software LowQ/HiQ are not four steps of one universal quality ladder. They are two renderer-specific pairs of sampling controls.

Warn About Bad Dimensions reports a source/layout mismatch; it does not repair the asset. A warning should send you back to source aspect, face size and layout preparation.

Material ID belongs to the material-domain CubeMap output and can be written into the MatID auxiliary channel when that renderer pass is enabled. It is not a face number and it is not a geometry ObjectID.

CubeMap output is not a 2D image intended for direct MediaOut. A typical graph sends it into Blinn/Phong/Reflect/Falloff or another material consumer, then into 3D geometry, with pixels appearing only after Renderer3D.

Blackmagic's basic example shows CrossImage → CubeMap → Blinn → Shape3D. This is useful because it makes the domain boundary explicit: an image enters CubeMap, and downstream data behaves as a texture/material.

For reflection/refraction work, CubeMap commonly acts as an environment texture inside a reflective material. This form of environment mapping approximates the environment as infinitely distant.

A static cubemap does not create true mutual reflections between neighboring scene objects. Reusing one map on multiple objects reuses one distant-environment representation.

The fastest orientation diagnostic is a labeled face test: six highly distinct images marked LEFT/RIGHT/TOP/BOTTOM/FRONT/BACK with Up arrows. It exposes swaps, mirrors and Z-convention errors much faster than a photographic HDRI.

In Separate Images mode, verify not only which face is connected where but also the internal orientation of each image. A correct face rotated incorrectly can create a seam that looks like a filtering problem.

Do not try to cure face-order or orientation errors with stronger anisotropic filtering. First verify layout, face assignment, face rotation, equal size/precision and convention; tune filtering only after the map is structurally correct.

The Settings tab contains common 3D texture-node controls. CubeMap-specific authoring lives on Controls, while scripting/serialized IDs should be verified from a minimal .setting/.comp on the target Resolve build.