Forum Replies Created
-
Posts
-
Dear AndreaOT,
Each collision model such as TTriangleModel (for instance) has a “group” property. This property actually represents the collision group of the collision model as an integer. In your case, you need to assign a different collision group to your object A and object B, because the collision detection is not performed between objects which are not in the same collision group.
Hope it helps.
Dear @zahra,
Thank you very much for your reply. Your way in explaining is very educative to me.
You welcome.
The reason for using “surface_fine” part in my code just is to extract the surface of the tissue, but I do not want it to have a real skin. If I add mechanicalObject, TriangularFEMForceField and TTriangleModel to the surface_fine node, it means that the tissue has a skin on it.
I think there is a misunderstanding out there. In physics simulation, it is important to differenciate:
- the collision detection stage which notifies the emerging interaction between the 2 objects and outputs inter-penetration information called collision response.
- the contact solving stage which uses the collision response as input in order to apply a motion correction to avoid inter-penetration while eventually considering another physical parameters like friction.
In SOFA, TTriangleModel is a component which is only used for the “narrow-phase” of the collision detection stage. The correction forces, which result from the contact solving stage (or constraint correction stage in our case), will be applied on the points of the mesh (which correspond to the degrees of freedom of your tissue) regardless of the kind of collision model(s) you use, in order to rectify the motion of the object. Using TTriangleModel, TPointModel or TLineModel will only have a slight impact on the collision response.
From this explanation, using the mentionned combinaison MechanicalObject, TriangularFEMForceField, and TTriangleModel does not means your object have a real skin. In this configuration, your tissue is a discretized surface like you wish. TTriangleModel does not add a shell around the surface if it is what you think. The same logic applies for the MechanicalObject, the latter will only contains information about the points belonging to the discretized surface. Besides, TTriangleFEMForceField manages the deformation of your object knowing its elements are triangles. The volume of the object and its internal forces are not considered unlike the use of tetraedra elements. So for me, using triangles like you do is completely appropriate to simulate your tissue surface. I don’t see any issue but maybe there is something I didn’t catch in your scenario.
If I do not add them, there wouldn’t be any friction, right? Is there any way I can solve this issue?
Actually, in SOFA, each point of your model have an associated friction coefficient. Fortunately, in your setup, all your individual coefficients are set on the same hard value (mu=0.9) which simplify the simulation. As I said above, the correction forces will be applied on the points of your mesh, even if your mesh is a no-closed mesh. So normally, friction will be considered in this configuration.
Hope it helps.
Best,
Antonin.
Dear @zahra,
In your python file scene, you have to remove the DefaultContactManager at line 22. The component CollisionResponse at line 24 is its substitute.
https://gist.github.com/zbounik/812ba1e8accbe8b66ea8b79c08048e2c#file-liversurfacetest-py-L22
Your soft tissue ‘surface_fine’ (node) must owns at least a collision model like TTriangleModel and a TriangularFEMForceField in order to take into account the weight of your object and its elastic properties. As your attempt, you could write:
surface_fine.createObject('TriangularFEMForceField', name='triangularFEMFF5', template='Vec3d', poissonRatio='0.3', youngModulus='60') surface_fine.createObject('TTriangleModel', name='tTriangleModel15', template='Vec3d')In addition, your tissue must owns a MechanicalObject which will contains the positions and velocities associated to the degrees of freedom of your tissue’s triangular mesh. More importantly, it will contains the displacements resulting from the constraint corrections, that’s why it is required. Moreover, the force fields also act on MechanicalObjects, so your object can’t moves if it does not owns a MechanicalObject.
surface_fine.createObject('MechanicalObject', template='Vec3d')Of course, an UncoupledConstraintCorrection must be added to your soft tissue too.
surface_fine.createObject('UncoupledConstraintCorrection')Hope it helps 😉
Best,
Antonin.Dear @Zahra,
Sorry for the late answer. I saw your python script and I understand why it does not work. In fact, I omitted to give you important details about FrictionContact:
FrictionContact only works when combined with the FreeMotionAnimationLoop component and not DefaultAnimationLoop. To clarify, the contacts are solved through a penalty function when you use DefaultAnimationLoop, whereas FreeMotionAnimationLoop is dedicated to solve the contacts through constraint resolutions.
rootNode.createObject('FreeMotionAnimationLoop')Using FrictionContact means building what we call a Complementarity Problem (CP) which is basically a system of Lagrange constraints. However, it is necessary to explicitly specify a ConstraintSolver into your SOFA scene. The most common choice is the GenericConstraintSolver.
rootNode.createObject('GenericConstraintSolver', maxIt='10000', tolerance='1e-7')To finish, the ConstraintSolver needs to know how to compute the constraint compliance matrix W of the colliding objects and how to apply the correction forces resulting from the constraint resolution. This operation is described by ConstraintCorrection components you have to place into your SOFA scene next to each of your MechanicalObjects. Often, we use UncoupledConstraintCorrection.
... Liver.createObject('UncoupledConstraintCorrection') ... surface_fine.createObject('UncoupledConstraintCorrection')It exists some scene examples about FrictionContact in the folder ‘examples/Components/constraint’ from the SOFA source code. It could helps you.
Additionnally, you may read the SOFA documentation about Lagrange constraints in the case you want to go deeper into the subject : https://www.sofa-framework.org/community/doc/main-principles/constraints/lagrange-constraint/
By the way, CollisionResponse is actually an alias for DefaultContactManager, which can be confusing… Using one or another instanciates the exact same SOFA component 😉
Hope it helps.
Best,
Antonin.Hi @Zahra,
In SOFA, the simulation of friction between objects is based on the Coulomb friction cone: https://scaron.info/teaching/friction-cones.html
In order to take friction into account within your SOFA scene, you’ll have to use a collision response of type ‘FrictionContact’ and specify its friction coefficient ‘mu’. The value of ‘mu’ should be close to 1.0 to avoid your soft tissue to slip along the surface.
Here is the XML syntax:
<CollisionResponse response="FrictionContact" responseParams="mu=0.8"/>And here is the Python syntax:
rootNode.createObject('CollisionResponse', response='FrictionContact', responseParams='mu=0.8')Best,
Antonin.
Hi @xiaojuan,
In SOFA, the component/class which describes the collision pipeline and how the contacts are handled is DefaultPipeline (alias CollisionPipeline). As it is visible in its init() method, the pipeline is very modular and needs additionnal components to be configured:
1 – A component like LocalMinDistance which describes the intersection method
2 – A component like BruteForceDetection which describes the broad phase collision detection
3 – A component which describe the narrow phase collision detection (it could be BruteForceDetection again because this one inherits from both classes BroadPhaseDetection and NarrowPhaseDetection)
4 – A contact manager component like DefaultContactManager (alias CollisionResponse). If you use FreeMotionAnimationLoop instead of DefaultAnimationLoop, the contact manager will construct a set of constraints which constitute the collision response. These constraints are solved thanks to a solver like GenericConstraintSolver then correction forces are applied (through a component like UncoupledConstraintCorrection) to avoid interpenetration between the 2 physical objects ( More information in the documentation: https://www.sofa-framework.org/community/doc/main-principles/constraints/lagrange-constraint/ ).
One important configuration parameter of the contact manager is its attribute ‘response’. The latter describe the constraint system (or complementarity problem) you want to construct when a collision is detected between 2 objects. In the case you want to handle friction, you’ll have to specify a ‘response’ like ‘FrictionContact’. It is also possible to add response-specific parameters like the friction coefficient ‘mu’ using the attribute ‘responseParams’. In case of deformable objects, the bounce force is not explicitly configurable because actually it depends of the elastic properties (Young modulus and Poisson ratio) of the 2 objects.5 – Eventually a collision group manager. When several objects are within the same group, they cannot collide each other.
Hope it helps.
Hello Noura,
I’m wondering if there is a way to exclude certain elements (nodes, edges, faces, etc.) in a mesh object from collision tests without deactivating the collision on the entire object?
If the elements you want to exclude from your collision models are always the same all along the simulation, a quick solution I see could be to split your mesh in 2 parts: one part which contains the elements you want to disable, and the other part the elements you want to keep active during collision detection. So, the latter will be the mesh you use as your collision model.
Otherwise, if the subset of elements you want to exclude from collision is dynamic, you may have to have your own collision detection component. I recommand you to have a look in the method doCollisionDetection from the class DefaultPipeline (which represents the default collision pipeline actually). You’ll probably have to change something about the narrow phase of the collision detection.
Or should this be managed once the collision is detected, by inducing a certain response for example? Any hint?
Indeed, you could also have your own collision response in order to have anti-interpenetration constraints only on the contact pairs (contact points) which are located on a particular subset of elements inside your collision model. But it does not seem appropriate for your needs. I think it is better and easier to change the behavior of the collision detection (narrow phase) in your case.
Hope it helps,
Antonin.
Thank you @hugo (and sorry for the late answer). I tried your solution but the problem is the same (I obtained the same error about GIL). But, I created a classical XML file scene (.scn) containing a PythonScriptController component which is configured to load my python controller. With this setup, when I try to load the XML file scene on C++ side, it works well!
Thanks @Binesh for your suggestion ! Actually I solved my problem because I noticed that using a SubsetMultiMapping generate a topology which is not displayed in the graph. My force field was unable to find it in the first place but it was simply because I called its init() method before insering it in the hierarchy, which is incorrect (My MechanicalObject, SubsetMultiMapping and the force field are dynamically created when a contact between two objects occurs). Now my force field can apply on the generated MechanicalObject.
Hi @Hugo ,
We looked at the SlidingConstraint by opening the mentioned example. Thank you Hugo! It was perfectly what we looked for. Roughly, here is what we made: First, we added a fixed line in the space. Then we added 2 points we attached to our screwdriver using a RigidMapping. Finally, we added 2 SlidingConstaint between the line and the respective created points. The result is a rail along which our screwdriver can slide.
