Smooth heightfiels show sometimes a bug which seems to be related to normals
getting inverted when they shouldn't. This causes wrong lighting which can
be mainly seen as dark spots (which go away with 'double_illuminate').

  The following example shows clearly the problem. It uses a slope y pattern
with slopes <0.5 (ie surfaces facing downwards) colored red and slopes >0.5
colored with gray to white. As a heightfield, it should not show any red
because all surfaces are faced upwards. However, it shows red where surface
normals are inverted.
  The curious thing about this is that the places of the inverted normals
(ie the red spots) are somehow dependant of the camera location. If you
try the two given camera locations you'll see that the amount and location
of the spots change.

-------------8<--------------8<-------------8<-------------8<-----------
camera
{ location #if(0) <0,0.3,0> #else 0 #end
  look_at z*1
}

height_field
{ function 200,200 { pattern { granite } }
  smooth
  scale <10,1.5,10>
  pigment {slope y color_map { [0 rgb x][.5 rgb .5][1 rgb 1] } }
  finish{ambient 1}
  translate -<5,.3,0>
}
-------------8<--------------8<-------------8<-------------8<-----------

  Tested on both windows and unix versions of povray.


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

Let me guess the reason for this: When povray calculates the ray-hf
itersection, it returns the normal inverted if the regular normal was at
an angle <90 degrees with respect to the incoming ray.
  There might be some archaic reason for this and it doesn't matter with
non-smooth heightfields, but it causes a misbehaviour when a smooth triangle
is oriented so that it faces the camera but some of its normal vectors are
pointing away from it.

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

Wasn't it Warp who wrote:

>  Smooth heightfiels show sometimes a bug which seems to be related to normals
>getting inverted when they shouldn't. This causes wrong lighting which can
>be mainly seen as dark spots (which go away with 'double_illuminate').

Is this the same as

Unsmooth smooth HF shading
(the shading of height-fields with abrupt changes is very ugly when
smooth shading is turned on)
http://news.povray.org/3c02ac19@news.povray.org

which was eventually determined to be a limitation, rather than a bug?

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Mike Williams <mik### [at] nospamplease> wrote:
: Is this the same as

: Unsmooth smooth HF shading
: (the shading of height-fields with abrupt changes is very ugly when
: smooth shading is turned on)
: http://news.povray.org/3c02ac19@news.povray.org

  It says:

"the shading of height-fields with abrupt changes is very ugly when smooth
shading is turned on."

  There are no abrupt changes in my example.
  The problem in my example seems that normals get inverted when they
shouldn't.

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

> Mike Williams <mik### [at] nospamplease> wrote:
> : Is this the same as
> 
> : Unsmooth smooth HF shading
> : (the shading of height-fields with abrupt changes is very ugly when
> : smooth shading is turned on)
> : http://news.povray.org/3c02ac19@news.povray.org
> 
>   It says:
> 
> "the shading of height-fields with abrupt changes is very ugly when smooth
> shading is turned on."
> 
>   There are no abrupt changes in my example.
>   The problem in my example seems that normals get inverted when they
> shouldn't.


If it helps some of the coders, that problem was there in 3.1.  It is 
not due to new code in 3.5.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   videotron.ca  */}camera{location<6,1.25,-6>look_at a orthographic}

Post a reply to this message

I have looked a bit at the heighfield code, but the reason of this inverting
is not as simple as I thought. There doesn't seem to be anything like:

  if(angle_between(incoming_ray, normal) < 90)
    invert(normal);

(this is pseudocode, not actual C code used in povray :) )

or at least I didn't find anything like that. If there's this kind of
inversion, it's quite hidden in some formula used in the code.
  Although the heightfield normal calculation code is rather simple, it's still
rather tricky to understand what exactly is done.
  I'll try to study it more.

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

It's not actually a heightfield bug. It's a more general phenomenon. If the
angle between the normal vector returned by the object (any object) and the
incoming ray is <90 degrees, then the normal vector is inverted.
  Here is another example where this happens:

camera { location -z*2 look_at 0 }
smooth_triangle
{ <-1,-.2,0>, <-1,1,-1>
  <1,-.2,0>, <1,1,-1>
  <0,.2,2>, <0,1,1>
  pigment { slope y color_map { [0 rgb x][.5 rgb .5][1 rgb 1] } }
  finish{ambient 1}
}

  The normal vector of this smooth triangle points always upwards, never
downwards, and thus it should never get colored red. But the inversion
phenomenon of the normal causes the artifact.

  (I think this was the reason why smooth meshes were double-illuminated by
default. It was a quick trick to get rid of this artifact! However, this
doesn't help with slope patterns.)

  I carefully tested the normal vectors returned by the heightfield object,
and they never point downwards, so the inversion indeed happens at a higher
level in the rendering process.

  However, I understand that removing this inversion could actually break
something else which currently works. One case could perhaps be CSG
illumination and inverted object illumination.

  Any ideas?

-- 
#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:
:   However, I understand that removing this inversion could actually break
: something else which currently works.

  By the way, it occurred to me what would this seriously break: If we are
looking at an object surface from one side and a light source is illuminating
the object on the other side, this normal inversion takes care that we see
a shadowed surface, not an illuminated surface. If the normal was not inverted,
then the surface would work like it was double-illuminated all the time if
the unmodified normal points at the light source and it wouldn't be illuminated
at all (no matter where you look at it) if the unmodified normal points away
from the light source.

  What a dilemma!

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

I don't have the POV 3.5 source available, but in POV 3.1:

lighting.c, Determine_Apparent_Colour()

...

  VDot(Normal_Direction, Raw_Normal, Ray->Direction);

  if (Normal_Direction > 0.0)
  {
     VScaleEq(Raw_Normal, -1.0);
  }

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

In article <3c4d9de5@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   However, I understand that removing this inversion could actually break
> something else which currently works. One case could perhaps be CSG
> illumination and inverted object illumination.

Any case where you can see both sides of a surface...any object that's 
clipped, triangles, bezier patches, height fields, discs, polygons, 
isosurfaces...

The only fix would be to detect for a hit from the "outside" of the 
object that still gives a normal that points away from the ray. This 
only happens with smooth triangles as far as I can tell, so the test 
could be restricted to that case if possible. As for what you do when 
you identify this case...that's a different problem, and I don't think 
it's been solved. Artificially limit the normal to be at 90 degrees to 
the ray? I think that will just make black areas. Ignore the 
intersection entirely?
If the intersection is ignored, you have to worry about the triangles 
behind it...maybe meshes/smooth_triangles should have a "front_only" or 
"cull_backsides" option, but that would break transparent meshes. Maybe 
just ignore the intersection and the first intersection with the same 
mesh that follows it...that should work for all well-behaved meshes, but 
might be complex to code.

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

Warp wrote:
> 
>   It's not actually a heightfield bug. It's a more general phenomenon. If the
> angle between the normal vector returned by the object (any object) and the
> incoming ray is <90 degrees, then the normal vector is inverted.
> 
> [...]

I think it would be interesting to know how other raytracers handle this.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

>   It's not actually a heightfield bug. It's a more general phenomenon. If
the
> angle between the normal vector returned by the object (any object) and
the
> incoming ray is <90 degrees, then the normal vector is inverted.

Imho these bugs can only appear if the normal is somehow modified.
Wouldn't it be possible to just test the unmodified normal?

--
#local T=text{ttf"timrom.ttf""Simon Adameit".01,0}#local Y=1;#while(Y>-1)
#local X=0;#while(X<7)#local O=trace(T<X,Y><X,Y>+z);cylinder{<X-3,Y,5>*.01
<X-3,Y,5>*.01+5e-3,5e-5pigment{rgb 25*O}}#debug chr(83-(O.x=0)*51)#local
X=X+.05;#end#debug"\n"#local Y=Y-.05;#end

Post a reply to this message

Looking at the code and testing a bit it's now extremely clear why this
artifact happens. It's not a bug, it's just a side-effect of normal
perturbation in smooth triangles.

  One possible solution is to invert the normal if the angle between the
incoming ray and the unmodified triangle normal is <90 and the angle between
the modified normal and the incoming ray is >90, or the other way around.
That is, for example in the heighfield function which returns the normal
vector for a certain point, in the block where it is calculated for a smooth
heightfield, something like this is done:

  if(dotProduct(incomingRay,unmodifiedNormal)*dotProduct(incomingRay,Result)<0)
    invert(Result);

  The effect of this is that when the problematic case happens, the normal
is inverted inside the heightfield code. Then it's inverted again at the upper
level, thus nullifying the inversion.

  However, there's one big problem here: As far as I can see, the normal
calculation function has no access to the incoming ray.
  Any ideas?

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

>   However, there's one big problem here: As far as I can see, the normal
> calculation function has no access to the incoming ray.
>   Any ideas?

Two...: 
 -(bad) Put the incoming ray in a global... not on the head, not on the head

 - Add a ray parameter to all the involved functions going from the function
   where it is needed upto the function it is already available.
   But you might end up with having to update all the objects (at least,
   the prototype of the functions). And stack size is not infinite...
    (ok, it can be just a pointer to the ray structure, that's not that big).


-- 
Non Sine Numine
http://grimbert.cjb.net/

Post a reply to this message

In article <3C4ED0D6.4084AD3C@atosorigin.com>,
 Jerome Grimbert <jer### [at] atosorigincom> wrote:

> Two...: 
>  -(bad) Put the incoming ray in a global... not on the head, not on the head

Not quite so bad, but still not good: put the incoming ray in the mesh 
struct. There shouldn't be anything that bothers it while the normal 
calculation is being done.


>  - Add a ray parameter to all the involved functions going from the function
>    where it is needed upto the function it is already available.
>    But you might end up with having to update all the objects (at least,
>    the prototype of the functions). And stack size is not infinite...
>     (ok, it can be just a pointer to the ray structure, that's not that big).

The best solution, but a pain to do.

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

In article <3c4ec167@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   The effect of this is that when the problematic case happens, the normal
> is inverted inside the heightfield code. Then it's inverted again at the 
> upper level, thus nullifying the inversion.

Yuck.

Any idea what the visual effects of this will be? I don't think it will 
look correct. You will be seeing a surface with the normal pointing away 
from you, I think that unless you toss an "fabs()" into the mix, you 
will end up with negative diffuse values.
Hmm, using "fabs()" might be a better method than inverting the normal 
anyway...

I still like my method: If the triangle normal is pointing towards you, 
but the interpolated normal is pointing away, ignore the intersection 
and the next one with the same object. The effect should be that you 
just don't see the corners that you shouldn't be seeing...it might even 
round out the outline a little.
This would probably be quite difficult to code, though...

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote:
: Any idea what the visual effects of this will be?

  It will look correct (well, not 100% correct, but smooth triangle shading
is never 100% correct anyways).

: You will be seeing a surface with the normal pointing away 
: from you

  That doesn't matter because it's only used for the illumination, nothing
else.

: I think that unless you toss an "fabs()" into the mix, you 
: will end up with negative diffuse values.

  How so? From the point of view of the light source, nothing strange is
happening.
  It should work correctly in the way I proposed.

  And where do you propose to put the fabs()? I don't understand it.

: I still like my method: If the triangle normal is pointing towards you, 
: but the interpolated normal is pointing away, ignore the intersection 
: and the next one with the same object. The effect should be that you 
: just don't see the corners that you shouldn't be seeing...it might even 
: round out the outline a little.

  This will result in big holes in the mesh in some cases (note that the
normal vectors at the vertices of the triangles do *not* necessarily have to
be the average of the adjacent triangle normals; they can be anything).

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

On 22 Jan 2002 12:14:13 -0500, Warp <war### [at] tagpovrayorg> wrote:

> It's not actually a heightfield bug. It's a more general phenomenon. If the
> angle between the normal vector returned by the object (any object) and the
> incoming ray is <90 degrees, then the normal vector is inverted.
> The normal vector of this smooth triangle points always upwards, never
> downwards, and thus it should never get colored red. But the inversion
> phenomenon of the normal causes the artifact.

I can be completly offtopic but could be normal determined by order of vertices
in triangle?

ABX

Post a reply to this message

On Thu, 24 Jan 2002 08:48:33 +0100, W³odzimierz ABX Skiba
<abx### [at] babilonorg> wrote:

>I can be completly offtopic but could be normal determined by order of vertices
>in triangle?

Then the renderer would have to trust that the order is correct, and
that is the task of either the export utility or the scene that
generates it. In any case the user shouldn't be doing the renderer's
job.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

On Thu, 24 Jan 2002 14:21:17 +0200, Peter Popov <pet### [at] vipbg> wrote:
> > I can be completly offtopic but could be normal determined by order of vertices
> > in triangle?
>
> Then the renderer would have to trust that the order is correct

not exactly
I proposed this becouse I always generate meshes from triangles builded in one
direction (ok, almost always). I helps me a lot in generating smooth normals.
Old behaviour could be supported just with #version 3.1; afaik there is no
export utylity for 3.5 so I suppose all utilities adds #version to exported
scripts.

> In any case the user shouldn't be doing the renderer's job.

But renderer can't decide as I understand.

ABX

Post a reply to this message

W³odzimierz ABX Skiba <abx### [at] babilonorg> wrote:
: I can be completly offtopic but could be normal determined by order of vertices
: in triangle?

  I didn't understand this.

  The problem is not determining the normal. The problem is just that if
the angle between the incoming ray and the normal vector returned by the
object have an angle <90 degrees, the normal is inverted.
  This works just fine in most cases (and it has to be done this way). The
only problem happens with smooth triangles and smooth heightfields in certain
cases.
  As for lighting, this problem goes away by making the object
double-illuminated (because then it doesn't matter which way the normal
is pointing). However, as for the slope pattern, the solution is not so simple
(double_illuminate is used only for lighting and can't be used for slope
pattern calculation).

  By the way: In a heightfield the problem with the slope y pattern goes
away if you "mirror" the color_map around 0.5 (of course it doesn't work if
the slope is anything else than y), besides making the heightfield
double-illuminated.
  With smooth meshes which use the slope pattern there's no currently fix,
AFAIK.

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

On 24 Jan 2002 07:51:51 -0500, Warp <war### [at] tagpovrayorg> wrote:
> The problem is not determining the normal. The problem is just that if
> the angle between the incoming ray and the normal vector returned by the
> object have an angle <90 degrees, the normal is inverted.

I see, sorry then.

ABX

Post a reply to this message

"W³odzimierz ABX Skiba" wrote:

> I can be completly offtopic but could be normal determined by order of vertices
> in triangle?

From memory:
In 3.1 code, the short answer is NO, at least for mesh, 
because the mesh code is free to reorder the vertices of any single triangle.(*)
So even if you carefully generate all your triangles with a +side and -side, 
once in the mesh structure it might be impossible to get back to the original
order. It's often simpler to use a smooth_triangle which allow to explicitely
specify a normal for each vertex (but take more memory, of course).

(*) and it does it, according to its own private criteria.
-- 
Non Sine Numine
http://grimbert.cjb.net/

Post a reply to this message

On Thu, 24 Jan 2002 13:38:00 +0100, W³odzimierz ABX Skiba
<abx### [at] babilonorg> wrote:

>not exactly
>I proposed this becouse I always generate meshes from triangles builded in one
>direction (ok, almost always).

Yes, but that's you. You're not the average Joe User.

>But renderer can't decide as I understand.

Yet :)


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

In article <9uuv4uoaebc3dldemv9snhjmopultmctlj@4ax.com>,
 Peter Popov <pet### [at] vipbg> wrote:

> Then the renderer would have to trust that the order is correct, and
> that is the task of either the export utility or the scene that
> generates it. In any case the user shouldn't be doing the renderer's
> job.

No. There is no way for the renderer to reliably determine the correct 
normal, and such a mechanism would break many meshes that use the 
winding to determine it. It normally isn't a problem anyway, since POV 
renders both sides of the triangle.
And it isn't related to the height field problem, which has more to do 
with the interpolation of smooth triangle normals.

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

In article <3C501EB7.263F96C0@atosorigin.com>,
 Jérôme Grimbert <jer### [at] atosorigincom> wrote:

> In 3.1 code, the short answer is NO, at least for mesh, 
> because the mesh code is free to reorder the vertices of any single 
> triangle.(*)
> So even if you carefully generate all your triangles with a +side and -side, 
> once in the mesh structure it might be impossible to get back to the original
> order. It's often simpler to use a smooth_triangle which allow to explicitely
> specify a normal for each vertex (but take more memory, of course).

Not true. The mesh stores the vertex *vectors* separately, the triangles 
then refer to that list. The triangles still know what order the 
vertices are in.

Proof? Use interior_texture on a mesh. The height-field macros make good 
examples...

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

"Christopher James Huff" wrote:
> Proof? Use interior_texture on a mesh. The height-field
> macros make good examples...

And after I fixed the height-field macros you even get the interior texture
on the *inside*, contrary to how it was before... ;)

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Jan 20)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message