Why Do Dop Points Move From Frame 1 to 2?

[Shalinar]

Pretty simple.. Any time I do a destruction setup, just fracturing geo, packing it, and running a simple sim, the points of the packed pieces jump from frame 1 to a slightly different position in frame 2. Why is this? It's incredibly frustrating when trying to map hi res pieces onto a low res sim because on frame 1, everything will look good but as soon as it gets to frame 2 all the pieces jump and now the fracture lines show before the destruction happens. Is there a way around this?

Thanks,

Chris

In attached example, just turn to wireframe, turn on Display points and scrub between frames 1 and 2 to see what I mean

dop_points_jump_example.hipnc

[younglegend]

Switching off the centre of mass for packed objects appears to solve the problem. But i'm not sure how much it affects when it comes to complex simulations.

[Noobini]

rbdpackedobject1>Solve on Creation Frame ? (don't know much tbh, just guessing)

Edited June 17, 2017 by Noobini

[Matt_K]

Is it perhaps the collision object padding?
If I remember correctly, by default there is a small padding amount added, and perhaps it is this pushing the objects away from each other?

Matt.

[vtrvtr]

It's because the pieces are interpenetrating so in the first frame they are "fixed". Take a look at the file uploaded. You'll see that the effect doesn't happen because the boolean makes a "perfect" cut

I remember reading here there's a way to turn this off in the bullet solver, but I can't see to find the thread and it probably wouldn't help you since the pieces would be intersecting anyway

Some reasonable solutions:

1. Use the VDB to Spheres from the shelf. In H16, you can compile that process which makes it very fast

2. Low the collision boundaries in the rbdpacked dop

3. Make the cuts in a way that they won't be intersecting to begin with

moving pts odf.hipnc

[Shalinar]

Interesting... Thanks for the replies everyone

I'm still trying to understand this further, and I've got some questions for anyone who might know.

1. If it's because of interpenetration, how come the geo itself doesn't move when the first frame is solved? I would expect the pieces to move along with the centerpoints, but that doesn't appear to be the case if the packed pieces are viewed in wireframe.

2. Does this mean voronoi fracturing by its very nature will always create interpenetrating pieces? Why is that? I can understand that boolean creates "perfect" cuts in that sense, but why does voronoi method create interpenetrating pieces?

3. If it's due to collision object padding, why doesn't the same thing occur when using boolean pieces? I would assume boolean pieces would still have a little bit of default padding added to the pieces, leading to the same effect, but that doesn't seem to be the case as Vitor demonstrated.

Again thanks in advance for any help, I really would like to understand what's going on at a deeper level (and why), so I can make better sims!

[KarlRichter]

@Shalinar I believe Kishen PJ found the reason your packed primitives change their pivot, and that the intersecting geo issue is not relevant here.

By default, Bullet will let geometry that starts with intersections stay intersected until they are affected by other forces in the simulation. Incidentally, you can change this behaviour by creating and setting the "found_overlap" point attribute on your packed prims.

I think your real issue here is how you are remapping your high res geo. See the attached example on how to use the dopimport node to drive high-res geo.

 

dop_points_jump_example.v02.hipnc