RESOLVE 21 · TRANSFORM · SPHERICAL PROJECTION / IMMERSIVE
PanoMap.
Decode the sphere.
Choose the target. Orient the world.
PanoMap is predictable when three jobs stay separate: Input Layout interprets the source projection, Output Layout chooses the target packing, and Rotation Order + X/Y/Z orient the spherical image. The native Resolve panel also exposes an important asymmetry: Auto exists on input, while output is an explicit VCross/HCross/VStrip/HStrip/LatLong/VR180/Immersive decision.
Input Layout · Auto/manual
Output Layout · explicit target
Order · pitch/yaw/roll
Zero the rotations while debugging geometry. A wrong Input Layout cannot be repaired with clever X/Y/Z values. Once conversion is correct, set the Euler order and orient the sphere—then verify the real render, not only the interactive 360 viewer.
A mathematical teaching proxy: all six Rotation Order options now compute different 3D orientation when axes are combined; layout controls change the actual displayed projection grid. Input Auto is assumed successful in this lab only. VR180/Immersive are schematic views, not real stereo/Apple packing. The axis conventions and resampling are not calibrated against Resolve’s renderer.
Five native Resolve views + a clearly labeled spherical-projection teaching proxy
5 native views · 6 core controls · 4 exercises01WHAT PANOMAP ACTUALLY SEPARATES
Source projection, target projection and spherical orientation are three different decisions.
Debug them in that order. Projection mistakes look like broken geometry; orientation mistakes look like a correctly mapped sphere pointing the wrong way.
Decode the source projection first
Input Layout tells PanoMap how the pixels should be interpreted as a sphere or cube map. A wrong source layout breaks the geometry itself: cube faces land in the wrong places, seams fail, or LatLong appears sliced. Rotation cannot repair a bad decode—establish the correct input interpretation first.
Output Layout is a separate delivery decision
Input and Output reuse many layout names, but they solve opposite problems. Input describes what you already have; Output describes what PanoMap must create. The supplied Resolve capture shows no Auto on output: VCross/HCross/VStrip/HStrip/LatLong/VR180/Immersive are explicit targets.
Rotation Order is part of the math, not UI decoration
Rotate X/Y/Z are applied sequentially. XYZ and ZYX are therefore not two labels for the same result: later rotations operate after earlier ones have changed orientation. With a simple single-axis correction the difference may be invisible, but compound orientation makes it critical.
A 360/immersive viewer may let you look around inside the sphere without changing the PanoMap output itself. Use Rotate X/Y/Z for an actual output-orientation change and verify the render/delivery in the target player or headset. Do not confuse interactive viewer navigation with a baked transform.
Check the non-commutative rotation experiment in the live laboratory: load the XYZ ≠ ZYX case and change only Rotation Order while keeping X/Y/Z untouched. The meridian grid and the marked beacon now move geometrically, not merely in the status label. Open Euler experiment ↑
02FIVE NATIVE VIEWS · EXACT VISIBLE CONTROLS
Read PanoMap from projection declaration to Euler orientation.
The screenshots resolve an important ambiguity in the older page: Auto appears on Input Layout, not on Output Layout. Output is an explicit delivery projection.
PROJECTION · INPUT / OUTPUT
Define what came in and what must go out first
- Input Layout
Interprets the source as Auto, VCross, HCross, VStrip, HStrip, LatLong, VR180, or Immersive. Auto attempts input detection from metadata/frame aspect; manual selection is safer for ambiguous files or missing metadata.
CheckIf faces are scrambled, seams are wrong, or spherical geometry is broken, check Input Layout before touching Rotate.
- Output Layout
Selects an explicit target: VCross, HCross, VStrip, HStrip, LatLong, VR180, or Immersive. Auto is absent from the supplied screenshot because output is a deliberate delivery-format decision.
CheckIf you only need to re-orient LatLong, keep input/output in the same layout and adjust rotation; avoid an unnecessary projection conversion.
- VCross / HCross / VStrip / HStrip / LatLong / VR180 / Immersive
Cross/Strip are cube-map families; LatLong is an equirectangular 2:1 sphere; VR180 and Immersive are immersive-oriented layouts in the modern Resolve workflow. They describe projection/packing geometry, not a creative look.
CheckCheck the requirements of the target player, headset, engine, or CGI pipeline. A visually plausible preview does not guarantee the correct delivery layout.
ORIENTATION · EULER ORDER / AXES
Rotate the sphere deliberately, one cause at a time
- Rotation Order
Sets the Euler sequence: XYZ, XZY, YXZ, YZX, ZXY, or ZYX. Blackmagic documents XYZ, for example, as X (pitch/tilt), then Y (pan/yaw), then Z (roll).
CheckWhen matching orientation from another 3D app, compare both systems’ conventions; matching numbers under a different order do not imply a matching pose.
- Rotate X
Rotation around X—pitch/tilt in Blackmagic terminology. Use it to tilt the spherical orientation up/down and correct that component of world pose.
CheckIf the problem is only horizontal heading, do not compensate with X just because the still looks similar; it makes later orientation harder to reason about.
- Rotate Y
Rotation around Y—pan/yaw. This is the main axis for changing heading/azimuth in a spherical scene without an ordinary 2D crop or pan.
CheckCheck the seam and important landmarks around the full sphere, not only the current central viewport.
- Rotate Z
Rotation around Z—roll. It is useful for leveling a tilted horizon, but under compound orientation its result depends on the selected Rotation Order.
CheckAfter leveling the horizon, inspect poles/projection boundaries: a locally level line should not hide an incorrect overall orientation.
The project captures document the visible Resolve PanoMap controls. Resolve 21 also expands immersive workflows around VR180/VR360 and spherical PanoMap rotation; those additions are discussed from current Blackmagic documentation without inventing controls that are not present in the supplied captures.
03A REPEATABLE PROJECTION / ORIENTATION WORKFLOW
Identify → decode → choose target → orient → sphere QC → delivery.
Keeping projection conversion separate from orientation makes failures immediately easier to localize.
Identify the source packing
Use frame aspect, metadata, documentation, and visible face arrangement to decide whether the source is LatLong, a cube cross/strip, VR180, or Immersive.
This is an editorial decision workflow, not Blackmagic’s internal projection graph. It deliberately separates source interpretation, target projection, spherical orientation, sphere-wide QC, and delivery validation.
Related references: Transform ↗ · Match Move ↗ · Picture In Picture ↗
04FOUR REAL PANORAMA DECISIONS
Cube conversion, pure re-orientation, immersive handoff and CGI exchange need different checks.
These are decision procedures, not presets. The correct layout is dictated by the source and the receiving system.
Cube map → LatLong for a 360 pipeline
Convert an HCross/VCross environment map to equirectangular 2:1 without scrambled faces.
- 01
Identify the real cube layout from the six-face arrangement and file aspect.
- 02
Set Input Layout = HCross or VCross; do not rely on Auto for an ambiguous source.
- 03
Choose Output Layout = LatLong and inspect seams before adding rotation.
- 04
Only then adjust heading/horizon with Rotate Y/Z and verify full-sphere delivery.
Re-orient LatLong without changing projection
Change the starting heading and level the horizon while staying LatLong → LatLong.
- 01
Set Input Layout = LatLong explicitly if Auto is ambiguous.
- 02
Keep Output Layout = LatLong—the goal is not projection conversion.
- 03
Use Rotate Y for heading and Z for roll; add X only when real pitch/tilt is required.
- 04
For compound orientation, verify Rotation Order and document it as part of the handoff.
VR180 / Immersive handoff
Avoid confusing projection conversion with metadata/project requirements of an immersive pipeline.
- 01
Confirm that the source genuinely matches the VR180 or Immersive layout and carries the expected stereoscopic/immersive structure.
- 02
Set Input Layout explicitly, then choose the target layout required downstream.
- 03
Use spherical rotation for world orientation rather than an ordinary frame Transform.
- 04
Validate in the target headset/player and separately verify project/delivery metadata.
Environment map for CGI / realtime engine
Match cube/equirectangular layout and orientation to an external coordinate system.
- 01
Get the engine specification: target layout, face order/orientation, and axis convention.
- 02
Convert Input → Output with zero rotation and validate faces/seams first.
- 03
Then match Rotation Order and X/Y/Z to the external world orientation.
- 04
Export a test with obvious directional landmarks so mirroring or 90°/180° offsets are easy to spot.
05CHOOSE THE RIGHT TRANSFORM TOOL
PanoMap solves projection geometry; other Transform FX solve different spatial problems.
Choose by the geometry problem before choosing by familiarity.
| FX | When it fits |
|---|---|
| PanoMap | When you need to interpret/convert spherical layouts and change orientation within spherical geometry. |
| Transform ↗ | When you need ordinary 2D position/scale/rotation without reinterpreting panoramic projection. |
| Match Move ↗ | When a transform must follow motion measured by a tracking solve. |
| Picture In Picture ↗ | When you need a presentation-oriented inset card with position/size/border/shadow rather than spherical remapping. |
06READ THE PROJECTION FAILURE BEFORE ROTATING
Scrambled faces, wrong targets and Euler surprises have different causes.
Reset orientation while diagnosing projection, then add the spherical transform back deliberately.
01Cube faces are scrambled or the panorama looks sliced+
Likely cause: Input Layout does not match the actual source packing.
Fix: Zero the rotation and explicitly test VCross/HCross/VStrip/HStrip/LatLong. Establish correct geometry before continuing.
02Source reads correctly but the rendered file has the wrong shape+
Likely cause: The wrong Output Layout was selected or downstream expects another projection.
Fix: Check the target specification and choose an explicit Output Layout. Do not look for Auto—it is absent from the supplied output menu.
03Compound Rotate values produce an unexpected orientation+
Likely cause: Rotation Order does not match the expected Euler sequence.
Fix: Compare XYZ/XZY/YXZ/YZX/ZXY/ZYX against the external pipeline convention. Set the order before fine-tuning angles.
04The viewer looks correctly oriented but the render starts elsewhere+
Likely cause: You changed the interactive 360 viewer direction rather than the baked PanoMap rotation.
Fix: Bake the required orientation with Rotate X/Y/Z and verify a short render in the target player.
05After leveling the horizon another region of the sphere looks wrong+
Likely cause: The compensation uses the wrong axis/order or only one viewport is being judged.
Fix: Inspect the full sphere, poles, and seam; separate heading, pitch, and roll rather than compensating randomly across axes.
06VR180/Immersive opens but delivery is rejected+
Likely cause: PanoMap solves layout/orientation, but the target workflow also depends on project/delivery settings and metadata.
Fix: Verify immersive project settings, codec/container, stereoscopic packing, and platform requirements separately from PanoMap.
07BEFORE DELIVERY
Approve projection first, then orientation, then the real immersive deliverable.
A correct-looking viewport can still hide the wrong output layout, seam, world pose, or missing delivery metadata.
08FAQ
Practical PanoMap questions.
How is Input Layout different from Output Layout?
Input Layout describes the projection you already have; Output Layout defines the projection PanoMap should create. Input has Auto; the supplied output screenshot does not.
Can I just leave Input Layout on Auto?
Yes, when metadata/aspect are unambiguous and the geometry is correct. For unusual sources, missing metadata, or strange seams, set the layout explicitly.
Why do the same Rotate X/Y/Z values change under another Rotation Order?
Because Euler rotations are sequential. After the first rotation the orientation has already changed, so the next axis no longer acts on the original pose.
Does PanoMap replace ordinary Transform?
No. Transform moves a 2D frame; PanoMap reinterprets/converts panoramic projection and rotates spherical orientation. They solve different geometry problems.
What is especially relevant in Resolve 21?
Blackmagic expanded immersive workflows: VR180/VR360 delivery and spherical PanoMap rotation are part of the modern immersive toolset, while Fusion gained PanoMap immersive rotation/ILPD retargeting. The supplied screenshots here document layout/rotation controls and do not invent extra ILPD controls.
Why does Rotation Order appear unchanged with only one non-zero axis?
Euler order becomes significant when multiple axis rotations are composed: rotations about different 3D axes generally do not commute. With only Rotate Y nonzero, changing the order changes nothing because the other two rotations are identities. In the teaching lab, use “Load XYZ ≠ ZYX experiment” to set three non-zero angles; then hold them fixed and change only Rotation Order. This demonstrates the mathematical principle, not pixel-for-pixel equivalence with Resolve’s closed renderer.
Does the laboratory generate real VR180 or Apple Immersive output?
No. VR180 and Immersive modes show two schematic fields of view only, to explain the 180° forward hemisphere and contrast them with full LatLong projection. They are not genuine stereoscopic samples, lens geometry, Apple Immersive packing, Resolve pixel rendering, or metadata export. For professional VR delivery, verify project setup, stereoscopic packing, metadata, and a test render in the actual target headset or player.
Sources and boundaries
Visible control labels and menu contents are anchored by five native Resolve captures stored in the project. Projection/orientation behavior and Resolve 21 immersive context are cross-checked against current Blackmagic documentation. The live hero is a teaching proxy and does not claim to reproduce Blackmagic’s projection resampling, stereo packing, metadata interpretation, seam filtering, or Euler implementation.
PanoMap changes projection/orientation, but an immersive delivery can also depend on project settings, stereoscopic packing, codec/container, metadata, and the receiving platform. Validate those separately in your exact Resolve 21/21.1 build and target device.