Search Issue Tracker

Status: Fixed

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

Graphics - General

-

-

Priority: 3Not yet prioritized for a release

-

Severity: 3Workaround is possible

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.

Comments (8)

  1. 61346f0769f693c6d6349938cdcf06e3?d=mm

    Static-Dynamo

    Oct 05, 2016 07:54

    Wasted several hours on this bug today. Please fix this!

  2. Ae7d819811cc106f8f14c385e17b19e8?d=mm

    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...

  3. Ff9dcae3f5edd8552b5f68385ecccd31?d=mm

    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.

  4. E609763d3a1f4313fc9f1fa0bcad64cb?d=mm

    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.

  5. 34d2c9deea0bd3680879a66ebeff9099?d=mm

    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.

  6. 69f839de09e48d7ddf0ff839677abf74?d=mm

    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.

  7. 6d6d2c7e7d1a8cda7a2bfb16214877d5?d=mm

    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.

  8. 69f839de09e48d7ddf0ff839677abf74?d=mm

    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.

All about bugs

View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.