Equirectangular vs Cubemap Environments

A flat rectangle cannot distribute spherical area evenly

In an equirectangular image, equal vertical pixel steps represent equal latitude steps, but rings of constant latitude shrink toward the poles. Relative samples per unit solid angle therefore scale as 1/cos(latitude): 1.00× at the equator, 2.00× at 60 degrees, and about 5.76× at 80 degrees. The values describe sampling geometry, not extra captured detail.

A cubemap avoids a single polar singularity by projecting onto six planes, but it is not equal-area either. Directional density changes from each face center toward its edges and corners. The practical trade is between a familiar one-image wrap and a multi-face delivery contract with different distortion placement.

Resolution comparisons need an explicit assumption

For a panorama width of 4N, one cube face of N pixels matches horizontal angular samples per degree at the panorama equator and at the center of a 90-degree cube face. The 2:1 panorama is then 4N × 2N, or 8N² pixels, while the cubemap is six N × N images, or 6N² pixels. That is where the 75% evidence figure comes from.

It is a sizing starting point, not a claim of identical reconstruction error everywhere. Pole detail, face-corner density, source sharpness, filtering, roughness convolution, display use, and camera field of view can justify a different size. Record the reason instead of passing along an unexplained “4K” label.

Conversion should happen at a deliberate boundary

Every projection conversion resamples the image. Keep the best known master, convert once for the target, and preserve the target manifest. If the destination can consume equirectangular HDR directly and builds its own filtered cube representation, the engine import may be the correct conversion boundary.

If the destination expects six files, use the existing Panorama to Cubemap Converter and verify the result in-engine. The guide remains the learn/evaluate owner; the converter remains the do-intent owner, and the Cubemap Face Order and Orientation page remains the detailed reference for filenames and rotations.

Projection and dynamic range answer different questions

Equirectangular versus cubemap answers “where are directions stored?” PNG versus Radiance HDR or OpenEXR, plus the actual pixel values, answers “what range and precision can be stored?” An 8-bit cubemap is still LDR; an HDR panorama can remain HDR until a target importer converts it to a cube texture.

PLAYTEX AI can export an estimated Radiance compatibility file from LDR-derived imagery, but that does not turn the source into a calibrated multi-exposure light probe. Carry the limitation through conversion and engine handoff.

The projection decisions worth recording

Source geometry

Establish the directional map before evaluating file format or lighting range.

• 2:1 aspect ratio: Maps 360 degrees of longitude across width and 180 degrees of latitude across height. Reject or crop only when the source contract says it is a full equirectangular sphere; a cropped panoramic photograph may not cover both poles.
• Horizontal seam: Joins the left and right image edges at the ±180-degree meridian. Repair exposure, color, or content discontinuity before conversion. A cubemap export can move the symptom, but cannot repair missing continuity.
• Pole inspection: Reveals the latitude-longitude oversampling and stretching concentrated near ±90 degrees. Review zenith and nadir in 360, especially after generative fill, cloning, denoising, or aggressive downsampling.

Cubemap contract

The six images are useful only when the destination interprets their directions the same way.

• Face size: Sets the square dimensions of each of the six cube images and therefore the base pixel budget before mipmaps. Start from source width ÷ 4 for matched center density, then change it from destination detail, memory, and platform evidence.
• Face order and filenames: Connects each file to positive or negative X, Y, and Z in the importer or loader. Use the destination convention. Three.js CubeTextureLoader documents px, nx, py, ny, pz, nz order; another engine may expose named slots or import a combined layout.
• Rotation and handedness: Determines which edge is up and whether the world appears mirrored when the six faces surround the camera. Check a labeled orientation grid and the current engine documentation. Do not infer rotation from filenames alone.

Values and filtering

Projection changes lookup geometry; the renderer still needs an honest value and sampling contract.

• LDR or HDR data: Controls the stored light range and precision independently of whether the layout is equirectangular or cubemap. Preserve scene-linear HDR through a supported HDR path. Converting PNG faces into an HDR-capable container cannot reconstruct clipped capture values.
• Mipmaps and prefiltering: Adds filtered representations for distance, roughness, or image-based-lighting lookup. Generate them in the destination pipeline and inspect cross-face filtering. Base-level continuity does not guarantee seamless lower mip levels.
• Color space: Controls how stored values are decoded before background display or lighting calculations. Treat display-color PNGs according to the target color-texture path and HDR environments according to the target linear-light path; verify the exact importer.

Keep one master, then convert once for the destination

Equirectangular and cubemap files can describe the same 360-degree environment. Use a 2:1 panorama for single-image authoring, inspection, and renderers that accept latitude-longitude input; use six cubemap faces when the destination asks for directional cube data.

Step 1: Create or upload the 2:1 source

Start with an equirectangular image whose width is twice its height. Use HDRI Sphere Generator for a new environment or an uploaded panorama, and keep the source provenance and value-range limitation with the asset.

Create or inspect an environment

Step 2: Inspect the complete 360-degree field

Orbit through the left-right wrap, level the horizon, inspect both poles, and check dominant-light direction before conversion. The flat 2:1 view is useful for broad edits, but a 360 viewer reveals spherical stretching that the rectangle hides.

Step 3: Read the destination contract

Confirm whether the target accepts an equirectangular texture, creates a cube texture during import, or wants six separate images. Record loader order, axis labels, handedness, up direction, color space, mip generation, and edge filtering for the exact engine version.

Step 4: Choose face size from a stated density target

A practical starting point is face size = panorama width ÷ 4. A 2048 × 1024 source therefore maps to 512 px faces. That matches horizontal samples per degree at the panorama equator and each cube-face center; it does not make either projection uniformly sampled.

Step 5: Convert locally and keep the manifest

Use Panorama to Cubemap Converter for an existing PNG, HDR, or EXR. Export the selected target naming, keep the generated manifest beside the six images, and avoid repeated panorama-to-cube-to-panorama round trips because each resampling can soften detail.

Open the panorama converter

Step 6: Test seams, corners, poles, and orientation in-engine

Use a high-contrast horizon, text or direction marker, one glossy object, and one rough object. Check every face boundary at more than one mip level, then rotate the camera through zenith and nadir. Approval belongs to the destination render, not only the exported thumbnails.

Failure symptoms and the assumption behind them

• The zenith looks pinched or smeared: the flat 2:1 edit hid pole distortion, source detail was insufficient, or downsampling was too aggressive.
• A thin line appears only after cube import: face order, orientation, edge filtering, compression, or mip generation does not match the target.
• Text or a landmark is mirrored: handedness or a positive/negative axis assignment changed during export or import.
• The horizon jumps at one boundary: two adjacent faces are swapped, rotated, or were processed independently after conversion.
• The base cubemap is clean but rough reflections show seams: inspect cross-face mipmap or environment-prefilter generation in the destination.
• The six faces look correct as thumbnails but the sky is upside down: the Y-face up direction or engine coordinate convention was assumed instead of tested.
• Lighting looks flat after converting PNG: projection changed, but missing HDR highlight values were not restored.
• A 4K panorama becomes six 4K faces by default: the face size label was copied without comparing angular density or runtime memory.

Is cubemap better than equirectangular?

Not universally. Equirectangular is convenient as one editable 2:1 master and is accepted directly by many environment loaders. Cubemap matches cube-texture APIs and moves the polar singularity into face edges and corners, but adds order and orientation risk. Choose from the destination contract and QA evidence.

What cubemap face size matches a 4K equirectangular panorama?

A useful starting point is panorama width divided by four, so a 4096 × 2048 panorama maps to 1024 px faces. This matches angular samples per degree at the panorama equator and cube-face centers. It is not an equal-quality guarantee at poles, edges, or corners.

Does converting an equirectangular PNG to cubemap make it HDR?

No. Projection conversion changes direction-to-pixel layout. HDR requires source values and a file/import path that preserve a high dynamic range. Six PNG faces made from an 8-bit PNG remain display-referred LDR evidence.

Why do equirectangular images look stretched at the top and bottom?

Equal-width rows are used for every latitude even though spherical latitude rings shrink toward the poles. Relative samples per solid angle scale as 1/cos(latitude), so the flat image increasingly stretches the polar neighborhoods.

Why do cubemap seams appear if every face came from one panorama?

The base projection can be continuous while the destination introduces a seam through swapped or rotated faces, independent compression, clamp/wrap behavior, non-seamless mip generation, or environment prefiltering. Test multiple mip levels and roughnesses in the target.

What order does Three.js CubeTextureLoader expect?

Current Three.js documentation lists positive X, negative X, positive Y, negative Y, positive Z, negative Z. The evidence ZIP uses px.png, nx.png, py.png, ny.png, pz.png, nz.png in that order and includes a manifest; still verify the installed Three.js version and handedness note.

Can I convert the panorama in this guide?

The guide is the learn/evaluate owner, not an upload tool. Use Panorama to Cubemap Converter for local PNG, HDR, or EXR conversion and target-named ZIP export. Use Cubemap Face Order and Orientation when you need the detailed engine naming matrix.