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

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

I'm admitting that I'm way over my head in this discussion, so I won't be 
offended if you inform me that I'm not making any sense. ;-)

To move forward a little and to generalize a little, one of the benefits of 
POV-Ray is the fact that it uses function based surfaces (CSG), rather than 
meshes.  i.e. A sphere is a sphere, not a bunch of triangles glued together 
with normal interpolation.  Imagine placing a sphere inside a slightly 
larger mesh-based sphere.  You'd see the smaller sphere poking through the 
mesh in some places, even though the mesh-based sphere would actually appear 
larger (this could be a neat illusion).  In the long-run, wouldn't it make 
more sense to actually create function based, spline-type surfaces?  Is that 
what NURBS are?  (If so, then this has probably been discussed before.)

Before you kill me, realize that I'm just making statements based on 
something that I know very little about and would have almost no idea how to 
implement, so be nice.  ;-)

Oh, also I've apparently been saying "smooth triangle problem" when I should 
have really been saying "shadow line problem".  I assumed they were both the 
same thing.

-- 
Jeremy
www.beantoad.com

Post a reply to this message

> In the long-run, wouldn't it make
> more sense to actually create function based, spline-type surfaces?  Is
that
> what NURBS are?  (If so, then this has probably been discussed before.)


Yes, that's what NURBS are AFAIK. However, even NURBS and some other smooth
objects (like bezier patches) which don't have a simple, predefined equation
governing them are approximated by triangles. The reason is that triangles
are a lot faster to render. Try rendering a parametric object in POV-Ray; I
don't believe it approximates the surface with triangles and it severely
impacts the speed.

Another difficulty is that triangle meshes, NURBS, etc all define a surface;
they don't define the "inside" of the object as well as x^2+y^2+z^2 - r^2
defines the inside of a sphere.

Function defined surfaces would certainly be more useful if these problems
didn't exist, but the speed of polygon-based surfaces is worth the
inconveniences.

> Oh, also I've apparently been saying "smooth triangle problem" when I
should
> have really been saying "shadow line problem".  I assumed they were both
the
> same thing.

They're different but since they both appear with smooth triangles they're
often grouped together.

The smooth triangle "normal flipping" bug (or not bug) occurs around the
edges of an object no matter where you look at the object from, creating a
black halo. The "shadow line" issue occurs at the points of an object with
smoothed triangles or perturbed normals which are along the line where the
light stops hitting the object. This creates a sharp transition from light
into shadow where one would want it to be smooth.

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

Post a reply to this message

"Jim Charter" <jrc### [at] msncom> wrote in message 
news:41508da6$1@news.povray.org...
> Jeremy M. Praay wrote:
>
>
>> real function-based surface, it would be, well, really cool.  In theory, 
>> such a feature could allow someone to completely replace a smooth 
>> triangle mesh with isosurfaces.
>>
> Yes I played with it a bit leaving the surfaces flat, the attraction being
> that you could then apply a real displaced texture to
> the surface.  It was very slow to render and first results were not
> too exciting.

With enough surface subdivision, and an bunch of RAM, maybe it would look 
pretty good.  After POVComp, I'll probably start messing around with that, 
just for fun.  Or maybe not.  I don't like committing myself to anything... 
;-)

-- 
Jeremy
www.beantoad.com

Post a reply to this message

Slime <fak### [at] emailaddress> wrote:
> But surely the artifacts caused by inverted normals around edges weren't
> intended.

  But the artifacts are not caused by a programming mistake but a design
mistake. There's a difference.

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

  Design mistake means that when they designed the engine they didn't
think of this problem. It doesn't have to be intentional.
  The program works exactly as designed (ie is bug-free), but the
design was flawed.

-- 
#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

Slime <fak### [at] emailaddress> wrote:
> They're different but since they both appear with smooth triangles they're
> often grouped together.

  The shadow line problem is not exclusive to triangles, but it can happen
with all objects with perturbed normals.

  And for those who have no idea what we are talking about, see the
sections 2.4.8 and 2.4.9 of the 3.6 documentation, or these links
(which contain essentially the same thing):

http://tag.povray.org/povQandT/TheShadowLineArtifact/index.html
http://tag.povray.org/povQandT/SmoothTriangleArtifact/index.html

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message 
news:4151bb42@news.povray.org...
> Slime <fak### [at] emailaddress> wrote:
>> But surely the artifacts caused by inverted normals around edges weren't
>> intended.
>
>  But the artifacts are not caused by a programming mistake but a design
> mistake. There's a difference.
>
>> 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.
>
>  Design mistake means that when they designed the engine they didn't
> think of this problem. It doesn't have to be intentional.
>  The program works exactly as designed (ie is bug-free), but the
> design was flawed.
>

Design Flaw = Bug
Design Flaw != Bug
Design Flaw ~= Bug

I think this debate could go on for awhile...  I'm half-expecting a certain 
someone to jump in about now and explain to us why this conversation is 
pointless and unhelpful.  ;-)  Or does he only do that to me?  :-(

-- 
Jeremy
www.beantoad.com

Post a reply to this message