Re: Polygon Problems

[Struan Gray <struan.gray(at)sljus.lu.se>]

Ronn Kling, ronn@rlkling.com writes:

> I agree that what you describe is a problem.  I pulled 
> something together that is included below that at least
> solves part of the line problem. What you have to do is
> to create a polyline object in another model, but offset
> the model by a small amount in the z direction.

	This works until the user rotates the model.  I've also tried
expanding the polyline object slightly, which works until you
construct a polyhedron with no well-defined centre.
	
	I'm working on adding a cylindrical linestyle to the polygon
edges, which will sidestep the problem at the expense of longer
calculation times.

	As an aside: I would love to be able to modify the Draw method for
various graphics primitives.  Not by actually modifying it, but by
augmenting it in the same way that Init and Cleanup methods can be
built upon in sub-classes.  In the above case, this would allow the
Draw method to work out where 'z' was in the current view and displace
the polygon that way before handing off to the usual Draw method.  It
would also allow you to easily implement useful 'on glass'-type
objects for labelling plots and diagrams.


> However, the polyline object suffers from the same
> problem as the surface object. They just aren't set
> up for cases with more faces than vertices.  This is
> really obvious when you run the example below.

    Aarrgh!
    
    
> 	It appears that the way RSI solved this with the teapot
> is to add points in the center of a polygon, In your
> octahedron example you would have to add point in the center
> of the face and thereby artificially create more triangular
> regions.

	This is another way of doing it.  Because I plan to add methods to
my polyhedra objects which will work on a polygon-by-polygon basis
(and not a vertex-by-vertex one) I prefer to duplicate vertices: the
octagon can be plotted if you just add two more vertices identical to
any of the existing ones.

	It's probably worth pointing out that with any shape which is
predictable you can always come up with a hack that works well enough.
 With objects you can even confine that hack to a superclass which can
be altered if and when RSI address the problem.  The difficulty is
that none of the hacks are general, so when I stop playing with nice
cubic lattices and head into the wild badlands of monoclinic crystals
or amorphous materials, I can't be sure that my programs will work.


> I hope this helps a little.

	It puts my mind at rest that I'm not the stupid one.  Thanks for
looking into it.

	As far as I can tell, neither of these effects are caused by any
limitation in OpenGL.  I'll submit a request to RSI for a composite
style and a polygon_normals keyword and see what happens.


Struan