Warp wrote:
> 
> John VanSickle <van### [at] erolscom> wrote:
> : For flat triangles the normal is derived from a cross-product of two
> : of the edge vectors (I presume) and therefore depends on the order
> : the vertices are defined.
> 
>   I think it doesn't matter which side the normal is pointing to (as
> in any other surface in povray). This specially doesn't matter with
> triangles since they do not have interior.

I tested this and it seems you're right; my memory is playing tricks on
me again.

Regards,
John

Post a reply to this message

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

> John VanSickle <van### [at] erolscom> wrote:
> : For flat triangles the normal is derived from a cross-product of two
> : of the edge vectors (I presume) and therefore depends on the order the
> : vertices are defined.
> 
>   I think it doesn't matter which side the normal is pointing to (as in 
> any other surface in povray). This specially doesn't matter with 
> triangles since they do not have interior.

John VanSickle is right, the normal is derived using the cross-product 
of the edge vectors.(or something like that) The "up" side of the 
triangle is determined by the order of the vertices.
For lighting calculations, the normal is always flipped so it points to 
the side the intersecting ray came from, so you don't notice a 
difference. However, the real normal does matter if you are using 
MegaPOV and interior_texture. I am not aware of any other places where 
it matters...

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Wasn't it Warp who wrote:
>Jason Miller <jas### [at] pinheirotcimetnet> wrote:
>: Does Povray care about the winding of a mesh?  As in, does it use 1 sided or
>: 2 sided polygons?  If it uses one sided, how can this be set to 2 sided?
>
>  I suppose that a 1-sided polygon is (like, for example, in OpenGL) a polygon
>that is seen only from one side. If the polygon is turned so that the other
>side faces the camera, then it's not rendered.
>  Povray only uses 2-sided polygons (ie. they are rendered now matter how they
>are rotated). I don't know of any plans of adding support for 1-sided polygons
>to povray (I'm not even sure how easy it is to make in raytracing).

I believe that 1-sided polygons are not possible in the current official
version of POVRay, but they can be achieved in MEGAPov by usng the
"interior_texture" keyword.

Every surface is considered to have an interior and an exterior (but
it's not always obvious which is which) and the interior_texture keyword
allows you to have a different texture on the two sides. If you make one
of these textures completely invisible {pigment {rgbt <1,1,1,1>}} then
you've got a 1-sided surface.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Chris Huff wrote:
> 
> In article <3974264c@news.povray.org>, Warp <war### [at] tagpovrayorg>
> wrote:
> 
> > John VanSickle <van### [at] erolscom> wrote:
> > : For flat triangles the normal is derived from a cross-product of
> > : two of the edge vectors (I presume) and therefore depends on the
> > : order the vertices are defined.
> >
> >   I think it doesn't matter which side the normal is pointing to (as
> > in any other surface in povray). This specially doesn't matter with
> > triangles since they do not have interior.
> 
> John VanSickle is right, the normal is derived using the cross-product
> of the edge vectors.(or something like that) The "up" side of the
> triangle is determined by the order of the vertices.
> For lighting calculations, the normal is always flipped so it points
> to the side the intersecting ray came from, so you don't notice a
> difference.

This is what I tested; the normal does indeed need to be flipped to
achieve this effect.  I'm fairly sure this was done in a recent
version of POV-Ray; I distinctly remember having to reverse the order
of some defined points in order to get the normals pointed the right
way.

Regards,
John
-- 
ICQ: 46085459

Post a reply to this message

In article <3974E13A.49899E8C@erols.com>, John VanSickle 
<van### [at] erolscom> wrote:

> This is what I tested; the normal does indeed need to be flipped to
> achieve this effect.  I'm fairly sure this was done in a recent
> version of POV-Ray; I distinctly remember having to reverse the order
> of some defined points in order to get the normals pointed the right
> way.

I think the bug fix was added in 3.1b along with some double-illuminate 
stuff:
"Fixed average normal bug and other normal flipping problems"

(revision.doc)

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: I think the bug fix was added in 3.1b along with some double-illuminate 
: stuff:
: "Fixed average normal bug and other normal flipping problems"

  But flipping the normal vector of a (non-smooth) triangle is NOT a bug! It's
the right behaviour.
  Think about a plane { y, 0 }. If you put a light source at y*10 it will
illuminate the top of the plane and the bottom will be shadowed. If you put
the light source at y*-10, it will be the other way around.
  Now, this same behavior has to happen with regular triangles as well. If
the light source is at one side of the triangle, that side has to be
illuminated and the other shadowed. It doesn't matter which side.
  To achieve this, the normal vector has to be flipped to point to the side
where the light source is. If the normal vector were pointing to the wrong
side, the side of the triangle which is facing the light source would be
shadowed, which is the wrong result.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Warp wrote:
> 
> Chris Huff <chr### [at] maccom> wrote:
> : I think the bug fix was added in 3.1b along with some double-illuminate
> : stuff:
> : "Fixed average normal bug and other normal flipping problems"
> 
>   But flipping the normal vector of a (non-smooth) triangle is NOT a
> bug! It's the right behaviour.
>   Think about a plane { y, 0 }. If you put a light source at y*10 it
> will illuminate the top of the plane and the bottom will be shadowed.
> If you put the light source at y*-10, it will be the other way around.

I was speaking of the calculations for normal patterns; the behavior
does seem to have changed since the 3.0 days.

Regards,
John

Post a reply to this message

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

> Chris Huff <chr### [at] maccom> wrote:
> : I think the bug fix was added in 3.1b along with some double-illuminate 
> : stuff:
> : "Fixed average normal bug and other normal flipping problems"
> 
>   But flipping the normal vector of a (non-smooth) triangle is NOT a bug! 
>   It's the right behaviour.

Umm, that's why it was added. Flipping the normal is the bug fix I was 
talking about. Before, it wasn't done, and sometimes caused problems. :-)

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: Umm, that's why it was added. Flipping the normal is the bug fix I was 
: talking about. Before, it wasn't done, and sometimes caused problems. :-)

  Oh, sorry. I got confused.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <39759DCA.E0B64DE7@erols.com>, John VanSickle 
<van### [at] erolscom> wrote:

> I was speaking of the calculations for normal patterns; the behavior
> does seem to have changed since the 3.0 days.

There have been changes...and wasn't there a limitation on what patterns 
could be used as normals in the 3.0.x versions? I think some of those 
changes had to do with allowing any pattern to be used.
Anyway, there will be even more changes...check out MegaPOV for a 
"preview" of what 3.5 should be like. Most of the changes have to do 
with making the normal scale more reasonably, they now act much more 
like actual surface deformations would.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message