12 replies to this topic

[MonkeyBrains]

Hi Everyone,

I'd like to share our whitepaper on colored translucent soft shadows for real-time 3D applications, see:

http://www.esperient...SoftShadows.pdf

The translucent shadow technique was all made using DirectX9 based shaders (SM2-SM3) in HLSL as an extension of our soft shadowing technique.

Some other real-time 3D demos are here:

http://www.esperient...=113&Itemid=200

If you want to play with our 3D tool, you can download a demo version here:

http://www.esperient...=112&Itemid=196

The tool comes with a large supply of HLSL (.fx) based shaders and post processing techniques that people are welcome to learn from and/or critique.

Cheers,
Ben

[Goz]

so ... what happens when a translucent shadow falls on a translucent coloured object?

It looks to me like you are just using modern shadow techniques to projectively texture a blurred standard (ie standard render) light view of the scene ... this isn't anything new and totally falls down in the situation queried above.

Correct me if i'm wrong though ... would be very interested in learning more on a real shadowing system that copes with transparencies ... all my attempts have brought up failure situations. Though 3 shadowmaps for red, green and blue gave nice looking solutions in contrived situations; it fails in general situations without a harsh quantity of slices being used.

In summary: More info needed.

[MonkeyBrains]

Your first point is exactly what this algorithm tries to solve.

If you have translucent objects who's shadows are overlapping onto another object, the shadow displayed is a combination of all shadow contributions. Yes, the algorithm uses render infomation from the point of view of the light source, but it's the "translucency" information it gathers, and not just the std colors. ie: A totally solid object will still cast a black shadow.

[MonkeyBrains]

While performing the shadow map calculation for the scene, the algorithm uses depth information from the point of view of the viewer, as well as from the light source. (a pretty standard soft shadowing technique). When rendering out the depth information from the point of view of the light source, an additional render target is used to store the "opacity" of the objects rendered. Back to front rendering is recommended for translucent objects for this. This "opacity" map determines the color of the resulting shadow when the final rendering pass is completed.

Translucent objects that cast an overlapping shadow will have their shadow contributions also combined.

Because this is all tacked on to a shadow map, very little change has to be made when performing your final rendering pass, except, instead of using a single channel for the shadow map, you can now use all of the color channels to utilize the color information.

[Goz]

Well can you give us more details? I'm intrigued. How do you, for example, accumulate multiple layers of transparent shadows. ie you have a cyan window that, obviously,casts a cyan shadow on a red window and therefore the red window, where the cyan shadow falls upon it, casts black but red on the part not exposed to the cyan shadow?

Its fairly simple to do this sort of thing with ray tracing but i've, personally, not figured out a way to do this without doing multiple passes (ie one pass for each depth level)? Depth peeling could work here but I've not tried applying it to a shadow algorithm ...

[Reedbeta]

Goz said:

you have a cyan window that, obviously,casts a cyan shadow on a red window and therefore the red window, where the cyan shadow falls upon it, casts black but red on the part not exposed to the cyan shadow?

Doesn't that work if you render a view from the light with opaques rendered first in white, then transparencies sorted and rendered front to back with multiplicative blending? As far as I can see, the pixels in the "opacity map" will then be the appropriate color for whatever opaque object lies under that pixel (modulo aliasing issues obviously).

Edit: unless you're talking about also lighting the transparent surfaces themselves, in which case yes, you would seem to need a deep shadow map of some kind, which would probably have to be assembled in multiple passes (but see also this paper).

[MonkeyBrains]

Actually, that's pretty close to how it's done.

To fit it in to the same render pass that the depth information gets saved in (and to have an alpha blending mode that still allowed the depth info to be correctly written into the float buffer), the opacity values written out can be thought of as "what color of light is this particular object blocking?".

ie: This "opacity map" will be black where no light is blocked, and white there all light is blocked.

This was the only way I could figure out to get everything still working in a single pass with the appropriate render / blending states.

When creating the resulting shadow map, inversing the "opacity map" will give the expected shadow color.

That said, I have no idea how shadows really "mix" in real life. Perhaps we all can shine a light on a beer glass tonight and compare thoughts on the results tomorrow?

Edit: That paper you linked to looks awesome! Most of my "depth peeling" attempts have always resulted in bad artifacts from z-fighting. I will have to try out this method to see where my attempts all went wrong.

[Goz]

Reedbeta said:

Edit: unless you're talking about also lighting the transparent surfaces themselves, in which case yes, you would seem to need a deep shadow map of some kind, which would probably have to be assembled in multiple passes (but see also this paper).

Exactly ... and for any item in between the 2 planes of glass ... its a complex problem without ray tracing ...

I'd love to get it working because you could do projective lighting by placing a shadow behind a given transparent surface. It would be a perfect one stop solution. This is one huge bonus to ray tracing over rasterising. It seems a lot of the time you are ending up attempting to hack a solution to make up for the lack of ray-tracing ...

Would love to come up with a good solution to this shadowing problem but, as yet, I just haven't been able to come up with a good one :(

[Goz]

MonkeyBrains said:

Actually, that's pretty close to how it's done.

To fit it in to the same render pass that the depth information gets saved in (and to have an alpha blending mode that still allowed the depth info to be correctly written into the float buffer), the opacity values written out can be thought of as "what color of light is this particular object blocking?".

ie: This "opacity map" will be black where no light is blocked, and white there all light is blocked.

This was the only way I could figure out to get everything still working in a single pass with the appropriate render / blending states.

When creating the resulting shadow map, inversing the "opacity map" will give the expected shadow color.

That said, I have no idea how shadows really "mix" in real life. Perhaps we all can shine a light on a beer glass tonight and compare thoughts on the results tomorrow?

So essentially this IS storing a depth map for red, green and blue seperately?

The problem, as i understand it comes when you place objects in between 2 shadow casters and you get the wrong shadow cast ...

[MonkeyBrains]

Goz said:

So essentially this IS storing a depth map for red, green and blue seperately?

The problem, as i understand it comes when you place objects in between 2 shadow casters and you get the wrong shadow cast ...

I think it is very similar to storing a depth map for red, green, and blue....but if one were to do exactly that, how would you accumulate overlapping shadows like the above algorithm?

Yes, placing a shadow-receiving translucent object between two translucent shadow casters is a problem for the shadow being cast on the middle object. The algorithm will work fine if the middle object is opague, but not translucent. Any ideas? (I'm wondering if there's something possible to try if utilizing the scene perspective depth map?)

[Reedbeta]

Goz said:

Exactly ... and for any item in between the 2 planes of glass

That will work fine if the object is opaque.

Goz said:

you could do projective lighting by placing a shadow behind a given transparent surface.

I think you can do this already with the method being discussed, as long as the surfaces you're projecting onto are opaque.

It's lighting translucent surfaces that are shadowed by other translucent surfaces that's the tricky part.

[Goz]

Ok so then it works by NOT writing transparent surfaces into the, required. depth buffer?

I think im getting how it works now :)

cheers

[Reedbeta]

Correct, transparent stuff gets depth tested, but does not write depth.