idea for future q3map2 shader functionality: translucency

(rgoer) #1

I’m not too sure how much of a pain in the ass this woudl be, but hows this:

q3map_translucent front opacity, back opacity– since this would only really work well for “cull none” surfaces, I’m not sure how you’d be able to differentiate between which side gets to be the “front” and which side gets to be the “back,” though, in Radiant.

In any case, you could get some nice translucent shadow surfaces–like rice paper or something–with a shader like this. Set front opacity to .25 and back opacity to .75, and light would still make it through the translucent surface, but it would catch shadows. Might look something like this:

Would be extra cool if the shader could be made to emit light according to the lightmap info that makes it through.

(Valhue2) #2

IDEA:

To differentiate bet/ the ‘front’ and the ‘back’, you could have 2 different shaders… such as ‘(x)trans_front’ and ‘(x)trans_back’, where x is the name of the texture… or something to the likeing. Thus you would have an individual shader for both the front and back. You would only use one texture through the use of the ‘editorimage’ command for a shader script… Well thats just my 2 Yen’s on how it could be set up.

V^2

(rgoer) #3

I realized I was being stupid when I worried about “front” and “back”–they are meaningless, as far as how the user sees them in Radiant, it’s only the “front” and “back” relative to a ray’s path during raytracing that matters. So you set the “front” and “back” opacity to whatever, then, during raytracing, a ray from a light that is situated on one side of a “cull none” surface to which the translucent shader is applied illuminates the first side of the surface it encounters (please realize, at this point, that I’m going on various assumptions that are, most likely, quite ignorant of the actual q3map2 raytracing process) using the “front” calculation. Since it’s working on the “front” for this first side, it does a quick “back” calculation and applies this to the other side of the same “cull none” surface. At this point, our pal the ray goes on about its marry way, illuminating all sorts of “normal” things and quickly forgetting about its torrid tryst of translucency. A new ray, however, is heading in our direction, from a different light source this time, and this ray is headed in almost the opposite direction as the first one. So the first side of our translucent surface that this new ray hits was the “back” before. Never fear, though, because this ray is keen. It sees our surface and knows that it needs to do a “front” calculation on the first side it hits. Having done that, it proceeds to throw in some “back” information for the other side. And I think things could just carry on like this until the cows come home (rendertimes would probably be increased by this functionality to that old-wives-tale kind of span, anyway).

So yeah, what exactly do I envision “front” and “back” to be? Well the “front” calculation would be kind of like lightmapping any old “surfaceParm trans” surface. The “front” opacity is “x” (a normalized value between 0 and 1), so you apply “x” amount of light from every ray that passes through to the “front” calculation, and let “1-x” amount of light get by the “front” and start the same calculation for the “back.” At least, I think that’s how it would work. Maybe somebody smarter than me could look at that shot I posted before, and summarize translucent raytracing more clearly?

Is anybody interested in this type of feature?

(wudan) #4

The only new thing you are suggesting is the "light comes in one end, is affected by this shader (which has alphashadow), and gets put out on the other end, ydnar suggested this once, but you get the same effect, more or less, with ‘goopy lighting’ - just give it some bounce, and scale as needed.

(rgoer) #5

Will current q3map2 shader technology allow for a shader to “catch” shadows, yet remain luminant? Like that orange block in the image up top? You are saying, Wudan, that such an effect is currently doable via the q3map2 raytracer? Without drawing the shadows onto the texture map beforehand?

(wudan) #6

Hmmm… catching shadows on a translucent object … not too sure, but I think so.