Search Issue Tracker
By Design
Votes
11
Found in
5.5.1p4
Issue ID
883099
Regression
No
[LightProbes] Switching light probes does not update them at runtime.
Switching Lightprobes does not updated them in runtime. When loading Lightmaps and Lightprobe data via script for some reason the probes are not updated, thus Dynamic game objects don't receive proper lighting. Static objects are updated as expected. There is no Console errors or warnings and the users scripts seems to be correct.
To reproduce:
1. Open project (attached to this description).
Note: You will see the scene with current baked Lighting (Image: "Example1.png"). These Lighting data is located in the "_main" folder.
2. Enter play mode and Lighting data from "Resources" folder will be loaded to Lighting settings.
Note: You can see that static game objects receive a baked green Directional light effect, but dynamic game objects stay the same (no lighting changes)
(Image: "Example2.png").
PROCESS OF BAKING A NEW LIGHTMAP (for swapping):
1. Change Directional Light color to something different.
2. Lighting -> Scene -> Build.
3. Drop baked Lighting data to another folder (for example "Resources").
4. Select Manager game object in the Hierarchy.
5. Under "Scene Conditions Manager" script drag and drop baked Lightmaps to there slots: "Lightmap Dir" and "Lightmap Light". (Image: "Slots.png")
6. Go to menu toolbar -> Tools -> RealVR and click "Copy Light probe data to conditions manager".
7. In Condition name slot write "TestMap" (same as starting condition in manager script) and press create. This will save all the Lightprobe data for the current Lighting settings.
8. Change Directional Light color to something different again (to better observe the effect).
9. Lighting -> Scene -> Build.
SCRIPTS:
LightprobeDuplicator.cs - Manu Item to save lightprobe data of the current lighting bake.
SceneConditionManager.cs - Loads saved Lighting data. Depends on script "SphericalHarmonicsExtensions.cs".
SphericalHarmonicsExtensions.cs - Receives saved lightprobe data. Depends on script "SerializableSphericalHarmonic.cs".
Now by entering play mode you can test the bug with new baked Lighting.
Reproduces with: 5.5.1p4; 5.6.0b9; 5.6.0b10;
(Older versions (5.3 & 5.4) treat lighting differently).
-
shubhamswaraj2021
Aug 18, 2020 11:25
good one <a href="https://www.lyricsauto.com">lyricsauto</a>
-
meave2323
Mar 17, 2020 10:15
Hope you can like the post here it is the very interesting look the batter update of file explorer to visit the site https://fileexplorerwindows.com and going the all setting of how to get help with file explorer in windows 10 computer lot of the people can save this information.
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
- Articulation Body with 'Revolute' Joint Type has erratic behavior when Upper Limit is set to above 360
- WebGL Player fails to render Scene when Terrain with Detail Mesh is added and WebGPU Graphics API is used
- Inconsistent errors are logged when different types are passed into the Query "Q<>" method in UIToolkit and the ancestor VisualElement is null
- Crash on GetMaterialPropertyByIndex when opening a specific Scene
- Discrepancies in the styling are present when using a TSS file instead of a USS file in custom EditorWindow
Resolution Note:
SerializableSphericalHarmonic, the container used to copy and transfer Lightprobe SH coefficients from one bake to another scene, is using private fields to store the SH coefficients. However, as the documentation states (https://docs.unity3d.com/ScriptReference/SerializeField.html): "When Unity serializes your scripts, it will only serialize public fields."
Therefore, after going into play mode, the serialized data (which wasn't actually serialized) is all black. This can be fixed in two ways: Either make all the fields in SerializableSphericalHarmonic public, or use SerializeField to force serialization on private members.