Crumbling Piller

[ntkirby]

Hello all,

I have one slight issue with this scene, the top part of the piller keeps popping up right after frame 1 and not sure why. The bottom remains stationary.

The goal is for the front of it (pos z) to crumble and let it tumble over because it has been just shot up (bullet holes)

The glue network seems to be working as I like it, its just the pop up. The higher I take substeps, the more it pops up...its like the guide geometry is not being created right

I am using Houdini 12.1.185

Thanks in advance.

bulletImpact.hipnc

Edited January 18, 2013 by frescalus

[A. Morales]

Havent taken a look at your file yet, but try playing with the collision padding* in the RBD solver and your Static solver, keep your subssteps around 10 and do increments down with each adjustment you do to the collision padding

Edited January 18, 2013 by amorales

[ntkirby]

I initially thought of that, but the padding never made a difference, I made them concave in the bullet options and that has made just a slight difference but it still kind of pops up just a tad...so I'm not sure how to really do this

[Scratch]

hey

you might want to read along in my thread, I had the same Issue but was able to solve it (still working on other stuff though).

-> http://forums.odforc...mbling-effects/

A good read to understand the tech behind bullet is this article over at fxguide:http://www.fxguide.com/featured/art-of-destruction-or-art-of-blowing-crap-up/

and also make sure to watch the new tutorial sidefx released just recently: http://www.sidefx.co...2350&Itemid=166

In short words your problem has to do with the way bullet handles collision geo. It uses convex hull approximation instead of volume based collision geo. So everything you set under the "volume"-tab of your RBD object is NOT relevant for bullte. Use the bullet tab, and check "show guide geometry" to take a look what bullet does. Make sure that you DONT use clustering on your voronoi node, because that can create highly concave geometry which will cause trouble using bullet. Don't take the substeps too high, i never go above 20 because bullet tends to act strange when given high substep numbers. Better oversample the entire dynamcis network by selecting the auto-dop node and increase the substep there (example, 2 substeps on the autodop network node will give you already 20 bullet subseps if you set bullet's substeps to 10 inside the autodop network). Be cautious with this value. It can get slow very quickly. In general, you do not need more than 3 substeps on the autodop network. (the only extreme example is when you have objects moving really really really fast).

hope that helps!

Edited January 18, 2013 by Scratch

[Netvudu]

Yup. Scratch is learning a lot of bullet and his hints are really good.

Just to demonstrate his point I quickly fixed your hip file to show you where the problem is.

You separated the top and bottom part of your pillar with a cookie (boolean) that is creating problematic geometry for bullet. I disconnected the cookie and re-separated both parts with just a quick procedural selection. It´s pretty ugly, but it shows the point I think.

You´ll see how the geometry now barely pops and simulates normally.

hope this helps.

bulletImpact_concaves_fixed.hipnc

[ntkirby]

Thanks for all of the replies, I am still trying to digest it and understand from the linked posts.

I built off Scratch's fracture based on curvature (kind of) and the file included is what I came up with so far.

I know how to get the area of the objects and all but I don't seem know how to compare them and fracture based on that

I have gone through that video and I think I have an idea on how to proceed with my next test and see how it goes..

of course the one issue I'm running into with this file is that the foreach loop is fracturing stuff that doesn't have any curvature

thanks to all that replied!

box_fracture.hipnc

Edited January 19, 2013 by frescalus

[Scratch]

You only need this "curvature" technique if you want to have e.g. a bumy ground as collision object that is not represented correctly in its shape when converted to a convex hull in one piece. In my example (I'm simulating rocks), nearly everything has a complex shape, so in stead of just fracturing the thing which has to crumble, I fractured EVERYTHING, to get bullet to represent my shapes as best as possible. Its like a mosaique. Many small pieces represent the shape of an object better than trying to achive this with one single piece. I hope that makes sense somehow. When doing so, the performance will go down siginificantly, because bullet has now to handle all that pieces instead of single objects (e.g. for the ground).

Fracture your hero-object (the one that has to crumble) like you want it, and all the other objects so that the shape is represented in a good way. Doing this based on curvature helps to achive this with as few pieces as possible, because it only adds more "division" (pieces) where the surface changes the most (=curvature of an object). Fewer objects, faster sim.

What helps to decide if you have enough pieces already to represent your original shape is the following workflow (credit to peter claes from method who came up with it!) When you look at my file, I measured the area of my fractured objects, and in a second parallel node tree, I measure the area of my pieces after being converted to a convex hull (happens in the foreach node using a shrinkwrap which does exactly that). I then use a attribute promote to sum up that area to get my total area. The closer these two total area values match, the closer and better you represented your actual geometry. You can calculate "total area / total convex hull area". Theoretically, and in an ideal case this should be 1 = both areas are the same, perfect match. In practice, you just make it as accurate to get what you need. It will get better the more pieces you use, but keep in mind, the more pices, the slower the sim. You have to find the right balance here and try what works for you.

After you are done, add everything (also the static objects) as rbd fracture objects to your sim, so everything is connected to the rbd solver. For all objects you want to have static, you uncheck "create active object" so that they are no longer affected by gravity etc. and stay in place (like we want them to). Make sure to check the colision geo of bullet often and watch out for interpenetrating pieces, thats what causes bullet to explode. If you spot interpenetrating objects, select that rbd object and increase the collision padding value. Watch what happens, you get greater gaps between the pieces. Greater gaps, less chance to have interpenetration, BUT more inaccurate collision geo, more inaccurate reperesentation of your actual geo, resluting in more inaccurate behaviour of your pices because collision geo and actual geo doesnt match up that well. You again have to find a balance here that works.

Keep it up! Bullet isn't a one two three I am done thing. But once you get the hang of it, it is fun to play with! Allways imagine the day when you tear down your first object, and it looks just great

Edited January 19, 2013 by Scratch

[ntkirby]

Sorry for my ignorance in Houdini I am still a novice trying to figure out all of the nodes here.

I read all through the thread, I can't for the life of me figure out how to get the area attributes from promoting them to details.

The only thing I can really think of to try (which I have been unsuccessful so far) is to promote up and then back down to the primitive level or even promote to the point level and compare that way?

I'm just not sure how to compare them from the detail level, once I figure that out I think I could figure out where to go next.

or a vop sop? I'm just throwing stones here...

Edited January 20, 2013 by frescalus

[Scratch]

Hey again

I prepared you a file where you can see how it is done. It's important that you understand what convex hull approximation means. If you do, great If not, head over to fxguide and read the article I linked you in my first link. It is essentilal to understand how bullet handles collisions in order to enable you to handle bullet. I just wanted to mention that again.

I hope the file makes sense. It isn't too difficult once you see it, I'm sure of that!

Keep it up!

Area_Sum.hipnc

[ntkirby]

Yes sir I do understand convex and also concave and how it plays into bullet

I will take a look at the file when I get home from work today..

I hope my reply wasn't misunderstood, what I was trying to do was find out how to use the area data from the details class and then depending on that data refracture certain objects that met the criteria that was basically explained in your other thread. It will seem trivial to most people, but I have only been working with Houdini since SIGGRAPH and have taken the intro course from cgtalk, I have a firm basic understanding on using Houdini, I want to go a little deeper.

Edited January 20, 2013 by frescalus

[Scratch]

Ah, ok, got it. Sorry, my bad!

Well, I did that manually. I tweaked the fracture until I got a working result. You can automate this of coures, but for my case, it was not neccessary.

Workflow: I read the area sum value from the details view -> detail attributes, then I compared it to the area_sum_convex_hull and then I calculated: area_sum / area_sum_convex hull. The closer you get to 1, the better they match. Take (1- your result) * 100 to get the error in percent. I hope that is what you are looking for.

O and by the way, you dont have to call me sir, that makes me feel so old

[ntkirby]

Do I need to food those into a foreach node? I still need to find a way to extract those and compare them and maybe use a switch I guess or a vop sop?

[Scratch]

You dont need to extract these or do anything with a vop sop. You take a calculator (a real one, or a software-one,), look the values up yourself (just read them, no houdini magic), and than calculate the things I said by hand, yourself. As said, you can automate this, but I think this is not neccssary and not worth the effort in this case (I also don't know how to code this, I do it by hand).

EDIT: To "extract" the values you need to compare, go to the details view -> detail attributes, or middle mouse over the attribute promote node.

I hope I could explain it now a bit better.

Edited January 20, 2013 by Scratch

[ntkirby]

That is what I want to do is learn how to automate it

By hand is one thing but I hate doing it manually after a while

Edited January 20, 2013 by frescalus

[ntkirby]

Alright, so what I've done so far...

I added a for each into the mix..

the 1st input is geometry I'm testing as the actual geometry that's cut

The 2nd input has the geometry I'm testing against...

For each of the geometry in the 1st input I'm getting the area called the cut_area

For each of the geometry in the 2nd input I'm using a shrinkwrap on it and then getting the area called the box_area

I promote both to detail level

I'm transferring the box_area to the 1st geometry

I created an attribute called area_tolerance, set it as a detail float attribute and testing by doing cut_area/box_area

so that's where I'm at so far...more details to follow

[ntkirby]

Here's an update to my box fracture

I'm not sure how close I am to getting what I want in terms of what was talked about in the thread I was linked...

but I put a foreach node inside a foreach node, but as you can see, the exploded view doesn't quite let me see the pieces, It seems like it wants to do what i want, but its not clean and I feel I may be going about this in slightly the wrong way and I think I have an idea to make it slightly better...

First I'm getting area attributes, I have one branch creating an attribute called "cut_area" and putting it into detail class

the other branch uses a tetrahedralize node and then I get that area and call it the "box_area"

then I use an attributetransfer to put the "box_area" onto the main object and create an area_tolerance attribute.. area_tolerance = cut_area/box_area

I tried a shrinkwrap but when I did the division I got values over 1 as opposed to using the tetrahedralize node with the output set to Convex Hull which I feel gave me more accurate values

Then I use scratch's solution for curvature and test the object and use a voronoi fracture on it.

The goal is to get houdini to recognize curvature on a single primitive group

Its (almost) working...

I've made progress thanks to peter and Philipp and others in this thread...

anyone have suggestions?

box_fracture.hipnc

Edited January 23, 2013 by frescalus

[ntkirby]

well I've tried using different names for each of the piece but every time I try to delete the original piece it just deletes the outter part, I can't seem to get single pieces and they overlap each other

[ntkirby]

Ok, here's an update

It appears I have it working now the way that I want and I can keep adding as many foreach nodes I want

I tried using a switch using a tolerance ratio but the problem is it is only keeping the geometry that I'm cutting so I switched it to a merge node

now the problem with that method is that in the first foreach it was making groups with 0 primitives, but I used a delete sop to get rid of them anyhow..

check out the file, any suggestions on improving it?

box_fracture.hipnc

[ntkirby]

Update to the file

this time I added switches inside the for loops to fracture the convex pieces and also a switch for error handling so if there's a problem on the first input just go to the 2nd input, this occurs if the user puts in a convex piece and does not fracture it.

in the end I plan to make this an asset so these options will be promoted up at the end once I get this squared away

The goal of this is to make a tool to let the user determine how many levels of fracture they want and how many times to fracture per level as well as fracturing convex pieces...

the iteration part I'm still trying to learn/work out so any suggestions is welcome!

box_fracture.hipnc

[ntkirby]

and another update

this time made an assett out of it...

it has problems with small geometry, I'm still trying to work on the pillar scene...

but it works, now just need to make it more robust and better....

box_fracture.hipnc

ntk_k_fracture.otl