On 01/23/2011 09:35 AM, clipka wrote:
> Am 22.01.2011 23:55, schrieb Robert McGregor:
> 
>> Hi all, regarding the blue ears/fingertips - I'm wondering if there's
>> a bug in
>> the way the color vector is handled somewhere. The color components
>> seem to be
>> inverted; for instance red is<0,1,1>  instead of<1,0,0>. Here are some
>> color
>> vectors I was playing with a while back. Note that they're all
>> inverted from
>> their RGB equivalents, but each renders as it's named color with SSLT:
>>
>> #declare sslt_aqua    =<1, 0, 0>;
>> #declare sslt_magenta =<0, 1, 0>;
>> #declare sslt_yellow  =<0, 0, 1>;
>> #declare sslt_blue    =<1, 1, 0>;
>> #declare sslt_red     =<0, 1, 1>;
>> #declare sslt_green   =<1, 0, 1>;
>> #declare sslt_white   =<0, 0, 0>;
> 
> As I already mentioned earlier, the SSLT parameters are /not/ colors,
> but a pair of wavelength-dependent coefficients that /determine/ the
> color; in POV-Ray, both coefficients are specified for three distinctive
> wavelengths (corresponding - not surprisingly - to red, green and blue,
> respectively).
> 
> The first parameter is the "scattering coefficient", specifying how
> often a photon (speaking of the physical thing here, not the POV-Ray
> thing) will be scattered (i.e. experience a change of direction) on
> average while travelling an "odometer distance" of 1 mm through the
> material. (The algorithm presumes that scattering is isotropic; the
> sample values are fit to match that presumption.)
> 
> The second parameter is the "absorption coefficient", specifying the
> probability that a photon will be absorbed while travelling that distance.
> 
> 
> The dark blue fingers are indeed the results of bad coefficient
> settings; they tell me that the units_per_mm setting is set in a way
> that a finger is close to - or even smaller than - the distance a red or
> green photon would travel before being scattered. In such situations,
> the current surface scattering implementation still gives wrong results,
> as it does not account for photons traveling through the object
> unscattered. (In reality, with features that small, non-isotropic
> scattering would dominate, making the object appear either transparent
> or translucent, or something in between.)
> 
> Where the bright edges come from I can't tell exactly; what I /can/ tell
> you is that (1) the math behind the algorithm was designed for planar
> surfaces, and may give less accurate results at edges, and (2) the
> algorithm cannot fully compensate for "fake smoothing"; so in essence
> you'll need a higher-resolution mesh.

you know this is awful good stuff that should be captured somehow ...
Robert: is there any way you could be conned into bundling this up into
a how to article?

Post a reply to this message