Search Issue Tracker
By Design
Votes
41
Found in
5.3.0b5
Issue ID
742265
Regression
No
[Material] Render Queue value is not updated until shader is changed and reverted
A materials render queue value is not updated when its shader is edited and saved, only after the material's shader has been changed and then reverted.
Reproduction steps:
1. Create two objects with Mesh Renderer components, one closer to camera than the other
2. Apply a different material to each
3. Apply any shader to the foremost object's material and a custom shader of equal Render Queue value to the back one (shader must use LEqual ZTesting)
4. Observe the foremost objects renders in front (last)
5. Change the custom shader to a higher Render Queue value and save it
6. Notice how it still does not render in front
7. Change the Inspector to Debug mode and view the materials Render Queue value, it has not changed
8. Now change that material to use any other shader, then back to the custom shader
9. Observe how that object now renders in front.
Workaround:
After a shader's render queue value has been edited change materials that use it to another shader and then revert to update the value on the materials.
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
JohnSmith1915
Apr 24, 2017 18:42
Wow, more than a year after and in version 5.6f p2 this important problem continue, is simply incredible.
Static-Dynamo
Oct 05, 2016 07:54
Wasted several hours on this bug today. Please fix this!
tanoshimi
Jun 04, 2016 10:17
Ack! Just discovered this bug myself - spent hours trying to work out why shader I was developing was not showing the skybox through transparency only to find out that it was due to a "cached" default renderqueue that had been assigned from the stub you get from right-clicking in the project -> create shader...
geroppo
May 28, 2016 05:02
For crying out loud they gotta fix this! I spent a solid 5 hours trying to understand why my shader wasn't working.
Gambit MSplitz
May 06, 2016 00:46
My big tiff with this is that the "custom render queue" property of a material is hidden, so I had no idea why my materials weren't rendering in the queues according to their shaders. You have to switch to debug mode in unity to find these values.
What's worse is the documentation/manual simply say that the only way to control render order is through shader or script, they do not mention that the editor can change this value or that you can view/modify this value in debug mode.
jistyles
Mar 23, 2016 07:21
I posted this in the forum, but thought I'd echo it hear:
So I've done a triage pass and found where this bug is coming from.
It's caused by the Standard Shader material interface which you can find the source in the built-in shader package under \Editor\StandardShaderGUI.cs
The Standard Shader supports a variety of "render modes". These change things like blend op's, zwrite, set keywords, etc... but it also explicitly sets the Material.renderQueue
If you ever have a material reference the Standard Shader, then it will stomp the -1 default with whatever is relevent for its "Render Mode", but it won't clean itself up if you then change the shader to something else.
bgolus
Dec 22, 2015 18:59
I suspect it was a naive fix to a similar bug. Something setting the custom queue and then changing the shader on the material and having it not respect the new shader's queue because it was being overridden in the material. This is something that would of happened all the time now with the Standard shader as it's custom editor sets the queue when you change it to the various transparency types. The most obvious fix for that is to set the material's queue to that of the new shader when it changes, especially if the person doing the fix didn't realize -1 was a magic number that did the same thing and respects changes to the shader after the fact.
Trigve
Dec 17, 2015 08:38
Anyone knows why it has been changed like that (Bgolus explanation)? Because I can't imagine a situation when the behavior like that would be useful.
bgolus
Dec 04, 2015 21:01
Unity's behavior regarding custom render queues was changed such that it sets a material's custom render queue when you change to a shader for the first time to the queue of that shader rather than keeping the default value of -1 which respects changes to the shader's queue after it has been assigned.