Search Issue Tracker

Fixed in 2023.1.X

Duplicate in 2021.2.X

Votes

44

Found in

2019.4.20f1

2020.3

2021.1.0b8

2021.2.0a3

2022.1

Issue ID

1375015

Regression

Yes

Scene is brighter in Standalone player if it was open in the Editor at build time

Shadows/Lights

-

Reproduction steps:

1. Check out repository https://github.com/Wilfrid-Unity/test-unity-scene-brightness that contains repro-projects
2. Start UnityEditor from Trunk revision 38ec60822087 or later (Oct. 17)
3. Open either project "test-birp-scene-brightness" or "test-urp-scene-brightness" (issues happens both in URP, BiRP, and HybridRP)
4. Make sure that scene "Scenes/BlocksScene" is NOT opened in the Editor
5. Build and run a first Development Build of the project that includes only scene "Scenes/BlocksScene"
6. Take a first screenshot of the scene in the first Standalone Player
7. Now in UnityEditor OPEN scene "Scenes/BlocksScene"
8. Build and run a second Development Build of the project that includes only scene "Scenes/BlocksScene"
9. Take a second screenshot of the scene in the first Standalone Player

Expected Result: First screenshot and second screenshot look the same.
Actual Result: First screenshot is darker, second screenshot is darker. Regression introduced in Version 2019.4.20f1;

Compare:

https://raw.githubusercontent.com/Wilfrid-Unity/test-unity-scene-brightness/master/standalone-player-screenshot-when-scene-was-not-open-in-editor-at-build-time.png
https://raw.githubusercontent.com/Wilfrid-Unity/test-unity-scene-brightness/master/standalone-player-screenshot-when-scene-was-open-in-editor-at-build-time.png

Additional information:

- Reproducible in 2022.1.0a13, 2021.2.0f1, 2021.1.27f1, 2020.3.21f1, 2019.4.32f1, 2019.4.20f1
- Not reproducible in Version 2019.4.19f1;
- Regression has been introduced with the skymanager refactor PR;
- The same issue happens in both Windows Standalone Player, as well as Switch Standalone Player (I did not test other platforms)
- The same issue happens with both UniversalRP, Built-In RP, or Hybrid Renderer (I did not test HDRP).

The test scene that can be used for Hybrid Renderer is this one:
https://github.com/Unity-Technologies/Graphics/blob/d82f0afe1b663e7d3b2dc6df82fce48a9c4419fe/TestProjects/UniversalHybridTest/Assets/SampleScenes/BRGGameObjects/BRGGameObjects.unity

Comments (11)

  1. Bwacky

    Nov 03, 2023 14:54

    Noticed this recently in 2022.3.11f1 and it's brightening all scenes up considerably where we make use of lighting adjustments. Will this ever be fixed? No workaround seems to work so far.

  2. Grannyboy

    Apr 16, 2023 18:20

    Over a year and still no solution in sight?
    Anyone ever found a work around? This is rather game breaking to be honest.

  3. Gosciu

    Sep 16, 2022 10:35

    In 2021.3.6f1 I solved this issue with
    Graphics settings -> Shader stripping: Keep All

  4. syros

    Jul 06, 2022 11:46

    We still have this same issue in 2021.2.3f1 URP , even saving the lighting asset wont fix it, any help or update with this issue will be rad , cheers \m/

  5. SilverStorm

    May 07, 2022 02:02

    I wanted to add that I made many builds of my game to test things and lighting was all fine in my title screen objects however I made a decision to change the lights into a prefab so I could reuse them in other scenes. This is when I got the darker scene in my next build and ONLY that change was made as far as I am aware. Simply converting the lights already in my scene to a prefab as indicated by the blue text name.
    I even tried to change to a new empty scene and then build my game and bug is still there.
    SOLUTION: I ended up deactivating the lightprefab but I duplicated the lights within it and moved them out of the prefab into my scene. I rebuild the build even with the title scene open and wallah the lighting was fixed. So maybe Unity can use this to help narrow things down it might be and issue with the prefab system.

  6. chrisdjali-wrld3d

    Mar 25, 2022 10:34

    The detailed comment I added is apparently considered a different bug, which is now tracked at https://issuetracker.unity3d.com/issues/player-lighting-not-generated-when-building-the-project-using-command-line

    If it's specifically command-line builds you're having problems with, not whether the scene's open in the editor, then I guess you should vote on the other issue.

  7. chrpetry

    Mar 24, 2022 11:49

    Setting up lighting in editor and fine adjusting not possible anymore.
    Please! I need a fix/workaround!

  8. AndersLindaas

    Mar 18, 2022 07:25

    Exactly same problem. This is stopping us from using a build pipeline and are stuck with manual building.

  9. kmikkel

    Mar 17, 2022 12:49

    We are seeing this in our project, we use Unity 2020.3.30f1 and we build to Android using batch mode and -executeMethod calling BuildPipeline.BuildPlayer.

  10. chrisdjali-wrld3d

    Feb 25, 2022 16:58

    I think I'm seeing this, or something like it, in a project I'm working on. Currently, it's targeting 2020.3.28f1. I spent quite a bit of time digging into it to be sure it wasn't a problem on my end, so I have quite a bit of information that might help chase this down, or determine that it's a separate issue that needs reporting separately. This is the closest thing I could find on the tracker, and seems like it could plausibly be the same thing.

    The intentional difference between my dark and bright builds is that the light ones are created through the editor, e.g. the Build or Build And Run buttons in the Build Settings window, or via Ctrl+B, and the dark builds are created via the command line, either with a custom build script called via -executeMethod that calls BuildPipeline.BuildPlayer, or via the -buildWindows64Player argument (or equivalent) for platforms that support that. I've not been able to get a dark build via the editor by having a different scene open, though, which doesn't match the description here, hence why I'm not certain it's the same issue.

    I've learned the following:
    * It's not resolved by creating a new, similar, scene.
    * It affects both Windows and WebGL, so presumably other platforms, too.
    * Looking at a dark and light Windows build side-by-side in RenderDoc shows the dark build is using UnityBlackCube for environment lighting and reflections, whereas the light build is using the default Unity skybox, as selected in the Environment tab of the Lighting window. I'd take this as evidence that the bright build is the correct one and the dark one is the one with a bug.
    * There are no levelN.resS files in the dark build. Copying them from a bright build does not make the dark build bright.
    * Copying the levelN file for the relevant scene (without copying the corresponding .resS file) is enough to make a dark build bright.
    * Inspecting the levelN file for the affected scene with AssetStudio (which is third-party, so could be incorrect) suggests that the bright build does reference the default skybox cubemap, whereas the dark one does not.
    * The behaviour is the same in 2020.3.21.0f1, which I believe is the last 2020 build before the regression here is supposed to have been introduced. I'm not totally sure of that, though. It might mean that this is a totally separate issue, or that the wrong commit's being blamed.

    I don't believe enough of Unity's source code is public for a non-staff-member to be able to discover whether this is the same issue or a separate one. If I've judged incorrectly, I'm happy to make a second issue report if someone lets me know.

Add comment

Log in to post comment

All about bugs

View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.