CGAL users discussion list

[Rostislav Khlebnikov <>]

Hello,

I have some very weird behavior of the same code on different platforms 
and for different build types.

So basically the code works fine only on one configuration out of four 
for me. It is Release version on Windows (Windows, MSVS 2013, x64, CGAL 
4.4 installed with the CGAL-4.4-Setup.exe installer and then built with 
CMake and MSVS 2013).
The Debug version always returns zero intersections. The code and the 
data are literally the same.

I have also tried to build the Linux version. I used Ubuntu 13.10 x64, 
gcc 4.8.1, libgmp and libmpfr installed using apt-get, and CGAL 4.4 
compiled from source using CMake. The only flag I changed when building 
CGAL and my test application  is adding -std=c++11 - i.e. they are 
compiled with -frounding-math.
Here, none of the versions actually work. The Debug version reports 
incorrect (I mean not even close to the windows ones) results or crashes 
with segfault, and the Release version hangs on building the AABB tree 
if I use my custom iterator or crashes with segfault is I use a simple 
std::list of triangles.

Do you have any hints why this might happen?

Thank you for your help,
   Rostislav.

On 10/08/2014 15:24, Rostislav Khlebnikov wrote:
> Hello Sebastien,
>
> yes, indeed - it is the tree.build() call that makes everything logical.
> Honestly, I just should RTFM better - I thought that 
> accelerate_distance_queries() call was responsible for this, which 
> does no good for intersections anyway and just eats more memory for KD 
> tree.
> So, I reverted to the iterator which returns triangles by value 
> constructing them on-the-fly and set the CGAL::Tag_true as the last 
> template parameter for primitive.
> The test results with are mixed (Isect shows the average over 100 
> all_intersections() calls, timed with QueryPerformanceCounter):
>
> NO CACHE:
> Build tree: 8.97505s
> nConversions: 82950772
> Isect: 2.97875ms
>
> CGAL CACHE:
> Build tree: 8.69819s
> nConversions: 72620628
> Isect: 1.97289ms
>
> WITHIN-ITERATOR CACHE:
> Build tree: 0.647395s
> nConversions: 568938
> Isect: 1.81151ms
>
> Hope this helps,
>    Rostislav.
>
>
> On 10/08/2014 14:39, Sebastien Loriot (GeometryFactory) wrote:
> > On 08/09/2014 05:59 PM, Rostislav Khlebnikov wrote:
> > > Hello again,
> > >
> > > I am just quite curious that the first call to the all_intersections is
> > > very very slow compared to the rest. For example for mesh with about
> > > 500k triangles, the first call takes about 10 seconds, while the all 
> > > the
> > > following ones with the same cutting query take about 3 milliseconds,
> > > giving the difference of 3000 times! Is there some lazy processing 
> > > going
> > > on that are triggered by the first call? Is this normal anyway?
> >
> > Try to call tree.build() before, it is probably the construction of the
> > tree that is happening at the first call.
> >
> > Sebastien.
> >
> > > Additionally, by adding the cached converted triangle as a member of
> > > Triangles_const_iterator, setting the reference template parameter to
> > > default and returning K::Triangle_3 const& from derefence() will speed
> > > up the first 10 times (down to 1 second) and also speed up the
> > > subsequent calls to about 2 milliseconds. It is clear why this happens,
> > > but I just wanted to mention it.
> >
> > Note that the last template parameter of AABB_triangle_primitive can be
> > used to cache the triangle in the primitive. Could you give it a try
> > and confirm it is as fast as your setting?
> >
> > Thanks,
> >
> > Sebastien.
> >
> > > So, if you could answer the questions in the first paragraph - that
> > > would be absolutely great!
> > >
> > > Thank you,
> > >     Rostislav.
> > >
> > > On 08/08/2014 00:30, Rostislav Khlebnikov wrote:
> > > > Hello Sebastien,
> > > >
> > > > yes, indeed changing the signature of the Triangles_const_iterator to
> > > >
> > > > class Triangles_const_iterator
> > > >     : public boost::iterator_facade<
> > > >       Triangles_const_iterator
> > > >     , K::Triangle_3 const           // Value
> > > >     , boost::forward_traversal_tag  // CategoryOrTraversal
> > > >     , *K::Triangle_3*
> > > >     >
> > > >
> > > > helped resolving the issue. Just writing this to say thanks to you and
> > > > perhaps help anyone looking into similar problem.
> > > >
> > > > Thanks again,
> > > >   Rostislav.
> > > >
> > > > PS: still weird that it worked in release :)
> > > >
> > > > On 07/08/2014 23:33, Sebastien Loriot (GeometryFactory) wrote:
> > > > > Thanks for the minimal reproducible example!
> > > > >
> > > > > Actually, if you read again the doc of boost::iterator_facade
> > > > > you'll see you're using the default for reference, which is
> > > > > value&. In your case, reference should be value (Triangle is a
> > > > > temporary).
> > > > >
> > > > > Sebastien.
> > > > >
> > > > > On 08/07/2014 11:14 PM, Rostislav Khlebnikov wrote:
> > > > > > Hi everyone,
> > > > > >
> > > > > > I'm using AABB_tree to compute intersections of a VTK poly data 
> > > > > > with a
> > > > > > plane. When I just convert the triangles from VTK to CGAL and store
> > > > > > them
> > > > > > in std list, everything works fine. However, I would like to reduce
> > > > > > storage requirements by creating a triangle iterator that 
> > > > > > iterates over
> > > > > > the VTK triangle data.
> > > > > > Code in main.cpp here shows how I do it http://pastebin.com/kNLQevXV
> > > > > > <http://pastebin.com/sKPFHTT2>
> > > > > >
> > > > > > In Release version everything works fine, but in Debug version -
> > > > > > intersections are never found! (Funnily enough it's a debug version
> > > > > > that
> > > > > > fails). I tried finding the problem - but I don't seem to understand
> > > > > > it.
> > > > > > What I found is that when CGAL uses the kernel to convert from
> > > > > > Triangle_3 to TriangleC3 with rep() and then uses this TriangleC3's
> > > > > > vertex() method on line 1909 in function_objects.h, the TriangleC3
> > > > > > 'base' variable becomes corrupted during get(base) call at line 
> > > > > > 94 in
> > > > > > Triangle_3.h (i.e. correct coordinates are overwritten in what 
> > > > > > seems to
> > > > > > be stack initialization in function call when I looked at 
> > > > > > disassembly).
> > > > > >
> > > > > > Is it something wrong that I do with my custom iterator? Or perhaps
> > > > > > it's
> > > > > > a bug in VS2013 compiler (I saw some bug reports regarding stack
> > > > > > corruption for VS2012 such as this
> > > > > > <http://stackoverflow.com/questions/11000798/structure-parameter-corrupted-on-function-call>, 
> > > > > >
> > > > > >
> > > > > > so perhaps it's not completely resolved).
> > > > > >
> > > > > > I attached all the code, input files and cmake file, so if 
> > > > > > someone who
> > > > > > has VTK and CGAL could quitckly test it on their platform. For me 
> > > > > > the
> > > > > > release version returns 54 intersections and debug - 0.
> > > > > >
> > > > > > Thank you in advance,
> > > > > >     Rostislav.
> > > > > >
> > > > > > CGAL installation info:
> > > > > > Windows 8.1, MSVS 2013, x64
> > > > > > CGAL 4.4 installed with the CGAL-4.4-Setup.exe installer and then
> > > > > > built
> > > > > > with CMake and MSVS 2013.