CGAL users discussion list

[Dimitris Tzionas <>]

Hi Sebastien,

thank you very much for your link and the information!

Although I found some tools from UNC, I didn't find this extensive list. Good to know this!

I decided to go with CGAL because of the documentation, the community and the prospects of further future use, but these tools are probably a bit more specialized.

So yesterday I had a first working prototype with CGAL, but my way is exactly what you mention.

My object is articulated and moving, so I'm recomputing the AABB tree at every step.

I'm not sure if there is a really optimal solution for my case, as the mesh deforms as a result of a tracking pipeline, so it's not an animation of more predictable part-movements.

A tool that aids the recomputation of the tree based on just the position-proximity of the triangles before/after the transformation could be helpful (though my application is not real time) but there are no motion dynamics that make things even more predictable.

Does anyone have any useful hint (even non-optimized) for this recomputation?

Best,

dimitris

On Tue, Apr 8, 2014 at 8:35 AM, Sebastien Loriot (GeometryFactory) <> wrote:

Just to mention that CGAL does not provide tools that are optimized if there is no static object (i.e. if you need to recompute the AABB tree
at each iteration and you have a lot of iterations).

You might want to have a look at what they are doing at UNC Chapel Hill:

http://gamma.cs.unc.edu/research/collision/

Sebastien.

On 04/07/2014 11:45 AM, dim_tz wrote:

I would like to have a collision detection module in my tracking pipeline,
detecting when two different meshes collide/interpenetrate or if there is a
self-penetration of an articulated mesh. Based on the depth of the
penetration there should be a penalization that combats this phenomenon. I
should get a list of the colliding faces/vertices in order to do so.

After examining several options, I decided to start working with CGAL.

In  this link
<http://stackoverflow.com/questions/7973402/mesh-to-mesh-intersections/7976920#7976920>
there is an interesting answer pointing to some examples. ( this
<http://doc.cgal.org/latest/Box_intersection_d/index.html#title3>   and
this <http://doc.cgal.org/latest/Box_intersection_d/index.html#title4>  ).
The examples use AABBs (Axis-Aligned Bounding Boxes), which is the proposed
way for non-rigid meshes, since a frequent update of them is needed. The
examples are clear for the self-intersection case, but the following are not
very clear to me:

Apart from creating a B.Box for each triangles, I guess that there is no
tree structure created under the hood to speed up the search process. Is it
so? If yes, any hint to do so?
In case of 2 separate meshes, I guess it's not nice to merge all
triangles/boxes in one vector and follow the examples (though it is
mentioned  here
<http://cgal-discuss.949826.n4.nabble.com/How-to-use-AABB-Tree-correctly-td4657967.html>
as a solution, it doesn't sound so elegant). Any hint for a nice practice?
Should one  mix <http://doc.cgal.org/latest/AABB_tree/examples.html>   these
examples, by creating trees of triangles/boxes? Although for the AABB tree
it is mentioned that:

"Note that this component is not suited to the problem of finding all
intersecting pairs of objects. We refer to the component  Intersecting
Sequences of dD Iso-oriented Boxes
<https://doc.cgal.org/4.2/CGAL.CGAL.Intersecting-Sequences-of-dD-Iso-oriented-Boxes/html/index.html#chapterBoxIntersection>
which can find all intersecting pairs of iso-oriented boxes."



--
View this message in context: http://cgal-discuss.949826.n4.nabble.com/CGAL-Mesh-es-intersection-collision-tp4659088.html
Sent from the cgal-discuss mailing list archive at Nabble.com.

--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss