clipka <ano### [at] anonymousorg> wrote:
> Extending double_illuminate 
> to accept float values would have been not so easy indeed, and would 
> also have broken scenes where it's used just as a kludge to get rid of 
> mesh artifacts.)

  Why would it have broken anything? A float parameter can be made
optional, so if it isn't specified a default is used.

  And btw, I think that the view that "double_illuminate is used as a kludge
to get rid of mesh artifacts" is a bit simplistic of a view.

  The fact is that double illumination (of smooth meshes) existed way before
the 'double_illuminate' keyword was introduced. Smooth meshes were by default
double-illuminated, I assume precisely because it avoided many of the
artifacts. At some point (maybe because people complained about it), they
were changed to be normally-illuminated, which introduced the artifacts.
Some time later the 'double_illuminate' keyword was introduced which could
be used to make smooth meshes double-illuminated again, as they have always
been. (I'm not 100% if 'double_illuminate' was introduced precisely because
of this smooth mesh issue, but it could at least partially be the reason.
I probably read all the related discussion, but I don't remember it anymore.)

  I'd even go as far as to say that, in fact, double_illuminate exists
precisely to reduce artifacts in smooth meshes, and any other use is the
"kludge", ie. trying to achieve some illumination effects which are not
physically correct.

  Thus the approach you took with your patch is, in fact, the correct one:
Keep 'double_illuminate' as the fix for smooth mesh artifacts, and instead
create a better solution for back illumination.

-- 
                                                          - Warp

Post a reply to this message