In article <403ccb81$1@news.povray.org>,
 Christophe Raffalli <raf### [at] univ-savoiefr> wrote:

> Moreover, the definition seems to differ from OpenGL's (order of 
> vertices) and seems not to use normals either when they are given so I 
> can not guess it !

It does use the order of the vertices...for example, the HF_*() height 
field generator macros produce meshes with correct normals. You do have 
to make sure that you only texture the mesh object as a whole, no 
per-triangle textures.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

I have a mesh2 with one texture and one interior texture and it does not 
render as I wat.

I understand better the problem: my mesh2 is not closed and it seems 
that the algorithm used to define the front and back side is the same 
than the algorithm to test if a point is inside the mesh: fire a ray in 
one direction and if the  number of intersection is odd you are inside 
(this is what the doc says).

But when the mesh in open, this fails. Clearly, for open mesh inside is 
not meaningfull. But back and front sides are. So this algorithm is a 
wrong choice and one should use the normals or the order of vertices to 
distinguish the back and front side (moreover it will be faster).

I can post a script and an image if I am not being clear.

Post a reply to this message

Christopher James Huff wrote:
> In article <403ccb81$1@news.povray.org>,
>  Christophe Raffalli <raf### [at] univ-savoiefr> wrote:
> 
> 
>>Moreover, the definition seems to differ from OpenGL's (order of 
>>vertices) and seems not to use normals either when they are given so I 
>>can not guess it !
> 
> 
> It does use the order of the vertices...

But how ? It is nowwhere in the doc ?

Lets say you have a triangle <A,B,C>.

If the normal defining tre front face the vertor product of (B-A) and (C 
-A) ? Is it somthing else ?

>for example, the HF_*() height 
> field generator macros produce meshes with correct normals. You do have 
> to make sure that you only texture the mesh object as a whole, no 
> per-triangle textures.
>

Post a reply to this message

In article <403### [at] univ-savoiefr> , Christophe Raffalli 
<raf### [at] univ-savoiefr>  wrote:

> I understand better the problem: my mesh2 is not closed and it seems
> that the algorithm used to define the front and back side is the same
> than the algorithm to test if a point is inside the mesh: fire a ray in
> one direction and if the  number of intersection is odd you are inside
> (this is what the doc says).

This has absolutely nothing to do with determining the backface.  It is
relevant to CSG.  The backface of a triangle has nothing to do with the
inside of an object.

> But when the mesh in open, this fails. Clearly, for open mesh inside is
> not meaningfull. But back and front sides are. So this algorithm is a
> wrong choice and one should use the normals or the order of vertices to
> distinguish the back and front side (moreover it will be faster).

POV-Ray does use the normals to determine what is to be considered the
backface and frontface.  You should not jump to conclusions about something
you don't understand what it is used for.  You simply looked at the
completely wrong spot in the documentation where the documentation explains
something completely different and unrelated.  As said above, the section
you are referring to explains how meshes inside and outside are determined
for use in CSG.  This has absolutely nothing to do with what you are trying
to do.

The only way to define the bachface and frontface of a triangle is to use
the surface normal.  To assume anything else is actually a bit insulting to
the intelligence of whoever implemented the mesh object.  Do you really
think they do not know how to determine the backface and frontface of a
triangle using a surface normal?

Your mistake is really simple, and as simple to fix:

If you do not provide a surface normal, POV-Ray has to compute one for you.
If both sides of the triangle mesh are to be lit and textured equally, the
direction of the surface normal does not matter. However, if you want
POV-Ray to apply different texturing or lighting to the backface and
frontface, it needs more information such that all normals point in the same
direction.

In order to let POV-Ray do this, you have to provide all triangle vertices
in the same order.  Either clockwise or counterclockwise, it does not matter
which order, just that they all have the same order.

This is the *only* way POV-Ray can compute a surface normal that always
points in the same direction.  Once all your triangle vertices are specified
in the same order, the surface normal will be well-defined and POV-Ray can
correctly apply the backface and frontface texture.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <403### [at] univ-savoiefr> , Christophe Raffalli 
<raf### [at] univ-savoiefr>  wrote:

> But how ? It is nowwhere in the doc ?
>
> Lets say you have a triangle <A,B,C>.
>
> If the normal defining tre front face the vertor product of (B-A) and (C
> -A) ? Is it somthing else ?

To solve your problem, it does not matter which order is used.  All that
matters is that the same order is always used, which obviously is the case
in a computer program.  From there it is really easy to determine which
order defines the frontface and the backface, as there are only exactly two
combinations possible as a triangle has exactly two sides.  So it is
extremely easy to find out by just applying a backface and frontface texture
even if this is not defined in the documentation (I did not search if it
is).  All you have to do is to always supply your vertices in the same
order.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

> If you do not provide a surface normal, POV-Ray has to compute one for you.
> If both sides of the triangle mesh are to be lit and textured equally, the
> direction of the surface normal does not matter. However, if you want
> POV-Ray to apply different texturing or lighting to the backface and
> frontface, it needs more information such that all normals point in the same
> direction.
> 
> In order to let POV-Ray do this, you have to provide all triangle vertices
> in the same order.  Either clockwise or counterclockwise, it does not matter
> which order, just that they all have the same order.
> 
> This is the *only* way POV-Ray can compute a surface normal that always
> points in the same direction.  Once all your triangle vertices are specified
> in the same order, the surface normal will be well-defined and POV-Ray can
> correctly apply the backface and frontface texture.
> 

You are right, but it is a pity that the manual is not clear on that 
point ! (I looked again, nowhere what you says is said in the doc)

Moreover, I found there must be a bug in my normal vector (I do have 
some), because when I remove them the front and back side are OK (the 
order of vertices gives a correct orientation because the same order is 
used under OpenGL)

However, OpenGL never uses normal for orientation, so I could not see my 
bug under OpenGL, and discovered it when I exported pov files.

Anyway a big thanks for your help. Your "aggressive" (a bit ;-) 
discourse let me think that you must be right and I must be wrong and 
the discovered that I had a bug ...

Again,  it is a pity that the manual is not clear on that point ! 
because I would not have had doubt if the manual was clear.

Now I just need to find the bug in my code and fix it !

Post a reply to this message

By the way, does povray requires normal of lenght 1. It is not clear 
again from the manual (so I assume it does not require anything)

Post a reply to this message

In article <403### [at] univ-savoiefr> , Christophe Raffalli 
<raf### [at] univ-savoiefr>  wrote:

> Anyway a big thanks for your help. Your "aggressive" (a bit ;-)
> discourse let me think that you must be right and I must be wrong and
> the discovered that I had a bug ...

That was the intention!  Good that you did not take it personally, because
it was indeed not ment that way! :-)

> Again,  it is a pity that the manual is not clear on that point !
> because I would not have had doubt if the manual was clear.

Probably this should be added to the manual if it is indeed not there or
very hard to find...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <403### [at] univ-savoiefr> , Christophe Raffalli 
<raf### [at] univ-savoiefr>  wrote:

> By the way, does povray requires normal of lenght 1. It is not clear
> again from the manual (so I assume it does not require anything)

It depends.  In cases were a non-unit length normal is useful, code should
not normalise it (and it should be noted in the docs where this happens).
However, everywhere else the code normalises the normals by default as
expected.

To answer your question, it does normalise mesh surface normals.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

I fixed my bug ... but it still seems very strange.

For OpenGL I used reduced precision (24 bits, 8 per coordinates) for 
normal. This was the problem for povray !

I tested in my code the original normal and the reduced precision normal 
only differs per 3% and the normal are almost orthogonal to the surface 
(visually from the ligthing).

So I can not explain how such a small difference can make povray 
exchange the front and back side (a pity the manual is not filled with 
mathematical formulas as the OpenGL spef does !!! may be there is an 
advanced user manual ?).

Anyway, I moved to 16bits per coordinate and it now works.


Thanks.

Post a reply to this message