The Particle Fluid Emitter is still available and should work as in previous versions, just plug it into the second input of the FLIP Solver. The code to set up the emitter from the shelf is still there as well, so you can get the old behavior from a custom shelf tool with the following code:


import doptoolutils
doptoolutils.particlefluidAddEmitterOrSink(kwargs, “emitter”)


The SDF-based emitters should actually be a good bit faster as you move to higher particle counts. If you run a sim with an SDF-based emitter with the performance monitor active, where is the time going?

goshone
2. Any idea what causes this to happen so I can avoid it in the future? I suspect is is using the wrong point to transform the corresponding piece. I have tried to be exact in the way I link points to pieces, using this expression to get the info:

dopfield( “/obj/AutoDopNetwork”, “piece`$ID-2`”, “CopyInfo”, “Options”, 0, “copynum” )

which is entered into the variable value field for stamping on the copy SOP. I use the $ID-2 to get the proper piece number. Again, this works flawlessly when not using clustering.

I believe the problem is with this expression. Basically it will work as long as your RBD piece names are successively named one after another, but in some obscure cases with clustering turned on that is not the case.

You're better off using the “id” attribute that DOPImport sets on the points to look up the object name of the RBD object, which also corresponds to the group output by the original VoronoiFracture SOP.

So you would stamp an “id” token on the copy sop, then use an expression in your Delete SOP like:

`dopobjectlist(“/obj/AutoDopNetwork”, stamp(“../copy1”, “id”, 0), 1)`

This is just using dopobjectlist to look up the object name from its id.

It turns out you can avoid the delete altogether, since the Source Group on the Copy SOP appears to be re-evaluated for each stamped value. So you can disable the delete and set the Source Group to:

`dopobjectlist(“/obj/AutoDopNetwork”, $ID, 1)`


This is a fair bit faster since it's not having to recook the input SOPs and delete geometry for each copy.

I've attached your example using this technique.

Edit:

I should add, probably a better way to do this is with two DOPImports set to Transform Input Groups, one that updates the low-res piece positions for preview, the other that transforms the identically named high-res groups (without ever actually sending that high-res geometry to DOPs).

This should be faster, handle transferring velocities to the pieces better, etc. Change the Connectivity Partition setting on the VoronoiFracture SOPs to Maintain Piece Numbering, which will help keep the piece names consistent with slightly different geometry. See attached.

You might have reversed polygons. Turn on Display Primitive Normals and make sure they're facing outwards. If not, apply a Reverse SOP before fracturing.

Alternatively, on the Groups tab on the VoronoiFracture node, just clear out the values for the names of the Interior and Exterior groups, and those groups won't be created in the first place.

You can use the Gas Reduce DOP to calculate the min or max of a field and store it another field (and constant fields use very little storage). Then use the min and max fields as parameters to your GAS Field VOP.

Two things to look at:

Cluster should work with a flat grid, just make sure to turn off “Create Inside Surface” on the VoronoiFracture SOP. That generally makes everything work better for 2D surfaces.

Then look at “Delete Exterior Cluster Edges” on the Cluster tab (not the best name in the world , which tries to clean up any edges left over after the cluster operation.

Unfortunately that the underlying Dissolve operate can cause artifacts with large flat polygons like those in a box, but you can usually work around it by changing the Offset of the Cluster noise.

Hi Detlef,

In your file, there's no DOP Object for the Magnet. If I add a Static Object representing the Magnet, then put “Magnet” into the ImpactGroup parameter, the Feststoff object bounces off Collision and fractures when it hits the Magnet. Is that what you want?

FWIW, I put an example of another way of emitting debris with the dynamic fracturing tools here. [forums.odforce.net]

There's an example in this thread [sidefx.com] that shows a way of generating more splinter-like fractures using the VoronoiFracture tools. It's based on the old asset from H10, but it should be straightforward to update to H11.

Yes, you can't fetch the object from DOPs until after its Creation Frame. So a Switch SOP like you've done is a good way to go. For motion blur you'll want to turn on “Geometry Velocity Blur” at the Object level, which will use the point velocities from the Trail SOP and the DOPImport SOPs.

I think it's great for an in-depth view of the RBD Solver. I believe there have been some changes in constraints since it was made, but otherwise it remains pretty accurate.

Plus it will make you grateful every day for the H9 interface upgrade

For SOP level animation it depends on whether you want to simulate deforming geometry, or hand off the animation of the object completely to DOPs at some point.

In the first case you can turn on “Use Deforming Geometry”, which does what it sounds like but can be slow as the collision SDF needs to be re-computed each timestep.

For the second case, append a Trail SOP set to Compute Velocity, which adds a velocity attribute to each point of your geometry, then turn on “Inherit Velocity from Point Velocity” on the RBD Object. Then set the “Creation Frame” to the frame when your SOP-level animation ends. See attached for an example of this technique.

I would get the animation hand off working before introducing the fracturing tools. Read this section [sidefx.com] in the Houdini docs about transferring animation to DOPs.
The VelocityTransfer on the fracture node controls how the pieces inherit velocity from the intact object at fracture time.

At the moment you have a tranform at the Object level, and animation at the SOPs level. I would consolidate those to the object level, or, since you want to fracture things later, maybe move it all to an RBD Keyframe Active node.

I copied your animation channels to an RBD Keyframe Active node, and that seems to work fine. Just set the Bypass flag on the fractureParms node while tweaking the animation.

I also set the DOPnet Substeps to 2 since the fracturing transition is smoother when you do that.

roughsporty
prefracturing is a artistic way to control the fracture behaviour. But what if I want to have also the artistic control of a second or third fracture. The makebreakable tool doesn't work for such things right?

You certainly get more control from pre-fracturing, although there are some settings on the “fractureparms” node you can tweak to get more control of dynamic fracturing.

Basically everything on the “Impact” tab of that node is a filter, with most parameters causing things not to fracture, i.e. all the conditions have to be met for a fracture to occur.

All of the parameters can be set on a per object basis using expressions or groups, so you can delay fracturing until an object is below a certain height, or only when it hits a certain object, etc.

I put an example file here [forums.odforce.net] that shows some more advanced uses of these parameters. In particular there's one that shows using the Break tool and RBD Glue Object for the primary fracture, then dynamic fracturing only on the pieces, with a couple of ways of limiting when the secondary fractures occur.

circusmonkey
While I am here is there any way to get the fracture tool to output point groups ?

Do you mean that instead of primitive groups called “piece0”, etc. you have point groups?

You can take over group creation by turning off “Create Output Groups” on the Groups tab, then turn on “Keep Internal Attributes” on the Attributes tab. That will give each primitive a “piece” attribute. You could AttribPromote that to points and Partition to create point groups.

Is that what you had in mind?

Hi Rob,

Can you give any more detail on your geometry? I've run some pretty high resolution geometry through it. The underlying VoronoiSplit SOP is multi-threaded and should perform pretty well, although it can be a bit memory-hungry.

I could probably generate some fracture times for “standard” geometry like the Stanford bunny or dragon if that's helpful.

And just to be clear, you're talking about SOPs, here, right, not dynamic fracturing?

Edit:

Try the attached file, which just uses the VoronoiSplit SOP and bypasses all the group creation, clustering, whatnot in the VoronoiFracture SOP, just to make sure that's not the problem.

This is a torus with about 1600 polys, which fractures into 500 pieces in about 1.5 sec on my machine (which is pretty fast - the machine that is).

Er, turns out the “Enable Fracturing” parameter is internally set to “Set Always” within the VoronoiFractureConfigureObject, so actually the easiest way to do what you want is probably:

Group DOP to create a group “tofracture” with whatever objects
“Enable Fracturing” parameter set to:

dopgrouphasobject(“.”, $OBJID, “tofracture”)

Howdy,

The VoronoiFractureConfigureObject DOP is set up like the other *ConfigureObject DOPs. They all attach data to objects and set their parameters at a fairly coarse level, then the idea is you can use the different data DOPs below that in the network to tweak these values.

So, for example, if you created a bunch of objects via the RBD Point object but wanted a few to have a very high friction, you'd set the typical values at the RBD Point object level, then use a PhysicalParms DOP to change the friction (by affecting the attached PhysicalParms data) to change the friction on selected pieces.

Similarly, the VoronoiFractureConfigureObject DOP sets the fracture parameters for all the objects, then you can tweak the values on a per-piece basis by using a VoronoiFractureParms DOP.

You could also turn the Default Operation on the VoronoiFractureConfigureObject to “Set Always” then set the Maximum Fractures parameter to something like:


if(dopgrouphasobject(“.”, $OBJJID, “to_fracture_group”), 1, 0)


Dynamic fracturing is a bit special in that it has its own solver that runs after the RBD Solver, and you can turn that off entrirely by setting the “Enable Fracturing” parameter to 0. That sets a value for a SwitchSolver that will completely bypass fracturing. You can then use a SwitchValue DOP to turn it back on for just those objects you want. This will be the fastest approach for lots of Point/Glue objects, where you only want to fracture a few of them.

I'm attaching an example that shows a few different ways of conditionally fracturing pieces from an RBD Glue Object. Note the VoronoiFractureParms DOP has a bug in its parameter layout. All the data is correct, but the layout looks a little wonky past the first tab.

Below is a quote from the sticky in the .hip:

There are four possible DOP network paths shown here. In the first the glued objects are always allowed to dynamically fracture, so the initial impact will fracture the middle piece while the others stay intact until they hit the groundplane.

In the second, the Voronoi Fracture Configure Object has its Default Operation set to “Set Always”, and has an expression in the Maximum Fractures parameter that only allows dynamic fracturing once the objects have dropped below the initial point of impact with the stationary tube.

In the third, all objects start out with maxfractures set to 0, then a VoronoiFractureParms DOP is used to set it higher on a piece-by-piece basis.

In the fourth, dynamic fracturing is disabled completely, then
enabled using a SwitchValue DOP. This will be the fastest for larger numbers of objects, since the fracture solver won't run at all for those objects with fractured disabled.

Hope that helps

cybermax
I'm trying to optimize the process of loading objects and try to implements convex decomposition using multiple-threads. But no result.

When I write # include <pthread.h>, compiler says “file not found”.

I use VS2005 on 64bit Win7

Did someone similar problem???

If this is a Houdini plugin, you might try the multi-threading support built into the HDK, which should work on any platform Houdini runs on.

http://www.sidefx.com/docs/hdk11.0/hdk_multithreading.html [sidefx.com]

Also, like all the other forces, you can add a Noise Field to the second input of the Magnet Force to modulate its intensity.