Hey!

Semi trivial RBD question here.

In all the examples I've looked at the collision geometry for a sphere RBD is a brickered up poly representation of a sphere. Surely this is a big overhead for something as basic as a sphere as well as being innacurate?

Cheers
Louis

You're right, an implicit sphere would be more accurate and cheaper.

I can't really explain it, except to point out that if the default RBD Object had a sphere as geometry and an implicit sphere as an SDF, then as soon as people pointed the RBD Object to their actual geometry, they'd start shouting “what?!” as the SDF remained a sphere and so therefore didn't work at all.

Does that help?

I think Louis is asking for implicit surfaces to be supported as SDFs

They are, as long as those surfaces are spheres, cubes or planes.

:wink:

Emmm… really?

To me it looks more like an implicit sphere is used to calculate the SDF rather than an implicit sphere being used directly in the solver itself.

If you have a look at this amazingly basic hip file, it seems pretty obvious to me that while the volume representation mode is set to explicit sphere, in reality the solver is running the poligonized SDF.

In the help it says:
Implicit Sphere -> Calculate the bounding sphere for the geometry, and create a volumetric representation that precisely fills that bounding sphere.

It doesn't say anything about using an optomised sphere description in the solver itself.

Am I wrong?

Also, in the RBD Solver itself the help for the culling method says:
In simulations with a large number of objects…..
Sphere means the objects will be treated as spheres and trivial intersection detection will be done with these spheres. This is fast, but with long skinny objects could cause false positives.

So the behaviour described here is what I'm interested in. Very very fast sphere RBDs. The help doesn't actually say how to achieve this though.

Louis

Ooooohhhhh - I see what you are saying now.

I don't completely understand this, so I will have to go back and get clarification, but I think the reason you get the result in your hip file is to do with the way collisions are handled. And that is that both the geometry and the SDF are used. If object A and object B collide, then the points of object A are compared to the volume of object B, and then the points of object B are compared to the volume of object A. What happens with that set of collisions, I'm not 100% sure, but the point is that your actual surface geometry also matters.

See my modification of your example - the middle sphere is a much better geometric sphere, but a terrible volume representation. Yet it rolls much more nicely than either of the other two. So I think the combination of geometry and volume is at work here.

However, this is an interesting question, and in the process of working through it, I also had another question. I'm going to go back and ask these, and see if that makes me any smarter. If so, I'll be back with more clarification.

Ok, I answered my own question with this other example. Here are two spheres, which begin the sim interpenetrating. The RBD Solver pushes them apart on frame 2.

Make sure you have perspective turned off, and then move to frame 2. Note that they still touch. Now change the collision representation to “Implicit Sphere” and recook. Note that they now do not touch. So I conclude from this that the implicit sphere IS making a difference to how collisions are calculated.

In fact, if you change the representation back to Ray Intersect, and set the sampling down to , and recook, you'll notice that the spheres move even closer together, which again is what you would expect.

Are you buying this?

One very important point here (the only point Craig is missing, I think) is that the collision guide geometry (the red polygonal representation of the SDF) is simply that - a polygonalization of the SDF. The RBD solver uses the SDF directly, not the polygonalization of the SDF, to do collision detection. So when you say “implicit sphere”, the SDF representation is a precise sphere. The polygonalization loses the prefectness of the sphere, but the RBD solver uses the perfect sphere for collision detection. Even when you use the Ray Intersect method, the rd polygonalization is only an approximation of the SDF. There is more information in the SDF than what can be described by a polygonal surface, and the RBD solver uses all the SDF information, not just the polygonal surface approximation of the SDF.

The culling method is separate from he actual collision detection. It is used to more quickly decide which pairs of objects to do real collision detection with. So when the documentation refers to false positives in the culling phase, that just means the solver will do more collision detection tests than it would if you used the bounding box culling method (if your objects are better approximated as boxes). Thosecollision detection test will then fail to find any collisions, so the end result will not be affected (it just may be a bit slower than if you used bounding box culling).

Mark