14 February 2019 at 9 h 23 min #13033
I want to use force fields or anything else but collision models to constraint free objects inside a closed mesh or prevent free objects from penetrating into a curved surface.
Since collision would cause dramatic FPS decrease in a FreeMotionAnimationLoop simulation, I want to avoid using collision models.
But I cannot find any other way to implement it. Does anyone have a solution?
Wong18 February 2019 at 18 h 12 min #13058
you can use some planeforcefields. By using 6 PlaneForceField you can create a virtual cube and it would force your object to remain through spring forces instead of collision forces.
Hugo19 February 2019 at 3 h 52 min #13063
I know what you mean. But I want a general polyhedron and it would deform at runtime, not just a cube.
Is it feasible?
Wong19 February 2019 at 9 h 04 min #13065
I never used it myself, but you could use RepulsiveSpringForceField. It will apply a repulsive force when approaching the points of your general polyhedral mesh.
Would this fit your expectation?
Hugo19 February 2019 at 10 h 30 min #13070
As far as I know, RepulsiveSpringForceField is a particle-to-particle component, not particles-to-particles component. So I do not think it would work.
Can you give me an expamle?
Wong19 February 2019 at 11 h 14 min #13075
Hmm the component does not seem to work that well. I should push some attraction-repulsion forcefield that I have somewhere.
Note that it isn’t compulsory to use the Lagrange constraint approach if you want only performance, with low accuracy. You can also prefer penalty method (using the classic DefaultAnimationLoop), like in the scene examples/Components/collision/TriangleModel.scn19 February 2019 at 19 h 40 min #13083
I remember that, few years ago, some have implemented collisions based on distance field representation to simulate a catheter moving into blood vessels while the vessels moving to follow heart movement. The advantage of this distance field approach was excellent performances of the collision pipeline even with a very big blood vessel model.
If you think this use case is close enough to you I can provide more details about that (but I need to refresh my memory on which distance field collision are available in the open-source of Sofa).20 February 2019 at 2 h 11 min #13085
Yes, I think that is just the kind of the component I am looking for.
Hope you to remember.
Wong22 February 2019 at 4 h 13 min #1310122 February 2019 at 14 h 55 min #13105
You can have Distance Field collisions by activating the SofaDistanceGrid plugin.
I don’t know if this plugin is available in the binary release of Sofa; If this is not the case you will need to re-compile Sofa by activating the plugin in the cmake build process.
When the plugin is on you will be able to execute the example that is in applications/plugins/SofaDistanceGrid/examples/FFDDistanceGridCollisionModel.scn
This example illustrate the use of the FFDDistanceGridCollisionModel component.
This component allows to do collision with Distance Field (a function that returns <0 if inside, 0 on the boundary and 1 outside) or a DistanceGrid (a discreet grid storing a sampled Distance Field). In the example the DistanceGrid can be deformed using a FFD while a second object (a tissue) is interacting with it.
– the distance grid is generated by the FFDDistanceGridCollisionModel at startup from a triangle mesh but we also have an external tool to generate it.
– depending on the complexity of the shape you need to represent you may need to increase the grid resolution (thus consuming a lot more memory).
– in your case you will need to flip the sign of the distance field as you want to “free space” to be the “inside” part. I’m not sure but this can probably be done by flipping the normals of the source mesh.
Hope this helps you.3 March 2019 at 8 h 08 min #13138
Did you made some progress on that topic ?3 March 2019 at 12 h 10 min #13140
I tried to use this plugin, but it is very likely to cause a crash. And the prerequisite that you use SofaDistanceGrid as a collision model of a deformable object is that you use the HexahedronFEMForceField, but sometimes I want to use the TetrahedronFEMForceField.
I give you the scene, you can have a test.
<?xml version="1.0"?> <Node name="root" dt="0.02"> <VisualStyle displayFlags="showBehaviorModels showForceFields" /> <RequiredPlugin name="SofaDistanceGrid" pluginName="SofaDistanceGrid"/> <RequiredPlugin name="SofaSparseSolver" pluginName="SofaSparseSolver"/> <CollisionPipeline /> <BruteForceDetection /> <FreeMotionAnimationLoop/> <GenericConstraintSolver maxIterations="1000" tolerance="0.001"/> <DefaultContactManager response="FrictionContact" responseParams="mu=0.6"/> <MinProximityIntersection alarmDistance="0.8" contactDistance="0.5"/> <Node name="cubeFEM"> <EulerImplicit name="cg_odesolver" printLog="false" rayleighStiffness="0.1" rayleighMass="0.1" /> <SparseLDLSolver name="SolverCube1" /> <MechanicalObject /> <UniformMass vertexMass="0.25" /> <RegularGrid nx="5" ny="5" nz="5" xmin="-3.5" xmax="3.5" ymin="-3.5" ymax="3.5" zmin="-3.5" zmax="3.5" /> <TetrahedronFEMForceField name="FEM" youngModulus="25" poissonRatio="0.3" computeGlobalMatrix="false" updateStiffnessMatrix="false" method="large" /> <LinearSolverConstraintCorrection solverName="SolverCube1"/> <Node name="Visu"> <OglModel name="Visual" fileMesh="mesh/smCube125.obj" color="red" /> <SubsetMapping input="@.." output="@Visual" /> </Node> <Node name="Surf"> <MeshObjLoader name="loader" filename="mesh/smCube125.obj" /> <Mesh src="@loader" /> <MechanicalObject src="@loader" /> <Triangle /> <Line /> <Point /> <SubsetMapping /> </Node> </Node> <Node name="Floor" activated="1"> <OglModel name="FloorV" fileMesh="mesh/floor3.obj" texturename="textures/brushed_metal.bmp" dy="-10" scale="1.75" /> <DistanceGrid fileRigidDistanceGrid="mesh/floor3.obj" scale="1.0" usePoints="0" proximity="0.5" contactStiffness="5.0" contactFriction="0.0" /> </Node> </Node>
Wong4 March 2019 at 10 h 13 min #13143
I’m not surprised there is a lot of bug in the DistanceField plugins because it is not often used. As SOFA is developed by volunteers if you know c++ and have the willing you are welcome to submit patches fixing things (https://github.com/sofa-framework/sofa/pulls), and we would be pleased to help you if needed. If you are not a c++ programmer it would be very helpful if you could open “issues” in our issues tracker so we can keep track on what is wrong and what to fix (when we have time). The issue tracker is there: https://github.com/sofa-framework/sofa/issues
Now about the last question regarding the TetrahedronFEMFOrceField vs HexahedronFEMforceField. If the component does not support TetrahedronFEMFOrceFied it shouldn’t be too hard to implement such behavior.
I have not looked at the code but I thinks that the only requirement is the ability to create a map function transfromating the un-deformed space to the deformed one. HexaderonFEMFF have trilinear interpolation for that…while Tetrahedron have their Bacyentric coordinates. So my suggestion is that if this is important to you I’m sure there is people that would be willing to help you to implement that if you ask for help on github.
- You must be logged in to reply to this topic.