> > The smooth triangle bug *is* a bug and there are solutions which work in
> > every case.
>
>   I have to disagree with your definition.

I figured someone would. =)

>   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 ).

But surely the artifacts caused by inverted normals around edges weren't
intended. I doubt anyone sat down and thought, "then we'll invert the
normals... and this will cause strange shadows along the edges of triangle
meshes, which we want..." It certainly (hopefully! =) ) wasn't a design
decision like this.

So it's kind of like this scenario: I sit down to write a program which
finds the intersection of a ray and a sphere. To do this, I use the cubic
formula. Lo and behold, when I compile and run my program, I discover that
the object I've rendered doesn't look like a sphere, because I should have
used the quadratic formula instead of the cubic. Nonetheless, the program
works as I designed it, and renders the shape that I told it to render - I
simply told it to render the wrong shape. Is that a bug? Well, the program
works as I intended it to work, but the result was not what I had originally
hoped for.

Obviously the case we have here is not such an extreme mistake, but the fact
is, the way POV-Ray was written failed to account for this small issue, and
since it produces a result that was not originally intended, I feel OK
calling it a bug. Smooth triangles *don't* work exactly as they were
intended to work because they were never intended to have this artifact.

But whatever, that's not the important thing. Just as long as no one tries
to call the artifacts a "feature." =)

> > 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.)

If I remember right, I essentially implemented that solution. I allowed the
user to specify the necessary distance before self-shadowing would occur.
This was kind of ugly because it wouldn't change if, say, you scaled the
object. It's also not a very clean solution to begin with, and it was hard
to find a distance value that worked all over an entire surface.

>   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...)

Yeah, I suppose it would only work well for solid, opaque objects.

>   (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... :) )

True. However, those cases are pretty rare. Especially with the restriction
that the outer object has to be opaque, how often are you going to have an
object nested inside an object needing the fix? And how often is it going to
get into the (ideally small) area that could cause this problem? I think
this would work in most cases, and the real advantage is that its behavior
is predictable.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message