RPTD

The hardware is a nVidia GeForce 9500M GS.

( Sorry for using post instead of edit but the forum editor here messes up removing all line breaks from the posts making it impossible to edit )

 

I forgot to mention that the CubeMap is of type GL_RGBA16F hence floating point. Regular Depth and RGB textures do not crash while filtering.

You can construct this situation, that's correct. I think the important point here is how shadowColor.rgb is defined. Is it defined as a multiplicative value (as I used for my last post) or a subtractive value? For white colored light this is the same but for color light it is not the same. I always thought the multiplicative value is the right one. After all simple diffuse shading is:

 

fragmentColor = lightColor * albedo

I'm creating for transparent shadow casters in addition to the depth map a color map. That's an RGBA texture. RGB stores the color a white light ray would have after passing the material. A stores the transparency or rather said the intensity of the light ray after passing the material. A=0 leaves the light ray unaltered while A=1 would fully block the light ray. During lighting there are some additional values but they are not important here. So for a fragment lit using this way the parameters sum up like this:

 

lightColor.rgb := the color of the light source for the red, green and blue component

shadowColor.rgb := the color of the transparent shadow caster (what's left of the light after passing the material)

shadowColor.a := the transparency of the transparent shadow caster (what fraction of light intensity is left after passing the material)

 

So using these values the following invariants have to be fulfilled:

1) shadowColor.a = 0: material is fully transparent. shadowedLightColor.rgb = lightColor

2) shadowColor.a = 1: material is fully opaque. shadowLightColor.rgb = black

 

Using your version I end up with this:

shadowLightColor.rgb = lightColor.rgb * shadowColor.rgb * ( 1 - shadowColor.a )

 

invariant (2) is fulfilled but invariant (1) is violated:

shadowLightColor.rgb = lightColor.rgb * shadowColor.rgb * ( 1 - 0 ) = lightColor.rgb * shadowColor.rgb  // fail

but it should be

shadowLightColor.rgb = lightColor.rgb

 

I made the following modification to fulfill invariant (1):

shadowLightColor.rgb = lightColor.rgb * mix( white, shadowColor.rgb, shadowColor.a ) * ( 1 - shadowColor.a )

 

This fulfills now both invariants:

(1) shadowLightColor.rgb = lightColor.rgb * mix( white, shadowColor.rgb, 0 ) * ( 1 - 0 ) = lightColor.rgb * white = lightColor.rgb  // q.e.d.

(2) shadowLightColor.rgb = lightColor.rgb * mix( white, shadowColor.rgb, 1 ) * ( 1 - 1 ) = lightColor.rgb * shadowColor.rgb * 0 = black  // q.e.d.

 

So the shadowColor has to be pulled towards white to fulfull the invariants. This fudge factor though doesn't make me happy as it doesn't have a physical something backing it up but it does satisfy the invariants. I have the feeling something is wrong here but I can't put my finger on it.

That's correct. But in the case of 1cm the transparency map would contain a low value (let's say <25%) while with 10000km it would be 100% (opaque). The thickness is definitely the physically correct way to look at it but for an artist it is an unnatural material property that's difficult to handle and tune. I'm looking to understand the physics behind the problem and then to derive a PBR material property that is useful to the artist and clear to module programmers. I did the same for the surface roughness which I defined in a linear range instead of the typical exponential range as this is a lot more natural and predictable to work with while still allowing the module programmer to map it to the appropriate physical calculation under the hood.

For the transparency I want to have the same. I want the transparency to be defined in a linear way that is artist friendly while mapping to the physical representation where required. After all the absorbtion for a surface is calculated sooner or later into a transparency/coverage factor. Think of it as the final factor affecting the light color in respect to the surface color. So unless I misunderstood you the absorption leads directly to a transparency/coverage value in the range from [0..1] for the three major wavelength like transparency(rgb) = functionOfAbsorption(rgb). Since real-time rendering is anyways one approximitation stringed to the next I'm not that much concerned with a 100% accurate physical formula as this is anyways impossible. Important for me is to answer properly the question "if my colored material has a transparency of 25% (no matter what k and d value is actually required for this result using the absorption formula) how does the transmitted light ray look like?".

I'm operating here only in the flat surface situation where I have no knowledge about volume. Working for a true volume obviously is the next step like fog or liquids. That's though a different problem since there I can determine the distance and then absorption is useful and artist friendly. For a flat surface though it makes no sense and stuff like glass is typically rendered as a double sided triangle with mathetically infitesimally small thickness.