No shadows visible on Transparency Shaders?!!

Hi,

I have some prefabs in my game using the Transparent/Bumped/Diffuse shader, and shadows do not appear on them even though my objects are set to rec. them.

All Transparency shaders are suffering from the same symptom.

Shadows appear fine with just a diffuse/Bumped shader.

Does anyone know of another Transparency shader I can use instead? I have searched the Wiki but nothing there to help.

The white areas of the alpha SHOULD have shadows on it.

Aras? Can you write up an alternative, or point me to where in the shader code I can add something to tell it to pick up shadows ?

Thanks.

 

I know that Transparent/Cutout/Diffuse shader supports shadows.

 

If it was that easy, they would have done it already. Shadows with partial transparency is kind of non-trivial, and you won't really find that in other engines either, that I know of. As Daniel says, you can use the cutout shaders.

--Eric

 

From my experience so far, I would say that transparency in itself is already not the most trivial thing inside a game engine ;-)

So I guess combining transparency and shadows is asking for trouble (or creating a really big challenge for yourself ;-) ).

Sunny regards,
Jashan

 

Fast foward four years...

We're up to Unity 3.5 now, and alpha blended objects still can't receive shadows. Will this be fixed soon?

Aras your response here is clever, but it only addresses the complexity of shadow-casting alpha objects. Shadow-receiving is much easier. In fact, it's trivial, and doesn't require any change to the rendering pipeline for generating shadowmaps.

So why can't alpha objects receive shadows?

 

+1 for semi-transparent objects receiving shadows

 

Bump this.... It shouldn't be hard to get transparent with shadow receive... Maybe consider expose cascade shadow map in the future? Would be great to have these available for glass or particle with shadowing effects.

 

Hi there! That shader from other forum can receive shadow.

Code (csharp):

1.  
2.  
3. Shader "TransparentDiffuse"
4. {
5.         Properties
6.         {
7.                 _Color ("Main Color", Color) = (1,1,1,1)
8.                 _MainTex ("Base (RGB) Trans (A)", 2D) = "white" {}
9.         }
10.  
11.         SubShader
12.         {
13.                 Tags {"Queue"="AlphaTest" "IgnoreProjector"="True" "RenderType"="TransparentCutout"}
14.                 blend SrcAlpha OneMinusSrcAlpha
15.                
16.                 LOD 200
17.                 ZWrite Off
18.                 CGPROGRAM
19.                 #pragma surface surf Lambert exclude_path:prepass
20.                
21.                 sampler2D _MainTex;
22.                 fixed4 _Color;
23.                
24.                 struct Input
25.                 {
26.                         float2 uv_MainTex;
27.                 };
28.                
29.                 void surf (Input IN, inout SurfaceOutput o)
30.                 {
31.                         fixed4 c = tex2D(_MainTex, IN.uv_MainTex) * _Color;
32.                         o.Albedo = c.rgb;
33.                         o.Alpha = c.a;
34.                 }
35.                 ENDCG
36.         }
37.        
38.        
39.         SubShader
40.         {
41.                 Pass
42.                 {
43.                         Tags {"Queue"="Transparent" "IgnoreProjector"="True" "RenderType"="Transparent"}
44.                         ZWrite Off
45.                         Blend SrcAlpha OneMinusSrcAlpha
46.                         Material
47.                         {
48.                                 Diffuse [_Color]
49.                                 Ambient [_Color]      
50.                         }
51.                         Lighting On
52.                         SetTexture [_MainTex]
53.                         {
54.                                 Combine texture * primary DOUBLE, texture * primary
55.                         }
56.                 }
57.         }
58.  
59. Fallback "VertexLit"
60. }
61.  

But I no idea how this works, because terminating of (Fallback "VertexLit") part turn of this ability. Manual say "If no subshaders can be run, fallback by used", but obviously, subhader work fine, and no need to be use fallback. Anyone can explain this behavior?

 

"RenderType"="TransparentCutout"
I think it is rendered as cutout,opaque object in fact, try debug it

 

I think it's not that, if i change tag to transparent, it's rendered in same way.
http://s2.ipicture.ru/uploads/20131018/GJfGGgts.jpg
And little different with fixed function.
http://s2.ipicture.ru/uploads/20131018/I7D7rTdM.jpg
I'm try do debug, but I'm not familiar with stuff like that.

Code (csharp):

1.  
2. #pragma multi_compile_fwdbase
3. #define UNITY_PASS_FORWARDBASE
4. or
5. #ifdef SHADOWS_SCREEN
6.  

And not understand what's going on.

 

Editing the shader like this worked for me (mind you I'm an artist, not a programmer, but this worked). I have a ground grass texture (png) with soft transparency at the edges and opaque in the middle, it has lightmaps generated by unity on UV2, and it correctly receives dynamic hard shadows generated from a directional light and a vertexlit shaded opaque object.

Code (csharp):

1. Shader "Custom/transparentwithshadow"
2. {
3.     Properties
4.     {
5.             _Color ("Main Color", Color) = (1,1,1,1)
6.             _MainTex ("Base (RGB) Trans (A)", 2D) = "white" {}
7.     }
8.  
9.     SubShader
10.     {
11.             Tags {"Queue"="AlphaTest" "IgnoreProjector"="True" "RenderType"="Geometry"}
12.             blend SrcAlpha OneMinusSrcAlpha
13.            
14.             LOD 200
15.             CGPROGRAM
16.             #pragma surface surf Lambert exclude_path:prepass
17.            
18.             sampler2D _MainTex;
19.             fixed4 _Color;
20.            
21.             struct Input
22.             {
23.                     float2 uv_MainTex;
24.             };
25.            
26.             void surf (Input IN, inout SurfaceOutput o)
27.             {
28.                     fixed4 c = tex2D(_MainTex, IN.uv_MainTex) * _Color;
29.                     o.Albedo = c.rgb;
30.                     o.Alpha = c.a;
31.             }
32.             ENDCG
33.     }
34. Fallback "VertexLit"
35. }

 

Not being able to receive shadows on semi-transparent object is a real problem in 2014 if you want to do some competitive rendering. I think the whole dynamic shadow system definitely needs an update. This screen space shadow collection seems like a very limiting system. Problems with MSAA, very poor shadow filtering, transparency issues...

Looking forward to an update on this engine part.

 

Bump for 5!

Alpha blended objects should at least receive shadow, for example particles in shadow. They don't need to cast so it would be a nice tweak while things are still going.

 

My issue is the other way around... I don't care much about the receiving surface (it's flat and opaque), but I want my casting surface, which is translucent, to cast colored/semi-transparent shadow.

 

This is close to what I need, but I need to have the entire geometry rendered as transparent, and then apply a shadow collector pass, and I'm not sure how to go about doing it. Is there a way to test if a pixel has a shadow on it, and then change that pixel alpha value to 0?

 

Will there be anything on this for Unity5 launch? Any improvements to 2D Shadows/Shaders?

 

On PowerVR GPUs (like on iOS devices) you really want to avoid alpha-test (Alpha Cutout) shaders to keep the overdraw optimisation. Therefore it would be really nice if alpha blended geometry could at least receive shadows.

On the other hand, if you seek a solution that will not kill the performance for transparent shadow casters, why not using alpha-cut shaders for those. In that case you could still render everything from front to back or what ever. However the limitation would be that you could not cast semitransparent shadows. And again, on PowerVR devices you will destroy the fancy overdraw optimisation (deferred tile based rendering stuff). But at least for foliage / leafs or fences this should be acceptable.

 

I don't know if i'm on the right topic, I need to receive shadows on a transparent material.

I'm quite a noob in shaders, do you think it's possible to receive a shadow on my transparent plane in the middle from the cube ?



I'm using a spotlight in UnityPro with deferred lighting with this shader:

Code (CSharp):

1. Shader "FX/Matte Shadow Mask" {
2.  
3. Properties {
4.     _Color ("Main Color", Color) = (1,1,1,1)
5.     _MainTex ("Base (RGB) Trans (A)", 2D) = "white" {}
6.     _Cutoff ("Alpha cutoff", Range(0,1)) = 0.5
7. }
8.  
9. SubShader {
10.     Tags {"Queue" = "Geometry-10" "IgnoreProjector"="True" "RenderType"="TransparentCutout"}
11.     LOD 200
12.     Blend Zero SrcColor
13.     Lighting Off
14.     ZTest LEqual
15.     ZWrite On
16.     ColorMask 0
17.  
18. Pass {}
19.  
20. CGPROGRAM
21. #pragma surface surf ShadowOnly alphatest:_Cutoff
22. fixed4 _Color;
23.  
24. struct Input {
25.     float2 uv_MainTex;
26. };
27.  
28. inline fixed4 LightingShadowOnly (SurfaceOutput s, fixed3 lightDir, fixed atten)
29. {
30.     fixed4 c;
31.     c.rgb = s.Albedo*atten;
32.     c.a = s.Alpha;
33.     return c;
34. }
35.  
36. void surf (Input IN, inout SurfaceOutput o) {
37.     fixed4 c = _LightColor0 + _Color;
38.      o.Albedo = c.rgb;
39.      o.Alpha = 1;
40. }
41. ENDCG
42.  
43. }
44. Fallback "Transparent/Cutout/VertexLit"
45. }

Any help would be appreciated, Thanks in advance.

 

I think he is referring to Apple's OpenGL ES Programming Guide for iOS - Tuning Your OpenGL ES App: Hidden Surface Removal document, where they write:

I spent the whole last week measuring performance of Unity's 4.6 built-in shaders on various iOS devices. The cutout shaders perform almost the same as the alpha-blend ones on iPad Air 2, iPhone 6 and iPhone 5S. On older/other devices, such as the iPad Air, the cutout shader perform much worse than the transparent ones!

 

So. Does the fact that Transparent objects can't cast shadows also prevent them from writing to the Depth Texture (when using DepthTextureMode.Depth) somehow?

I truly cannot figure out how to make sprites write to a depth texture that I can use later. Unless I set the shader's Queue to AlphaTest, but that messes up my ordering.

 

Whether a pixel is written to the depth buffer is controlled by ZWrite in a shader. You can make a transparent shader write to the depth buffer, but as soon as a surface drawn by this shader isn't opaque, thus transparent, you get various visual glitches.

 

Shadows from transparent shadows are supported on unity 5 ;-), as well as the shadow strength depending on the opacity.

 

I just posted a request for a shadow catcher shader in the Asset Store "wishlist" thread... but if it could be part of Unity 5 built-in shaders, it would be even better

 

Great news, Aras, thanks a lot for the info !

 

Transparent shadows are caustics afaik

 

That are transparent shadows, or? Calculating the color instead of b/w?

 

This is awesome. I've been looking for something like this to use on my character when the camera zooms in close and I need to fade him MMO style but still cast shadows

 

seriously ??
unity 5 has nice PBS and GI stuff but custom transparent or cutout shaders cant receive shadows or self-shadow ?
really ??
seems like a Ferrari with Fiat 500 tyres !!

i was so glad i did a moss shader, but so disaponted it can't receive shadows.....
back to vertex lighting

 

Hi guys, anyone found a decent solution for this yet?

I too need to blend multiple textures according to an alpha map on a single mesh. The way that I've accomplished this is using alpha:fade and blending by alpha, I guess, just starting writing shaders last week so this terminology may be incorrect.

The issue I've encountered I believe is the same as discussed in this post. The surfaces don't seem to receive shadows no matter how hard or what I try. Being that I'm inexperienced I doubt I'll find a solution so my last resort is to hope either Unity has a solution on the way or someone has found a way to alphablend textures while still receiving shadows.

 

It can be done, just not without it's problems. Set the render queue in the shader to anything before transparent(I find alpha test works well enough). There's still some sorting issues, but it can work.

 

i have a transparent surf shader that has 2 layers , one with vertex displacrement and transparency, i used this and it worked well
Tags {"Queue"="AlphaTest+50" "IgnoreProjector"="True" "RenderType"="TransparentCutout"}
the 2 surfaces receive shadows (but the transparent doesn't cast them).

 

So here we are again...
It's almost 10 years since this thread was opened (8.5, to be precise) and the issue is still in the exactly same state as it was back then: not even going to be solved ever.

The only solution is to use "AlphaTest+50" dirty hack (with Transparent render type) which will ruin the rendering order completely (and, btw, for some reason it doesn't work in surface shader in U5).

Unity-style, as always.
Sometimes you're so desperately tired of this "never fixed issues" stuff that you really start hoping for Unreal to become more mobile-targeted, so we could just switch to it.

 

Well as you get the same issue in Unreal then what would be the good of that?

 

Let's not do the whole ue4 vs unity thing yet again. Shadows on alpha blended objects are required and Unity knows this. It's also non trivial to solve.

 

I did it by custom shadowmaps, sampling the shadowmaps directly, for each shadowmap, in the transparent shaders. So basically, the processing is increased linearly with the number of shadowed light sources within the range. 10 light sources? 10x the render time, per transparent object (sort of, I mean, GPU's don't strictly follow that, but it's running the same code 10 times, per say). I generally restrict the number of objects however to the important objects and since the number of transparent objects is small, it is not that bad.

Having transparent objects 'cast' shadows... is extraordinarily non-trivial. That's probably why they haven't done anything with it.

 

+1 on transparent objects being able to receive shadows. When is that happening?

Keep in mind, we understand that there is a distinct difference between transparent objects being able to cast shadows and transparent objects being able to receive shadows.

The former is very complex. It'd be nice, sure, but I think I am speaking for most of us when I say we don't really care about it -- the tremendous amount of work to get something like that in is probably not worth it.

The latter, however? I can't for the life of me imagine what sort of technical limitation would prevent that from working simply. Spotlights, for example, can project shadow-like areas of dark and light through the use of a cookie. Yes, sampling from a light cookie is different than sampling from a shadow map, but not in a way that should matter in this case.

In the case of a shadow map you are comparing the depth of the pixel being rendered (which can be calculated for both transparent objects and opaque objects by, for example, using the worldPos at each pixel) to the depth stored in the shadow map.

I recall something similar being done by an asset, "V-Light" - it'd draw a series of semitransparent planes in front of the light source and use percentage-closer filtering to cast soft shadows through them - which is basically the same stuff unity's lights use.

But yeah, I can't figure out what sort of technical limitation would keep Unity from having transparent objects receive shadows by now, given that it is already possible for transparent objects to be affected by cookies. Please help me understand what the difficulty is.

 

Thank you for the concise answer. I had completely forgotten about shadow cascades though which is what made it seem like it'd be easier to do than it is. Though there is one point that's kind of unclear still:

I've gathered that this far is that there is an inherent incompatibility between transparent objects, and caching surface values to a screenspace buffer (IE deferred rendering): Transparent surfaces violate the requirement that at any given pixel there is only one visible surface. This is also why with deferred rendering, MSAA is not possible.

Of course, transparent objects can be drawn in any pipeline, so transparent objects must therefore use forward rendering after all the opaque stuff is out of the way. The forward rendering pipeline (correct me if I'm wrong) makes no such use of screenspace buffers -- instead values like normals, shadow maps, etc. are calculated for each pixel, then discarded after the pixel is drawn.

So, to summarize my confusion:

- Transparent objects cannot be rendered using screenspace buffers.
- However, the forward rendering pipeline does not use screenspace buffers. (Or does it?)
- Opaque objects rendered in the forward pipeline may receive shadows from opaque objects.
- Transparent objects are always rendered in the forward pipeline.

- Therefore, transparent objects should be able to receive shadows from opaque objects, yet this is not currently possible.

I'm trying to close this gap, but my best guess is that even with forward rendering, shadows are rendered into a separate buffer first as you said. In which case even the forward pipeline is semi-deferred, and that is probably where the confusion lies in all of this.

 

Looking for guidance on a related issue.

I have some water. I want it to receive a shadow, because without shadows casting on it it looks very weird in my scene. The way I'm doing this is I render the water in the geometry pass. So far so good. The water renders a buffer of the scene beneath the water, to do the "transparency." (This is in quotes because the water is not technically transparent, it just LOOKS transparent)

I want to make the water more or less "transparent" based on depth - to do this I need the depth buffer to not include water.

The problem is that _CameraDepthTexture includes water, since it's part of the opaque pass, so I have to render my own depth buffer which is essentially the same.

This is starting to get really inefficient - I render a reflective pass, a refractive pass, and my own depth buffer. Is there any way to reduce this? It seems like the options would be:

1. Render the water in the transparent pass so that it doesn't write to the depth texture, but somehow bind the shadow map to it so I can still do shadow stuff in it.

2. Render the water in the opaque pass, but somehow make it not part of the built in _CameraDepthTexture

3. Render the scene without the water, then render the water separately afterwards, clipping against the depth. Using this approach I wouldn't have to render a refractive texture, because I could just use the render for that. (Assuming I rendered it to a rendered texture, it would serve as my refractive texture as well) I would still need a way to bind the shadow map here to get shadows on it - this would be a shadow map from a different camera or something weird like that...

Any ideas?

Edit: If I make my water shader RenderType "Transparent" it doesn't seem to get rendered into the DepthNormalsTexture (At least the normals part of it anyway) However it still does get rendered into the _CameraDepthTexture

TL;DR: I need a way to access the shadow map from water, or a way to make things in the GeometryPass not render into the _CameraDepthTexture

 

ZWrite Off

Try using that in your shader.

 

Unfortunately that doesn't work, I assume because the _CameraDepthTexture is made using replacement shaders or some kind of prepass. (Some old console hardware had a special z-prepass thing you could do)

 

if i had a way to get the shadow map that is used in the RenderShadowmapDir timing (see at the frame Debugger)
i could do the shadowing manually, but looks like i we cant get this texture ...

 

Has anyone ever figured out a workaround for this? I'm working on an AR project with dynamic lighting, and would like to cast shadows on an invisible table to composite against the live video. Ideally it would support multiple light sources. Deferred v. forward is less critical.

J.

 

This case is somewhat easier. The real problem isn't that you can't have transparent objects receive shadows, it's that transparent objects can't receive shadows and have something else receive shadows beyond it. The transparent object will essentially eat all the shadows for that pixel. I believe there's some threads on shadow matte shaders you can look for.