[SOLVED] Main clock frequency in SOFA

[luibass92]

Hi everyone,

I was wondering which is the frequency in Hz of the main in a SOFA scene.
I receive data from an external server but I don’t know at which frequency I should send these data and I want to send them in a synchronized way with SOFA…

Cheers,
Luigi

[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

[luibass92]

Thanks for your reply Hugo.

Cheers,
Luigi

[luibass92]

In my scene I have always 20 FPS more or less.
Do you know some ways to increase the FPS rate? I would like to reach 50-60 FPS.

I’m using as graphic drive a NVIDIA GT 520MX (1 GB).

As solvers I’m using the following:

<EulerImplicit name="cg odesolver" printLog="false" />
<CGLinearSolver iterations="100" name="linear solver" threshold="1e-20" tolerance="1e-20" />

I don’t know if they can cause the low FPS rate…

Cheers,
Luigi

[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

[Fabien]

Your number of iterations is high and tolerance/threshold is quite low. Do you need that much precision ?

That may be a reason why your scene is low, especially if it does not converge to your requested tolerance, you would do all 100 iterations every time step, many of them for nothing.

Try maybe to keep them to default values (25 iterations and tolerance 1e-6 or so) and see what happen.

[luibass92]

Hi guys,

First of all thanks for your replies.

My application is a robotic hand, the meshes are included and are 20 meshes (collision and visual) for 20 DoF in total… I know it is a lot but the collision detection is not actually working because the hand is the only object in the scene and auto-collisions are not modeled (all of the meshes have the same “group” attribute).

The hand should move according to its joints values passed through socket (it works I’ve tested more times).
The problem is that the joints values are calculated starting from the sensors mounted on the real robotic hand that I have in my lab.
So I would like to see the SOFA simulated hand moving in real time with the real robotic hand and not with 3/4 seconds of delay. This is why I need 30 or higher FPS…

I tried the 25 iterations and 1-e6 tolerance but didn’t change anything.

Hugo what do you mean with “reducing the resolution of your objects (mechanical, visual, collision)”? I don’t think I’ve set the resolutions…

Cheers,
Luigi

[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

[luibass92]

OK these are the screenshots of my simulation, respectively collision meshes and visual meshes (they are identical):

The meshes are not created by me, but downloaded from the web. The hand constructor doesn’t provide official meshes but I’m sure that these ones are correct.
So I can’t tell the estimation of the number of points… But zooming in the meshes I can see that they are “empty” inside, so there are no useless points, there are just the superficial points.

If it is useful my code for generating the meshes is always the same (repeated for each mesh):

<Node name="Collision">
                    <MeshObjLoader name="MeshLoader"  filename="mesh/f21.obj" scale="100" rotation="180 0 90"/>
		    <Mesh src="@MeshLoader" /> 
                    <MechanicalObject template="Vec3d" src="@MeshLoader"  />
                    <TriangleModel group="1"/>
                    <LineModel group="1"/>
                    <RigidMapping  input="@.." index="2" />
                </Node>
<Node name="Visu">
                    <OglModel name="Visual" filename="mesh/f21.obj" scale="100" rotation="180 0 90"/>
                    <RigidMapping template="Rigid3d,ExtVec3f" input="@.." index="2" output="@Visual" />
</Node>

I don’t know if there are attributes to change in the code (in LineModel and TriangleModel for example).

I didn’t try to remove all the collision meshes because I know that I’ll need them in my project (the hand should manipulate a deformable object in the scene). I tried to remove all the viual meshes (they are not so useful) but it didn’t change anything…

Thanks again for your reply,
Luigi

EDIT: I’ve tried to deactivate all the collision meshes nodes and actually the simulation goes way faster… So the problem are these collision meshes even if I put them all in the same group (<LineModel group="1" />)

EDIT 2: I found out that my meshes were constructed with a lot of duplicated points (I don’t know why), so I’ve simplified them and now the simulation is faster. Unfortunately if I add another object in the scene activating the collision detection with the hand, it goes still slow. So if you have some other suggestions to improve the speed of my simulation I’ll thank you :).

[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

[luibass92]

Hi Hugo,

I will try the decimation of the meshes soon! Thanks for the tip.

What do you mean with “GPU collision detection”? I run my entire system using my GPU NVIDIA GeForce GT 520MX, I’ve installed the drivers and now it is used just the NVIDIA as GPU for every operation…
Is there a way to tell SOFA to use the NVIDIA drive just for collision detection?

Cheers,
Luigi

[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

[luibass92]

Hi Hugo,

I’ve decimated all the meshes (some with a ratio of 0.25, others with 0.5) and now the simulation without other objects in the scene runs at 30 FPS more or less.
Obviously if I add another object (a sphere) the simulation slow down to less than 10 FPS.

Anyway your tips have been really useful, thanks a lot!

I will take a look to the CUDA plugin for sure.

Cheers,
Luigi

[Hugo]

Alright Luigi,

I think we can close this thread and do not hesitate to open a new one if you face any new issue. Cheers,

Hugo

[luibass92]

Sure, I’ll mark it as solved!

Cheers,
Luigi

[Author]

Posts