[Noura]

Hi Hugo,

No matter where the torque is applied (on the center of mass or on another point), the proximal extremity of the bone (Node RAF_Proximal in the scene) should be fixed against translation.
In other words, imagine that the bone is mounted to a fixation device at this point (RAF_Proximal) which allows it only to rotate but not to go away.

Hope that it is clear now?

Noura

[Noura]

Hi @Binesh,

Thanks for your comment.
In my current scene, there is no mesh topology node. Do you mean in the “Surface_Radius” Node? If yes, I already tried to set both: once a “FixedConstraint” and then a “PartialFixedConstraint” on the vertex (which has index no 1011). None of these lines:
<FixedConstraint name="fixation_poisition" indices="1011" />
<PartialFixedConstraint name="fixation_poisition" indices="1011" />

has an influence, and the point is still moving!

Even if one of both solution would work (which means restricting the motion of the vertex), I think that it is not the appropriate way because this would constraint the rotation as well which is not what should happen.

Any other suggestions?

Noura

[Noura]

Hi,

Maybe adding <FixedTranslationConstraint template="Rigid3d" /> inside
<Node name="cube" activated="1">
should restrict the translation and allow the rotation? Not sure if this is the proper way to do it.

Noura

[Noura]

Hi Zahra,

Regarding your first question, that line is not important, it’s just an html foramt error which should underline the phrase “In your scene”.
In your scene, if you want to use Python …

For your second question:
First of all try to test your scene without arguments, run:
zahra@zahra-System-Product-Name:~$ /home/zahra/sofa/Sofa17.06/build/bin/runSofa /home/zahra/PhD/python/testpythonsofa/caduceusPython.py
If it works fine, now we come to the next issue: it looks like you are using a wrong character before the argv ‘–’, make sure that it is the minus sign ‘-‘ and you also missed an additional one, try to run:
zahra@zahra-System-Product-Name:~$ /home/zahra/sofa/Sofa17.06/build/bin/runSofa /home/zahra/PhD/python/testpythonsofa/caduceusPython.py --argv “VariableName” valueNumber valueString
this should work fine in case the previous works.
Afterwards, I’m not sure what are you doing with these parameters, if your objective is just to follow the tutorial, so the idea here is that you can pass some variables to your simulation directly when you start your simulation, for example:
runSofa caduceusPython.py --argv “material_stiffness” 5000 rubber
Then you can read these values directly in your python code as explained in the tutorial, For example while you create the scene graph:

    def createGraph(self,rootNode):
	variableName = self.commandLineArguments[1] # Get the name of the varible material_stiffness"
	valueString = self.commandLineArguments[3]  # Get the string value "rubber"
        # rootNode
        rootNode.createObject('VisualStyle', displayFlags='showVisual  ')

So far, you will get “material_stiffness” in the variableName and “rubber” in the valueString. You may then use these variables in the python script.

Hope this helps!

Noura

[Noura]

Hi Eleonora,

As mentioned before, I think that using attach constriants between 2 vertices requires that these 2 vertices be close to each other, optimally they should share the same position (see illustration). Otherwise the connection won’t look good because of the distance gap between the objects.
In my simulation, I managed to get good meshes where objects which should be attached having vertices sharing the exact position. Afterwards, it is possible to use getIndicesInSpace function from the MechanicalObject class to get the indices within an epsilon range. Note that in recent SOFA version – after the date of this post-, a parameter called constraintFactor is added to the AttachConstraint and which should have a value between 0 and 1. This allows loosy/tight attachments as I guess.

Hope that it was helpful!

Best,

Noura

[Noura]

Just to conclude before closing the thread: it looks like gcc 7.3.0 issue. I switched to clang 6.0.0 without any problems.

Noura

[Noura]

Hi Hugo,

I think that searchUp should be called here, as it a BaseObject function.

typename T::SPtr searchUp() const { const BaseContext* context = getContext(); return typename T::SPtr(context->get<T>(BaseContext::SearchUp)); }

I also noticed that this error is gcc dependent:
– using gcc 7.3.0 => compilation error
– using gcc 5.4.0 => compiles fine

Best,

Noura

[Noura]

Yes, I meant the error message you get on the terminal when you type runSofa.
According to the output you posted, everything sounds working fine for me (i.e. You didn’t got any error message and the deprecated constructor seems to be just a warning).
Sorry! I have no clue why you don’t get the default scene running properly.

Noura

Last thing, you asked if you have to install QtCreator. This is not required, but you should have the library (Qt >= 5.5.0) installed on your OS as mentioned in the build tutorial.

[Noura]

Could you share the error message that you get when you run a sample scene or just when you type runSofa ?

[Noura]

Hi Zahra,

” – May the problem be that, cmake says that it “Could NOT find GLUT (missing: GLUT_glut_LIBRARY GLUT_INCLUDE_DIR)”? (It does not seem like an error in cmake).”

To remove the previous error message, verify that you have GLUT installed on your ubuntu.
sudo apt-get install freeglut3-dev

I assume this could be an issue.

Best,

Noura

[Noura]

More precisely, I need some clarification of the parameters d_materialName, d_parameterSet, and d_anisotropySet which should be set in the force field.

Noura

[Noura]

Hi Baymin,

Here you can find a doxygen code documentation of some parts of SOFA
https://www.sofa-framework.org/api/master/sofa/html/index.html

In addition, I would recommend to take a look at SOFA documentation project on GitHub
https://github.com/sofa-framework/doc

Best,

Noura

[Noura]

I include the modified function just in case someone would like to try it.

    virtual bool canCollideWith(CollisionModel* model)
    {
        if (model->getContext() == this->getContext()) // models are in the Node -> is self collision activated?
            return bSelfCollision.getValue();
        else if( this->group.getValue().empty() || model->group.getValue().empty() ) // one model has no group -> always collide
            return true;
        else
        {
            std::set<int>::const_iterator it = group.getValue().begin(), itend = group.getValue().end();
            for( ; it != itend ; ++it )
                if( model->group.getValue().count(*it)>0 ) // both models are included in the same group -> do not collide
                    return true;

            return false;
        }
    }

[Noura]

Hi @Binesh

A quick modification according to your hint in CollisionModel.h seems to change the grouping as desired “Reverse Grouping”.

I didn’t verified enough if this will lead to an odd behavior but for now it’s perfect!

Thanks!

Noura

[Noura]

Hi @wendyarch,

Here is a minimal scene example how to load two obj spheres (a small sphere for the tumor and a big one for the ovary).

<?xml version="1.0"?>
<Node 	 name="root"  gravity="0 0 0"  dt="0.01"  >

     <VisualStyle name="visualStyle1"  displayFlags="showWireframe " />

    <Node name="Big_Sphere" activated="1">
                <MeshObjLoader name="loader" filename="big_sphere_05.obj"/>
                <Mesh src="@loader"/>
                <MechanicalObject  template="Vec3d" name="MO_BigSphere" src="@loader" />
		<UniformMass totalmass="1" />
        	<OglModel name="Visual" fileMesh="big_sphere_05.obj" color="green"  />     
    </Node>

    <Node name="Small_Sphere" activated="1">
                <MeshObjLoader name="loader" filename="small_sphere_05.obj"/>
                <Mesh src="@loader" />
                <MechanicalObject  template="Vec3d" name="MO_smallSphere" src="@loader"  />
		<UniformMass totalmass="0.1" />
        	<OglModel name="Visual_2" fileMesh="small_sphere_05.obj" color="red"/>
                
    </Node>
    
</Node>

You can get the spheres obj files at this link

I’m not sure what do you mean by placing a ball inside the other. You say that you have the obj files of the two meshes, so I suppose that the initial configuration of the 2 meshes are already be in such a way that the small object is inside the bigger one.

Hope this helps!

Noura

[Noura]

It works fine, and makes the scene content more compact.
Thanks Hugo!

Noura

[Noura]

Hi Hugo,

Thanks for the clue that abstract classes are grouped in the framework directory.

It is also interesting to know about the upcoming architecture. Nice project!

Noura

[Noura]

Hi Bam,

your concern about a proper contact surface is relevant. using AttachConstraint is not very intuitive and strongly depends on the contact surface resolution and topology of both objects. I also tried joint springs to connect both objects and the result was not satisfying as well!

In case I could do it in a better way, I’ll consider updating this topic.

Best,

Noura

[Noura]

Thanks Max for this explanation! Yes it helps.

– I see, RigidMapping even works, but it won’t maintain “realistic” deformations.

– In the scene example DeformableOnRigidFrameMapping, the false displacement is suppressed by an opposite one.

– Your suggestion regarding the implementation helps, maybe no mapping is needed at all, and just appropriate attachment can perform well.

I’ll keep you updated.

Noura

[Noura]

Hi Hugo,

object A is a bone and B is a muscle attached to it. The motion of B is derived by the motion of A (this is why I established mapping between them).

At the same time, the muscle should not penetrate the bone when they collide.

I’ll mark this topic as resolved, and start a separate thread concerning the collision when needed.

Thanks,

Noura

[Noura]

Hey Hugo,

Thanks for the hint! Indeed, your suggestion worked fine.

A mapping between object B(deformable) and the centre of mass of object A (rigid) allowed “B” to follow “A” which follows its centre of mass in turn.

<RigidMapping template="Rigid,Vec3d"  name="RM_AB"   input="@objetA_centre_mass/MO_A" output="@objetB/MO_B" />		

However, I realized that this mapping won’t be sufficient for the succeeding step
where the collision with “A” should be detected … The later entails the entire mechanical state vectors with their corresponding topology not only the centre of mass.

The idea was to reduce the computation cost by just moving one particle of “A” instead of the complete positions. Now I think I have to refine the mesh.

Please don’t hesitate to correct me if I’m wrong.

Noura

[Noura]

just to let you know that I looked for another way to do it, and it seems that applyTranslation,applyRotation do the task in a simpler way. I think i found the answer to my question above.

Noura

[Noura]

Exactly! the simulation will be slow and saturates after a while, this is why I worried about the increasing memory size. I placed the load function in the constructor and now it keeps the correct positions size ( My error was because I thought that since the ldr is declared at every simulation step, the positions should not be appended).

As for the TDestType, I agree it must inherit the base class 😉

Concerning the translation, still not correct, but I’ll manage to find out the reason.

Finally, the OglModel, now it is working fine. There was an error in the mapping I used which prevented it from updating correctly according to the correspondent mesh. This is why I was trying to reproduce the same positions change. Now, the behaviour is as it should be.

Thanks again Jean-Nico!

Noura

[Noura]

Hi Jean-Nico,

Yes, your explanation helped me a lot. Thank you!

1- The remark concerning the sofa::component::topology::MeshTopology was on point! I mistaked the type of the “Mesh” component in the scene. I linked the “mesh_link” attribute to a sofa::component::topology::MeshTopology and it works fine.

2- Concerning your remark that the linked object must inherit the Base class, I’m not quite sure about this because both the OGLLink and STLLink in the above code do not, and they are working fine.

Looking at the SingleLink class

class SingleLink : public TLink<TOwnerType,TDestType,TFlags&~BaseLink::FLAG_MULTILINK>

where

template<class TOwnerType, class TDestType, unsigned TFlags>
class TLink : public BaseLink

It isn’t clear enough to me which types TDestType is destinated to. But no problem! I did what I need using the link to the MeshTopology.

Before marking the topic as resolved, I would ask for some hints concerning the odd size values of the d_positions in my second post.

I’ll summarize the problem again:
The “Lunatum.stl” mesh file contains 1732 points.
It is the same value which I obtain using the “mesh_link” when calling the getNbPoints()

However, after the following code

    TMeshSTLLoader* ldr = m_stl_link.get();
    ldr->load();    
    sofa::helper::vector < sofa::defaulttype::Vec< 3, SReal > >	my_vertices;
    my_vertices = ldr->d_positions.getValue();  
    std::cout<<"number of vertices: "<<my_vertices<<std::endl;

I’m expecting that size of my_vertices should be equal the vertices number in the file loaded using the STLLoader(which is 1732) Right?

But, at the first simulation step the size of my_vertices is equal to 3464 which is (1732+1732)
at the second step the the size becomes 5196 which is (3464+1732)
then 6928 ( 5196+1732) and so on …

I should have missed some reinitializing for example? Any idea?

Thanks,

Noura

[Noura]

Here are other connected questions, I put them in the same thread, but in a separate post for the sake of clarity.
I have some wrong behaviour when getting values using links, the problem is illustrated in the following minimal example, and the questions are listed as comments inside the code:

class  MyComponent : public BaseController

{
public:

    SOFA_CLASS(MyComponent, BaseController);
        
	typedef  sofa::core::loader::MeshLoader  TMeshSTLLoader;
    typedef  sofa::component::visualmodel::OglModel TOGLModel;
    typedef  sofa::helper::io::Mesh TMesh;

    typedef sofa::core::objectmodel::SingleLink< MyComponent, TMeshSTLLoader, BaseLink::FLAG_STOREPATH|BaseLink::FLAG_STRONGLINK> STLLink;
    typedef sofa::core::objectmodel::SingleLink< MyComponent, TOGLModel, BaseLink::FLAG_STOREPATH|BaseLink::FLAG_STRONGLINK> OGLLink; 
    typedef sofa::core::objectmodel::SingleLink< MyComponent, TMesh, BaseLink::FLAG_STOREPATH|BaseLink::FLAG_STRONGLINK> MeshLink; 

    OGLLink m_ogl_link;
    STLLink m_stl_link;
    //MeshLink m_mesh_link; 
  
}

MyComponent<DataTypes>::MyComponent():
						   m_stl_link(initLink("stl_link", "desc. of the link")), 
                           m_ogl_link(initLink("ogl_link", "desc. of the link"))
                           /* m_mesh_link(initLink("mesh_link", "desc. of the link")) */
  
{
...
}

template<class DataTypes>
void MyComponent<DataTypes>::updateOnBeginStep(){
	
	if(!m_stl_link.get())
    {
        std::cout << "Error getting link" << std::endl;
        return;
    }
    

    TMeshSTLLoader* ldr = m_stl_link.get();
  
    ldr->load();
    
    sofa::helper::vector < sofa::defaulttype::Vec< 3, SReal > >	my_vertices;
    my_vertices = ldr->d_positions.getValue(); 
    
    // First question concerning the size of the vertices 
    // I noticed that the my_vertices size increases by x(the initial size of the positions in the stl loader) at each updateOnBeginStep. 
    // Should I establish the link to the mesh instead of the the stlLoader? this brings me back to my first post 
    
    std::cout<<"number of vertices: "<<my_vertices<<std::endl;
    
    
    // Second question concerning the translation value
    Data<Vector3> myVec;
    myVec=ldr->getTranslation();
    std::cout<<myVec.getValue()[0]<<", "<<myVec.getValue()[1]<<", "<<myVec.getValue()[2]<<std::endl;
    // I was expecting to get the values dx="9,425276" dy="-36,149002" dz="4,296117" as they are set in the scene, but I get 0 0 0. Did I missed something?
    
    
    // Third question concerning the visual model
    if(!m_ogl_link.get())
    {
        std::cout << "Error getting link" << std::endl;
        return;
    }
        TOGLModel* ogl = m_ogl_link.get();

    ldr->applyTranslation(1,0.0,0.0);
    ogl->applyTranslation(1,0.0,0.0); // Is there another way to make the oglModel updates automatically with the corresponding mesh.
}

Again the scene node:

    <Node name="Lunatum" activated="1">
                <MeshSTLLoader name="loader" filename="Lunatum.stl"  dx="9,425276" dy="-36,149002" dz="4,296117" rx="0" ry="5" rz="0"/>
                <Mesh src="@loader"/>
                <MechanicalObject src="@loader" />
                <OglModel name="Visual" fileMesh="Lunatum.stl" color="blue"  />
                <MyComponent  ogl_link="@Visual" stl_link="@loader"  listening="1" />                

    </Node>

Thanks,

Noura

[Author]

Posts