[Scheikl]

Hi @twxu,
oh, yes you are absolutely right.
You can generate that by setting recompute to true.

<PrecomputedConstraintCorrection recompute="true" />

Cheers,
Paul

[Scheikl]

Hi @twxu,
LinearSolverConstraintCorrection is actually a pretty expansive computation, as it solves the linear system at each time step anew.

Could you try the adapted scene as follows?

<root node>
    <FreeMotionAnimationLoop />
    <GenericConstraintSolver />
    <DefaultPipeline />
    <BruteForceDetection name="N2" />
    <MinProximityIntersection />
    <DefaultContactManager response="FrictionContact" />

    <pneunet node>
        <EulerImplicitSolver />
        <CGLinearSolver />
        (load mesh, mechanical object, etc.)
        <PrecomputedConstraintCorrection />
    </node>

    <cylinder node>
        <EulerImplicitSolver />
        <CGLinearSolver />
        (load mesh, mechanical object, etc.)
        <PrecomputedConstraintCorrection />
    </node>
</node>

As long as the model is not changed too much during the simulation (for example by using the CarvingPlugin) that should be fine.

Cheers,
Paul

[Scheikl]

Hi @andrija987,
I actually don’t know how I would approach that with two deformable bodies…

Maybe you could try to adapt the code in the actuated arm of the SoftRobots Plugin.
https://github.com/SofaDefrost/SoftRobots/blob/master/docs/tutorials/Tripod/details/actuatedarm.py

Personally I would try to take that code and add the deformable objects under the Rigid3 objects in ServoArm and ServoBody and map them to the Rigid3 objects.
So basically for your scene try to make Input_port1 a child of pointCon1 and not the other way around.
But I am not sure how to properly map the “soft” part to the “rigid” part…
Even if that does not work in the way you want it, the scene might give you a good understanding of how the components in the ArticulatedSystemMapping work.
Exploring a bit in the Scene Tree of the GUI helps a lot.

Let me know if that worked. 🙂

Cheers,
Paul

[Scheikl]

Hi @andrija987,
no worries. 🙂

The beam part should not be necessary.
As long as you have some Rigid3 objects it should work fine.
I can highly recommend the Tutorials in the SoftRobots Plugin.
For ArticulatedSystemMapping this one should be quite helpful:
https://github.com/SofaDefrost/SoftRobots/blob/master/docs/tutorials/Tripod/details/s90servo.py

Sure! I would be happy to have a look at the code.

Cheers,
Paul

[Scheikl]

Hi @sukhraj,
happy new year!

Finding colliding elements between two specific collision models can be achieved with a ContactListener object: https://github.com/sofa-framework/sofa/blob/master/SofaKernel/modules/SofaBaseCollision/src/SofaBaseCollision/ContactListener.h

You can add that to your Scene with

listener = scene_node.addObject(
    "ContactListener",
    collisionModel1=node1.LineCollisionModel.getLinkPath(),
    collisionModel2=node2.innerCollision.LineCollisionModel.getLinkPath(),
)

as an example in SofaPython3.

I would be very interested in any solution you come up with for the rupturing part!

Cheers,
Paul

[Scheikl]

Solved in https://github.com/sofa-framework/SofaPython3/pull/78 🙂

[Scheikl]

Hi @jnbrunet,
No worries!

Thanks, have a nice holiday! 🙂

Cheers,
Paul

[Scheikl]

Hi @jnbrunet,
sorry for the late reply!

Oh okay, that makes sense.

Would a scene with default meshes from sofa/share be okay?
https://cloud.ipr.kit.edu/s/STwn3oAHNn4dnnG

Cheers,
Paul

[Scheikl]

Hey @hugo,
no, the topic is still unsolved. 🙁

If anyone has an idea how to solve/avoid this issue, I would be happy to try it out and report on the results.

Cheers,
Paul

[Scheikl]

Hi Peter,
sadly I don’t have access to a windows computer, so I can’t really help you more on this.

Cheers,
Paul

[Scheikl]

Hi Peter,
I just realized I did not catch that you are working with the windows version of SOFA.
There should be a SofaPython.lib inside of \lib.

Cheers,
Paul

[Scheikl]

Hi Peter,
the extension (py) not handled is usually caused by SOFA not finding the correct plugin to handle python files.

When starting SOFA (runSofa in /bin), go to Edit->Plugin Manager and make sure “SofaPython” is listed as a plugin. If that is not the case, click “Add” and and select libSofaPython.so from /lib.

Let me know if that fixes your problem.

Cheers,
Paul

[Scheikl]

Hi @andrija987,
you are very welcome! 🙂

The topic seems quite fun, let me know how it works out.

Cheers,
Paul

[Scheikl]

Hi @andrija987,
would it be possible for your case to first constrain the motion of the two bodies with a LinearMovementConstraint and then introduce a spring? That would basically do the same thing that you are describing, right?

There es an example scene you could use as a starting point:
https://github.com/sofa-framework/sofa/blob/4a493466d6be376d325a19bff97b5e4abf571370/examples/Components/constraint/LinearMovementConstraint.scn

Cheers,
Paul

[Scheikl]

Hi @trannguyenle,
I would replace anything Plugin-specific with “dummy code”.

<MeshObjLoader name="meshLoader_2" filename="dt/cube_low_res.obj" scale="3" handleSeams="1" /> for example could be replaced by <MeshObjLoader name="meshLoader_2" filename="mesh/cube.obj" scale="3" handleSeams="1" />

And you could delete things like <IHPDriver Scale="1000" listening="1" permanent="1"/> which is likely part of the plugin, but not necessarily something you need to get a simple scene up and running.

Cheers,
Paul

[Scheikl]

Hi @trannguyenle,
I think you might be interested in this one: https://github.com/sofa-framework/sofa/blob/4a493466d6be376d325a19bff97b5e4abf571370/applications/plugins/Xitact/examples/XitactGrasping.scn

The Xitact part might not be working right now, but the general composition of the scene should be exactly what you are looking for.

Cheers,
Paul

[Scheikl]

Hi @jonny,
alright, I am looking forward to it!

You are very welcome. 🙂

Cheers,
Paul

[Scheikl]

Hi @jacqueline. 🙂

That is a Linker problem.
I fixed that by adding

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$SOFA_ROOT/lib

to my environment (conda in my case). ($SOFA_ROOT should be your build dir. E.g. /home/yourname/sofa/build/v2006)).
Adding it to your .bashrc/.zshrc/… works aswell. 🙂

Cheers,
Paul

[Scheikl]

Hi @jonny,
I’m glad that helped! 🙂

For the deforming floor, you could try setting appropriate flags in the collision model to tell sofa that these models are supposed to move, but not deform.

floorCollis.addObject("MeshTopology", src="@loader")
floorCollis.addObject("MechanicalObject")
floorCollis.addObject("TriangleCollisionModel", simulated="false", moving="true")
floorCollis.addObject("LineCollisionModel", simulated="false", moving="true")
floorCollis.addObject("PointCollisionModel", simulated="false", moving="true")
floorCollis.addObject("RigidMapping")

Sadly I do not have any (successful) experience with any of the Constraints. 😀
But introducing a ForceField was pretty sufficient for my use cases. As @hugo said in the post, it does not ensure, that the points will be at the exact same location. But that really depends on the use-case, right?

Maybe try using BoxStiffSpringForceField. This one will take the indices of both objects from their respective boxes and create springs between them.

[Scheikl]

Hi @jonny,
I just had a look at the files.

My intuition would be to create a MechanicalObject with the Rigid3d template (so you only have to set one position value to move the floor, and not every position for each node. And then use a RigidMapping between this MechanicalObject and your collision and visual models.

###Creating the floor
floor = rootNode.addChild(name)
floor.addObject(
    "MechanicalObject",
    name="mechObject",
    template="Rigid3",
    translation="0 0 -30",
    rotation="90 0 0",
    )

###VisualModel
floorVisu = floor.addChild("VisualModel")
floorVisu.addObject(
    "MeshObjLoader", name="loader", filename="mesh/floor.obj", scale=1
)
floorVisu.addObject("OglModel", name="model", src="@loader", color=[0.8, 0.8, 0.8])
floorVisu.addObject("RigidMapping")

###CollisionModel
floorCollis = floor.addChild("collision")
floorCollis.addObject(
    "MeshObjLoader",
    name="loader",
    filename="mesh/floor.obj",
    triangulate="true",
    scale=1,
    )
floorCollis.addObject("MeshTopology", src="@loader")
floorCollis.addObject("MechanicalObject")
floorCollis.addObject("TriangleCollisionModel",)
floorCollis.addObject("LineCollisionModel")
floorCollis.addObject("PointCollisionModel")
floorCollis.addObject("RigidMapping")

That might speed things up a little. At least for moving the floor.

[Scheikl]

Hi Jonny,
I had a similar problem and the SoftRobots tutorial on the tripod was incredibly helpful.

Have a look at the setupanimation function here:
https://github.com/SofaDefrost/SoftRobots/blob/master/docs/tutorials/Tripod/details/tripodcontroller.py

If you can use the splib, great! If not, you may want to copy out the relevant snippets of code from there. 😉

Cheers,
Paul

[Scheikl]

Hi J-N,
I finally managed to get everything running. There were some weird version mismatches between pybind11, Sofa, SofaPython3, and *drumroll* Qt.

Your example works perfectly fine and a marker is created at each time step.

Thanks again for the help!

Cheers,
Paul

[Scheikl]

Hi J-N,
that looks promising, thank you very much! 🙂

[Scheikl]

Quick question on the side: Do you think the second approach is feasible as well?

[Scheikl]

Hi J-N,
aaahh I see.

Unfortunately by SofaPython3 version is too old (it does not feature the initVisual function) and I ran into some dependency errors with Sofa.

I will try to get it working and give you a heads up, once that works.

Thanks a lot for your help!

Cheers,
Paul

[Author]

Posts