I have a shader on my background object who’s render order is set to “Queue” = “Background”. I have another shader on a cube who’s render order is set to “Queue” = “Geometry”. It’s my understanding that this means the background object is rendered first, followed by the cube object.
In the cube, I’ve set the blend mode to Blend Zero One. I understand that’s supposed to take none of the new color, and just leave the old color. The desired result would be the cube being completely invisible, but instead, the cube is drawn with the cameras background color, and the wall rendered before it cannot be seen behind it:
Left is the desired effect, Right is the effect I’m getting.
Why can’t I see my background object behind the cube? Thanks.
i’m not super sure but i think background is rendered after geometry. it’s because we can get many pixels rejected when drawing the skybox (which is the background) and thus reducing overdraw (it’s about speed after all :-)).
try putting your cube into “Queue” = “Transparent” instead.
Now another question, Is there any way to make my invisible cube receive shadows now, as if it was textured with what’s behind it instead of actually being invisible?
In other words, I understand it may not work with blend modes, but is there any way for me to set the pixel color in the shader to the color already in the buffer?
If you’re just shadowing as if the background was the surface albedo, you can probably get away without any fancy stuff like GrabPass, and just render your lighting result with a multiplicative blend like DstColor Zero.
Thanks again! I tried using DstColor Zero on the blend mode and it worked, but unfortunately it was giving me problems I couldn’t resolve. The shadows would effectively be cast onto an invisible plane, but some objects behind the plane would draw on top of the shadows since I turned off ZWrite when drawing the wall. I tried making the offending objects render before the wall by putting them in background-1, but that didn’t help.
I looked into grab pass, and it seems like that would be the perfect solution. The only problem is, to get shadows cast on an object textured with grab pass I believe I need to have a surface shader.
I looked at this shader in the examples:
That shader does exactly what I want, but it doesn’t receive shadows. So, I set up a surface shader and brought in the _GrabPass texture. The problem with that, is the texture’s UV’s don’t match up like I want them to, so the object doesn’t look invisible, it looks like it’s textured with a screenshot of the game. I tried following tutorials and examples from other shaders which ended up using tex2DProj, but they always use it inside of a fragment shader, and whenever I use it in my surface shader all hell breaks loose and it refuses to compile.
So my question now, is how can I achieve the effect of the above shader using a surface shader? Thanks again for all your help on this.
That’s exactly the effect I’m going for, but when I switched to forward and tried out the shader with a directional light, all I could see was a pitch white surface. Even if I could get it to work in my game, though, my mechanics rely on shadow casting point lights using deferred lighting, so unfortunately switching to forward just wouldn’t be an option.
Are you still having problems with this superbob. If you are let me know. Ive just done a shader that used Grabpass in a surface shader it. would take nothing for me to knock up another for you. I have a gut feeling though, with what you are trying to achieve there might be another hurdle or to in terms of forcing the deferred system to not light the surface, even with a custom lighting function be cause of the way the Gbuffers work. I think 3.2 now will shadow point lights if that helps?
Yep, still having trouble with it, it’s turning out to be quite a tricky problem. If you have a grabpass surface shader I’d be thrilled to see it, and if you figure I can get a point light casting shadows in 3.2 then I can probably switch to forward. Forward’s probably a better system for our game any way, since we really only have one light ^^.