Cubemap becomes much brighter when recreated in the current PlayCanvas Editor

Help & Support
1

Hi,

I’m experiencing an issue where a Cubemap becomes significantly brighter when I recreate it in the current PlayCanvas Editor.

I have been investigating this by comparing an older project checkpoint with the current project state.

Environment / observations:

  • A build published around June 18, 2026 displays correctly.
  • Restoring the project to a checkpoint from around June 18 also restores the correct appearance.
  • Changing the Engine version back to 2.19.7 does NOT fix the issue in the current project state.
  • An older Cubemap created previously displays correctly.
  • If I recreate a Cubemap now using the same source environment texture, the resulting Cubemap is significantly brighter.
  • Enabling “Generate legacy cubemap” does not change the result.
  • Copying the previously working Cubemap from another project also does not reproduce the original appearance correctly.

I also tried another workflow:

  1. Start from the original HDR environment map.
  2. Open it in the PlayCanvas Texture Tool.
  3. Reproject it to:
    • Target: Cube
    • Encoding: RGBE
    • Size: 512
  4. Export the six HDR cubemap faces.
  5. Import those six HDR files into PlayCanvas.
  6. Create a new Cubemap manually from those six faces.
  7. Prefilter the Cubemap.

With this workflow, the result becomes much closer to the original / correct appearance.

It is still slightly brighter than the old Cubemap, but the large brightness difference is mostly gone.

This makes me suspect that the issue may be related to the current Editor’s environment texture → Cubemap conversion path, RGBM handling, or the generated prefiltered environment data, rather than the runtime Engine version itself.

Another observation:

When comparing the downloaded Cubemap data, the incorrectly bright Cubemap and the older working Cubemap appear to be generated differently. The newer problematic result seems to be handled differently with regard to RGBM / alpha data, while the Texture Tool → RGBE six-face workflow produces a result much closer to the old Cubemap.

Because restoring the old checkpoint immediately restores the correct rendering, but simply switching the Engine version does not, it seems that some Editor-generated asset data or asset conversion behavior may have changed.

Could you please confirm whether there have been any recent changes to:

  • Cubemap generation
  • Equirectangular → Cubemap conversion
  • RGBM decoding / encoding
  • Prefiltered environment map generation
  • envAtlas generation
  • HDR texture import / processing

that could cause this difference?

I would also like to know if there is a recommended way to reproduce the exact behavior of Cubemaps generated by older versions of the Editor.

For privacy/confidentiality reasons, I cannot post the original environment images publicly, but I can provide additional technical information if necessary.

Thank you.

2

Hello,

We are experiencing an issue where existing cubemaps suddenly become corrupted in the PlayCanvas Editor.

The issue is not limited to newly created cubemaps. Cubemaps that previously worked correctly are also affected.

We noticed that when a new fork is created, the cubemaps are already broken in the fork. This may help identify when the project or asset data becomes corrupted.

Symptoms:

  • The cubemap appears broken in both the Editor viewport and Launch.

  • When a new fork is created, the cubemaps are already broken in that fork.

  • Previously published builds still display the cubemap correctly.

  • Restoring the project to an older checkpoint also restores the cubemap correctly.

  • The RGBM option on the source texture is automatically disabled.

  • The sRGB option is automatically enabled instead.

  • Manually restoring the RGBM and sRGB settings does not fix the cubemap.

  • Removing and reassigning the textures does not restore it.

  • Reimporting the original .hdr file and creating a completely new cubemap also produces a broken cubemap.

  • Once the problem occurs in the current project state, newly recreated cubemaps remain broken.

This suggests that the original HDR file itself is not corrupted. It also does not appear to be only a viewport cache problem, because the issue occurs in both the Editor and Launch.

The following results may be important for diagnosing the issue:

  • Engine version: 2.22.2

  • Current Editor: broken

  • Current Launch: broken

  • Newly created fork: already broken

  • Previously published build: working correctly

  • Project restored from an older checkpoint: working correctly

  • Newly imported HDR and newly created cubemap in the affected project state: still broken

I do not know the exact date when the issue first started, but it was definitely already occurring approximately one week ago.

It appears that something in the current project state, asset metadata, fork creation process, or cubemap processing is automatically changing the texture color-space settings and preventing both existing and newly generated cubemaps from working correctly.

Could this be related to a recent Editor update, asset-processing change, fork creation, or an issue with RGBM/sRGB metadata?

Please let me know what additional information would be helpful. I can provide screenshots, browser console errors, checkpoint information, and a private project link if necessary.

Environment:

  • Engine version: 2.22.2

  • Browser: Google Chrome

  • OS: Windows 11

  • Affected areas: PlayCanvas Editor and Launch

  • Source environment file format: .hdr

  • Issue first confirmed: approximately one week ago; exact start date unknown

3

Moved posts together as they sound related

4

CC @mvaligursky

5

Could you attach a minimal reproduction to GitHub issue #2260—a small public project using a non-confidential HDR environment map, with steps to trigger the brightness change?

Ideally, include a working cubemap and a newly generated one from the same source. If creating a fork triggers the issue, please link both the original project and affected fork in the issue.

We’re investigating possible RGBM/sRGB metadata and cubemap regeneration issues; a simple repro would help us confirm the cause.

6

@KPal is working on this and will update here with a conclusion.