Nick Petit
npetit
About Me
Connect
LOCATION
WEBSITE
Houdini Skills
Availability
Not Specified
My Badges
SideFX Staff
Since Feb 2008
Recent Forum Posts
Invoke graph a Subnetwork with a Parallel for Compile Block Oct. 14, 2026, 2:55 a.m.
It looks like you're using expressions to drive the transform - expressions aren't fully supported, the expressions are evaluated at the current frame and each point representing the nodes stores its parms current values.
If you look at the geometry spreadsheet with the attribfromparm3 SOP, you'll see each point has a "parms" dictionary attribute - if you inspect the value for the point that represents the transform1 SOP you will see the "r" parm is stored as 3 floats of the parms current values, not the expression you have driving it.
Instead of driving an Xform SOP with an expression, you can use a point wrangle and plug the "foreach_count1" block begin SOP into its second input and rotate the points in VEX:
If you look at the geometry spreadsheet with the attribfromparm3 SOP, you'll see each point has a "parms" dictionary attribute - if you inspect the value for the point that represents the transform1 SOP you will see the "r" parm is stored as 3 floats of the parms current values, not the expression you have driving it.
Instead of driving an Xform SOP with an expression, you can use a point wrangle and plug the "foreach_count1" block begin SOP into its second input and rotate the points in VEX:
int iter = detail(1, "iteration"); float roty = 20.0 * iter; matrix3 rot = maketransform(0, set(0, roty, 0)); @P *= rot;
Strange artefacts on RBD Material Fracture Detail Aug. 11, 2026, 5:33 p.m.
Can you share the hipfile here? Otherwise, file a bug and submit the file there and I can take a look at it.
Floating RBD July 29, 2026, 2:06 a.m.
Not entirely sure what you're trying to achieve but there were a number of issues in the setup.
One big issue was the animation was done early on in the graph (a simple xform in Y) which makes the whole setup unnecessarily time dependent.
The main reason things aren't behaving as expected is you are then applying a transform pieces to the render geo only (not the constraints or the proxy geo).
The easiest way to fix the setup and improve performance is to move the animated transform just before the RBD Bullet Solver, and have it transform all 3 streams (render geo, constraints and proxy geo) at the same time by RBD Pack'ing the output of the RBD Configure SOP.
Here's an annotated version of your hip file that goes through a few of the issues and has the wall move upwards before getting hit by the collision sphere.
Generally, a good way to check the sim if it's not doing what you expect it to, is to visualize the sim geometry. On the RBD Bullet Solver > Visualization > Show Collision Shape. That shows the geometry Bullet uses in the sim (after the collision padding and shrinking is applied) and you would notice in your case it isn't moving upwards like the render geometry is.
One big issue was the animation was done early on in the graph (a simple xform in Y) which makes the whole setup unnecessarily time dependent.
The main reason things aren't behaving as expected is you are then applying a transform pieces to the render geo only (not the constraints or the proxy geo).
The easiest way to fix the setup and improve performance is to move the animated transform just before the RBD Bullet Solver, and have it transform all 3 streams (render geo, constraints and proxy geo) at the same time by RBD Pack'ing the output of the RBD Configure SOP.
Here's an annotated version of your hip file that goes through a few of the issues and has the wall move upwards before getting hit by the collision sphere.
Generally, a good way to check the sim if it's not doing what you expect it to, is to visualize the sim geometry. On the RBD Bullet Solver > Visualization > Show Collision Shape. That shows the geometry Bullet uses in the sim (after the collision padding and shrinking is applied) and you would notice in your case it isn't moving upwards like the render geometry is.