CGAL users discussion list

[Asher Kamiraze <>]

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.html drops the same problem. Note that I use VS2010 64 + CGAL 4.2.

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?