CGAL users discussion list

[Tauheed Farhan <>]

thank for clearing that up, yes indeed you are right there is only 1 infinite 
vertex and many infinite cells.

for the time being im stuck with 32bit processor so thats a problem. I wanted 
an out of core implementation of Delaunay to get my problem solved.

indeed doing that my self is quite hard, to come up with a procedure to 
partition the data points and swap them in and out of memory and stitching 
them together. 

Anyways im currently trying Martin Isenburg streaming delaunay implementation 
it looks very promising I would post my experiences as soon as I get it done,

Thanks for all the help, If any still has any suggestions do let me know.

Many thanks :)


________________________________________
From: Sylvain Pion 
[]
Sent: 08 January 2010 10:11
To: 

Subject: Re: [cgal-discuss] Scalable Delaunay Triangulation 3D

(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/

--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://lists-sop.inria.fr/wws/info/cgal-discuss