StandardShaderGUI script current issues

Hi,

So its well known that the current standardShaderGUI.cs file supplied with the builtIn-shaders.zip (5.0.1) from Unity has a bug that prevents it from compiling (see end of this post), but recently I discovered another issue that is rather problematic, though easily fixed.

[edit] - This is not a bug afterall, please read next post.
The new issue is that the way the standard shader allows different rendering paths (e.g. opaque vs transparent) partly relies on dynamically setting the renderqueue of the material. For some strange reason in the source code line 293 has 'material.renderQueue = -1;' for the opaque path.

As far as i'm aware a negative number is not valid ("Render queue number should be positive to work properly.") or at least unhelpful since in this instance Unity will place the opaque material into the transparent render queue. This is clearly incorrect and will cause the opaque models to be sorted wasting performance and may be confusing when doing other effects.

To address this error simply change that line to 'material.renderQueue = 2000' to place it into the 'geometry' queue.

Thankfully this error is not present with the internal Unity version of standardShaderGUI.cs or whatever it is using as in testing the standard shader works correctly. The issue is only in the downloadable version used as a learning tool or to make you own custom material editors or standard material. However the fact that it contains this error is unhelpful.


The error that prevents standardShaderGUI.cs from being compiled has been reported elsewhere but i'll add details here for completeness.

line 203 has the following code

Code (csharp):

1. DetermineWorkflow( ShaderUtil.GetMaterialProperties(new Material[] { material }) );

Unfortunately ShaderUtil.GetMaterialProperties() is inaccessible due to its protection level.
So simply replace the line with

Code (csharp):

1. DetermineWorkflow( MaterialEditor.GetMaterialProperties(new Material[] { material }) )

Quite why the supplied standardShaderGUI.cs is different to the internal one is a mystery to me and also frustrating that bug reports have yet to be acted upon it. The compile bug was reported almost a month ago (684398) and i'm sure others have reported prior to that. The new issue has been logged as case (690396)

 

Addendum to original post, regarding the RenderQueue = -1 issue.

After discussing with Aras and learning new information this is not a bug.

Using a RenderQueue of -1 is valid, despite what the docs currently say, indeed it has a special meaning, that of 'use whatever the shaders default tags are for the RenderQueue'. This is a pretty big distinction and its important to know.

So the problem I initially faced and why I thought this was a bug, is that my test shader had default tags for Queue and RenderType set to 'transparent'. This made sense at the time since I was testing/leanring how to dynamically switch a shader's renderType/Queue/Blend mode from the inspector via material drawers ( i.e. was using standardShaderGUI.cs and standard shader as a template). This meant that when setting the shader to use the opaque render path from the inspector it used the -1 value for the RenderQueue and returned to using its defaults that were set to transparent, hence why it rendered to the transparent queue.

The fix was easy, I simply changed my test shader RenderType and Queue tags to use appropriate settings for Opaque geometry, so that when using RenderQueue = -1 in code it reverted to the correct default for opaque rendering.

So not a bug, but is a failing of documentation that will hopefully be addressed and a useful learning experience