Using Custom Meshes?

[tsor13]

Wonderful project! I work in a soft robotics research lab, and this is astounding work. We've spent some serious time trying to get our own custom meshes to work with it, but have had a hard time with it. Is there a way you can upload an .OBJ file or something to simulate?

[drebain]

Unfortunately, it's not currently possible for this code to automatically generate the viper primitives needed for simulation from a surface mesh. If you would like to use a custom mesh you will need to provide these by generating them yourself or specifying them by hand (which was the approach we used for this demo). We describe a method for generating primitives in the paper (viperization) but without some further work it is limited to muscle-like structures with "start" and "end" points.

If you want to try specifying by hand you can modify the structures defined in Octopus.h. The approach we used was to manually place spheres over the surface mesh in 3D modelling software and then hard-code their parameters (x,y,z,r) into this file along with "pill" primitives connecting them.

Once you have that you could replace the existing surface mesh loading code (lines 334-374 in OctopusComponent.h) with code that loads your .OBJ using the SurfaceMesh::read() method.

One part that is done automatically is the computation of deformation weights used to rig the mesh to the primitives, so if the fit of the primitives to the mesh is good then this should not require any intervention.

[tsor13]

Thanks for the help! I'll try that approach and see if I can get it working. One follow up question. In the demo, the octopi are unmoving. However, I'd be more interested in simulating something more similar to the muscle simulation described in section 8.2 of the paper. I was wondering if you could offer some guidance on a) disabling intra-muscle collisions and b) activation of muscles? Is this built in in any way to the code provided in the repo?

[drebain]

For collisions, the current behavior is to only resolve collisions between primitives with different group IDs, which are set to a single unique value for each octopus instance, meaning instances will collide with each other but not themselves. If you want different behavior, you can control which primitives are allowed to collide by changing the group IDs (relevant line).

For activations, I think the simplest way to produce a contraction force would be to reduce the rest length of the stretching constraint (created here) by modifying the constraint object dynamically.

[tsor13]

In the paper, it describes that you simulated muscles by using rigid bones affixed to VIPER primitives. Where would one go to i) create a rigid structure in a Viper scene and ii) affix a VIPER pill to such a structure? Thank you so much for your help!

[drebain]

The way we made rigid structures was to add primitives without constraints and with the kinematic flag set to true. An example of adding kinematic primitives is the pillars from the demo video. These are still ordinary primitives from the solver's perspective, so you can add a constraint between a kinematic and non-kinematic particle, and the solver will only apply forces to the non-kinematic one.

By keeping track of the ID's of these primitives you can drive them by setting their positions/radii every step from the outer simulation loop. An example of what this looks like is the mouse manipulation where the particle under the mouse is temporarily made kinematic.