5 replies to this topic

[Mikal]

Hi

I'm trying to shatter a piece of wood using the Bullet Solver. I'm repeatedly coming across an issue where the elongated shards of the 'wood' will rotate indefinitely on their ends and stubbornly refuse to fall to the ground or lose momentum. I assume there's some feedback issue with the angular velocity, but am unsure how to limit this. Any ideas DOP experts?

Thanks!

M

Attached Files

•  fracturedWood.hip   362.87K   41 downloads

[kare]

Mikal, on 20 July 2012 - 12:14 AM, said:

Hi

I'm trying to shatter a piece of wood using the Bullet Solver. I'm repeatedly coming across an issue where the elongated shards of the 'wood' will rotate indefinitely on their ends and stubbornly refuse to fall to the ground or lose momentum. I assume there's some feedback issue with the angular velocity, but am unsure how to limit this. Any ideas DOP experts?

Thanks!

M

Use auto freeze

[rayman]

I think the pieces don`t fall because you are using concave geometry, but the bullet is set to use convex representation of them.

Anyway, high rotation velocity and endless rotation of small pieces is issue that I`m also trying to resolve.

[SteveRed]

There are a number of things working against you here in my opinion. First and formost, inside dops you have a few settings that are going to make bullet a bit less stable.

1)On the Rigidbodysolver I normally work with a MUCH lower penetration threshhold (something around -.001 is what I normally work with) that way objects have less interpenetration, and therefor react a bit more accurate with less spinning and jittering.
2)Also on the solver the substeps and constraint iterations I normally have set to 10, the default. While the change in accuracy isn't too noticeable with these, it also doesnt really change the solve time much at all so I wouldn't ever decrease them.
3)On your Rigid Body Glue Object, go to the Collisions Tab and under Bullet Data find the Collision Padding setting. It defaults to either .01 or .02, I make it 0, Always. When objects sit on top of each other this stops them from trying to slide and rotate off each other. Things will ocassionally pop a bit on the ground, but normally the autofreeze takes care of that first.

Those are just a few personal preferences for making bullet react in a more behavable manner. Note that all these values will drastically change how your glue is working, so its not just a plug and play situation youre still going to have to find the sweet spot.

The big issue, as already said, is the geometry being created from your Voronoi's clustering, its turning the top and bottom into difficult to handle geometry. This becomes an issue when you decrease the penetration threshold as it will cause your center to pop away from the base. You can probably fix this through using the newer GlueCluster tool, as it won't combine your top and bottoms into one piece like the voronoi tool does, it will just assign them a higher glue value then the center.

The help docs have a really solid example on the GlueCluster and how to properly set it up, but if I have time tomorrow I'll try and get it working in your file for you.

Edited by SteveRed, 20 July 2012 - 06:43 PM.

[Mikal]

Hey guys

Thanks for the feedback. I looked into the Glue Cluster tool as you suggested Steve and it definitely helped the geometry to sit together without requiring a large glue value. Although I found any clustered pieces in bullet produced a weird rotation behaviour - either abnormally slow or an off-center pivot. Removing any clustering and avoiding concave surfaces - the rotation issues are resolved, and bullet behaves properly.

Anyway RBD works well, so will stick with that!

Cheers

[Scratch]

I had the same "pieces keep spinning infinitely" issue in my simulations. RBD works fine though.
So can this officially be declared a bug? Meaning, that when it comes to fracturing, one should avoid using the bullet solver?

Edit: I have to dig into that Glue-Cluster topic! At the moment, I am not familiar with this workflow.

Edited by Scratch, 25 July 2012 - 05:10 AM.