CGAL users discussion list

[Philipp Moeller <>]

Asher Kamiraze 
<>
 writes:

> Thank you Philipp for your answer. I agree with your slicing idea, but it
> appears that replacing my Custom_Triangle_3 with the custom primitve as
> described in
> http://doc.cgal.org/latest/AABB_tree/AABB_tree_2AABB_custom_example_8cpp-example.htmldrops
> the same problem. Note that I use VS2010 64 + CGAL 4.2.

By "the same problem" you mean that extra data in My_triangle is not
properly preserved? That sounds very much like it shouldn't happen. I
can have a look at it this week to see what is going on.

>
> I am working on a minimal sample which reproduces the problem, but have to
> write it from scratch with IO from my applications. Once done, I will post
> it on the list with test data.
>
> You also suggest me to check how the object is constructed. Should I track
> in debug its insertion in the AABB tree to see what exactly happen?
>
> Best regards,
>
> Asher K
>
>
>
>
>>
>> 2013/12/9 Philipp Moeller 
>> <>
>>
>>> Asher Kamiraze 
>>> <>
>>>  writes:
>>>
>>> > Hi all,
>>> >
>>> > I am currently facing a problem with AABB Tree. I have defined my own
>>> > triangle class (because I need to store an integer for each triangle) :
>>> >
>>> > typedef CGAL::Simple_cartesian<double> Simple_Cartesian;
>>> > typedef Simple_Cartesian::Triangle_3   Simple_Triangle_3;
>>> >
>>> > class CustomTriangle_3 : public Simple_Triangle_3
>>> > {
>>> > public:
>>> >     Simple_Cartesian::Vector_3 _normal;
>>> >     Arr::Face_handle _handle; // is an int
>>> >
>>> >     CustomTriangle_3(Simple_Point_3& a, Simple_Point_3& b,
>>> Simple_Point_3&
>>> > c) : Simple_Triangle_3(a,b,c) { _handle = -1; _normal =
>>> > CGAL::unit_normal(a,b,c); }
>>> >     CustomTriangle_3() : Simple_Triangle_3() { _handle = -1; }
>>> > };
>>> >
>>> > I then build a std::list of CustomTriangle_3 and insert them in an AABB
>>> > tree:
>>> >
>>> > typedef std::list<CustomTriangle_3>::iterator                  Iterator;
>>> > typedef CGAL::AABB_triangle_primitive<Simple_Cartesian,Iterator>
>>> > TrianglePrimitive;
>>> > typedef CGAL::AABB_traits<Simple_Cartesian, TrianglePrimitive>
>>> > AABB_triangle_traits;
>>> > typedef CGAL::AABB_tree<AABB_triangle_traits>                    Tree;
>>> > typedef Tree::Object_and_primitive_id
>>> > Object_and_primitive_id;
>>> > typedef Tree::Point_and_primitive_id
>>> > Point_and_primitive_id;
>>> > typedef Tree::Primitive_id
>>> > Primitive_id;
>>> >
>>> > std::list<CustomTriangle_3> triangles;
>>> > // some code to build CustomTriangle_3
>>> > _tree.insert(triangles.begin(),triangles.end());
>>> > _tree.build();
>>> > _tree.accelerate_distance_queries();
>>> >
>>> > _tree is a class member of type Tree.
>>> >
>>> > For each created triangle, I set its _handle member to a valid value (a
>>> > positive integer).
>>> >
>>> > Later, in an other method, I query the _tree:
>>> >
>>> > if ( _tree.do_intersect(query) )
>>> > {
>>> >                 std::vector<Primitive_id> intersectedPrimitives;
>>> >                 _tree.all_intersected_primitives(query,
>>> > std::back_inserter(intersectedPrimitives));
>>> >
>>> >                 //for(std::vector<Primitive_id>::iterator
>>> > it=intersectedPrimitives.begin();it!=intersectedPrimitives.end();++it)
>>> >                 for(unsigned int
>>> gh=0;gh<intersectedPrimitives.size();++gh)
>>> >
>>> > _facetsToPoints[intersectedPrimitives[gh]->_handle].push_back(
>>> > _points[i][j] );
>>> >                     //_facetsToPoints[(*it)->_handle].push_back(
>>> > _points[i][j] );
>>> > }
>>> >
>>> > This is where the problem occurs: when I try to access
>>> > intersectedPrimitives[gh]->_handle, I get an inconsistent handle. If I
>>> run
>>> > the program in debug mode, I got an assertion:
>>> >
>>> > Expression: list iterator not dereferencable
>>> >
>>> > At the first all_intersected_primitves query, intersectedPrimitives
>>> > contains 3 elements, all inconsistent (bad _handle and normal). I am
>>> > wondering what I am doing wrong, and hope you could help tracking the
>>> > problem.
>>>
>>> This sounds a lot like slicing is happening somewhere (e.g. an object of
>>> type A is constructed from an object of type B which inherits of A and
>>> all the extra information of B is lost). Could you check how the object
>>> is constructed and maybe attach a complete, minimal test-case to
>>> reproduce the issue?
>>>
>>
>>

-- 
Philipp Moeller 
GeometryFactory