Search Issue Tracker
By Design
By Design in 2022.2.X
Votes
0
Found in
2019.4.38f1
2020.3.34f1
2021.3.2f1
2022.1.0f1
2022.2.0a12
Issue ID
UUM-3248
Regression
No
Quads with Transparent Unlit Shaders are positioned incorrectly in the Game view when parented to non-uniform scaled GameObject
How to reproduce:
1. Open the user's attached project
2. Open scene BugReport/Bug
3. Press the Play button
4. Observe the movement of the Quads in the Scene view and Game view
Expected result: all same-colored Quads move in line with each other
Actual result: one of the blue Quads moves out of place in the Game view
Reproducible with: 2019.4.38f1, 2020.3.34f1, 2021.3.2f1, 2022.1.0f1, 2022.2.0a12
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
- Error “Shader error in 'YSCloudCover': call to 'tex3D' is ambiguous at Assets/YSCloudCoverText.shader(606) (on d3d11)“ is present when compiling tex3D shader with DXC
- Placeholder asset is not loaded with Advertisement Legacy sample when using the latest version of the package
- Addressables content build fails but the Player build is successful when building a development build
- Out-of-bounds memory access with multiple CanvasRenderers under a Canvas when using Mesh API
- Inspector tries to access file after it was deleted when the file was locked in Inspector window
Resolution Note:
The user's shader logic is incorrect because it's offsetting the mesh by the object space normal.
Normally, all of the sprites in their scene would have the same normal because they come from the same mesh, however some of the sprites are batched together which changes their normal to be the world space normal. This can be verified by adding the tag "DisableBatching"="True" which will make their test work.
The correct fix would be to update the code so that the normal and position are in the same space (e.g. world space) before doing the offset. Provided is an example of how to do this.
float3 normal = meshData.normal;
float4 worldPos = mul(unity_ObjectToWorld, float4(meshData.vertex.xyz, 1.0));
float4 worldNormal = mul(unity_ObjectToWorld, float4(meshData.normal.xyz, 0.0));
worldPos.xyz += normalize(worldNormal) * _Speed * delta;
o.pos = mul(mul(UNITY_MATRIX_P, UNITY_MATRIX_V), worldPos);
Resolution Note (2022.2.X):
The user's shader logic is incorrect because it's offsetting the mesh by the object space normal.
Normally, all of the sprites in their scene would have the same normal because they come from the same mesh, however some of the sprites are batched together which changes their normal to be the world space normal. This can be verified by adding the tag "DisableBatching"="True" which will make their test work.
The correct fix would be to update the code so that the normal and position are in the same space (e.g. world space) before doing the offset. Provided is an example of how to do this.
float3 normal = meshData.normal;
float4 worldPos = mul(unity_ObjectToWorld, float4(meshData.vertex.xyz, 1.0));
float4 worldNormal = mul(unity_ObjectToWorld, float4(meshData.normal.xyz, 0.0));
worldPos.xyz += normalize(worldNormal) * _Speed * delta;
o.pos = mul(mul(UNITY_MATRIX_P, UNITY_MATRIX_V), worldPos);