Search Issue Tracker
Won't Fix
Votes
0
Found in
2020.3.45f1
2021.3.19f1
2022.2.7f1
2023.1.0b4
2023.2.0a4
Issue ID
UUM-27637
Regression
No
Additively loading Light Probes when using Realtime GI causes probe values to rest to ambient
Steps to reproduce:
# Clone and update the following repo: [https://github.cds.internal.unity3d.com/unity/Additive-Lighting/tree/uum-27637]
# Open the Scene TESTSCENES/MASTER.unity
# Generate lighting for the current Scene constellation.
# Save all Scenes to write references to Scene files
# Look at the lovely red lighting in the red plane's light probes. So hot. So red. Mmmmm. [sic]
# Unload the Scene Red_PlaneWithProbes from the Unity Hierarchy.
# Load Red_PlaneWithProbes again.
Observe:
Light Probes that were unloaded and reloaded now fall back to the ambient colour coming from the Skybox.
Expected:
As the Lighting Data asset has not been unloaded or replaced, these Light Probes should recover the red indirect they had before. Infact, if you rebake the Scene using BakedGI, this is the behaviour you get.
What's even more unexpecteder is that if you Save All after the lighting generation (Realtime GI) and then close the Scene. Repoen and then do the unload/reload from the repro steps above, you _do_ get the expected behavior.
I can't even...
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- [UaaL] Freeze on "GetLightingSettingsOrDefaultsFallback()" when rotating device screen after unloading Unity framework
- A white vertical artifact is present when any Material from HDRI is used for a panoramic skybox
- Editor freezes when handling Havok collision interactions between a thin collider and the player controller
- No blue outline is shown on a folder in the Project tab when an external file is being dragged over the folder
- Profiler - Taking you to the wrong section when using 'show'
Resolution Note:
Thank you for your bug report.
After reviewing the issue and the impact it has on our users our team has decided that this case will be resolved as "Won't Fix". This does not mean that the issue isn’t a legitimate bug, but instead that we are not able to prioritize the fix, at this time.
The case will now be closed, and will not be reopened unless new information arises that would change the issue’s impact. Please let us know if you have additional information relating to the severity of this bug.