clash, contact & allowed distance computation

Avatar
Kai Knospe

we would like to use eyeshot for clash computation. we already found all pairs which might contact due to BSphere to BSphere calculation and want to check pair by pair.

currently the collision detection does take too much time for large products and is not giving back distances between meshes.

1

Comments

12 comments
Date Votes
  • Avatar
    Alberto Bencivenni

    Hi Kai,

    Can you elaborate more on:

    1. This kind of computation can be done in a timely manner or mainstream CAD system? If yes, using what options?
    2. What do you mean with "check pair by pair" exactly?

    Thanks.

    0
  • Avatar
    Kai Knospe

    Hi Alberto,

    as you know we are using 3DExperience 2018x (better known as Catia V6) for our Design department having all kinds of interference checks available.

    We also have some Teamcenter Visualization Seats (Mockup licence) with this functionality.

    Now our Viewing User like Manufacturing would also like to use that. Since we are using Eyeshot for them an integration would be great.

    pair by pair means, since we can get all relevant couples (one leaf node against another leaf node) using Boundingspheres is very cheap to calculate, we wanted to check the pairs only, not again a large collection of BR all against all.

    Kai

    0
  • Avatar
    Alberto Bencivenni

    Hi Kai,

    I didn't ask info about your environment but on the Catia clash detection, you are taking as a reference.

    1. Is Catia using BRep or Mesh of triangles?
    2. What option did you specify for Catia clash detection?

    Thanks.

    0
  • Avatar
    Kai Knospe

    Alberto,

    i did not ask for a discussion how others are doing this task or if it makes sense to do so...wondering :-(

    Catia is using cgr, now 3drep so mesh geometry

    default option is clash & contact only

    it is possible to add knowledge rules as well but this is out of scope here

    Kai

     

    0
  • Avatar
    Alberto Bencivenni

    Clash detection is a wide field, we need to compete with the same weapons....

    Nice to know you are using Mesh of triangles even on Catia.

    0
  • Avatar
    Kai Knospe

    once you will have access to our vm ware it might be possible to access catia also, at least together with me in a remote session

    0
  • Avatar
    Martin Walter
    (Edited )

    Hi Kai,

    although I might be wrong (Alberto, please correct me in that case), I'd say, that the current basic collision detection scheme doesn't easily yield data like minimal distances. As far as I know, currently some kind of octree is used for collision detection, probably with SAT(slow if you don't quit on first hit) test or something similar.

    If you need functionality like that, have a look at algorithms like GJK. There are some implementations out there.

    https://gist.github.com/vurtun/29727217c269a2fbf4c0ed9a1d11cb40 (very simple implementation)

    https://github.com/MattiaMontanari/openGJK (openGJK is more or less full-fledged and suitabe for a C# application - but you'd contact the owner to need to get a commercial license for this one).

    https://github.com/kroitor/gjk.c (for a nice explanation)

    While collision detection is quite mainstream, minimal distances between Meshes is not (yet).

    Best regards,
    Martin

    0
  • Avatar
    Melissa Angelini

    Hi Martin,

    Yes, you're right, we use the octree structure inside our CollisionDetection (just for the CollisionCheckType with SubdivisionTree).

    Thanks a lot for the attached documentation.

    I just had a quick look at it and - if I understood well - the GJK algorithm works with convex polyhedron objects only, am I right?

    Unluckily, at the moment we're not able to exploit that into our CollisionDetection, but I saved the documentation for possible future integration into Eyeshot. 

    0
  • Avatar
    Martin Walter
    (Edited )
    Hi Melissa, 
     
    thanks for your reply! Yep,  depending on how you do things internally you would have to subdivide non-convex meshes into convex parts and/or you could use gjk for checks against convex hulls.
     
    I'm not talking about replacing your current collision detection algo. I'm not sure how fast your current collision detection is, right now, but I'd guess that you would suffer performance-wise.
    Being able to do minimal distance queries against Meshes on the other hand... that could really be useful, if you don't support that already(which you don't at the moment, I think).
    Another thing that would be nice in this regard would be to intoduce multiple collision detection methods, that one could just use.
    Or a way to switch between multiple collision detection methods globally, at least.
    From where I'm standing, that should be quite doable, and smaller issues with new cd methods would not be so critical.
     
    But... Actually I wanted to point Kai to implementing stuff like this himself, if he really needs it with high priority.
    0
  • Avatar
    Kai Knospe

    Hi Martin,

    thanks for the Info and Link!

    Currently we are calculating clashes using dassault systemes 3dexperience 18x and coretechnology 3devolution dmuinspector, both in automated nightly batch mode. generally we are fine with this combination of high end products.

    But since we have our own eyeshot driven 3d visualization platform for manufacturing it would be nice to do some "on the fly" calculation right now (without waiting for the next night :) )

    Since we already break down the pairs by first using bsphere to bsphere intersect, than sat for the bboxes we are on the last mile with the meshes.

    For the first step it would be enough not to have the distance information but the intersect true or false between to meshes...any ideas on that?

    Kai

    0
  • Avatar
    Martin Walter
    (Edited )

    Hi Kai,

    you're welcome! :) Well, you could take a look, here: https://github.com/Mszauer/3DCollisions/blob/688f2a557a902cdae6615b5cd2b526c613a2821b/CollisionDetectionSelector/Collisions.cs#L417

    There should be all basic Intersection tests, there. I've never used the above library or really checked the code, but the documentation looks like they knew what they were doing. Documentation: https://gdbooks.gitbooks.io/3dcollisions/content/

    One thing I don't fully understand... If you're implementing the intersection testing yourself, and don't go in the direction of using GJK for minimal distance queries, but for "simple" collision detection, are you aiming for implementing your complete custom collision detection?

    If you want to do this, and be faster than the one Eyeshot provides, you'll probably have to put some work into it.
    Melissa contacted us regarding that subject, and it seems, that Eyeshot collision detection has some recent quite substantial performance improvements. I haven't come round to testing that, though. Maybe you might give this a shot if you haven't already, before going further.
    One thing would certainly be a BVH (segmenting the meshes into an occtree, or something similar) for additional pre-testing before performing triangle/triangle queries.
    Our BVH uses a kind of KD-Tree like sparse OBB-Tree, that splits the triangles so that each triangle is contained in it's subnode, then drilling down to minimal leaf size (based on tri size and num of tris). Additionally we use simplified pre-testing collision meshes and convex hulls, depending on the task / situation. If it makes sense for you, to implement all of that is hard to say for me.

    You could also just use simple BSpheres as your BVH for starters and the work your way up from there.

    We're using C++/CLI and some C for performance reasons, but I doubt, this is a real requirement, nowadays.

    Ah, they have something on that, aswell: https://gdbooks.gitbooks.io/3dcollisions/content/Chapter4/bch_shake.html

    So I suggest to go ahead and have a look! :)

    You might event just want to use the library they provide. If I'm correct the code is public domain, so no strings attached.

    HTHH,
    Martin

     

    0
  • Avatar
    Melissa Angelini

    Hi Martin and Kai,

    Thanks for showing your thoughts and documentations. It is always good to see these exchanges.

    For your references, during the checkMethod OBWithSubdivisionTree, we currently use a kind of OBB-Tree reflecting the Block/BlockReference Hierarchy as BVH of pre-test to break down pairs among leaves entities. Then we intersect the individual octrees for-each entity (chosen to avoid time-consuming that should be needed to maintain and rebuild a unique tree for the entire scene for each transformation step). So we have a kind of Oriented-Octree (oriented with the transformation applied to the leaf entity) on which triangles are subdivided but never cut to fit the sub-nodes.

    We choose to keep triangles also into the middle-nodes (if they don't fit the children nodes) instead of just to the leaves, in order to keep the minimum number of triangles and the lighter memory usage as possible. It seemed a valid choice at that time, but we could reconsider that if it will demonstrate not valid anymore. For this reason, an isotropic triangulation usually works better to get a balanced and optimized tree.

    Unluckily, I'm afraid that Kai already checked the updated CollisionDetection version for SubdivisionTree check mode, since those improvements were already released in the period he asked for this feature (July 2020). We were already in contact indeed about this argument and I added one of his files into our test cases.

    Best regards,

    Melissa

    1

Please sign in to leave a comment.

Didn't find what you were looking for?

New post