Search Issue Tracker
Won't Fix
Votes
0
Found in [Package]
9.0.0, 8.1.0, 8.0.1, 7.1.8.
Issue ID
1242629
Regression
No
[HDRP] Auto exposure effects occur on entering/exiting in play mode with Sprite Shape controller
Auto exposure effects occur on entering/exiting in play mode with "Sprite Shape controller".
Steps to repro:
1. Create a new HDRP Project.
2. Windows > Package Manager > 2D SpriteShape > Install.
3. Gameobject > 2D Object > Sprite Shape.
4. Enter in Play mode.
Actual Result:
Auto exposure effects occur on entering/exiting in play mode.
Expected Result:
Auto exposure effects should not occur.
Reproducible in:
2020.2.0a10, 2020.1.0b8, 2019.3.0f3 with Package Version 9.0.0, 8.1.0, 8.0.1, 7.1.8.
Environment:
Occurring on Windows 10 & Mac 10.15
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
- Crash on PrepareDrawShadowsCommandStep1 when entering the Play Mode in a specific project
- Physics Layer Collision Matrix's Layer names, checkboxes and hover highlights become misaligned when the Editor's UI Scaling gets changed
- Light/shadow information on an edge of a Terrain tile creates a seam with an adjacent Terrain tile when baking a LightMap
- "Missing types referenced from component UniversalRenderPipelineGlobalSettings on game object UniversalRenderPipelineGlobalSettings..." warning is thrown after switching the Platform to tvOS
- “Metal: Error creating pipeline state (Universal Render Pipeline/2D/Sprite-Lit-Default): Vertex attribute BLENDINDICES0(5) of type uint4 cannot be read using MTLAttributeFormatFloat2 (null)“ when setting GPU Skinning to GPU after opening the project
Resolution Note:
This is unfortunately expected.
The issue lies from the fact that we perform pre-exposure based on the exposure computed previous frame. For the first frame we don't have such exposure and we set an exposure texture that is "neutral" but cannot be correct for what is actually on screen, hence the exposure system will adapt starting from that neutral value.
A content specific workaround for an application that I can suggest to the user is: if you are able to identify what the a fixed exposure could be on the first frame, start the application with fixed exposure with the value that is correct for your starting point (this is specific to your application). After the first frame you can switch back to automatic mode and the automatic exposure system will work with a good starting point.