<<<<<<<<<<<<<<<<<

_indexed_polygon(renderer) Rendering _indexed_polygon(renderer)

NAME

_indexed_polygon - rendering primitive for a set of polygons that share vertices

NOTE

This class is actually a placeholder for a specific rendering class, such as phigs_indexed_polygon. Since its interface is identical across architecures, only one man page exists. Thus, throughout this man page you should think of _indexed_polygon as (class)_indexed_polygon where (class) is the name of the renderer of interest (i.e., gl, phigs, starbase, vogle).

DESCRIPTION

The _indexed_polygon class is a geomtric interface to the rendering system. It is used to render a set of polygons on the display. This class can only be used from within a program. The _indexed_polygon class differs from the _polygon class in that it uses one set of vertices that are shared to define each polygon. Thus, it should be used when defining surfaces that are comprised of polygonal elements, while the _polygon class is more general (and less efficient) in that polygons do not have to lie next to each other. This class has been out of use for a while. I am not sure how well supported it is. As of April 93 it still doesn't handle texture coordinates. I know of nothing that uses it off hand.

SUPERCLASS

(class)_modeller

MESSAGES

build! args Send a new copy of the geometry to the rendering primitive. The next time the object is drawn, this geometry will be used. These are "hidden" arguments, that is, they can only be sent from within a program, not from scripts. They are:

int numpolys; int numcoords; int *connect; float *coords; float *colors; float *normals;

numpolys is the number of polygons in the set. numcoords is the total number of vertices in the set. connect is an array of lengths and indices into the coords array. The first element of connect holds the number of vertices in the first polygon, n1. The next n1 elements in connect are the indices of each vertex in the coords array. They are based at offset 1, that is, you need to subtract one from

the value to get the offset into the coords array. colors and normals are indexed in the same manner (if they are non-null). If the colors argument is non-null, it points to an array of RGB triplets - one for each vertex. The polygon's vertices are then colored with this data and shaded dependent on the current properties. A null value ignores vertex colors and produces only the geometry. If the normals argument is non-null, it points to an array of IJK triplets - one for each vertex - defining the surface normal at that vertex. If shading is performed, the normal will be used in the lighting calculation to determine the color of the vertex. A null value ignores vertex colors and the system will perform the lighting calculation (if necessary) in its default manner (dependent on each system).

draw! This message causes the geometry last passed into the object (via build!) to be rendered.

EXAMPLES

I would say to see display_indexed_polygons.cls for an example but no such file exists. That is a real bad sign. So I'd say look at display_polygons.cls to see how the polygon primitive works. From that you should be able to see how indexed polygons would work. I think that all rendering primitives should take indexed poygons/tmesh since that is how display data stores it and it's more compact, a four fold savings for a planar_grid. I would modify display_polygon though and not bother with a different class. - km