RBD Hard Constraints/Glue Constraints & Sanity check

hard constraints will read Force, Angle, Torque and Distance
Glue constraints will read Strength and Impact

Sometimes you will glue things together and they will still seem to come apart (when attached to something animated for example). Try solving the RBD Packed Object on creation frame - this MIGHT fix it...

Check your Constraint Network's "Overwrite with SOP" field if constraints are not being deleted correctly. It should only be active (value of 1) for the first frame of the simulation. Then it should go back to 0. Otherwise, it will constantly read in the constraints from the SOP level (ie. replacing it with vanilla untouched constraints)

RBD Clustering, an "update"

Instead of using the cluster attribute found in Sam's notes...

Add a primitve VOP to your constraint primitives.
Create a voronoi noise and promote the frequency to the top level.
Plug the output (dist1 is good) into a ramp float node and then mess around with the curve to create some interesting patterns (try adding noise to this), which will essentially operate as clusters.. Export this to Strength, or multiply it by a pre-existing value.

RBD, Constraints..Glue, fracturing. NAMES

Name attributes are the most important things when making constraints for RBDs.

Create a name attribute for your object/fractured pieces by laying down an Assemble node, without the Packed option enabled. Create your constraints with this geo (it will retain the Primitive Name Attribute, and pass it down to the Point level once you've used Connect Adjacent Pieces)

In another branch, use another Assemble node to follow up the previous Assemble node, this time with Packed enabled, but the others disabled. Now when you add your constraints to your DOP network, they'll be able to find the correct Pieces to attach to.

ALSO make sure your object names are all unique.
Names. Names. Names.

Another "quick" way to make rest lengths for your constraints is to do a Convert Line node just before the Primitive Wrangle (where you do s@constraint_name="thingy"). This is important for Hard Constraints.


A general rule for constraint types - Hard Constraints will provide overall flex between pieces.. Glue Constraints will keep the pieces all together.
Hard Constraints react to Force, Glue Constraints DO NOT.
Glue Constraints react to Strength and Impact. Hard Constraints DO NOT. *

*unless you tell them to in a SOP Solver - eg. if (@force>chf("breakThreshold")*@strength)
But this is you explicitly adding Strength into the mix... Could be any old attribute.

point deform tricks

The point deform node is very useful to wrap deform high res geo with lower proxy geo.
To help it along in the case of overlapping objects, you can offset the objects.
Create a  point class attribute for both the high res and proxies.
Then move the pieces both high res and rest-position low-res using @P+=i@class
The deforming proxy geo will stay "as-is".

By seperating the geo in this way you can avoid "some" intersections...

set animation curves to infinite, etc.

In the graph editor, right click the channel (eg. translate Y) and click Channels>Channel properties..
Here you can change the In and Out to whichever infinity-behaviour you'd like.

stick noise to geo

Something super simple and dumb that I'm surprised I've never used beforehand!

To keep a 3d noise value from,say, a point-vop sticking to Geometry, make a rest-position value before the object is meant to start animating. There is a handy Rest SOP for this.

emitting only 1 particle per point per frame

Obviously stole this from ODforce:

if you want just 1 particle emitted per point at a given frame, the basic expression would be in the rate of the source node of your pop network
if you decide to put it in the impulse rate :
npoints(opinputpath("../",0))
and turning off the const. activation
if you decide to put it in the const rate
npoints(opinputpath("../",0))*$FPS
and turning off the impulse activation
don't forget to put the emission type to points(ordered) or you won't have a particle per point
this will hower emit the exact amount of points your emitter sop has per frame, so if your emitter has points that last 2 frames, you'll have 2 particles per point after 2 frames.


*Also, you could use $NPT/10 instead of npoints... Dunno if this works

When would you use this?
If you have a source which is changing point count each frame, eg, a pattern of cracks being animated (like when Godzilla is underneath a road)... 
I think the $FPS version helps when it comes to substeps etc like with Maya, where you need to divide the perframe emission to account for the substeps... 

The first option works well if you divide the emission count (just add a /10 or whatever after the expression)