Polygon question

[Sasha kacanski]

Have a question?
Regarding polygon function
RiPolygon(4, RI_P, (RtPointer)ColSquare, RI_NULL);
If I want to make "let's say" a cube from 6 squares and I position it
with
translation and rotation routine in prospective view, why am I getting
inverted normals and consequently black cube.
Is it any function that inverts the vertex normals as in OpenGL world or
I need to average the vectors manually.
Thanks /s
--
---------------------------------------------------------------
Sasha Kacanski
ph. 734.930.6640
240 Murray Avenue
Ann Arbor, MI 48103

[T. Burge]

Sasha Kacanski wrote:
>Regarding polygon function
>RiPolygon(4, RI_P, (RtPointer)ColSquare, RI_NULL);
>If I want to make "let's say" a cube from 6 squares and I position it
>with translation and rotation routine in prospective view, why am I
>getting inverted normals and consequently black cube.
>Is it any function that inverts the vertex normals as in OpenGL
>world or

Polygon expects the points to be listed in a clockwise order, so just
reverse the order you list points in your positional array ColSquare or
use ReverseOrientation or set the orientation to be right-handed or
somehow stick in a Scale (with a minus sign) among your
transformations. Any one of those techniques should work, but the first
one is probably the best with hard coded data. If reading in data from
somewhere then maybe using ReverseOrientation is best for what you are
doing.

T. Burge

[Rick LaMont]

In article <3510B096...@ic.net>, Sasha kacanski <sa...@ic.net> wrote:
> If I want to make "let's say" a cube from 6 squares and I position it
> with translation and rotation routine in prospective view, why am I getting
> inverted normals and consequently black cube.

The short answer:
- Specify the vertices in clockwise order from the camera's point of view; or
- Call RiReverseOrientation to flip the "current orientation" first.

If you can make one square with the normal facing the camera, then you can
use translation and rotation to create the other five faces, being careful
to make the normals point outward from the cube.

There's a whole lot going on behind the scenes here. There are three things
to worry about: 1) the current coordinate system; 2) the geometric primitive
normal; and 3) the current orientation. (Note: The "current orientation" and
"the orientation of the current coordinate system" are two different concepts.)

1) The initial camera coordinate system is left-handed. Transformations such
as reflection can flip the orientation of the current coordinate system.

2) Each geometric primitive has a well defined normal. For polygons, the
normal is perpendicular to the plane of the polygon and is in the direction
of a viewer who would see the vertices in clockwise order.

3) The current orientation is a RenderMan graphics state variable. It can
take on one of two values: left-handed or right-handed. The default value
is left-handed. Whenever the orientation of the current coordinate system
flips, so does the current orientation variable. The user can directly modify
the current orientation with RiOrientation() or RiReverseOrientation().

In the end, whenever the current orientation does not match the orientation
of the current coordinate system, normals are automatically flipped.

Much of this article was paraphrased from the spec:

http://www.pixar.com/products/renderman/toolkit/RISpec/section4.html#Orientation
http://www.pixar.com/products/renderman/toolkit/RISpec/section5.html#Polygons

Rick LaMont
Dot C Software, Inc.
http://www.dotcsw.com/