Food Simulation

Post Reply
p99user
Posts: 4
Joined: Mon Feb 15, 2021 9:57 pm

Food Simulation

Post by p99user »

I'm looking for existing projects using Bullet, possibly pybullet, for food simulations.
In particular I'm interested in simulating the act of scooping granular media from a metal container.

So far, I've tried by simulating food with small spheres, using realistic CAD model for spoons and metal containers. I'm not able to reliably avoid the compenetration of the food with the container and the spoon with the container. This results for instance in the food leaking from the container, when pressure is applied with the spoon.
User avatar
drleviathan
Posts: 690
Joined: Tue Sep 30, 2014 6:03 pm
Location: San Francisco

Re: Food Simulation

Post by drleviathan »

To avoid tunneling of convex grains through a concave container in Bullet you should use btCompoundShape (collection of convex sub-shapes) for the container rather than a convex mesh shape like btBvhTriangleMeshShape. The penetration resolution logic works much better for convex-vs-convex than convex-vs-concave. Unfortunately, to approximate a smooth round container with convex parts requires a large number of sub-shapes in the collection, and you'll need to overlap to prevent grains from tunneling between adjacent pieces. So unless your metal container is conveniently a box then you'll need many parts. This is possible to do, and while the efficiency of a btCompoundShape with hundreds or thousands of sub-shapes can be surprisingly good, I doubt you'd be able to run such a shape against a few hundred grains in real-time, even on expensive hardware.

Bullet does not work well for "very small" bodies, where the "very small" threshold is probably somewhere between 0.2 and 0.04 units (depending on shapes used and substep configuration). So, you'd probably have to scale your simulation up such that a grain's smallest dimension is larger than the threshold. Scaling the simulation in this way is not limited to just the spatial dimensions: you'd also have to scale time and tune your friction/restitution/damping coefficients as well. Of course, the time dilation makes it even harder to run the simulation in real-time since you would effectively be taking very small substeps.
p99user
Posts: 4
Joined: Mon Feb 15, 2021 9:57 pm

Re: Food Simulation

Post by p99user »

Thanks for you answer, the compenetration are definitely reduced following the first part of your answer. In particular, I'm using v-hacd in pybullet.

I'm still seeing tunnelling of the small particles though. By scaling you mean simply an absolute rescaling of the objects in the scene, when importing from URDF?
Can you clarify on the units? Do you refer to the scale factor that I find for instance in a URDF, like in:

Code: Select all

<mesh filename="myobj.obj"  scale="0.1 0.1 0.1"/>
User avatar
drleviathan
Posts: 690
Joined: Tue Sep 30, 2014 6:03 pm
Location: San Francisco

Re: Food Simulation

Post by drleviathan »

Bullet is tuned for meters and seconds. There are hard-coded thresholds in the details of shapes and collisions which makes Bullet not work well for tiny objects.

However, you could "pretend" Bullet's units are centimeters instead of meters, and thereby simulate smaller physics. So a 0.01m object would have dimensions of 1.0 units in the simulation. When you do this you must increase gravity to be 980 distance_units/second^2, however that would cause your objects to fall very fast and achieve high velocities, so you could compensate by "pretending" the unit of time is 10x smaller (deciseconds) and keep the acceleration of gravity 9.8 distance_units / time_unit^2 (note the inverse square term!). If your substep were 1/60 time_unit then would really represent 1/600 seconds, and your simulation will not run real-time unless you take 10 substeps per real-time 1/60 second, which would be hard to do with high grain count.

With such small effective timesteps you would want to keep friction low (less friction per time unit), restitution high (more bounce per time unit), and probably set the non-physical "damping" terms as low as possible. You could keep mass units at kilograms however the inertia tensor units scale with distance^2 so you'd want to make the inertia tensors 10000X larger, effectively making the grains correctly slower to rotate per unit time.

Note, the RigidBody approximation can fail for very small timesteps. At really small steps all things flex and wobble and such micro-physical effects would start to become important in order to achieve accurate results, so using a RigidBody Bullet simulation at extreme scales starts to become a sketchy proposition.

I should mention: this is all theoretical. I've never actually tried it. And if your simulation can't run in real-time then it won't really be interactive. On the other hand you could run the simulation, record it, and then play the movie back at 10x speed.
p99user
Posts: 4
Joined: Mon Feb 15, 2021 9:57 pm

Re: Food Simulation

Post by p99user »

Lowering the timesteps worked to avoid tunnelling!

Now the remaining problem is the collision spoon-to-container, that is concave(hacd)-to-concave(triangular mesh), where the spoon is dynamic and the container is static. Right now the object get fused together when they collide, like if they are jammed. Sometime is possible to get them unstuck, other times I just need to restart the simulation.

This conversation looks relevant: viewtopic.php?f=9&t=12939&p=43020&hilit=gimpact#p43020

My impression is that the solution is there, but are Gimpact and Compoundshape exposed in pybullet?
Another solution is perhaps collisionMargin, but this is not exposed in pybullet, according to the quickstart guide (https://docs.google.com/document/d/10sX ... hxVUA/edit#)
User avatar
drleviathan
Posts: 690
Joined: Tue Sep 30, 2014 6:03 pm
Location: San Francisco

Re: Food Simulation

Post by drleviathan »

I would expect hacd to use btCompoundShape under the hood. Maybe try also using hacd on the container.
p99user
Posts: 4
Joined: Mon Feb 15, 2021 9:57 pm

Re: Food Simulation

Post by p99user »

I tried that already, not working unfortunately. The two meshes compenetrate.
User avatar
drleviathan
Posts: 690
Joined: Tue Sep 30, 2014 6:03 pm
Location: San Francisco

Re: Food Simulation

Post by drleviathan »

I'm guessing your container walls are thin, and the scoop part of your spoon might also be relatively thin. Thin convex parts of a btCompoundShape could very well penetrate with those of another.

A likely simple solution would be to change your container model to have thick walls: at least twice as thick as: max_expected_spoon_speed * substep_duration.
Post Reply