sdf

[guolin-11]

Intro

Hi!

I am a student;

My setup

mjx

My question

When using SDF plug-in, it often takes a long time to load the model. Is this normal? And what are the factors that determine the loading time of a model?

Minimal model and/or code that explain my question

No response

Confirmations

• I searched the latest documentation thoroughly before posting.
• I searched previous Issues and Discussions, I am certain this has not been raised before.

[quagla]

Hi, do you mean an SDF plugin of type mujoco.sdf.sdflib? That's because SdfLib has to create an octree representation of the geometry, which requires evaluating the SDF multiple times during the compilation using TriMeshDistance, which is slow. At runtime, the SDF is evaluated only using the Octree, which is fast.

[quagla]

The sdflib plugin was removed, now the functionality is supported natively in mujoco. You can remove the plugin from your model and just leave the geoms defined as sdf.

[joaocandre]

As far as simulation performance, I go from

 Simulation time      : 0.06 s
 Steps per second     : 158572
 Realtime factor      : 317.14 x
 Time per step        : 6.3 µs

 Newton iters / step  : 0.97
 Contacts / step      : 3.98
 Constraints / step   : 15.91
 Degrees of freedom   : 6
 Dynamic memory usage : 0.2% of 13M

 Internal profiler, µs per step
              step :    6.3  (100.00 %)
           forward :    6.1  ( 97.54 %)
          position :    4.5  ( 71.24 %)
          velocity :    0.2  (  3.76 %)
        constraint :    1.3  ( 20.31 %)
           advance :    0.1  (  1.16 %)
             other :    0.2  (  3.52 %)

   position total  :    4.5  ( 71.24 %)
     kinematics    :    0.8  ( 12.97 %)
     inertia       :    0.1  (  0.89 %)
     collision     :    2.7  ( 42.76 %)
       broadphase  :    0.2  (  2.43 %)
       narrowphase :    1.0  ( 16.20 %)
     make          :    0.7  ( 11.41 %)
     project       :    0.0  (  0.35 %)

to

 Simulation time      : 2.75 s
 Steps per second     : 3634
 Realtime factor      : 7.27 x
 Time per step        : 275.2 µs

 Newton iters / step  : 1.06
 Contacts / step      : 8.96
 Constraints / step   : 35.82
 Degrees of freedom   : 12
 Dynamic memory usage : 0.2% of 14M

 Internal profiler, µs per step
              step :  275.2  (100.00 %)
           forward :  274.9  ( 99.91 %)
          position :  271.7  ( 98.74 %)
          velocity :    0.4  (  0.15 %)
        constraint :    2.7  (  0.97 %)
           advance :    0.1  (  0.04 %)
             other :    0.3  (  0.10 %)

   position total  :  271.7  ( 98.74 %)
     kinematics    :    0.9  (  0.32 %)
     inertia       :    0.1  (  0.03 %)
     collision     :  269.1  ( 97.78 %)
       broadphase  :    0.4  (  0.15 %)
       narrowphase :  267.1  ( 97.05 %)
     make          :    1.5  (  0.54 %)
     project       :    0.0  (  0.01 %)

just by introducing an SDF geometry into the simulation.
Hence my original question i.e. could there be performance gains by writing a custom plugin, namely I could exploit several aspects of the object such as axis symmetry?

[quagla]

If it's a simple geometry, it could be the case (try benchmarking the torus plugin), but the question is what did you have in the simulation when it goes at 300x realtime? It's probably only primitive geoms, no meshes.

[quagla]

A fair comparison would be introducing introducing an object but 1) using an sdf vs 2) using as many convex meshes as are needed to approximate it.

[quagla]

But yes, if your geometry is as simple as a torus then you can get the same numbers as primitives with s plugin. I would suggest you benchmark the SDF examples to get an idea. Also notice that the performance is dependent on the SDF initpoint and iteration parameters. The default values are conservative.