CGAL users discussion list

["Sebastien Loriot (GeometryFactory)" <>]

On 04/08/2014 11:27 AM, Dimitris Tzionas wrote:
> 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?

if you have a movement by large blocks without update in the blocks
you can keep the AABB-trees intact and just change the intersection
predicates to into account the position of the block.

Sebastien.

> Best,
> dimitris
>
>
>
>
> On Tue, Apr 8, 2014 at 8:35 AM, Sebastien Loriot (GeometryFactory)
> <
>  
> <mailto:>>
>  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/
>     <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
>         
> <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
>         <http://doc.cgal.org/latest/Box_intersection_d/index.html#title3>>
>            and
>         this
>         <http://doc.cgal.org/latest/__Box_intersection_d/index.html#__title4
>         <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
>         
> <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
>         <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
>         
> <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
>         
> <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
>     <https://sympa.inria.fr/sympa/info/cgal-discuss>