I am trying to have a ball fall on some letters, and when the ball hits the letters, they move down a little and then snap back in place. I want letters that aren't impacted to stay static. I set the glue amount super low and still the letters don't move. What am I doing wrong here? Attached is a screenshot and the project file.

I've simplified your setup. Here are some notes however:

For the sphere, you can use implicits which work natively with bullet and are much faster.

You have the letters plugged into the collision input on the RBD Bullet Solver - that 4th input is mostly for static collisions you don't really want to output from the sim (think set geometry) - although you can do a lot more with this, by default whatever is plugged in there will be treated as static colliders.

You are using a connect adjacent pieces SOP to create the constraint geometry between the letters, after the RBD Configure SOP - RBD Configure will pack the input geo, making the geo unavailable for the connect adjacent SOP to work with - as is, it's only outputting the input geo, so it's not doing anything. You're plugging this into the first input of a RBD Constraint Properties SOP - the constraint geometry should always come through the 2nd (pink) inputs - so nothing was really happening to this and there is nothing coming out of the RBD Constraint Properties SOP's constraint geometry output, which you then pipe into the RBD Configure SOP where your sphere is plugged into.
Even if you did create constraints properly, plugging in constraints that don't have any RBD geo counterparts in the 1st and/or 3rd inputs of the RBD Bullet Solver won't do anything.

Have a look at the docs for how bullet constraints work - they typically are a 2 point polyline where each point has the name of the RBD piece it connects to, and the prim itself holds attributes specifying the name of the constraint DOP object it is represented by (the constraint type if you want) and other attribs allowing you to configure each constraint's behaviour - at minimum you'll need a "constraint_name" string prim attrib and a "name" string point attrib for constraints to work, and at least one of the names needs to match the name of a RBD geo piece in the sim (some constraints, such a glue constraints, need both points to have names of existing RBD pieces).


For the kind of effect you're after, you can do it a number of ways, but the RBD Configure SOP has a handy Pin constraint setup (with an action script button to automatically create the RBD Constraint Properties SOP pre-configured for you) that allows you to do just that fairly easily.

Have a look at some of the RBD tutorials to get a feel for how the high level triple wire RBD toolset works and how the various geometries flow between nodes.

Thank you! This is very helpful and I appreciate it. I will check out some more RBD tutorials.

I'm a little confused about how the guiding sim works. I actually like the way the guiding sim moves better than the main sim. (I don't like the angular rotation when the ball hits the letters in the main sim, but in the guiding sim the letters just bounce down and back up and there is a nice springyness to them as they settle back into their original positions. So maybe I just use that one.) Are these 2 different SIMs, or does the guiding sim on the right somehow guide the sim on the left?

Also,

1. how do I get my color attributes back onto the ball for rendering? I tried blasting out the ball post-sim, then using a copy to points to copy the render ball (with the colors) onto the point info from the primitive ball, but it doesn't move correctly, and also I lost my colors after the merge node, so I need to get them back.

and

2. I want to bevel the letters for render but want to do this post sim so it doesn't slow down the sim. How do I break out the separate geo after the sim for post processing? (I tried a blast node, since the ball is 0, but when I blast out the ball, the Cd attributes on the letters (which are based on prims) get all blurred and messed up.)

For the guiding, you can see all I'm doing is plugging in the static letters into the 5th input, where the guide geometry goes in. On most nodes if you hover over the inputs, you should see the input labels which tell you what the input is expecting.
I left the guiding setup in there as a very bare bones example but you can use it to great effect to have explicit control of your RBDs while still respecting collisions etc.

With the pin constraint method, the first sim on the left, you can control how the constraints affect the letters by tweaking the RBD Constraint Properties. For the soft constraints, play with stiffness and damping to affect how the constraints affect the position of the letters (how far they move, how bouncy they are, how quickly they come to a rest, etc) and play with the angular stiffness and angular damping to control how the constraints affect the rotation of the letters. I deliberately lowered the angular stiffness to allow the letters to woble, something that would be harder the achieve without animating the guide geometry explicitly.


1) The output of the RBD Bullet Solver SOP is the simmed version of what goes into it. The RBD Configure SOP packs the geometry [www.sidefx.com] for bullet when necessary. Nothing gets removed, all attributes are available for rendering. You'll notice though that the implicit sphere doesn't get packed, it stays as an implicit sphere - the RBD Configure SOP only packs geo that needs to be packed - geo that isn't understood natively by the RBD Packed object DOP.
The sphere has a primitive Cd attribute, while the letters have a point Cd attribute. When we merge both the sphere and the letters, you can see they now have both a point and a prim Cd attribute. The attribute that didn't exist previously on the sphere and letters automatically gets assigned that attribute's default value. So the sphere gets a {1,1,1} point color, and the letters get a {1,1,1} prim color (Cd is a special attribute which defaults to white).
The order of precedence for which various processes will consider an attribute with the same name is Vertex > Point > Prim > Detail.
So in your case, the viewport and the SOP Import LOP will prioritize the point color (on the letters) and ignore the prim color (on the sphere). Simply do an attrib promote on sphere or the letters and promote the Cd attribute to either prim on point and you'll get your sphere color back.


2) I would do all the modelling operations before the sim - it's simpler than doing it after and the RBD SOP tools are designed to have a geometry (render geo, always plugged in the first inputs) representation and a proxy geometry (lighter sim geo, always plugged in the 3rd inputs) to go with it, for that very reason. Just make sure the matching geo and proxy have the same name attribute.

Because the RBD SOP tools are designed with this 3 wire workflow in mind (geo, constraints, proxy), it can be cumbersome to bring various streams together. To avoid having to merge each stream, the RBD Pack and RBD Unpack nodes help with that.


I've updated the hip file to reflect a few of those changes.

Thank you so much for the explanation! That's very interesting about order of precedence for attributes. It makes sense now!

Also, I love what you did in the wrangle for the guide sim where the letters gallop and spin around. Very fun!

I appreciate all your help. Thank you!