Not sure if I'm doing something wrong but if I set the collision hull type to compound and hit play, nothing happens. Works fine for convex, cylinder, etc.

Hey Dave can you attached you scene, if you can. or maybe add some images to see your settings or something. Difficult to know what it is without seeing anything

sure - here you go

you need to use a bake ode node for that, and it will give you a points representations for your geo, is also kind of slow to compute. But Im wondering why do you want to use compound, you do not need it for that scene. Are you looking for a better representation of your collision obj?

you can just use Convex mode and check Create Convex Hull Per Set Of Connected Primitives on RBD Packed Object
unless you really want to create compound shape just from primitives

tamte
you can just use Convex mode and check Create Convex Hull Per Set Of Connected Primitives on RBD Packed Object
unless you really want to create compound shape just from primitives

Yeah, that is the best way to go. In that mode, the solver will still auto-detect boxes, spheres, tubes, and c-regions (capsules), so you can get the exact same results as the ODE compound workflow without needing extra setup, and it'll also handle convex hulls.

cwhite
… In that mode, the solver will still auto-detect boxes, spheres, tubes, and c-regions (capsules),…

sounds great, I wonder how that works
Does it detect it directly from the shape?
Or does it rely on bullet_georep attribute to be present?

since in help for bullet_groupconnected it says only “When Geometry Representation is Convex Hull, specifies whether the solver should create a compound shape that contains a separate convex hull collision shape for each set of connected primitives in the geometry.”
so it's not really clear to me what are the rules for primitive shapes being recognized as primitives instead of convex

tamte

cwhite
… In that mode, the solver will still auto-detect boxes, spheres, tubes, and c-regions (capsules),…

sounds great, I wonder how that works
Does it detect it directly from the shape?
Or does it rely on bullet_georep attribute to be present?

Yeah, the convex hull mode will use more optimal collision shapes where possible based on the object's geometry. If, for example, the geometry (or the primitives in one connected component if that option is enabled) consists of a single primitive sphere, the solver will use Bullet's sphere collision shape instead of converting the sphere to polygons and using its convex hull.

thanks, for primitives that makes sense, but what about box or plane? those are not primitives, will it detect automatically from polygonal shape?

tamte
thanks, for primitives that makes sense, but what about box or plane? those are not primitives, will it detect automatically from polygonal shape?

For boxes, it looks for six polygons that form a box shape (roughly the same approach as the Bake ODE SOP). This means that the default box will get the optimal collision shape, but for anything more complicated (like if the Axis Divisions parameter was used) you'd want to switch from Convex Hull to Box to get an auto-fitted box shape.

If the geometry has an SDF representation attached that is set to Implicit Plane, then a ground plane collision shape will be used (this is how the Ground Plane DOP works). Otherwise, you can also get a plane shape by switching the representation from Convex Hull to Plane, which “auto-fits” a plane by using the first primitive normal it finds.

great info, thanks Cameron

would Create Convex Hull Per Set Of Connected Primitives take advantage of bullet_georep if present?
like 3 packed prims with the same name attribute and bullet_georep different for each of them, like box, convex, concave

EDIT: actually that may be what Compound should do right? let me check

No, the solver only inspects bullet_georep on the top-level packed primitive. If it's set to convex hull, then for each group of connected primitives (if that option is on) it'll build either a convex hull or a more optimal collision shape like a box or sphere

The compound mode is a little more like what you're describing, though it only supports primitive shapes.

cool, thanks

tamte
you can just use Convex mode and check Create Convex Hull Per Set Of Connected Primitives on RBD Packed Object
unless you really want to create compound shape just from primitives

This doesn't seem to create collision meshes that respect concaves, which is why I wanted to use compound, which is meant to work with concave meshes

geo:

collision geo:

cgbeige

tamte
you can just use Convex mode and check Create Convex Hull Per Set Of Connected Primitives on RBD Packed Object
unless you really want to create compound shape just from primitives

This doesn't seem to create collision meshes that respect concaves, which is why I wanted to use compound, which is meant to work with concave meshes

I'm not sure why you expected it to work for concave meshes, since the docs (http://www.sidefx.com/docs/houdini16.0/nodes/dop/rbdpackedobject) [sidefx.com] indicate that it's only for simple primitives. It sounds like you want a convex decomposition tool?

OK - well, I thought compound was intended to do this but I guess not. It would be nice if there was a reliable way to do this in the future. I was just experimenting and noticed it was failing so it seemed like a bug.

After trying the sphere compound geo and finding that really slow and not very realistic for this large concave plateau, I went with a Voronoi shatter and compound mesh for the collider and it was very reasonable to solve and produces decent results:



It's similar to what Unreal Engine does - dices concave geo into convex parts. This is just more prone to still being concave so the solution would be to paint in extra particle density in the convex bits to use for the Voronoi shatter