CGAL users discussion list

[Peter Hachenberger <>]

Hi Gilbert,

I'm glad that I could help you. It's interesting to know that Gmp and
mpfr make such a difference.

Did you also add the option -DNDEBUG? This might again give you 20-40
seconds.

Peter

On Tue, 2008-01-08 at 23:55 -0600, Gilbert Bernstein wrote:
> Sorry about spamming the list so much here.
> 
> Peter,
> 
>       It seems the problem was the lack of gmp and mpfr. (from what I  
> understand they're mutually dependent inside of CGAL) After  
> installing those and rebuilding CGAL, all my programs worked  
> correctly without changing the code at all.
> 
> It takes me 80 seconds to convert robocat with -O2 set and using the  
> exact_predicates_exact_constructions kernel.  This seems at least  
> within the realm of plausibility now.  Do you have any  
> recommendations on trying to bring this number down closer to 20  
> seconds?  Perhaps a particular Kernel is very well suited?
> 
> -- Gilbert
> 
> 
> On Jan 8, 2008, at 6:03 AM, Peter Hachenberger wrote:
> 
> So, the robocat took less than 20 seconds on my notebook, which has 2
> Ghz with only one Core. So, taking also your other mail into accout, it
> seems that your CGAL installation might miss some important data types
> and is therefore slower than necessary. Maybe the code I gave you in the
> previous mail will not compile, because you don't have Gmp or some
> similar problem.
> 
> Peter
> 
> On Mon, 2008-01-07 at 13:46 -0600, Gilbert Bernstein wrote:
> > Peter,
> >
> > Here is the robocat (3756 vert 7512 tri) model, which I was able to
> > get through in half an hour.  I was running another job along with
> > it, so it may not take that long, though it should take a good while.
> >
> > I also tried a simplified shark model (1007 vert 2010 tri) which I
> > just measured at appx. 2 min to convert on my 1.83 Ghz Core Duo (not
> > Core2) (using only one core I believe)
> >
> > -- Gilbert
> >
> > On Jan 7, 2008, at 6:11 AM, Peter Hachenberger wrote:
> >
> > Hi Gilbert,
> >
> > half an hour is more than I would expect from a model of that size. I
> > have an example file that has about 2/3 of the size of your model and
> > the execution of  handling_double_coordinates takes less than half a
> > minute. So, I'm a bit surprised. Can you please send me the file so  
> > that
> > I can test it.
> >
> > Peter
> >
> > On Mon, 2008-01-07 at 03:47 -0600, Gilbert Bernstein wrote:
> >> It seems I have to apologize for making such a stink here.  It was
> >> probably a false alarm.
> >>
> >> I think I had unreasonable expectations on the speed of the
> >> computation and thought the program had gone into a loop.  I managed
> >> to push a smaller model (3756 vertices 7512 triangles) through the
> >> conversion both ways just now by waiting about half an hour.  I also
> >> know the model in question has some very funky joins between parts
> >> (lots of long, close, sharp polygons) so I'm pretty sure this was
> >> just a matter of patience.  If only I was testing with the teapot.
> >> Then I could make a really awful joke about watched teapots.
> >>
> >> I just ran another model (1007 vert 2010 tri) through just fine, much
> >> faster, so yeah...
> >>
> >> -- Gilbert
> >>
> >> On Jan 7, 2008, at 3:12 AM, Andreas Fabri wrote:
> >>
> >>
> >> Gilbert,
> >>
> >> It might be the best to just post a file that makes problems.
> >> What is your OS/compiler, did you just take the example or
> >> demo program, or write your own program? In the latter case
> >> what kernel did you chooses?
> >>
> >> andreas
> >>
> >>
> >> Gilbert Bernstein wrote:
> >>> Andreas,
> >>>     I'm fairly sure all of the meshes I've tried are triangular
> >>> meshes, (I went back and checked a couple of them (since they're in
> >>> ascii) by eye) so I don't think that's the problem.
> >>> -- Gilbert
> >>> On Jan 7, 2008, at 2:10 AM, Andreas Fabri wrote:
> >>> Hello,
> >>> A typical problem is to have faces which are not triangular,
> >>> and at the same time not coplanar.
> >>> andreas
> >>> Gilbert Bernstein wrote:
> >>>> Hi,
> >>>>     I'm having an awful lot of trouble successfully building Nef
> >>>> Polyhedra from .off input files.  The only model I have
> >>>> successfully translated from .off to a Nef Polyhedron and back is
> >>>> a cube.  I have tried a number of different models, all supposed
> >>>> to be watertight, and which were certified by the
> >>>> Polyhedron_3::is_closed() function.  It certainly may be the case
> >>>> that there was something off (ba dum chh) about these models, but
> >>>> I've reached my point of frustration.  If anyone has any known
> >>>> working examples of importing models into the Nef Polyhedron type,
> >>>> or any suggestions, I would much appreciate the tips.
> >>>> -- Gilbert Bernstein
> >> -- 
> >> You are currently subscribed to cgal-discuss.
> >> To unsubscribe or access the archives, go to
> >> https://lists-sop.inria.fr/wws/info/cgal-discuss
> -- 
> You are currently subscribed to cgal-discuss.
> To unsubscribe or access the archives, go to
> https://lists-sop.inria.fr/wws/info/cgal-discuss