CGAL users discussion list

[Peter Hachenberger <>]

On Wed, 2008-01-09 at 04:57 -0600, Gilbert Bernstein wrote:
> Peter,
> 
> I just tried DNDEBUG and it reduced the time to convert the cat from  
> off to nef down to ~30 seconds, which seems like it should make sense.
> 
> So, as the next entry in the never ending story, I just tried to  
> perform the shark union with a much  higher polycount shark model and  
> discovered the following error upon trying to convert the result back  
> from nef to off:
> 
> CGAL error: precondition violation!
> Expr: it1.e_ == it2.e_
> File: /usr/local/include/CGAL/iterator.h
> Line: 563
> Explanation:
> terminate called after throwing an instance of  
> 'CGAL::Precondition_exception'
>    what():  CGAL ERROR: precondition violation!
> Expr: it1.e_ == it2.e_
> File: /usr/local/include/CGAL/iterator.h
> Line: 563

I don't know this error, which is probably because I never use the
filtered kernel (Homogeneous<leda_integer> is most efficient at the
moment). But my first try know would be to look closer at the input
file. Many off-files have features that are pretty hard to handle. There
are facets intersecting one another, empty facets, etc. So, try to
convert the off-file with the example program complex_construction. You
might want to change it a bit in advance, because it does not output the
result. This program will convert the off-file most likely and tell you
whether there were problems with some facets. From that output and the
resulting file you can find out whether there was something wrong with
the off-file.

Warning, this might take 10 minutes.

Peter


> I'm using the following header consistently across all conversion  
> programs and the set operations file:
> 
> #include <CGAL/Exact_predicates_exact_constructions_kernel.h>
> #include <CGAL/Polyhedron_3.h>
> #include <CGAL/IO/Polyhedron_iostream.h>
> #include <CGAL/Nef_polyhedron_3.h>
> #include <CGAL/Nef_3/SNC_indexed_items.h>
> #include <CGAL/IO/Nef_polyhedron_iostream_3.h>
> 
> typedef CGAL::Exact_predicates_exact_constructions_kernel Kernel;
> typedef CGAL::Polyhedron_3<Kernel>  Polyhedron;
> typedef CGAL::SNC_indexed_items Items;
> typedef CGAL::Nef_polyhedron_3<Kernel, Items>  Nef_polyhedron;
> 
> Sorry 'bout this.
> 
> -- Gilbert
> 
> On Jan 9, 2008, at 4:43 AM, Peter Hachenberger wrote:
> 
> 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
> -- 
> You are currently subscribed to cgal-discuss.
> To unsubscribe or access the archives, go to
> https://lists-sop.inria.fr/wws/info/cgal-discuss