CGAL users discussion list

[Sylvain Pion <>]

(Tauheed, please quote messages correctly when replying,
otherwise it's hard to distinguish your answer).

Tauheed Farhan wrote:
> I meant the algorithm adds additional vertices while computing the delaunay 
> triangulation . they call them infinite vertices which are far more than the 
> actual vertices,
> http://www.cgal.org/Manual/3.2/doc_html/cgal_manual/TriangulationDS_3/Chapter_main.html
> I dont care about these infinite vertices which the algorithm adds, my 
> concern is only with the actual vertices I gave as input.
> The algorithm fills up my 2GB memory after inserting 6 million points. I'm 
> using triangulation_hierarchy_3 class which builds the delaunay incrementaly
> I have a 32bit windows machine and cannot access more than 2GB of main memory per application 

Panagiotis is correct, you misunderstood it.  There is only one infinite 
vertex.
Potential waste can come from infinite cells.  This is usually a reasonable 
percentage
(which doesn't mean we should not try to revisit this choice at some point).

You cannot indeed hope to fit this in virtual memory in a 32bit machine, 
obviously.
The rule of thumb is that the 3D Delaunay triangulation takes about 300 bytes
per point in 32bit, and 500 bytes in 64bit.
So for 200M points it will take about 100GB of memory (64bit needed anyway).

> If i understood you correctly you are suggesting I do the delaunay triangulation on partitions of data that can fit in memory and swap the result of delaunay 
> in and out of memory. how would I stitch the results of delaunay triangulation of different partitions together if I follow this path?.
>  I'm not sure if i fully understood when u mentioned the local swap friendly 
> order

If you really need to stick to 32bit, you will need to manage the parts that
are in memory at a given time yourself.  This is not easy...

--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/