I read the manual about interior texture. It says that it can be apply 
to triangle (and I assume mesh and mesh2) but I did not find (with a 
grep) the definition of backside and frontside for triangles, mesh and 
mesh2 ?

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 !

Please help.

Thanks

Christophe Raffalli

Post a reply to this message

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

> I read the manual about interior texture. It says that it can be apply
> to triangle (and I assume mesh and mesh2) but I did not find (with a
> grep) the definition of backside and frontside for triangles, mesh and
> mesh2 ?
>
> 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 !
>
> Please help.

You cannot currently recreate the OpenGL backface cullling effect with
POV-Ray.  This effect only exists in OpenGL as a speed optimisation because
for OpenGL it is faster to not render backfacing triangles.  This is not the
case in POV-Ray.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> In article <403ccb81$1@news.povray.org> , Christophe Raffalli 
> <raf### [at] univ-savoiefr>  wrote:
> 
> 
>>I read the manual about interior texture. It says that it can be apply
>>to triangle (and I assume mesh and mesh2) but I did not find (with a
>>grep) the definition of backside and frontside for triangles, mesh and
>>mesh2 ?
>>
>>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 !
>>
>>Please help.
> 
> 
> You cannot currently recreate the OpenGL backface cullling effect with
> POV-Ray.

I am not sure I understand
>  This effect only exists in OpenGL as a speed optimisation because
> for OpenGL it is faster to not render backfacing triangles.  This is not the
> case in POV-Ray.
> 

What I want is to be able to choose which face if the backside and which 
face if the front face for a mesh2 in fact.

For the moment I get a nice patchwork (not completely random) because 
texture and interior texture are applied in a way I do not understand to 
each triangle in the mesh. (my mesh uses OpenGL convention for the order 
of vertices and has normals pointing to the outside).

Should I give a script sample ?

>     Thorsten
> 
> ____________________________________________________
> Thorsten Froehlich
> e-mail: mac### [at] povrayorg
> 
> I am a member of the POV-Ray Team.
> Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Christophe Raffalli wrote:
> 
> I read the manual about interior texture. It says that it can be apply 
> to triangle (and I assume mesh and mesh2) but I did not find (with a 
> grep) the definition of backside and frontside for triangles, mesh and 
> mesh2 ?

AFAIK the use of interior_texture depends on the normal direction and 
the normal direction of a flat triangle in a mesh depends on the order 
of vertices.  In case of a smooth triangle this is of course more 
complicated, you probably can even create triangles with partly 
interior_texture and partly not.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

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

> What I want is to be able to choose which face if the backside and which
> face if the front face for a mesh2 in fact.

You cannot do this if you also desire to apply individual textures to each
face of the mesh.  You can of course split the mesh into as many faces as
you want to texture individually, but I am aware that doing so is not
feasible if you have many individual textures.

> For the moment I get a nice patchwork (not completely random) because
> texture and interior texture are applied in a way I do not understand to
> each triangle in the mesh.

interior_texture is only applied to those triangles which do not have their
own texture.  I understand that this may not always be desired, but
currently (POV-Ray 3.6 beta 1) you cannot get the effect you would like.

> Should I give a script sample ?

No, I completely understand what you are trying to do.  As said, you cannot
currently recreate the effect you desire as of POV-Ray 3.6 beta 1.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <g82### [at] tritonimagicode> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> AFAIK the use of interior_texture depends on the normal direction and
> the normal direction of a flat triangle in a mesh depends on the order
> of vertices.  In case of a smooth triangle this is of course more
> complicated, you probably can even create triangles with partly
> interior_texture and partly not.

Nope, the way interior_texture is currently implemented it won't work as
expected with meshes.

    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

Thorsten Froehlich wrote:
> 
> Nope, the way interior_texture is currently implemented it won't work as
> expected with meshes.

Well - i never tried it but at a first quick glance i can't find a 
reason why not.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <1q6### [at] tritonimagicode> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

>> Nope, the way interior_texture is currently implemented it won't work as
>> expected with meshes.
>
> Well - i never tried it but at a first quick glance i can't find a
> reason why not.

Just believe me.  It is not obvious why it won't work, but I did have a very
close look at it very recently, and it will not work as expected.  In fact,
it cannot work as expected.

    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

Thorsten Froehlich wrote:
> In article <403### [at] univ-savoiefr> , Christophe Raffalli 
> <raf### [at] univ-savoiefr>  wrote:
> 
> 
>>What I want is to be able to choose which face if the backside and which
>>face if the front face for a mesh2 in fact.
> 
> 
> You cannot do this if you also desire to apply individual textures to each
> face of the mesh.  You can of course split the mesh into as many faces as
> you want to texture individually, but I am aware that doing so is not
> feasible if you have many individual textures.
> 

I only have two textures: one for all frontside and one for all back side.

>     Thorsten
> 
> ____________________________________________________
> Thorsten Froehlich
> e-mail: mac### [at] povrayorg
> 
> I am a member of the POV-Ray Team.
> 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:

> I only have two textures: one for all frontside and one for all back side.

So what is the problem?  As long as you don't specify per triangle textures
in a mesh, everything will work just fine.  All you need to do is specify
both texture and interior_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 <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

On Thu, 26 Feb 2004 15:34:41 +0100, Christophe Raffalli
<raf### [at] univ-savoiefr> wrote:
> 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 ?).

OpenGL API is for programmers, POV-Ray scripts are also for artists. They
shouldn't be contignously discouraged during reading manual IMO.

If programmers are interested, majority of formulas can be reached through
reading sources (though extracting some parts it is not an easy task).

ABX

Post a reply to this message

ABX wrote:
> On Thu, 26 Feb 2004 15:34:41 +0100, Christophe Raffalli
> <raf### [at] univ-savoiefr> wrote:
> 
>>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 ?).
> 
> 
> OpenGL API is for programmers, POV-Ray scripts are also for artists. They
> shouldn't be contignously discouraged during reading manual IMO.

That is not a good argument the math could be in a separate chapter or 
documentation.

> If programmers are interested, majority of formulas can be reached through
> reading sources (though extracting some parts it is not an easy task).

This is very bad. Getting the math from a C (or C++) file is a nightmare.

Moreover, in a doc you can first give a simplification and the give 
refinment. In the code you immediately have the full refined solution 
where everything is mixed.

Moreover, the math involved are generally no so hard (linear algebra + a 
bit of phisics and there are probably some artist that could surprise 
you by understanding them :-)

> ABX

Post a reply to this message