hey,
I am sure you all seen this paper (http://graphics.berkeley.edu/papers/Pfaff-ATC-2014-07/Pfaff-ATC-2014-07.pdf [graphics.berkeley.edu]) and video: https://www.youtube.com/watch?v=4Wl0ksysYKM&feature=youtu.be [youtube.com]

I am wondering if this is something doable in houdini? has somebody already fumbled with that? The concept behind that system seems to be adaptable.

voronoi fracturing allows for a variety of patterns, but I find it often synthetic looking.

cloth tearing there is something available: http://ihoudini.blogspot.com.au/2013/11/cloth-tear-geometry-and-shading-detail.html [ihoudini.blogspot.com.au]

the other part is surly possible in houdini sadly the berkely student don't use houdini for there thesis so we won't get otls shame on them :-)

As nice as sams setup is, its still tearing along predefined edges.
I really like the idea of procedural stress areas.

It´s awesome, but a bit out of reach for most of us regarding processing power.
The author states each simple example took “a few hours” to sim. Now picture trying to use this in a production shot context…. :?

Netvudu
It´s awesome, but a bit out of reach for most of us regarding processing power.
The author states each simple example took “a few hours” to sim. Now picture trying to use this in a production shot context…. :?

jep, thats a drawback. but I would always favour a predictable good and believable result than having fast sim times, turnarounds.

Netvudu
It´s awesome, but a bit out of reach for most of us regarding processing power.
The author states each simple example took “a few hours” to sim. Now picture trying to use this in a production shot context…. :?

I think that must came from something that's the equivalent of using very large DOP substeps… Houdini's various solvers are also capable of very accurate results, but – as you also said – the time it takes is not an option for a production schedule

Netvudu
…
The author states each simple example took “a few hours” to sim. Now picture trying to use this in a production shot context…. :?

in the paper he states 24-88s per frame for those examples which sounds quite reasonable
considering that each example is quite high resolution even though it may be considered “simple”

Even though I can´t backup my guessings with actual data, 88s per frame on such simple examples might mean something along the lines of half an hour or more per frame in a real production situation.

Meaning about 200 hours per sim…which sounds unreasonable for most cases.

Then again…we´re just guesstimating.And I´m sure this tech will be optimized sooner or later.