RE: [gts-general] gts delaunay performance

[Gary R. V. S. <g.r...@wo...>]

I haven't looked at GTS's Delaunay code at all, so take what I say with a
grain of salt.  I suspect this is probably due to the algorithm used rather
than any compliation or implementation issues.  The Delaunay algorithm in
GTS is an incremental one (you can add and remove sites dynamically), and
these unfortunately tend to be less time-efficient than non-incremental ones
where you give it the whole point set and let 'er rip.

Not to turn you away from GTS, but if all you're doing is 2-D Delaunay, and
you don't need incremental insertion or deletion, you might want to take a
look at QHull (http://www.geom.umn.edu/software/qhull/) or Triangle
(http://www.cs.cmu.edu/~quake/triangle.html).  QHull is fairly actively
maintained, don't know much about Triangle, but I do know both seem to be
well-respected.

> -----Original Message-----
> From: gts...@li...
> [mailto:gts...@li...]On Behalf Of Charles
> Werner
> Sent: Friday, June 15, 2001 4:36 AM
> To: gts...@li...
> Subject: [gts-general] gts delaunay performance
>
>
> I am working with triangulations of large data sets > 500000
> points. Consequently speed is
> an important criterium.  When I run the delaunay program in the
> test directory the speed
> for 10000 points is about 15 seconds on a PII 450 Mhz machine
> running Linux. This is an order
> of magnitude slower than I had expected.  Is there some way to
> speed this up with GTS?
> I used the normal compilaton flags generated by the configure script
>
> Thanks
>
> Dr. Charles L. Werner
> Gamma Remote Sensing AG
> Thunstrasse 130
> CH-3110 Muri b. Bern, Switzerland
>
> Tel: +41 31 951.7005
> FAX: +41 31 951.7008
> http://www.gamma-rs.ch
>
>
> _______________________________________________
> Gts-general mailing list
> Gts...@li...
> http://lists.sourceforge.net/lists/listinfo/gts-general
>