You can prep most of it in SOPs without doing much in LOPs at all. The SOP Create LOP has a button to automatically detect and assign materials.

Here's an example showing how you can assign different materials to different instances (an example for native and for point instances) as well as getting variations in materials by using primvars (SOP attribs) to drive the material look.

The Material Variation node doesn't need materials to be created at any particular point - in fact it doesn't need to know anything about the materials at all. It does try to find materials that are assigned to the instances in order to find input names and types to populate the drop down menu for the primvar names, but nothing prevents you from creating the primvars manually.

What determines whether a primvar will have an effect on the material, as long as the material has a way to read the given primvar of course, is where the primvar is authored.

On point instances, the Material Variation LOP will author the primvars on the point instancer prim. These will override inherited primvars and overwrite primvars of the same name on the point instancer.
If you have primvars authored on the prototype prims however, these will take precedence.

Depending on the scale of your scene, the "Collision Padding" and "Shrink Collision Padding" settings might be causing this. Try setting it to 0, see if that helps, and then scale it up in very small increments.

Here's a hip file with a few different ways of achieving the effect.

In order to get the "emit" attribute from the sim onto your geometry, you'll want to add it to the RBD Bullet Solver SOP's > Output > Transfer Attributes list of attributes.

The RBD Bullet Solver SOP stores all the emitted geometry in a solver SOP, at its emission position, rotation and scale. From there it's a straight forward transform pieces SOP.
The reason it does this is there is no guarantee that all the unique emitted geometry is always available through the first and/or third inputs.
For example, on frame 1 you have a cube plugged into the first frame - a cube is emitted. On frame 2 you switch to no geometry, so nothing gets emitted and on frame 3 you switch to a sphere which gets emitted. On frame 4 and up you switch to no geo.
Without caching the emitted geo, you'd only see the cube on the first frame and the sphere on the 3rd frame and then nothing.

Storing the emitted geo at its emission position, rotation and scale is the same as baking in its rest xform.

Here's one way of detecting impacts inside a SOP solver inside the RBD Bullet Solver SOP.

I don't think that file is the same as the one you showed the problems with, I can't repro the issue in this file and the ball position is very different to the one in your video.
I did notice that you are fracturing the pieces in a for loop, which will result in duplicate names for different pieces - if you use a connectivity SOP to create the name attribute before the RBD Material Fracture SOP, enable the "Fracture per Piece" option, you'll get the same result without the need for a for loop.

You use 2 assemble SOPs to create the names with the same prefix then merge - this results in overlapping names.
In /obj/constraint_and_sim_test you unpack the packed fragments and pipe that through a connect adjacent pieces SOP to create the constraints (which have duplicate names). You then repack the unpacked geo with an assemble SOP set to create the names which creates new unique names - your constraints won't match up with the geo.

Here's a cleaned up version of your hip file with no overlapping names.

With Next Constraints, the constraints have next_constraint_name and next_constraint_type attributes which causes the constraints to, when broken, switch to this constraint name and type instead of being deleted.
next_constraint_name then becomes constraint_name and next_constraint_type becomes constraint_type.
Keep in mind these are the only 2 next_* attributes that get renamed this way.

Having the next_constraint_name be the same as the constraint_name isn't all that useful since they share the same attributes. For example, if both constraint_name and next_constraint_name are set to "Glue", since the constraints will have the same "strength" value (there is no next_strength attribute) when the constraint breaks due to an impact being stronger than the constraint's strength, the constraint is broken, switches over to the next_constraint (Glue in this case) and immediately breaks again since the impact is stronger than the constraint's strength.

If you want to change the constraints' strength over time, the simplest thing to do is to animate it in SOPs with a RBD Constraint Properties SOP node and add the "strength" attribute to the RBD Bullet Solver SOP's list of constraint attributes to override. On the RBD Bullet SOP, under the Constraints tab, Override Attributes, enable the Attributes and add "Strength" there.

Here's a hipfile with various examples.

If you have a hipfile it'll help identify what's going wrong. The way the sim is behaving looks very wrong - I suspect it might have something to do with you possibly having duplicate names in the RBD pieces and constraint anchor names since you are fracturing in a for loop.

Here's a simple example showing the distance threshold breaking the soft constraints.

You have a name attribute on the incoming geometry - this is used to identify each piece to match to an instance. Since all the cubes have the name "box" and the spheres "sphere", they'll be treated as only 2 separate pieces.
Drop an attribute delete before the geo plugged into the Find Instances SOP and it'll find the instances as you'd expect.

Middle click on the node - it tells you how many unique prototypes and how many instances it has detected.

By default, the Mode is set to "Extract and Instance" - this creates the unique prototypes and copies them where needed.
To output the prototypes out of the first output and the instance points out of the second output, set the Mode to "Extract Prototypes". You can use the "Copy Instances" quick setup to set this up for you as well as a pre-configured Copy to Points SOP.

For 1), on the RBD Bullet Solver node, in the output tab, enable Impact Data. Press the "Fetch Impacts" button - this will create a object merge pointing to the impact points from the sim.

With these points, impactobject and parentobject attributes tell you which objects are involved in the impact event.

Ground, when ground or heightfield collisions are enabled, is always 0
Collision Geometry (plugged into the 4th input) is 1 when ground collisions are enabled else 0
RBD Geometry is 2 when collisions and ground collisions are enabled, 1 when only collisions or ground collisions are enabled, or 0 when neither collisions nor ground collisions are enabled.

The impactprimnum and parentprimnum tell you which prims from their respective ground/collision/rbds objects are involved in the impact.

So, say you have 3 RBD pieces (object 1), a box (primnum 0), a sphere (primnum 1) and a lense (primnum 2), falling on top of one another and a ground collision (object 0), if you want to find all impacts that involve the lense, you'll have to find all impact points that have
(@impactobject==1 and @impactprimnum==2) or (@parentobject==1 and @parentprimnum==2)

Unfortunately these particular LOP nodes are a little quirky. Their definition hasn't changed. They have a small set of default parameters which will be updated for you when the definition changes, but most of the other parameters get built dynamically when the node is created.
The "Arnold", "Karma", "Renderman", "Husk" folders and all the parms below them fall in that category.

The only way for you to "update" those nodes is by either replacing it with a fresh new instance and recreating the channel references, parm defaults etc that you had setup, or by editing the nodes' parm interface and adding those new folders and parms.

If you look at the various nodes' onCreated script, you'll see there is a handy function that handles creating all the missing parms.

In the case of the RenderVar LOP:


If you replace with your own hou.Node object, it'll recreate the missing Husk parms on your node.

One caveat is it won't remove any old and deprecated parm, so it's always good to compare all the parms on your updated node with the parms on a fresh new copy.

When you LOP Import the instancer prim and unpack to polygons, it'll bring in a packed USD for each instance with a "usdvisibility" string attribute set to "invisible" for all invisible instances.

In SOPs, you can use all the usd_* VEX functions to get any attrib/primvar etc from any prim on the stage.

Here's an example that shows both the usdvisibility attribute being accessible in a SOP Modify LOP and a sopnet, and another example showing how you can get the instancer attributes onto the instances in SOPs.

With regards to invisibleIds, keep in mind that if your instances have Ids you'll need to first get the Id attribute per instance and check if it can be found in the invisibleIds array as opposed to simply using the instance index as I am doing in the example.

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.

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.

Here's an updated hip file with it working in all cases - the point position however doesn't reflect the pivot offset but should still give you a pretty decent idea of where the pieces are.

Don't set the start frame to $F, this is causing the objects to be created at every frame which will kill performance and adds these offsets you're seeing. If you want to inherit animated attributes from SOPs, under Properties > Pieces > Override Attributes > Attributes, add whatever attribute you want to update there.

If you want the RBDs to match the orientation of the input cubes, you can either completely overwrite w or use targetw and spinresist attributes to get something a little less contrived.

Here's an updated hip file as an example.

It's the wrangle called "transform" in your original hip file, under /stage/instancer1.

Here's the updated hip file.

Hi Jose,

Thanks for that file, it was very helpful.

I've backported the fixes and they'll be available with 20.5.376

jarjarshaq
@npetit wow! Huge improvement over setting explicit frames. Thank you very much. In fact the documentation actually tells you to use frame offset method because it's not time-dependent <facepalm>.

Using the static frame offset I'm getting better performance in LOPs with the retime instances LOP than I'm getting in SOPs with the usdframe prim intrinsic...