Strumpy Shader Editor [Now Open Source]

The thing is, the unity lighting is correct, apart from the naming of the two variables being confusing. This is the standard Blinn-Phong rendering model with additive specular on top standard light incident dot normal, and Lambertian limited specular taken into account via the multiplication of the the specular by the light color from the buffer which has already had lambertian scaling applied

You listed this:

Code (csharp):

1.  
2. ((Spec value ^(pow) Gloss value) * (Light vector ·(dot) Surface Normal)) + albedo
3.  

When this is not how specularity is performed in a photo realistic way, at least according to every paper I have seen on the topic (unless you intend 'spec value' to be dot( n, half).

Standard blinn-phong shading is of the form (taken from real time rendering 3'rd edition):

Code (csharp):

1.  
2. Output = (SurfaceDiffuseColor * dot( lightDir, normal) * LightColor) + SurfaceSpecColor * pow( dot( halfVector, normal ) ) * dot( lightDir, normal )
3.  

But it is very common to omit the scaling of the specular by the Lambertian term, unity does not do this though, it is passed via the dot( n, l) the light color.

The problem is that when using deferred rendering individual shaders are 'locked out' of modifying HOW the lighting buffer is written. This means that for consistency between forward / deferred would be broken if I renamed these variables to 'roughness' and 'specular / power' as the prepass renderer expects there to be a specular value output from the shader.

The best way to think of it is that 'gloss' is the multiplication of the specular highlight brightness with the specular highlight color, and that 'specular' is the specular power that is used for the raising of dot(n,h), i.e the sharpness of the specular falloff (this is a single float).

Alternatively I could just in the graph display rename 'specular' to 'roughness' and 'gloss' to 'specular color'. That might clear some things up.

Warby / Neptune_Imaging:
Are you currently using forward rendering? If so there was a bug that I fixed after looking into this on specular in forward rendering. If your issues were with deferred then it's a bit more odd. Can you hook me up with some sample scenes and some descriptions on what you expect to see?

 

To break it down the specular term is:

Code (csharp):

1.  
2. //Standard Blinn-Phong lighting
3. viewDir = normalize(viewDir);
4. half3 h = normalize (lightDir + viewDir);          
5. float nh = max (0, dot (s.Normal, h));
6.  
7. //Raise the dotted half vector to the power of s.Specular
8. //Use the master node 'specular' input to control the size of the
9. //highlight. This is the same as a roughness paramater!
10. float spec = pow (nh, s.Specular*128.0);
11.  
12. //Multiple spec by the light brightness
13. //This is done because in deferred we only have
14. //One channel for specular so we can't save color
15. spec *= Luminance (_LightColor0.rgb);
16.  
17. //Now we create the colored spec
18. //It is a combination of the specular intensity
19. //The surface specular color
20. //And then scaled by the light color (this will be precalculated (n dot l)
21. //So to change the brightness / color of the specular highlight (not the size)
22. //Modify the gloss paramater
23. half3 spec = light.a * s.Gloss * light.rgb;
24.  

 

Unity free? then you are using forward! I'll PM you an updated shader template tonight to see if it helps with the specular.

 

Hey warby, I just sent you a PM, could you check it out and get back to me.

 

The way unity works with beast is that the beast bindings expect there to be shader paramaters with certain names, one of those paramaters is _color. When I'm designing shaders in SSE I normally name the paramaters the same as in the default unity shaders (i.e. MainTex, Color ect). This is so fallback is supported and beast binds nicely. Maybe in a future version of unity you will be able to manually specify beast bindings, I also have some ideas on how this could be better addressed. There is also some interesting handling of custom shaders with emissive but I can't remember the ruls off the top of my head.

 

That's currently very possible to do in the shader editor, but it's quite an elaborate shader and I don't currently have the time to dedicate to making shaders of this size on request. What you want to do (to start with) is sample the cube from the reflection vector of the surface using the 'Vertex Reflection' node. In this example I have also made the alpha be based on an alpha from a texture and set the blend mode to be srcalpha / oneminussourcealpha (so you can configure the alpha from the texture), and also given the windows a 'blue' hint in the albedo. It's nothing amazing, but it's a decent start for some glass. You will need to set the queue to transparent if you want to use this shader also.

 

There is a better way to do this using the view direction and the Fresnel node. If you load up the 'rimlighting' shader you will notice that the edge is 'brighter' then the rest (and plugged into emission). If you plug this into alpha you will have a shader that tapers at the edges. Play with the rimlighting shader to see what I mean.

 

A normal map defines the surface normal at a point. What you are describing doesn't really make much sense. What do you mean by 'normal map effect'? One thing you could try is doing:

Unpack the normal map
Add that to a float4( 0.0, 0.0,1.0,0.0) that is multiplied by some scaling factor
Renormalize (make sure you are only doing 3 component!)

That will bias the normal towards the default vertex normal, reducing the normal effect. I'm still not 100% sure exactly what you mean though.

It should work. I'm not totally familiar with the standard glow-effects in unity, but I believe they are based on the surface alpha output value. I'll do some more research tonight for you but it should 'just work' I believe.

 

In the unity pipeline there is not much that you can do about this. This is due to the fact that when you render with transparent objects you are not writing to the z-buffer. Because of this ALL the triangles of the mesh will pass the z-buffer test and be rendered, even those that are behind other triangles.

In games I have worked on we solved this by allowing for 'depth written transparency'. We would render the whole scene normally, then any object that required this 'special' processing would be rendered into the depth buffer and then blended with the back buffer. This would cull the behind triangles. It's nor easily possible in unity currently but I have not really looked into it. Many games actually have the issue you are describing.

What kind of blending are you using? If you use additive (one,one) it should look 'okay' but you will be able to tell where elements are overlapping.

 

You sure can. It will actually just take the .rgb/.xyz of the vector. The normals are expressed in tangent space so a normal of (0,0,1) is 'standard'.

 

No, not really. The surface shader model is used to describe surfaces, you can't really get any information at shading time as to whether a texel has light hitting it or not. If you were guaranteed to be only using deferred you could do something sneaky and apply a texture if the accumulated light value is below a certain threshold. But this would require a custom lighting shader of the likes that is not supported in SSE (i.e. you would need to write a totally custom lighting shader).

 

Did some experimenting to validate this and it indeed does work (with one or two caveats). The in editor preview looks darker / fades to grey for opaque shaders if you specify alpha. This is a bug in the preview mechanism and will not be reflected in the actual scene. It is a 'non-trivial' fix and may not even be actually possible to fix with the limited access we get to the rendering pipeline.

Another point of note is that all the transparent shaders from unity don't actually seem to write to alpha, they use colormask RGB. This means they won't contribute to glow. It's recommended that you follow this model as well. In my example I simple hooked a slider up to alpha (you could use a texture or anything) and then used that on an opaque material with colormask set to RGBA to make a configurable glow. Was pretty easy and looked great!

 

Could you post some screenshots / a picture of your graph / how it is setup (master node)? I can't really tell what would be up otherwise. If you want me to have a more indepth look export that part of your scene including the sgraph file and I'll have an in depth look.

WRT clip: Things only get clipped when their value is below 0 (Have a look at the clip example graph). We minus by 0.5 to make the desired texels get clipped.

 

Oh no that's horrible... I have no idea what to do

 

3.3a - Full Unity 3.2 support, bug fixes

Unity 3.2 is now out. They have added to and also modified many aspects of shaderlab for this release and it has sadly made SSE 3.2 incompatible.... But never fear, the new version is here. It features full unity 3.2 support, fixes interface issues, and also has some bug fixes of it's own. If you are using unity 3.2 you NEED this upgrade for the shaders generated by SSE to work properly.

Contributers
Stramit
Texel

Documentation
Remember to check out Texel's documentation here.
Planet tutorial by Clamps here

From Clamps' Planet Tutorial


Donation
This project is free for all members of the community. If you are a big studio, or really enjoy using the Shader Editor and would like to donate towards the project we would really appreciate that, the cost of software purchases needed to make this has added up. You can donate via paypal by clicking here.

Download
Click the link at the bottom this this post to download.

Upgrading Notes
Before upgrading please remove Strumpy Shader Editor 3.2x from your project. All of the shader editor files have been moved around and tidied up and it is important to have a clean work area. Back up / move any graphs you would like to keep before deleting SSE 3.2.

Please back up all of your graph files before upgrading. Graphs from Strumpy Shader Editor 3.2 should be compatible with 3.2 with no modification. If this is not the case contact us immediately either via this thread or PM. Please include a copy of the graph. We do not foresee any issues though.

After you have upgraded to 3.3 it will be necessary to update the shader master node settings. These have changes so much that it was impossible to ensure complete backwards compatibility. Of note is that you should really check the depth write states, and the blending states of the loaded shader. You should also assign a rendertype, in SSE 3.2 this is much more important.

After updating / fixing the graph please reexport your shader. Shaderlab changed how the UnpackNormal function works and it takes different arguments now. This is handled behind the scenes in SSE but you still need to regenerate the .shader file. Any materials with this issue with show up as being pink.

Features / Fixes
Supports new unity 3.2 shaderlab subset
This is a direct mapping to shaderlab.


Support for:
Render Type
Improved Blending
Exclude pass

Bug fixes
*Unpack normal / sample normal fixed for 3.2
*Fix infinite loop regression
*Update lighting template so that forward / deferred look closer in terms of illumination

Roadmap
Beta 3.x - 3.x

• Advanced Lighting Sub Graph
• Fallback Support
• LOD Support

Asking for help with shaders
If you need any help with the shader editor or shaders in general ask away here. We will help where we can!

Bugs
It is inevitable that some bugs have slipped though the cracks for this release. If you run into any issues at all post in this thread. The more issues you report the more we can fix. We want this tool to be as usable as possible so any / all feedback is welcome!

Get 3.3b HERE instead... it's better!

 

This is out of our hands it's all handled by unity itself. We might be doing something wrong though. This issue has existed since we put tooltips in. Might have to try for a 'real' fix soon.

I tested all the graphs on osx but not windows. This might be a windows only issue. I'll ahve a look tonight and fix it if needed.

It's because of the way we upgraded the master node. We removed some (bad) inverse logic and it switched the depth write. In the upgrade notes I made mention of this. It needs to be checked per old graph.

 

clip should always work so long as the value is below 0 no matter what kind of shader it is.Could you test the example clip shader and tell me if that works and then try and emulate what it does for the clip paramater?

 

Is this in SSE or not? i just tracked down an issue in 3.3 of SSE that is cuased by me using a name in my Input sturucture called worldNormal. Unity have added this to their list now. I have renamed it sWorldNormal and will be releasing a patch in the next hour or so that fixes it. It only showed up on windows which is super odd to me. Are you doing something similar in your shader? If you pm it to me I could take a look and tell you whats up.

 

I just tested a clip using a texture.... it looks like it works for me.

 

3.3b - Bug fix

Thank for reporting a few bugs people. I have fixed them. The main issue was to do with the new 'World Normal' support added by unity. It conflicted with one of the generated variable names. Oh and I also fixed up the line ending warnings (finally!)

Contributers
Stramit
Texel

Documentation
Remember to check out Texel's documentation here.
Planet tutorial by Clamps here

Donation
This project is free for all members of the community. If you are a big studio, or really enjoy using the Shader Editor and would like to donate towards the project we would really appreciate that, the cost of software purchases needed to make this has added up. You can donate via paypal by clicking here.

Download
Click the link at the bottom this this post to download.

Upgrading Notes
Before upgrading please remove Strumpy Shader Editor 3.2x from your project. All of the shader editor files have been moved around and tidied up and it is important to have a clean work area. Back up / move any graphs you would like to keep before deleting SSE 3.2.

Please back up all of your graph files before upgrading. Graphs from Strumpy Shader Editor 3.2 should be compatible with 3.2 with no modification. If this is not the case contact us immediately either via this thread or PM. Please include a copy of the graph. We do not foresee any issues though.

After you have upgraded to 3.3 it will be necessary to update the shader master node settings. These have changes so much that it was impossible to ensure complete backwards compatibility. Of note is that you should really check the depth write states, and the blending states of the loaded shader. You should also assign a rendertype, in SSE 3.2 this is much more important.

After updating / fixing the graph please reexport your shader. Shaderlab changed how the UnpackNormal function works and it takes different arguments now. This is handled behind the scenes in SSE but you still need to regenerate the .shader file. Any materials with this issue with show up as being pink.

Bug fixes
*World normal node does not cause shader compile issue (windows only)
*No more line ending warnings! (wooo).

Asking for help with shaders
If you need any help with the shader editor or shaders in general ask away here. We will help where we can!

Bugs
It is inevitable that some bugs have slipped though the cracks for this release. If you run into any issues at all post in this thread. The more issues you report the more we can fix. We want this tool to be as usable as possible so any / all feedback is welcome!