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.

Post a reply to this message