If you look at the RBD Bullet Solver SOP's help card, there is a RBDBulletSolverEmission example that shows how to prep assets for instanced emission.
As long as you pack the geometry before copying it onto the emission points, the geometry will be instanced. The RBD Bullet Solver will ensure names will be unique per instanced frame/step, but they do need to be unique between copied instances to start with.
Here is a simple hip file with 3 examples, going from simple to more complex. The last example packs each object (this could be fractured objects with constraints) using the RBD Configure SOP and then RBD Packs each one so it becomes a self-contained RBD asset that you can then copy onto emission points. The RBD Unpack SOP has an option to ensure names are unique for that very purpouse.
Found 181 posts.
Search results Show results as topic list.
Technical Discussion » Instancing with emit rbd
- npetit
- 360 posts
- Offline
Technical Discussion » Preventing Rocks from Falling Through the Ground During Rumbling RBD Simulation
- npetit
- 360 posts
- Offline
There's a number of ways to do this.
You could animate the packed RBDs rising before the sim, set them to animated=1 and active=0, and switch to active=1 and animated=0 once they're out of the ground (i.e: use the Winding Number SOP to figure out if a rock is inside the ground or not).
You could turn the ground collision geometry to a heighfield and push it down where the rocks are using a heightfield project, animate it returning to the shape you want over a few frames by animating upwards the rocks you are using to heightfield project, leave all the RBDs as active, they should slowly be pushed upwards.
You could animate the packed RBDs rising before the sim, set them to animated=1 and active=0, and switch to active=1 and animated=0 once they're out of the ground (i.e: use the Winding Number SOP to figure out if a rock is inside the ground or not).
You could turn the ground collision geometry to a heighfield and push it down where the rocks are using a heightfield project, animate it returning to the shape you want over a few frames by animating upwards the rocks you are using to heightfield project, leave all the RBDs as active, they should slowly be pushed upwards.
Houdini Indie and Apprentice » Cone Twist constraints in SOP's ?
- npetit
- 360 posts
- Offline
I can't say too much other than this should be a lot easier to setup in the next version of houdini with some significant improvements to the cone twist constraints in particular.
Technical Discussion » Convert Alembic to polygons?
- npetit
- 360 posts
- Offline
Depending on how the packed alembic comes through, it may not be "animated" but "deforming".
An animated RBD packed object expects packed static geometry which is animated via packed transforms - animation that lives on the packed geo.
If the animation lives on the mesh points themselves, i.e you unpack or convert the packed alembic to poly before packing it again, this is now a deforming RBD - the internal geometry needs to be rebuilt at every time step. If you don't import it as such, it'll appear to be frozen at the first frame.
Depending on what you are trying to do, it's best to try and avoid deforming RBDs where possible as they can have a significant impact on performance, as well as not playing nice with constraints.
If the packed alembics are animated, you should be able to use them directly in sim without needing to first unpack or convert to poly.
If they are deforming, you could try using the RBD Deforming to Animated SOP if the geometry is split up into various named pieces. If that doesn't do the trick, you may need to first chop up the deforming geo into various small pieces that can be rigidly transformed while still giving a decent representation of the deformed mesh.
An animated RBD packed object expects packed static geometry which is animated via packed transforms - animation that lives on the packed geo.
If the animation lives on the mesh points themselves, i.e you unpack or convert the packed alembic to poly before packing it again, this is now a deforming RBD - the internal geometry needs to be rebuilt at every time step. If you don't import it as such, it'll appear to be frozen at the first frame.
Depending on what you are trying to do, it's best to try and avoid deforming RBDs where possible as they can have a significant impact on performance, as well as not playing nice with constraints.
If the packed alembics are animated, you should be able to use them directly in sim without needing to first unpack or convert to poly.
If they are deforming, you could try using the RBD Deforming to Animated SOP if the geometry is split up into various named pieces. If that doesn't do the trick, you may need to first chop up the deforming geo into various small pieces that can be rigidly transformed while still giving a decent representation of the deformed mesh.
Technical Discussion » RBD bullet solver cone twist constraint
- npetit
- 360 posts
- Offline
Here's a quick example showing how you might setup some conetwist constraints to use with the RBD Bullet Solver SOP.
Notice I'm only driving a few of the conetwist constraint properties via attributes on the constraint prims.
If you want different settings per constraint for other properties, you'll need to add them as attributes and make sure their default values (which will be multiplied by the prim attributes) on the RBD Bullet Solver are set to 1.
The tricky thing with the conetwist constraint would have to be the motor_target. It's not very intuitive in the slightest. While the parameter on both the RBD Bullet Solver SOP and the ConeTwist ConRel DOP specify a motor_targetr vector param, you need to set a quaternion motor_target attribute. This attribute needs to be updated at every timestep, so make sure you add it to the list of constraint attributes to be updated by the RBD Bullet Solver.
Notice I'm only driving a few of the conetwist constraint properties via attributes on the constraint prims.
If you want different settings per constraint for other properties, you'll need to add them as attributes and make sure their default values (which will be multiplied by the prim attributes) on the RBD Bullet Solver are set to 1.
The tricky thing with the conetwist constraint would have to be the motor_target. It's not very intuitive in the slightest. While the parameter on both the RBD Bullet Solver SOP and the ConeTwist ConRel DOP specify a motor_targetr vector param, you need to set a quaternion motor_target attribute. This attribute needs to be updated at every timestep, so make sure you add it to the list of constraint attributes to be updated by the RBD Bullet Solver.
Technical Discussion » Python Panels, Parameter Panes, and Multiple Node Instances
- npetit
- 360 posts
- Offline
I'm not sure what you mean - is the xform state a python state for one of your HDAs?
You can't send args to the onEnter callback (or any other callback for that matter) of a state, it's all handled internally. The only way you have of communicating with a state is via the command interface - the state needs to implement onCommand and define which commands it will listen for and execute... a xform SOP doesn't have a state, it has a handle directly hooked into its parms.
If you are talking of having your own code activate a xform SOP, then you can definitely set whatever transforms you want directly on the node's parms.
If this is all happening from one of your HDA's states, then keep in mind that activating a node's state will kick you out of your own HDA's state, so you have no control over what happens next.
You can't send args to the onEnter callback (or any other callback for that matter) of a state, it's all handled internally. The only way you have of communicating with a state is via the command interface - the state needs to implement onCommand and define which commands it will listen for and execute... a xform SOP doesn't have a state, it has a handle directly hooked into its parms.
If you are talking of having your own code activate a xform SOP, then you can definitely set whatever transforms you want directly on the node's parms.
If this is all happening from one of your HDA's states, then keep in mind that activating a node's state will kick you out of your own HDA's state, so you have no control over what happens next.
Solaris and Karma » Retime USD
- npetit
- 360 posts
- Offline
GrahamDClark
Any recommendations to make it better/more correct?
I would drive the 'timey' attribute by distance or something. And so I think I excluded 'timey' from being also updated in the python. It still gets slow on lots of stuff.
The only thing I'd change in your code is the
if timey is not None: frame = curFrame * node.evalParm("timescale") - timey
and replace it with
frame = curFrame * node.evalParm("timescale") - (timey if timey != None else node.evalParm("frameoffset"))
this is to ensure you reuse the frame offset from the parm if timey doesn't exist on the current prim as opposed to whatever the last prim with a valid timey attrib set your frame variable to.
Otherwise, if you know you have all the timesamples you care about, you could make the python LOP non-time dependent by grabbing all the timesamples on the animated attribs, deleting them from the attrib and re-applying them with the time offset - this would avoid having you invoke hou.frame(). This is only really an option if the input node isn't time-dependent - you'd get a bigger initial hit but then scrubbing the timeline would be free since the python LOP won't be time-dependent and its result cached.
GrahamDClark
Could I vex it for speed?
You could use VEX, using
usd_attrib(<stage>, string primpath, string name, float timecode);
Solaris and Karma » Retime USD
- npetit
- 360 posts
- Offline
fadjo
Hello, Is there a way to retime cameras too?
Actually, I spoke too soon. After talking to Mark and looking into the hip file a bit more in depth, the timeshift is doing what it's supposed to, and only offsetting the time samples on the specified prims. The problem is the transform for the camera is coming from its
/cam
parent which has been omitted from the list of prims to retime. If you add /cam
to the timeshift LOP's primitives parm, you'll have the camera motion retimed as expected. Now, looking at the viewport after the timeshift LOP, it looks like the whole stage is being retimed - however the time samples that are being displayed are for different frames - but having only 1 time sample on the stage at the current time, that's what's being displayed.
Writing the sequence of frames to disk will fix that, or, dropping a cache LOP either before or after the timeshift LOP will ensure the correct thing is being displayed in the viewport since more timesamples are available.
Technical Discussion » Breaking glue constraints RBD solver
- npetit
- 360 posts
- Offline
AndyWWhat platform are you on? The hipfile I posted should definitely break on the second impact. Here are frames 30 and 50 of the sim.
The hip file you posted doesn't break on the second impact when I run it, I'm on H19.5.303 . Here's my test setup
In your setup, you're setting the strength to 0 on frame 25 which would be almost the same as simply deleting all the constraints at frame 25.
Here's a hipfile with a few options that show how you can control the breaking explicitly.
Solaris and Karma » Retime USD
- npetit
- 360 posts
- Offline
That should work, and you can see that adding a cache LOP gets the camera to reflect the retime - this looks like a bug.
In the meantime, if you want to retime any particular prim instead of the entire stage, you can do it fairly easily with a Python LOP - you just need to make sure there are timesamples available on the attribs that need retiming.
In the meantime, if you want to retime any particular prim instead of the entire stage, you can do it fairly easily with a Python LOP - you just need to make sure there are timesamples available on the attribs that need retiming.
Technical Discussion » Python Panels, Parameter Panes, and Multiple Node Instances
- npetit
- 360 posts
- Offline
You don't have access to the python state directly, however, you can set the node to current, activate its state and send it commands.
And in your state, you need to implement the onCommand(self, kwargs) method.
import toolutils node = hou.node(<path to node>) sceneviewer = toolutils.sceneViewer() if sceneviewer.currentState() != <python state>: sceneviewer.setCurrentNode(node) sceneviewer.setCurrentState(<python state>) sceneviewer.runStateCommand(<command name>, kwargs)
And in your state, you need to implement the onCommand(self, kwargs) method.
Technical Discussion » Breaking glue constraints RBD solver
- npetit
- 360 posts
- Offline
The "From Frame" option in the constraint breaking thresholds tab of the RBD Bullet Solver SOP limits the evaluation of the thresholds to only be performed from that frame onwards. This means if any of the conditions are met at that particular frame for all the constraints, they will all be removed at that frame. Without seeing your hipfile, it's hard to tell why exactly they are all disappearing at that frame.
This however does not prevent Glue constraints from breaking beforehand - Glue constraints are unique in that they are the only constraints that have their own internal breaking mechanism. The RBD Bullet Solver introduced the constraint breaking thresholds as an additional constraint solver to allow all the other constraints to break too. Typically Glue constraints aren't evaluated by the constraint breaking mechanism (you can see the "Glue" constraint name missing from the default constraint names) since many of the thresholds simply don't apply to them.
One way to achieve what you're after is to set the glue constraint strength to -1 (unbreakable) until the frame at which you want to allow them to break under whatever condition you see fit.
In 19.5 we made updating the constraint attributes from SOPs a lot simpler. If you animate the strength attrib on the constraint prims, on the RBD Bullet Solver SOP, under Constraints > Override Attributes, enable Attributes and set it to strength.
Here's a hipfile as an example.
There are many other ways to do this however.
You could accumulate impact data on the RBD pieces and break the constraints manually after a certain number of impacts on the constraints anchored RBD pieces.
You can get info from the impact points and use it to determine which object the RBD pieces have collided with and only break the constraints if their anchored RBD pieces collide with a specific object.
You could accumulate the impact on the constraint prims and break them once they've reached a certain threshold, or do the same with a force (that's a nice way of having wind slowly break constraints to release fractured pieces over time)
...
Hope this helps and gives you some ideas on how to solve your issue!
This however does not prevent Glue constraints from breaking beforehand - Glue constraints are unique in that they are the only constraints that have their own internal breaking mechanism. The RBD Bullet Solver introduced the constraint breaking thresholds as an additional constraint solver to allow all the other constraints to break too. Typically Glue constraints aren't evaluated by the constraint breaking mechanism (you can see the "Glue" constraint name missing from the default constraint names) since many of the thresholds simply don't apply to them.
One way to achieve what you're after is to set the glue constraint strength to -1 (unbreakable) until the frame at which you want to allow them to break under whatever condition you see fit.
In 19.5 we made updating the constraint attributes from SOPs a lot simpler. If you animate the strength attrib on the constraint prims, on the RBD Bullet Solver SOP, under Constraints > Override Attributes, enable Attributes and set it to strength.
Here's a hipfile as an example.
There are many other ways to do this however.
You could accumulate impact data on the RBD pieces and break the constraints manually after a certain number of impacts on the constraints anchored RBD pieces.
You can get info from the impact points and use it to determine which object the RBD pieces have collided with and only break the constraints if their anchored RBD pieces collide with a specific object.
You could accumulate the impact on the constraint prims and break them once they've reached a certain threshold, or do the same with a force (that's a nice way of having wind slowly break constraints to release fractured pieces over time)
...
Hope this helps and gives you some ideas on how to solve your issue!
Technical Discussion » Collision Geo changes Bullet Solver behaviour
- npetit
- 360 posts
- Offline
If I remember correctly we changed the order in which the collision and rbd objects are created between 18.5 and 19 or 19.5.
In your setup, $OBJID returns the incorrect index and cannot find the constraint geometry, and thus starts shrinking all of the pieces immediately.
Try replacing $OBJID with `dopobjscreatedby("../../rbd_object/")`
In your setup, $OBJID returns the incorrect index and cannot find the constraint geometry, and thus starts shrinking all of the pieces immediately.
Try replacing $OBJID with `dopobjscreatedby("../../rbd_object/")`
Technical Discussion » rbdmaterialfracture
- npetit
- 360 posts
- Offline
Technical Discussion » rbdmaterialfracture
- npetit
- 360 posts
- Offline
Yup, that's one of the current limitations of the glass fracturing - it needs to be able to find the edges of the glass pane so the 2D detail noise that gets applied after the fracturing can be faded out near the edges so as to prevent internal faces from poking out. This doesn't work with curved glass and is exactly the problem you're facing.
Another big problem with this approach is it creates cracks and holes in the high-res geometry where adjacent pieces have points resulting from the internal faces remeshing prior to the noise being applied, do not line up.
The solution I sent you above is slightly different to the new curved glass fracturing in the next release (which is an option on the rbd material fracture's glass fracturing), but it should give you a bit of an idea as to how to go about it.
The main thing is the concentric crack points use a wrangle to get each piece's name attribute - internally this means only those points will be considered when fracturing each piece. Since you first need the radial cracking to be done before you can know what name each piece will have, you need to perform this with 2 RBD Material Fracture nodes, each time feeding them the crack points.
Hope that helps!
Another big problem with this approach is it creates cracks and holes in the high-res geometry where adjacent pieces have points resulting from the internal faces remeshing prior to the noise being applied, do not line up.
The solution I sent you above is slightly different to the new curved glass fracturing in the next release (which is an option on the rbd material fracture's glass fracturing), but it should give you a bit of an idea as to how to go about it.
The main thing is the concentric crack points use a wrangle to get each piece's name attribute - internally this means only those points will be considered when fracturing each piece. Since you first need the radial cracking to be done before you can know what name each piece will have, you need to perform this with 2 RBD Material Fracture nodes, each time feeding them the crack points.
Hope that helps!
Technical Discussion » rbdmaterialfracture
- npetit
- 360 posts
- Offline
Here's an example of how to use the RBD Material Fracture SOP's concrete fracturing with custom input points to recreate the glass fracturing patterns.
Technical Discussion » rbdmaterialfracture
- npetit
- 360 posts
- Offline
This definitely shouldn't happen, however glass fracturing as it stands has some limitations which have been addressed for the next release with an entirely new and more robust method for giving you those types of fractured patterns while also supporting curved surfaces.
Is it possible for you to share the geometry you're having issues with?
Is it possible for you to share the geometry you're having issues with?
Technical Discussion » Vehicle jump speed too fast.
- npetit
- 360 posts
- Offline
We added an option on the RBD Bullet Solver SOP to add an "age" attribute to the RBD pieces, as well as an "active_age" attribute and Just Activated group to make it easier to inject entirely new forces into the sim on activation. This helps identify pieces that have just switched from animated or deforming to active.
Here's an example of how it can be used to do what you're after. Notice though that by default the RBD Bullet Solver updates the v and w attributes on the animated RBD pieces so when they switch from animated to active their momentum is preserved - no need for any v or w injection.
Here's an example of how it can be used to do what you're after. Notice though that by default the RBD Bullet Solver updates the v and w attributes on the animated RBD pieces so when they switch from animated to active their momentum is preserved - no need for any v or w injection.
Technical Discussion » Python Panels, Parameter Panes, and Multiple Node Instances
- npetit
- 360 posts
- Offline
It's not the pypanel that is doing anything with handles - the handles are registered with the nodes' python states. The pypanel simply sends commands to the python state that then does whatever is needed to show/update the handles as required.
Technical Discussion » Delete a fractured piece from dynamic sim?
- npetit
- 360 posts
- Offline
That hip file was saved in 19.5 and makes use of a newer dopimport::2.0 SOP.
Replace it with an old dopimport SOP, set the import style to "Create Points to Represent Objects", set the dop network to "../dopnet1" and the object mask to "rbdpackedobject1" - now the sphere pieces should move again.
You may need to attrib delete the path attribute created by the assemble SOP.
Replace it with an old dopimport SOP, set the import style to "Create Points to Represent Objects", set the dop network to "../dopnet1" and the object mask to "rbdpackedobject1" - now the sphere pieces should move again.
You may need to attrib delete the path attribute created by the assemble SOP.
-
- Quick Links