[Hugo]

Hi @atefe

Using XML, you can use the existing code of SOFA, i.e. build simulations with existing components, define their parameters for the models (e.g. stiffnesses, mass) and the numerical settings (e.g. time steps, collision info etc).

However, if you want to implement new models, change governing equations, you need to: either write new C++ classes or do it through the SofaPython3 plugin. However, the latter is still in alpha phase yet. A stable version should be released in January, with SOFA v20.12.

For dynamic topology changes, this is not directly feasible in SOFA. But the API is there to implement it.

Best wishes,

Hugo

[Hugo]

Hi @yupeng

As I said earlier, setting a DiscreteIntersection in your scene will allow you to use collision on Tets. But you need to add in your collision node, a TetrahedronCollisionModel.

Example of a TetrahedronCollisionModel:

<?xml version="1.0" ?>
<Node name="lroot" gravity="0 -9.81 0" dt="0.02">
    <RequiredPlugin name="SofaOpenglVisual"/>
    <DefaultPipeline name="CollisionPipeline" verbose="0" />
    <BruteForceDetection name="N2" />
    <DefaultContactManager name="collision response" response="default" />
    <DiscreteIntersection/>

    <MeshObjLoader name="LiverSurface" filename="mesh/liver-smooth.obj" />

    <Node name="Liver" gravity="0 -9.81 0">
        <EulerImplicitSolver name="cg_odesolver"   rayleighStiffness="0.1" rayleighMass="0.1" />
        <CGLinearSolver name="linear solver" iterations="25" tolerance="1e-09" threshold="1e-09" />
        <MeshGmshLoader name="meshLoader" filename="mesh/liver.msh" />
        <TetrahedronSetTopologyContainer name="topo" src="@meshLoader" />
        <MechanicalObject name="dofs" src="@meshLoader" />
        <TetrahedronSetGeometryAlgorithms template="Vec3d" name="GeomAlgo" />
        <DiagonalMass  name="computed using mass density" massDensity="1" />
        <TetrahedralCorotationalFEMForceField template="Vec3d" name="FEM" method="large" poissonRatio="0.3" youngModulus="3000" computeGlobalMatrix="0" />
        <FixedConstraint  name="FixedConstraint" indices="3 39 64" />
        <Node name="Visu" tags="Visual" gravity="0 -9.81 0">
            <OglModel  name="VisualModel" src="@../../LiverSurface" />
            <BarycentricMapping name="visual mapping" input="@../dofs" output="@VisualModel" />
        </Node>
        <Node name="Surf" gravity="0 -9.81 0">
            <TetrahedronSetTopologyContainer name="topo" src="@../meshLoader" />
            <MechanicalObject name="spheres" />
            <TetrahedronCollisionModel name="CollisionModel" />
            <IdentityMapping name="sphere mapping" input="@../dofs" output="@spheres" />
        </Node>
    </Node>
</Node>

I hope this helps.
Best wishes,

Hugo

[Hugo]

Ola @jjcasmar

Sorry for keeping you waiting last two weeks.

kFactor is indeed not straightforward to understand. It’s a good point.
kFactor is defined in the MechanicalParams. These are set by the ODESolver (integration scheme) when writing:

matrix = MechanicalMatrix(mFactor, bFactor, kFactor);

For instance, for EulerImplicitSolver we have:

matrix = MechanicalMatrix(1+tr*h*f_rayleighMass.getValue(),-tr*h,-tr*h*(h+f_rayleighStiffness.getValue()));

In this case:
kFactor = -tr * h * (h+f_rayleighStiffness.getValue())
where h=dt

This kFactor is therefore used in implicit schemes, and it must be applied in the addDForce and addKToMatrix, when the implicit part of forces are applied.

Could reformulate your last point?
I am not sure to get where lies the lack of clarity.

Finally, I profit from this post to thank you directly for your strong activity around SOFA! Good to have you.

Hugo

PS: it would great to hear from your work at the SOFA Symposium in 3 weeks!

[Hugo]

Hi @amackeith

The friction built by default in SOFA is indeed isotropic.

I could ask to the teams working on such collision/friction topics, how could an anisotropic friction be implemented.
Sounds like a very interesting development.

Best wishes,

Hugo

[Hugo]

Hi @shan

Are you referring the scene step3.pyscn in the “FirstStep” tutorial of SoftRobots? When running this scene on my computer, I do not receive any error.

What is your SOFA version please?
Best wishes.

Hugo

[Hugo]

Hi @shan

Thank you for granting the access. I am able to run your scene.
The data “indices” means the indices of the degrees of freedom (nodes) of your deformable object which will be affected by the rigidification.
The data “frames” corresponds to a list containing the quaternion (position + orientation) of all rigid frames: [[rx,ry,rz], [qx,qy,qz,w]]

Let me know it this clarifies your point.
Regarding the global understanding of SOFA, do you have some more specific questions so that I can answer accurately?

Best wishes,

Hugo

[Hugo]

Hi @fabianvargas

I am not sure to understand whether you are facing a problem or not.
For your information a detailed reply regarding boost was made here.

I hope this helps. If not, please do not hesitate to post a new question.
Best wishes,

Hugo

[Hugo]

Further to the analysis of your problem here are the conclusion:

• it seems the CMake variable SOFA_WITH_DEPRECATED_COMPONENTS seemed not defined, it’s strange cause it should be the case in the v20.06 sources
• then you had a local change in the file FindPackageHandleStandardArgs.cmake
• now, you need to install boost as stated in the doc and SOFA will be properly compiled

Best wishes,

Hugo

[Hugo]

To understand how a rigidification works, you can also check the example: examples/Components/animationloop/MechanicalMatrixMapper.pyscn

Best

Hugo

[Hugo]

Hi @shan

I requested access to your mesh to test the scene.

Regarding your last question: the way the scene is created here is a bit contra-intuitive. First, all sub-nodes are created. Finally they are added in the simulation (as child node of the root node). This root node is the starting point of the simulation, and this is where the solvers (integration scheme and linear solver) are defined in this case.

Does this help?
Best wishes,

Hugo

[Hugo]

Dear @haithamhussien

Welcome on the forum, it is a place for both naive and advanced questions. So no need to apologize.

Repost from #15863 : Depending on the type of animation loop you are using, I would have two main solutions:
– the most appropriate constraint to attach physically two objects would be the BilateralInteractionConstraint (requiring a FreeMotionAnimationLoop)
– the second would be the AttachConstraint, a project constraint ensuring that at the end of the time step, the desired points of both objects are in the same location.

You could also set StiffSprings between your objects, but in this third solution would not ensure the exact connection at each time step.

Anyway, you connect two objects they also need to have the same DOFs (Vec3d/Rigid..). If one object is deformable while the other is rigid, you might have to create a dedicated subnode to connect the two models.

Do not hesitate to take a look at the associated scene examples:
– examples/Components/constraint/BilateralInteractionConstraint.scn
– examples/Components/constraint/AttachConstraint.scn
– examples/Components/forcefield/StiffSpringForceField.scn

I hope this helps.
Best wishes,

Hugo

[Hugo]

Dear @jacqueline

Welcome on the SOFA forum and my apologies for the answer delay!
The warning you are having comes from the fact that in SOFA image formats are not supported by default. To support bpm, png etc, you need to activate the CIMG plugin.

Let me know if this helps.

Hugo

PS: important notice, the SofaPython3 plugin is still in alpha version. Use it with care and do not hesitate to report any issue. Thank you for your understanding.

[Hugo]

Hi @mckysd5

Just a curious question why do you need to have a scene in C++?

If you need this, then you will have to build your scene (adding components etc) and init, and run yourself the simulation as it is done in the Main.cpp of runSofa.

Best

Hugo

[Hugo]

I close this topic since two other topics where open:
here
and here.

Hugo

[Hugo]

Yes and you can also take a look at the doc page : Create your scene in C++

I let you close the topic if you’re fine with this. Keep us posted about your progresses.

Best,

Hugo

[Hugo]

As I said in my previous message, you might have to go for the master branch or wait for the v20.12 (not so far away !). The automatic reload of a mesh when changing the filename has been introduced in #1408. Until this PR, MeshLoader was a passive class in the scene.

I hope this helps.

Hugo

[Hugo]

Which version of SOFA are you using?

[Hugo]

Dear @twxu,

Strange, are you sure of having python2.7 ?
Could you try to load manually the SofaPython plugin from the PluginManager (Edit->PluginManager) ?

best,

Hugo

[Hugo]

Hi @mckysd5

Do not be sorry for asking, never be. Yes you can. Such components in SOFA are called Engines. You can check out – as an example – the one called TransformEngine: C++ code

Best wishes,

Hugo

[Hugo]

Hi @zahra

I think you will never succeed to get a different filename (here filename being a string variable) by writing this:

self.Cylinder.getObject('loader').findData('filename').value='filename'  

But rather:

self.Cylinder.getObject('loader').findData('filename').value=filename

Let us know if it helps.
Hugo

[Hugo]

Hi @mckysd5

To improve my answer could you tell me which part of my reply was unclear to you?

Best

Hugo

[Hugo]

Ahah @shahramshokouhfar, never thought about de-activating this.
I would guess that de-activating this line in InteractiveCamera could work.

Let me know if it does the job.

Hugo

[Hugo]

Hey @zahra !

First of all, for a proper update of the GmshLoader, you might have to use the master branch of SOFA. Current work are ongoing on building a robust architecture for component updates. (If you want to know more, do not hesitate to join the SOFA Symposium and Technical Committee !)

Anyway, in python, you would just need to access and replace the Data field filename in your python function.

myLoaderPtr.filename="my_new_filename"

If you share with us a simplified version of your scene I could give you a more relevant example. Best,

Hugo

[Hugo]

Hi @mckysd5 and welcome !

As is, using XML scripting this would not be feasible (static scene description). Python is the easiest way to go. An alternative if you need one would be to implement a C++ component (derivated from a TransformEngine) which would have a Data connected to the Geomagic button, which would apply a rotation if pressed and cancel it when released.

I hope this helps.

Best wishes,

Hugo

[Hugo]

Hey @antonio-8196
Let me poke you for you an expert: @jnbrunet could you please take a look to help Antonio in its use of SofaPython3 ? Thanks +++

Best

Hugo

[Author]

Posts