Do you mean something like Humus’ demo? That did tinted shadows (I don’t remember the details) but it seemed a bit expensive (is it not?). Sure, you can do all sorts of stuff but you need to have the processing power. How could they be doing so much?
If the art team has to say “this light casts coloured shadows” and a transparent object moving before another light doesn’t give a tinted shadow or the case is not expected, then it’s a hack (by my definition, anyway). Does it really work all round or is it a special case thing?
About the shaders, you could get away with saying that if you did something like in HL2 and allowed custom terms that respect a given framework, innit? Or are they explicitly claiming more?
It depends, the art team needn’t specify anything of the sort under many circumstances.
Render to texture once would be possible then it’s just a cubemap projection potentially under transformation, only dynamic translucent objects need be rerendered to texture and you could afford to do that each frame and of course the resolution is set arbitrarily.
You need only render select occluders to the shadow texture in fact this is essential.
I assume, that that demo simply uses a cubemap to texture that object (but that´s not necessary) and additionally uses that cubemap for a texture-lookup to “fake” those tinted shadows, which is really the most simple thing to do.
I am very sure, that this won´t work with all transparent objects, like windows, and windows behind windows (so that objects in between get correctly colored).
I assume, that this doesn´t work with Humus´ demo, either, does it? A few days ago i was thinking about how his demo works exactly, but i always came to the solution, that it will only work in very special cases, not in general. Or am i wrong about that?
Yeah, transparent shadowing is very complicated. I believe the humus demo only works correctly with one layer of transparent objects (as far as I can tell). To get true tinted shadows you would have to do a depth peeling of sorts to encorporte many different filtered colors.
I haven’t really looked into how UT3 is supposed to use soft shadows, but I think it’s similar to how pixar does it (with oversampled shadow maps). As for tinted stuff, I believe they were doing things on a per object basis, which would provide correct depth in the case of planes (though could still have issues with self overlapping objects…).
For soft shadows, they said in a video presentation that they use two shadow cube maps. One “crisp” and one blurred. Then they interpolate the two maps based on the distance of each pixel from the light source.
Yeah, that’s what I was guessing too. If they put the front depth value in, they’d at least get on level that wasn’t shadowed (but that would break other full shadowing along that ray), oh well .
Video presentations! I’ve only read about the specs and seen screenshots. sigh and once again I’m out of the loop . Off I go to find them. Though that multi level thing is cool (how ATI, among others was doing depth bluring). Hmmm, that gives me way too many ideas . Wouldn’t there still be artifacts where two soft parts would interact (since you’d technically need multiple depth values at that point)?
Originally posted by Madoc: Do you mean something like Humus’ demo? That did tinted shadows (I don’t remember the details) but it seemed a bit expensive (is it not?).
It’s not much more expensive than regular shadow mapping.
Originally posted by Jan:
[b]I assume, that this doesn´t work with Humus´ demo, either, does it? A few days ago i was thinking about how his demo works exactly, but i always came to the solution, that it will only work in very special cases, not in general. Or am i wrong about that?
Jan.[/b]
It should work fine as long as you have no overlapping of transparent objects in the shadow map. If there’s overlapping only the window that’s closest to the light will be taken into account, which I guess could look reasonable in most cases, but I don’t know really. You could extend the technique to work with many layers though by using many passes and sorting your geometry.
Originally posted by ZbuffeR: From the description of Humus demo about tinted shadows, it will color as well an opaque object placed between the light and the tinted glass.
No it won’t. It will look correct in this case too. It will only tint objects that are behind the window from the light’s point of view.
You may want to ammend the description then… it says that you don’t write the depth value with the shadow color (or at least that is omitted). If that is indeed how it works, then how would you prevent the object from casting the color on objects in front? Also, if you do write the depth value, what happens to the objects that are supposed to further occlude the light behind it (the colored shadow would shine through those objects…)? Seems like a catch 22 to me… Did you figure out a way around these things?
Well, if an object is in front of the window, it will of course be in front of the window in the shadow map too. So you’ll get (white, depth) in the shadow map.
Originally posted by Humus: Well, if an object is in front of the window, it will of course be in front of the window in the shadow map too. So you’ll get (white, depth) in the shadow map.
But what if you have a transparent object, an opaque object behind that and another opaque object behind that. AFAIK your demo does correctly shadow the first opaque object with the color from the glass and the second object with a black shadow (because the object in the middle occludes the light completely.
It does this by not depth filling transparent objects when rendering the depth shadow map. As Humus has posted anything in front of the glass will be written to the shadow map, (depth and color). The only limitation is multiple layers of transparent objects, which it definitely can’t handle without improvements. I assume when rendering the transparent object itself the light contribution isn’t modulated by the shadow color or it’d self shade.
Originally posted by dorbie: I assume when rendering the transparent object itself the light contribution isn’t modulated by the shadow color or it’d self shade.
Correct.
If it’s not depth filling for transparent objects then how could it reject the case where an object is in front of a window for instance?
In a shadow mapping system, without depth information for the window from the light’s perspective, there would be no way to reject those cases, right? And if that’s the case then you’d get the window color shining on objects in front of the window with respect to the light. Am I just confused and you are actually using a stencil method (which seems like it would require deferred shading of sorts… or many passes)?
lol, wow, I can’t believe I missed that (I read it, I just misinterpreted it…). Sorry guys. So yeah it would just be the multi-translucent layers that would be an issue. Cool…
.
. Wouldn’t there still be artifacts where two soft parts would interact (since you’d technically need multiple depth values at that point)?