[GRASS5] [bug #242] (grass) R_polygon_abs() seems to ignore islands

[Eric G. Miller]

On Thu, May 03, 2001 at 05:32:31AM +0100, Glynn Clements wrote:
> > I think your being a little too pessimistic here.  The OpenGL scenario
> > has several issues not present in a 2d representation.
> 
> OpenGL also assumes that polygons are planar, which basically reduces
> the problem to 2d:
> 
> 1. Project the polygon onto a 2d plane.
> 2. Compute which edges need to be split and where
> 3. perform the actual interpolation using the 3d coordinates.
> 
> It's part 2 that's hard, and that's a 2d problem.
> 
> > Also, I'm sure
> > there was considerable concern about the speed of the implementation,
> > since GL is used in games and such where the image needs to change
> > rapidly (less of a concern here).
> 
> Not really. 
> 
> 1. Because the GLU tessellator is just a library which uses the
> lower-level GL polygon facilities, you would typically call the GLU
> tessellation functions while constructing a display list. The display
> list would comprise the individual convex polygons, so you wouldn't
> necessarily have to continually re-tessellate the polygon.
> 
> 2. OpenGL isn't just for games. Mesa possibly more so, as its primary
> focus has tended to be with software rendering. In any case, I'm
> fairly sure that they would have settled for a slow tessellator in
> preference to no tessellator.
> 
> 3. Game developers normally circumvent the entire problem by ensuring
> that the source data is built entirely from convex polygons. 
> Furthermore, it's quite common to use just triangles, as even the most
> geometrically illiterate 3d modeller simply cannot create a non-convex
> triangle.
> 
> > Besides, I *know* this problem is solvable (even if I don't have the
> > solution yet).
> 
> I know that it's solvable (SGI have a working GLU 1.2 tessellator). I
> also know that it's not a five-minute job.

If it were a five-minute job, it'd be done already ;)  I'm well aware of
the difficulty and have been researching a solution that's correct and
efficient.

> > The weak solution would be just to rasterize all of
> > the fill areas in a seperate buffer and then "overlay" that on the
> > current display buffer.  I considered that approach for d.area but
> > haven't yet tried it to see if it's faster for large data sets (I
> > assumed not).
> 
> If d.area converts to rasters, the HTMLMAP driver isn't likely to be
> much use.

True, but I wouldn't run d.area for HTMLMAP anyway, since the main point
of d.area is doing filled polygons (though d.vect doesn't currently
handle the hole scenario at all). I think HTMLMAP could be better done
as a module rather than a display target anyway.

> More generally, rasterisation reduces the information content. 
> Presumably there are other vector operations which should be able to
> handle shapes which aren't convex polygons.

Much of this problem is specific to drawing routines for fill.  There
are some elements that would be applicable for union/intersect type
operations (though we need real attribute support before such things
will have much utility).  When I was referring to rasterization, I was
specifically thinking of display.  For hardcopy (map files) keeping
vector is better...

Happy Hacking!
-- 
Eric G. Miller <egm2 at jps.net>

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'