Slime <fak### [at] emailaddress> wrote:
> The smooth triangle bug *is* a bug and there are solutions which work in
> every case.

  I have to disagree with your definition.

  A bug is, by definition, a programming mistake. That is, a feature was
intended to work in a certain way but due to a programming mistake it
does not.
  Smooth triangles work exactly as they were intended to work and thus
it's not a bug. There's no programming mistake in the smooth triangle
code (with this regard, at least; of course there may be other undiscovered
bugs there... :P ).

  The thing is that the specification of triangle shadowing calculation
was flawed to begin with. It does not have a programming mistake (ie. bug)
but a design mistake.

  Originally (in POV-Ray 3.1 and earlier) smooth triangles were
double-illuminated by default. This is most probably because the
coder who coded the mesh code noticed the artifact too late and
thought making triangles double-illuminated would be the easiest
way around the problem. (It may of course be that he designed
triangles to work like this to begin with, but I would bet that
he did not realize about the normal inversion problem until it
was too late.)

> However, this bug is very difficult to fix given the way that
> it's ingrained in the POV-Ray code.

  This is true. When I first figured out the reason for the lighting
artifact in smooth triangles (ie. due to wrongly inverted normals)
I tried looking at the code to see if there would be an easy way to
change this behaviour, and there really wasn't.
  Basically the decision whether or not to invert the normal vector
the primitive returns to the rendering engine should be done based
on the true normal vector at that point of the surface, not based
on the modified normal (which smooth triangles return).
  However, implementing this kind of check would have needed really
ugly kludges to the existing rendering engine, and may have actually
even perhaps slowed down rendering by some small factor (because the
check should be done only for smooth triangles, not every primitive).

> The shadow line artifact is not a bug, however, and there is no real perfect
> solution to it. My solution in SlimePOV is also kind of a hack, and it
> doesn't really behave completely intuitively.

  What kind of fix is it?

  This is one kind of solution which has been proposed:

  When testing self-shadowing, translate the starting point of the shadow
ray away from the surface by an amount equivalent to the perturbation
emulated by the normal pattern. (Shadowing from all other objects should
be performed normally, else you run the risk of the translated starting
point ending up inside another object. OTOH one could argue this is
what should happen in the first place, but I think it's a question of
opinion.)

> I was thinking recently, however, about a different possible solution to the
> shadow line artifact: what if there were a keyword that prevented the
> *inner* surface of an object from casting shadows?

  That would work in most cases, but if the surface of the object is
semitransparent, the shadowing would not be the same with the flag
(otoh, the shadows of semitransparent objects are not realistic in
either case, unless you use photons, which is the correct way to get the
correct shadow, and photons would probably be unaffected by this kind of
flag...)

  (And of course all kinds of pathological cases can be thought of:
For example, what if there's a slightly smaller object inside the
current object? It will cast a shadow to the outer object visible
from the outside... :) )

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message