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

<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