Am 23.03.2010 17:13, schrieb Thorsten Froehlich:

>> IIRC, POV-Ray 3.5 mishandled alpha transparency against the background
>> in that with antialiased edges and semi-transparent surfaces it blended
>> the surface's color with the background color and then saved the
>> resulting
>> color with an alpha value. This caused object borders to have a
>> pixel-wide
>> halo of the wrong shade, and especially semi-transparent surfaces
>> would have
>> the wrong color.
>>
>> This was fixed in POV-Ray 3.6, where it's calculated correctly (iow. the
>> background color has no effect on the pixel colors when using +UA).
>>
>> Last time I checked (it has been some time, though), the same problem had
>> resurfaced in POV-Ray 3.7 beta. Someone had undone the fix in POV-Ray
>> 3.6.
>>
>> Has this been corrected already?
>
> The fix was that alpha is treated differently depending on the version
> directive as the 3.6 change was unpopular...

I just noticed the following:

(a) With +UA, POV-Ray 3.6 /completely/ suppresses the background except 
in reflections and radiosity-based diffuse illumination.

(b) POV-Ray 3.7 /without/ a #version directive (or with #version >=3.7) 
/always/ takes the background into account, and uses the background's 
transmittance as the basis for alpha channel computation.

(c) POV-Ray 3.7 /with/ a legacy #version directive (e.g. #version 3.6) 
/always/ takes the background into account as well, except that it 
forces the transmittance to 1.0.

The latter variant is totally rubbish, as it cannot be used for anything 
useful at all, and doesn't actually make the thing backward compatible.


As a side note, I think (a) is the most useful, as it allows for the 
background to be used for specifying a color to be seen in reflections 
of the background, while not showing up in the image itself - something 
that cannot easily be accomplished otherwise - so completely 
"retreating" from that behavior seems a bad idea to me. Instead, I 
suggest to make this behavior configurable to the user independently of 
the #version directive, using some additional syntax; and as we're on 
it, we can extend the same syntax to be used with a sky sphere as well, 
so the user can choose whether to have the sky show up only in 
reflections (leaving the background completely transparent), or in the 
background as well (e.g. for generating fully or partially opaque 
clouds). Or use this additional syntax only for the sky_sphere, and make 
the background always invisible in the image itself when +UA is 
specified. (If a user wants to mix some constant background into the 
alpha channel, they can always resort to using a sky sphere with a plain 
constant-color pigment.)

I'm thinking about something along the lines of

background {
   COLOR // only used in reflections or without +UA
}
sky_sphere {
   alpha_substitute { // must be first
     // pigments only used in reflections or without +UA:
     PIGMENT_1
     PIGMENT_2
   }
   // pigments to use always:
   PIGMENT_3
   PIGMENT_4
   ...
}

or:

// to be rendered always:
background { COLOR }
sky_sphere { PIGMENT_LIST }
// to be rendered /additionally/
// "behind" the regular background & sky_sphere
// only in reflections or when +UA is not used:
alpha_substitute {
   background { COLOR }
   sky_sphere { PIGMENT_LIST }
}

Note that if the alpha_substitute contains any transmittance in itself, 
this might be used as an indicator that the user wishes alpha 
transparency even in reflections.

Post a reply to this message