Voronoi - dynamic - location based fracture (WIP)

[johner]

This brings up a question I've been interested in. In your setup are you accessing the clipping code directly and able to define a clip face rather than a clip plane or limit the actual clipping area in any way? During my work on some of these problems earlier there were cases, like windows, doors and other "holes" in otherwise solid surfaces that could create problems for the Clip SOP (and I, grudgingly, implemented a user switch to Cookie if they wanted). Or maybe I just answered my own question since there are cases where you're flirting with that as well.

I'm clipping the whole plane, but assuming that you're dealing with a watertight mesh (i.e. it's a window or door or whatever, but it's been extruded so it has volume, not just a single poly), then this can be handled by doing your clip/cap with a Clip, Divide, then Hole SOP, as Simon and kuba mentioned earlier in this thread. Attached is a screenshot of a fractured box-with-a-window that was done with the Fracture SOP, which uses these SOPs for the clip/capping. The .hip file is attached, you can get the Fracture OTL upthread, but it also contains an example of just creating a concave cap with a hole in it around the window.

Keep going soldier, I'm done for! If we have to use the Cookie the terrorists win!

Ha! I wish I could be more of a fan of the Cookie SOP. I actually tried the new VolumeBreak initially for some of this, but it's got a bug that leads it to sometimes go off and gobble up 8GB of memory or so, which I deemed impractical.

window_clip.hip

Edited May 30, 2009 by johner

[pockets]

I'm clipping the whole plane, but assuming that you're dealing with a watertight mesh (i.e. it's a window or door or whatever, but it's been extruded so it has volume, not just a single poly), then this can be handled by doing your clip/cap with a Clip, Divide, then Hole SOP, as Simon and kuba mentioned earlier in this thread. Attached is a screenshot of a fractured box-with-a-window that was done with the Fracture SOP, which uses these SOPs for the clip/capping. The .hip file is attached, you can get the Fracture OTL upthread, but it also contains an example of just creating a concave cap with a hole in it around the window.

Ha! I wish I could be more of a fan of the Cookie SOP. I actually tried the new VolumeBreak initially for some of this, but it's got a bug that leads it to sometimes go off and gobble up 8GB of memory or so, which I deemed impractical.

Interesting. I'll take a look at that, thanks. I wonder how this would end up working on a practical model though. It's easy enough to get the Fracture SOP to fail using only primitive shape inputs which lead to our searching for a more reliable, non-Cookie method last year. A solution for a single squared torus like this example is one thing, though still computationally non-trivial to solve but I wonder about geometry like an apartment building with twenty or fifty windows on a side. Even for small numbers of shots and a finite number of buildings I've already seen it's next to impossible to impose rigid rules for FX concerns even if you could guarantee total reliability by building things a certain way. I know there's no panacea for this stuff right now. It's interesting though.

[johner]

Interesting. I'll take a look at that, thanks. I wonder how this would end up working on a practical model though. It's easy enough to get the Fracture SOP to fail using only primitive shape inputs which lead to our searching for a more reliable, non-Cookie method last year. A solution for a single squared torus like this example is one thing, though still computationally non-trivial to solve but I wonder about geometry like an apartment building with twenty or fifty windows on a side. Even for small numbers of shots and a finite number of buildings I've already seen it's next to impossible to impose rigid rules for FX concerns even if you could guarantee total reliability by building things a certain way. I know there's no panacea for this stuff right now. It's interesting though.

Just to be sure we're on the same page, when I mentioned the Fracture SOP above, I meant the Voronoi Fracture SOP in the OTL that I posted upthread.

You describe a really good test case, I think, so I increased the size of the box from that last example to "building" size and added 18 windows per side. Nowhere near production-complexity of course but an interesting test. I did a pre-fractured test where I used the Voronoi Fracture SOP to break the building into 400 pieces (took about 40 seconds) and did a sim as an RBD Glue Object. Flipbook here.

I also did a test with the dynamic fracturing, which in some ways is a more interesting test, because it has to fracture not just the building, but pieces of the building. Flipbook here.

Neither of these are the best-looking sims in the world or anything, but I was encouraged that the fracturing process seemed to hold up for at least this relatively simple geometry, which is nevertheless concave in all sort of weird ways.

building_fracture.hip

[Jason]

Hey Johner;

I love this thread, but was meaning to ask about your CGAL implementation - because for a while I was interested in making something similar:) Could you go into that a bit, perhaps in another thread?

[johner]

Hey Johner;

I love this thread, but was meaning to ask about your CGAL implementation - because for a while I was interested in making something similar:) Could you go into that a bit, perhaps in another thread?

Hi Jason,

Funny you should mention this, I was trying to track down a small problem in my build of the CGAL-python bindings today and found this about two hours ago .

At the moment I've only used CGAL's Delaunay tetrahedralization code to get the Voronoi adjacent cell points for any given cell point. As I described above, at the moment I'm completely cheating in the 3D case and just clipping starting from the nearest points and moving outwards, as provided by a short VEX SOP that uses pointclouds to store the closest points in a "nearest" attribute. The nested ForEach SOP then uses that and the "numnearest" attribute to control how much clipping is done. While that works in a lot of cases (and really all cases if you're willing to take the hit of just settings MaxCuts to the total number of cell points, which is actually not too bad at < 100 points or so), it's obviously not a very good solution in the general case.

The idea was always that at some point I'd have a more clever way of filling in those attributes and the ForEach SOP would work the same, but then doing only as much clipping as needed. So that latest version I posted above uses Triangulate2D to give me the Voronoi adjacent points in 2D, but I'm still working on the 3d fix.

In the meantime I just used CGAL to give me that same information in 3D to confirm that having that information worked, sped things up, fixed the nasty cases I'd run into, etc., and it seemed to do all that. I'm only using the "incident_vertices" method of the Delaunay_triangulation_3 class, which is exactly the information I need.

So, I made a Python SOP that created the Delaunay triangulation and set the appropriate attributes, then just applied it to the incoming cell points in the 3d case before inputting them to the Fracture SOP, then just unlocked the asset and bypassed the "get_nearest_points_pcloud" node that is the VEX SOP I desribed above. This makes the Fracture SOP more robust and faster for some of the more challenging test cases I had, which tended to include concave input geometry and irregularly spaced cell points.

The code for the Python SOP is below, sparsely commented, since I really only meant it for testing. If you have a build of python-cgal, you should be able to stick it in a Python SOP and do what I described above. Still working on a CGAL-less version. Let me know if you have any questions.

from CGAL.Kernel import Point_3
from CGAL.Triangulations_3 import Delaunay_triangulation_3
import operator
geo = hou.pwd().geometry()

#create tetrahedralization
dt = Delaunay_triangulation_3()
ptvertex = {}
for p in geo.iterPoints():
    vertex = dt.insert(Point_3(*p.position()))
    ptvertex[p] = vertex
    vertex.set_info(p)

#create dictionary of points to incident vertices and get max number of incidents
maxincident = 0
ptincident = {}
for p, vertex in ptvertex.items():
    incident = dt.incident_vertices(vertex)
    ptincident[p] = incident
    maxincident = max(maxincident, len(incident))

#create nearest and numnearest attribute with enough space for max incidents
defnear = [-1,] * maxincident
nearest = geo.addAttrib(hou.attribType.Point, "nearest", defnear)
numnearest = geo.addAttrib(hou.attribType.Point, "numnearest", 0)

sort = True
#set the nearest and numnearest attributes for each point
for p, incident in ptincident.items():
    pos = p.position()
    incidentpts = [inc.info() for inc in incident if not dt.is_infinite(inc)]
    #optionally sort the incident points by increasing distance from the current cell point
    if sort:
        ptdist = [(incpt, (incpt.position() - pos).lengthSquared()) for incpt in incidentpts]
        ptdist.sort(key=operator.itemgetter(1))
        ptnums = [ptd[0].number() for ptd in ptdist]
    else:
        ptnums = [pt.number() for pt in incidentpts]
    nincident = len(ptnums)
    #pad the ptnums list and set the attributes
    ptnums += [-1,] * (maxincident - nincident)
    p.setAttribValue(numnearest, nincident)
    p.setAttribValue(nearest, ptnums)

[MagnusL3D]

Hey Johner

I'm still pretty new to Houdini and this will be my first post here on Odforce, but I must say I realy love the work your putting into this. And here's a flipbook from a test I did.

VF_Test01.mov

/M

[johner]

By the way, saw a cool new Star Wars game cinematic from Blur today.

Just from the looks of it, I'd guess the debris/fracturing when the space ship crashes through the hangar is done with a Voronoi decomposition (maybe the latest Rayfire?)

Edited June 2, 2009 by johner

[Solitude]

By the way, saw a cool new Star Wars game cinematic from Blur today.

Just from the looks of it, I'd guess the debris/fracturing when the space ship crashes through the hangar is done with a Voronoi decomposition (maybe the latest Rayfire?)

You nailed it. ...(i used to work there)

Great work by the way. I was going to eventually try and tackle something like this for my first big houdini venture (when I get time... which will be never haha) but you beat me to it, and did it way better than I could've anyway. hehe. It's a great asset / tool that was much needed for houdini.

Edited June 2, 2009 by Solitude

[Jason]

You nailed it. ...(i used to work there)

Great work by the way. I was going to eventually try and tackle something like this for my first big houdini venture (when I get time... which will be never haha) but you beat me to it, and did it way better than I could've anyway. hehe. It's a great asset / tool that was much needed for houdini.

The great thing about Johners system is that it's so open that you can jump and modify it and improve it! Much better than a closed 3rd party bit of code!

[kubabuk]

Hi johner,

I guess you are using cgal on linux. Am I right? I gave up with cgal some time ago (but in my case on XP), since it was compiled for python 2.4 unfortunately incompatible with the python version in HOM.

Of course there is always an option to compile it yourself.

Cheers,

Kuba.

[johner]

The great thing about Johners system is that it's so open that you can jump and modify it and improve it! Much better than a closed 3rd party bit of code!

Yes, please! Poke, prod, improve. Let me know if you see anything boneheaded or that could be done better. That's already happened a few times in this thread and the asset is much improved because of it.

Hi johner,

I guess you are using cgal on linux. Am I right? I gave up with cgal some time ago (but in my case on XP), since it was compiled for python 2.4 unfortunately incompatible with the python version in HOM.

Of course there is always an option to compile it yourself.

Yup, I'm a Linux-only geek these days. Ubuntu 9.04 has a pre-built package for CGAL, so I just installed with apt-get. Downloaded the CGAL python bindings and did "python2.5 setup.py build" and "python2.5 setup.py install". (made sure to use python2.5 so I could use it from within Houdini) Pretty painless. I've got a couple of parameter passing problems in my build but nothing I can't work around.

But problems like you're having are why I'd really rather not have a dependency on CGAL, unfortunately.

Edited June 3, 2009 by johner

[CeeGee]

johner building hip file but little change

two building total 4000part

65frames - 4h simulation

building.mov

[sanostol]

I totally missed this. Outstanding stuff and thanks for sharing, Johner

And thanks for all the sticky notes

Martin

Edited June 3, 2009 by sanostol

[pockets]

Just to be sure we're on the same page, when I mentioned the Fracture SOP above, I meant the Voronoi Fracture SOP in the OTL that I posted upthread.

Ah, that does make a difference.

Flipbook here.

Flipbook here.

Neither of these are the best-looking sims in the world or anything, but I was encouraged that the fracturing process seemed to hold up for at least this relatively simple geometry, which is nevertheless concave in all sort of weird ways.

Very nice. The dynamic fracturing indeed holds up well, as well as any Rayfire examples I've seen to date. This is fun stuff!

[Netvudu]

Johner this thing really rocks. I

Edited June 3, 2009 by Netvudu

[johner]

Johner this thing really rocks. I

Edited June 4, 2009 by johner

[mangi]

Hi there Johner, Mangi from madrid spain.

"I plan on releasing it here in a few days for testing"

It's really cookie.

Thanks really valuable work you made.

[Netvudu]

Did you maybe forget to change the group mask in the RBD Fracture/Glue Object to "piece_*"? There's also an "outside" and "inside" group for all the outside and inside primitives, and if they get pulled into the RBD Fractured Object as well they screw things up.

Dang, you were right johner. I forgot the group mask. I

[Magnus Pettersson]

i been following this thread and the work you done so far is amazing, very good work johner!

[Bernard]

Hello ,

great tool....

does this work with H 9.5 or H 10 ?

thanks,

bern