[Hugo]

Hi Luigi,

I am no expert in collision detection and response.
Researchers worked about CUDA collision detection based on the LDI method: see the following paper. But it is not public yet in SOFA, I am trying to get evaluation contract for it. I can let you know about it.

About using CUDA in SOFA, have a look at the SofaCUDA plugin.

Cheers,

Hugo

[Hugo]

Hi Luigi,

That’s what I expected: by deactivating the collision, the simulation runs way (way) faster. And, what confirms your EDIT 2 its that your collision mesh is too refined to run with close-to-real-time performances.

Could you give a try to decimate your surface mesh and run the simulation again ?

Then, the option to improve performance would be to consider GPU collision detection or (as written previously) multi-thread approach. This is work in progress as you can see in issue #24.

Cheers.

Hugo

[Hugo]

Dear Luigi and Fabien

About the solver, decreasing the number of iterations must be done carefully, i.e. you must check that it does not affect your convergence. Whatever, as you noticed, it did not change anything.

What I meant was to decrease the resolution of the imported mesh, especially for the collision. But, if you do not model the collision (for now), did you try to remove all components of collision (while keeping the meshes for visualization) ?
I am pretty sure, something is getting computed.

Could you send us a screenshot of your hand mesh and an estimation of the total number of points in the meshes ?

Cheers,

Hugo

[Hugo]

Hi guys,

Here is a post from Erik about SofaPhysicsAPI, it could be of interest.
Cheers,

Hugo

[Hugo]

Hi guys,

Here is a post from Erik about SofaPhysicsAPI, it could be of interest.
Cheers,

Hugo

[Hugo]

Hi Luigi,

The performance of your simulation is due to the complexity of your simulation. For instance, if you use a very detailed mesh (many dofs), or a detailed collision model etc. Reducing the resolution of your objects (mechanical, visual, collision) would help improving the performance, but this is maybe not worth considering depending on your application. Solvers (as you wrote) only solve the system you give them to solve, there is not much to optimize there.

What do you intend exactly to do?

Magic speedups are impossible, however, you can experiment the SofaCUDA plugin and use some CUDA codes. But, to be efficient, the whole SOFA scene (including your self-developed components) must be implemented with CUDA support.

Finally, multi-thread approaches are also possible. But this is work in progress as you can see in issue #24.

Cheers,

Hugo

[Hugo]

Hi Elek,

Have you notice the post of Alex above ?
He’s right, the OglAttribute should not be compiled when the SOFA_NO_OPENGL flag is true.
I will correct it next week. You can already make the change locally on your machine.

Cheers,

Hugo

[Hugo]

Hi Luigi !

The frequency of a SOFA loop is not constant since it depends on the computation time, i.e. the complexity of your system.

The best way to create an interface component with your server is to communicate through data.

About the real “frequency” of SOFA, i.e. the number of frames per sec, you can not see it by default. The simulation might be faster than the visualization and can be constrained by the vsync from the graphics of your computer (example on linux).

Timers allow you to know about your computation times.

Best,

Hugo

[Hugo]

Dear Wong,

I’ll try to do it point by point and at my best knowledge!
The FreeMotionAnimationLoop corresponds to an AnimationLoop where:

1. the system without constraint is solved: this gives the free positions and velocities,
2. then the constraints are solved (I think using a GaussSeidel approach)
3. finally, a correction is applied to the free positions and velocities based on the contraint solving

The UncoupledConstraintCorrection is an approach for solving the constraint independently from eachother. In other words, each constraint is solved without considering the neighboring constraints which results in a diagonal constraint matrix. I think the field compliance corresponds to the value on this diagonal matrix.

Finally, rayleigh terms in the integration scheme (e.g. EulerImplicit) are terms aiming at numerical damping. This numerical damping can be computed based on the stiffness or mass matrix. See line 65 of EulerImplicitSolver.cpp with the r_M et and r_K terms.

Cheers,

Hugo

[Hugo]

Hi Coco,

There is a page dedicated to it in the documentation, you should carefully read the doc.

Let’s take an example in DefaultAnimationLoop.cpp. Have a look at the DefaultAnimationLoop::step() function.

Here, the way of using AdvancedTimer is visible. First, you need the header to be included:
#include <sofa/helper/AdvancedTimer.h>

Then, in the function, you always have a first Timer starting the counting and another ending the Timer:

 sofa::helper::AdvancedTimer::stepBegin("MyTimer");
//Here the code that you want to measure the computation time
 sofa::helper::AdvancedTimer::stepEnd("MyTimer");

Finally, to actually measure the time spent for this piece of code what you need is click in the tab “Stats” of runSofa and then click “Log Time”. Run 100 steps and get the timers in the command window.

Cheers,

Hugo

[Hugo]

Thank you VERY much for sharing this Luigi!
Cheers

Hugo

[Hugo]

Perfect.
Thank you for sharing,

Best,

Hugo

[Hugo]

Ok I close this topic then.
Cheers,

Hugo

[Hugo]

Nice ! well done Coco !
What was the issue ?

Cheers,

Hugo

[Hugo]

Hi Coco,

I would advise to use a backtracer to check where does this crash come from.
Moreover, for the writing of such a main() I would advise to stay close and compare with the one from runSofa.

Cheers,

Hugo

[Hugo]

Hi Jens,

when trying your scene there is : Cylinder_big.msh and cylinder_instrument_100.obj missing. Could you share them with us to have the complete scene ?

Cheers

Hugo

[Hugo]

Hi Luigi,

I’ll try if some expert can shortly look at you problem. But for specific needs and support from experts, it then become a charged service of the SOFA Consortium.

At my best knowledge, there is no such a class. I wrote you the steps to follow for the implementation.

Best,

Hugo

[Hugo]

Hi Sen,

You could try using the Geomagic plugin for the haptic interface instead ?
Sensable plugin is rather old. But appart from this scene, there is no other example for the moment. We would be glad if you could share some.

Cheers,

Hugo

[Hugo]

Hi Alex,

we discussed it (indirectly) morning in the Sofa-dev meeting.

We were talking about the Loader and Exporter: avoiding duplication of codes in loaders and exporters while keeping optimal components. OglModel came in the discussion since it not only loads obj files but textures as well …

Maybe Fred could help on this. Let’s keep in touch.
Cheers,

Hugo

[Hugo]

Hi Luigi

I am no expert in Rigid simulation.
However, there is an interesting example in /examples/Components/controller/ArticulatedHierarchyBVHController.scn.

What you need to do is to get inspired from it.

• create an interface component translating the information of your server into a data: which is a serie of joints Data<vector<BVHJoint> >),
• create a component inheriting from the ArticulatedHierarchyContainer and allowing to have as input a serie of joints (instead of a filename)
• finally connect both components

Cheers,

Hugo

linked to this ArticulatedHierarchyContainer.

[Hugo]

Hi Luigi,

yes please, for other users it might be useful.
can you share the part that solved the issue ? and you can also set this discussion as solved.

Cheers,

Hugo

[Hugo]

Dear robagar,

Did you compile the Flexible plugin ?
(activate it in cmake-gui and recompile)

cheers,

Hugo

[Hugo]

Hi Elek,

I never saw that, but it seems that everything is in the output ? no ?

note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated)

Did you try setting this -fpermissive flag ?

Cheers,

Hugo

[Hugo]

Dear Albert,

What do you mean exactly by “I cannot access the OglModel directly” ?
OglModel hierarchy is :
sofa::component::visualmodel::OglModel< ExtVec3f > ...

Best,

Hugo

[Hugo]

Nice to hear Luigi.

About the collision detection: something easy is just to remove the collision model of some parts (here removing and ).
But what you seem to target is more a specific CollisionPipeline. I think you will have to implement some new pipeline or new collisionListener. Maybe something already exists, I am no expert of collision.

I set the topic as solved, since the problem of mesh is solved.
Do not hesitate to create a new topic for any further question.

[Author]

Posts