Search Issue Tracker
Won't Fix
Votes
0
Found in
2021.3.36f1
2022.3.22f1
2023.2.16f1
6000.0.0b13
Issue ID
UUM-67792
Regression
No
[HDRP] Object is rendered with artifacts when Time is multiplied by a non-whole number, the UV Length is multiplied by 1 and the object has a Skinned Mesh Renderer
Reproduction steps:
1. Open the “ReproProject“ project
2. Open the “Assets/StackLit Demo“ scene
3. Enter Play Mode
4. Observe the Game View
Expected result: There are 2 cubes in the Game View, and both are rendered the same
Actual result: The cube on the left has visual artifacts
Reproducible with: 2021.3.36f1, 2022.3.22f1, 2023.2.16f1, 6000.0.0b13
Reproducible on: Windows 11 Pro (22H2)
Not reproducible on: No other environment tested
Notes:
Does not reproduce with Mesh Renderer
Changing “Move Speed” property value in “Assets/Broken Material“ to a whole number fixes the issue.
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
- “Remove Unused Overrides” available on not loaded Scene and throws “ArgumentException: The scene is not loaded” warning
- Adaptive Probe Volume occlusion edge is calculated incorrectly when viewing probes near geometry edges
- Sampling a texture using an HLSL file throws shader errors and the code does not compile
- "Graphics.CopyTexture called with null source texture" error when Base Camera of an Overlay Camera is removed with DX11 Graphics API and Compatibility Mode enabled
- WebGL sends wrong value with large numbers when SendMessage function is used
Resolution Note:
Hey,
Firstly, thanks for the great repro. I have some good news and some bad news.
The bad news: We can't ship a generic fix to this. The bug occurs because of floating point operations in the HLSL spec, which doesn't put hard guarantees on the order of execution. Your shader kicks up the perfect storm, and causes the motion vector or depth-only pass to compute a different depth than the forward pass, even with the same logic and the same inputs. This is also why your NaN checks fix the issue; the compiler just decides that it will not reorder the floating point ops. It doesn't get fixed because any inputs are actually NaNs. The generic fix will slow down all shaders, even those who aren't affected by this discrepancy, which is why we cannot ship a wide fix.
The good news is that there are a couple of workarounds:
1. In the project window, click your shader graph, and then click `Copy Shader` in the inspector window.
2. Right click the project window, and then Create > Shader > Unlit Shader. Double click the newly created shader to open it in a text editor.
3. Paste the copied code. Rename the shader in the first line to, say, `FixedShader`.
Option A: If you can use only DX12:
4. Search for `Name "DepthForwardOnly"`. Around 35 lines down, replace the line `#pragma only_renderers d3d11 playstation xboxone xboxseries vulkan metal switch` with `#pragma use_dxc`.
5. Search for `Name "MotionVectors"` and then `Name "ForwardOnly"` and replace the same line in those two places.
6. Start the editor in DX12.
7. Assign this new `FixedShader` to your renderers and your problem should be fixed.
Option B: Fix across all APIs:
4. Replace the line `SV_POSITION_QUALIFIERS float4 positionCS : SV_POSITION;` with `SV_POSITION_QUALIFIERS precise float4 positionCS : SV_POSITION;` across the whole file.
That's it. The addition of the `precise` keyword tells the compiler to respect the order of floating point operations, and to also not fuse multiplies and adds into `mad` instructions. It also changes the GPU assembly to indicate this to the compiler backend.
I know this isn't a perfect solution, but I hope this is a useful workaround.