Voronoi - dynamic - location based fracture (WIP)

[johner]

I got a question, is that the final geo for DOPs?, or is still the "low res" geo the one you pass to DOPs?

actually it could be a good idea to have both options.

Good question. I think you could use it either way. DOPs actually seems to do a pretty good job with the higher detail interior. One reason for that is that with the regular, planar interior surfaces, a lot of times you need to turn on the "Edges" representation and "Triangulate" in the Collision params for the objects to avoid interpenetrations, which slows things down a lot. With the interior detail, you've already got enough point resolution that you don't need that anymore. So you can use only point/volume collisions that DOPs does quite well and quickly.

That said, you could certainly use the low-res output as proxy geometry, provided you didn't add so much noise to the interior to dramatically change the shape of the objects. You could put two Fracture SOPs with the same inputs, but one adding the interior detail. The output pieces will be named that same and have roughly the same shape, so you could send the lowres into DOPs and then use a DOPImport to transform the hires pieces.

I'll try to remember to add an example of doing this when I get the interior detail stuff sorted out.

Edited August 28, 2009 by johner

[Mario Marengo]

... and this topic should be pinned.

Great work, Johner!

[fxrod]

... pinned and become the Houdini standard way of breaking things!

We have many variations of fracturing tools at R&H and this is by far the best way of doing this. Used in conjunction with some other fracturing tools (using cookie) the user can have some really good control over the art-direction of the fractures. In other words, make the hero cuts, then use this on those hero cuts to break into smaller pieces.

[johner]

I have a couple of questions, What it the best method to get the simulated fractured geo (from a dynamic fracture sim) back from DOP's into SOP's? or is your intention to render direct from DOP's.

Also, I meant to point out to anyone trying out the dynamic fracture stuff, there was a Houdini bug fixed in 10.0.372 that fixes the re-fracturing problem I was asking about earlier, so make sure you have at least that version (or earlier than 10.0.295 or so).

Monday, August 17, 2009

Houdini 10.0.372: Fixed under-cooking problems that could occur when using stamp() (or stamps()) exp​ressions in Houdini.

[elipse]

Cheers Johner,

forgot the old object mask!!

That surface detailing is looking pretty cool too!!

In your otl is there any randomness for whether an object fractures or not? I know you've got your force thresholds and delay for next fracture, but I think it would be cool to add a random factor to it also, so for example an object that is outside your thresholds may actually fracture and one that is within them maynot.

Cheers

Chris

[johner]

If I have Connect Inside Edges on and Cusp Interior Edges off, I will get a closed surface (no faceted faces). If I render this, I get shading artifacts at the edges. I'm wondering if there's a solution using creaseweights that would allow these surfaces to shade smoothly over creases. The reason I ask is because I would like to add true displacements to my surfaces and I can't do that with faceted faces.

Maybe we can add creaseweights to the edges on the exterior pieces? I'll see if I can whip up an example of what I mean.

By the way, I'm finding Mantra does a really nice job on the interior detail stuff when rendered as subd's (non-flat quads and all), so having some way for the user to easily set creaseweights sounds like a good idea.

Edit: attached a quick example. Just an environment light on the last frame of a fractured sphere sim, "render as subdivision surfaces" on, no creaseweights or anything, stock granite material with bump mapping only. So low-frequency detail from geometry, hi-frequency from the shader. Looks pretty granite block-ish, I think. Also attached is the viewport view. I sim'd the hires geo here, but it certainly could have been done with proxy geo like varomix was asking about.

In your otl is there any randomness for whether an object fractures or not? I know you've got your force thresholds and delay for next fracture, but I think it would be cool to add a random factor to it also, so for example an object that is outside your thresholds may actually fracture and one that is within them maynot.

Not at the moment. The dynamic fracturing needs a fair bit of attention at some point.

Edited August 28, 2009 by johner

[MagnusL3D]

I would be curious if there was some smart way to reduce the polycount after the deformation, without having the poly reduction destroy the edges between pieces.

but hey thats just a though and this work is purly amazing, looking forward to see more ! keep up the good work.

/M

[fxrod]

Hey John:

I think there are precision errors with the voronoi fracture otl that aren't allowing chunk faces to be closed correctly. I have posted a hip file that illustrates this.

Here's what's contained in the network.

1. A 100x80x300 box
   
2. Scattered points on the fog volume.
   
3. Both the box and scattered points are moved away from the origin, frame by frame, and fractured.
   
4. One chunk is isolated and you can see that surfaces are not closing correctly. Check out frame 52 while displaying the blast SOP.
   

If I dive into the ../cut_piece_for_each_point/cut_at_clip_plane_for_each_nearest and bypass the clip_keep_just_cap SOP, it seems to work correctly. I think it's because you are clipping the capped geometry by just a tiny amount (-0.0001) and there is enough of a discrepancy between the clip distance, origin, and direction to cause an error. I think this might also be a problem if you have a very large object (say 100000.12 x 100000.12 x 100000.12) because you are deriving the distance and direction by subtracting the nearest point by the sample point, both of whose position values might be rather large. I understand that Houdini has a precision of 8 digits, so it will truncate a value such as 100000.123 to 100000.12. This might be enough to throw things off.

Normalizing the scale of the geometry and moving it to the origin before fracturing seems to work. Would it make sense to add this into the otl, if this is the case?

voronoi_fracture_precision.hip

[johner]

Hey John:

I think there are precision errors with the voronoi fracture otl that aren't allowing chunk faces to be closed correctly. I have posted a hip file that illustrates this.

Hi Francisco,

Thanks very much for the report; that's a good test case. You're absolutely right about the cause of the problem, the question is the best way to give the user a way to fix it. That second Clip SOP in there that you diagnosed, the clip_keep_just_cap SOP, is really just there to attempt to cut non-watertight meshes, which I suppose might be useful in some unusual cases. But I've been doing some benchmarking with some higher-res meshes and looking for SOPs to remove or bypass in many cases (especially in the inner loop like that), and I have to figure that the vast majority of meshes sent through this thing will be watertight, so maybe there should be an option to bypass that second Clip?

So add an option, defaulted to off, of "Input Geometry is Non-watertight" or (non-manifold, maybe, or some better wording), and also expose this second Clip SOP's bias value at the asset level and enable only when it needs tweaking. Most of the time you wouldn't have to mess with it and there'd be a very slight performance boost from not doing the second clip, but it's there in cases like yours.

Any thoughts?

Thanks again

[fxrod]

I'm inclined to say that the tool should be limited to manifold geometry and would error out if it is not. I'm having a hard time visualizing how this tool would work with non-manifold geometry. Is there an example where turning the "Input is Manifold" checkbox would be useful?

BTW: Thanks for all the quick replies!

[johner]

I'm inclined to say that the tool should be limited to manifold geometry and would error out if it is not. I'm having a hard time visualizing how this tool would work with non-manifold geometry. Is there an example where turning the "Input is Manifold" checkbox would be useful?

Well, I guess my answer would be, because it actually sort of works to use non-manifold geometry, so why not leave it as an option? I'm right in the middle of abusing, er, testing the toon character with the idea of figuring out ways to use this on a deforming character. Just a second ago I made a group of the characters left hand, then put that into the "Group to Fracture" field of the Fracture SOP, which basically just cuts the group off, fractures it, then merges everything back together. So the hand geo in this case will be hollow, since it was cut off at the wrist. Attached is a picture of the topmost, hollow piece looking down into it with the rest of the hand templated. The rest of the hand pieces will be solid. Send all of them into DOPs with the SDF generation set to "Laser Scan" and it generates a very respectable collision volume and simulates fine.

Is this useful? I don't really know yet, but it's already there so why not leave it in or at least make it an option defaulted off so it doesn't mess up the more typical cases. Thoughts?

Edited September 3, 2009 by johner

[fxrod]

Sold! I can see why this would be useful in this case.

I think we should add it as an option (toggle) in the otl.

Also, any chance we'll see the volumesample/noise stuff in the asset? Is this something that should remain a post-process? I've worked out my own solution but am curious to see what you thought about adding it to the asset.

[johner]

Also, any chance we'll see the volumesample/noise stuff in the asset? Is this something that should remain a post-process? I've worked out my own solution but am curious to see what you thought about adding it to the asset.

Yup, I should have a release out in the next few days with that and a few other features. When I say post-process all I really mean is the detail/noise is added further down in the OTL network from the main ForEach loop that does all the cutting, which is the main performance bottleneck. So (assuming you don't have insanely high SOP caching levels throwing away geometry), the results of the cut will be sitting in a node in the OTL and all the interior detail stuff can be tweaked downstream without re-cutting.

There's a couple more features I added that require re-cutting, and I'm going to try to keep their parameters in the "Cut Settings" part of the parameter page as a reminder that changing them re-cooks the cutting, but you should be able to tweak everything else without doing so.

[johner]

One interesting thing I realized now that there's the whole interior detail/noise feature (which I promise to release soon):

One possible way to do the cutting involved in the fracture process would be to cut the geometry representing the Voronoi cells of the input points from the bounding box of the object, rather than the object itself. Then just do a ForEach and iterate over each cell geometry and Cookie that against the original geometry set to intersection and merge the results. One cut operation would look something like the following:

So there's a slightly expanded bounding box, the original input (tube) geo, and the Voronoi cell geo all templated here, showing the result of the Cookie OP set to Intersection. The exact same result as the Clip approach used currently in the Fracture SOP, so not that interesting a way to do it as Clip is more robust than Cookie.

But once you add the ability to add detail/noise to that Voronoi cell geometry cut from the bounding box, the results get more interesting:

Since the bbox is slightly expanded, the noise on the cell geometry exists at the surface of the input geometry, so the cut at the surface is no longer planar. But since the geo coming out of the Fracture SOP is nice clean, watertight geometry, the Cookie SOP actually does a decent job with it, and you still get all the control of cell point placement, density, etc. I wouldn't trust it for purely procedural fracturing, but for something that can be babysat it might be an interesting use. Quick animation here (where you can also see some minor Cookie artifacts).

No idea if this actually belongs in the Fracture SOP itself, but I'll include an example of using the output of it this way in the next release.

Edited September 4, 2009 by johner

[fxrod]

Hi John:

We use a very similar technique at R+H that I developed some time ago, where we would iterate through boolean shapes that would cookie the source geometry. The attractive thing about the clip is its reliability. We found that when you do a large number of fractures, you run the risk of the cookie not working. And, since you'd have to jitter to get the errant cell(s) to cookie correctly, you would need some way to find that iteration and jitter just on that cut. Also, since we work in centimeters, you run into those messy precision errors when working with large geometry.

Craig Zerouni posted a Fracture SOP on the Exchange that uses a SOP Solver instead of a Foreach. This allowed us to control the jitter of the cookie on a per timestep basis. However, Craig admitted to me that he would have used a Foreach if he had it when he built it.

So, all in all, I tend to favor the clip and the volumesample solution IMHO.

[johner]

Yeah, having played with this setup some more I really began to miss the clean geo and fairly bullet-proof output of the Clip/detail/noise approach, so I think this probably belongs in example-land.

I remember Craig's Fracture SOP, pretty darn impressive for no real iteration tools at the time. I think the problem with all the iterative techniques is you're sending each piece of geometry through the Cookie SOP multiple times, and each time it comes out a little dodgier than the last until it can't handle it anymore.

The approach I described above has the advantage that each piece of geometry is only Cookie'd once, and is really clean going in. If it doesn't work for a particular piece, you just change the GroupMask in the ForEach to exclude it (or delete it afterwards) and Cookie it with its own settings and merge everything back together again. You're not tweaking things on a particular cut then having to re-run all the cuts after it.

But I agree about reliability, so like I said, maybe just an example, and you use a setup like that if there are cases where every single surface cut just has to be non-planar for some reason.

[johner]

OK, finally time for a new release!

The main additions in this release are the interior detail / noise, although there's a few other features and some new examples. In particular look at "interior_detail" and "fracture_cookie" in the basic_fracture_examples.hip. There's also a new examples file, DOPs_examples.hip, showing various ways (OK, two) of using the output of the Fracture SOP in DOPs. There's an example there of using it to create lo-res proxy geometry.

A few bugfixes as well: here's a quick flipbook of dynamic fracturing with an animated metaball exposion, with detail being added to the generated pieces. There's also a first pass at Help for the Fracture SOP now, so most of the parameters for interior detail, etc. should be explained there.

Please let me know if you find any problems.

Below is the list of changes for this release:

v0.11

-----

new features

added interior detail / noise

added optional third input for SDF to use for depth sampling

added option to partition each individual piece by connectivity

very possible to get more pieces than cell points in this case

each partition within a piece is named according to centroid's proximity to current cell point

added ability to copy attributes from cell points to piece points or primitives

exposed interior detail settings to Fracture Solver

added first pass at Help for Voronoi Fracture SOP

added "Assume Input is closed" and "Capping Tolerance" parameter and avoid clipping cap if on (default)

bug fixes

Fracture SOP should now behave well when used within ForEach SOPs with the default ForStamp name

fixed a slowdown when cutting only one piece with large numbers of cell points

fixed metaball explosion could trigger fracture in FractureSolver even with no overlap (due to "outside density")

piece names should be based on cell point numbers even when fusing cell points removes degenerate points

new/updated examples

basic_fracture_examples.hip

stained glass now uses cell point attribute copying

interior detail

fracture / cookie setup

dynamic_fracture_examples.hip

animated metaball explosion

DOPs_examples.hip

lores/low detail proxy geo for hires/hi detail geo

creating RBD Glue Object hierarchy with "hero" cuts from Break SOP

v0.10

-----

initial release

voronoi_fracture_011.tar.gz

[johner]

OK, finally time for a new release!

And another, found and fixed a couple of unpleasant bugs.

I accidentally introduced a dependency on the Cell Point Group parameter and the triangulation, meaning the Fracture SOP would re-generate the triangulation any time you changed the cell point you were looking at. Bad.

Also, some benchmarking made me realize I had a quadratic slowdown with the number of cell points. Basically within the nested ForEach SOPs I was Blasting away the non-current cell point and its non-current neighbors on each pass through, meaning that with thousands of cell points I was doing many thousands of Blasts of many thousands of points. Very bad. So now I'm using expressions everywhere and things are much faster.

So, for example, the "stained_glass" example consists of lots of 2D fractures of a single quad, so the Clipping is very fast and all the overhead is in the ForEach SOPs. Increasing the number of cell points to 1000 made the fracture take 65 seconds on my machine with the previous version, now it takes about 6 seconds. You can now do a 5000 point/piece fracture in this example in about 35 seconds (there's a little overhead, but it's close to a linear slowdown).

v0.12

-----

bug fixes

fixed obscure bug in piece naming that could cause conflicts with piece partitioning and a large number of fused input cell points

fixed changing the "Cell Point Group" parameter would force re-triangulation

fixed quadratic slowdown with number of cell points

voronoi_fracture_012.tar.gz

[Jason]

This sounds excellent Johher! Thank you very much!

[varomix]

Great release John I love the interior detail features, in my own opinion, this is the best destruction tool I've ever used

and oh yeah, it runs way faster now

thank you

Edited September 14, 2009 by varomix