…and final thing… in import to SOPs, the @name attribute created will always be the mesh component of the path attribute? @path = ‘/path/to/mesh’ @name = ‘mesh’
For anyone interested.. Ive just RFEd for some documentation improvements for the RBD procedural workflow, but also this is my summary
“`Incoming LOP geometry in SOPs will contain @name and @path attributes. @path will be the USD prim path and should be maintained for the round trip to SOPs and back to LOPs. “/root/myGeometry/mesh01” @name will be equivalent to the mesh component of the full @path (and aids in the construction of USD hierarchies in the absence of @path) “mesh01”
Outgoing geometry Input geometry transformation will now be driven by the RBD simulation’s point transforms. As such we need to establish a relationship between the RBD simulationn points and the newly fractured geometry pieces, while creating no additional pieces in the USD hierarchy. While the fracture creates many pieces of geometry, if those pieces carry the same @path attribute, they will have a singular mesh path in USD, maintaining the original input path hierarchy upon return to LOPs.
FOR THE STATIC FRACTURED GEOMETRY We establish this relationship with a primitive @piecename attribute – which would be the concatenated string of the incoming mesh (ie @name) + the piece naming as derived from your fracturing process. @piecename = “mesh01-piece0-1” (while maintaining @path = “/root/myGeometry/mesh01”) @piecename = “mesh01-piece0-2” (while maintaining @path = “/root/myGeometry/mesh01”) … FOR THE SIMULATION POINTS We establish this relationship with a point @piecename attribute that differs from the fractured geometry in that it will be the concatenated string of the full path (ie @path) + the piece naming as derived from your fracturing process. @piecename = “/root/myGeometry/mesh01-piece0-1” @piecename = “/root/myGeometry/mesh01-piece0-1″“`
I feel if the docs kinda spelt this out a little more for the dummies in the back like me, they might make a little more sense than just a rote learning excercise in dropping nodes
I feel like the above falls under ‘assumed knowledge’ – but it’s only assumed by USD eggheads, not your average SOPsy artist looking to bring their workflows to LOPs
This is my take on: www.sidefx.com/docs/houdini/solaris/houdini_rbd_procedural.html