Packed Intrinsics to RBD Sim. Woes...

[Annon]

Hey all,

So if you could take a look at my scene it will make a lot more sense I think, but here we go...

 

Imagine you have a piece of cached geo and you want to randomly activate parts to break off and tumble...

Using packed RBDs you just get the simStartFrame geo and it doesn't update, so we have to do that ourselves (or do we?).

 

In my setup I have it most of the way there. I get a relative matrix between a rest and animated geo and update the intrinsic information. It's slightly off, I'm sure someone will know why. But my main problem is understanding the intrinsic pivot. If I add angular velocity in there (w) then things go bonkers. If I try to update the intrinsic pivot, things go bonkers. So I'm a little bit stuck. I've been updating @P, not sure if that's correct, I just don't know...

 

All the scene is is a simple sphere/mountain with some animation. I want to release it (make active) on a certain frame and have the inherited velocity and angular velocity work correctly.

 

I hope someone can help me out on this, it's got me quite perplexed.

Thanks

Christian

packedIntrinsicsStuff_v004.hip

[rayman]

H14 or H13?

[rayman]

This is basic setup in 14.

Don't need to compute matrices and velocities - just use point attributes and import them.

packedIntrinsicsStuff_v004_H14.hipnc

[Annon]

Hey Pavel,

It's great that H14 removes the need to do all this stuff, but I feel there's something to be learnt from it.

I'll probably start building stuff in H14 soon, but in the mean time I'd like to get this sorted in my head so I can get my next scouts badge

 

Any ideas? Thanks for the scene.

Christian

[rayman]

You are right - there is a lot you can learn form it.

H14 approach is nice, unfortunately you still have to use some VEX magic and matrix computations to use constraints with it (and glue constraints are still impossible). At least I didn't find another way. This is probably good idea for RFE .

 

It is doable in 13 too. There are 3 approaches:

-update P and orient. Then you have to recompute all other attributes - pivot, transform, v , w , intrinsics...

-update v and w and leave the rest to bullet.

-create hard constraints and update them to move pieces

 

1) I don`t like the first approach. Yes, it will produce correct result and pieces will be placed exactly where they have to be, but there will be problems with collisions. Oh and constraints won`t work. You can find many variatons of this setup : https://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=30392&start=0&postdays=0&postorder=asc&highlight=

 

2)Second approach is great. Compute offset matrices and use them to produce correct v and w. Now you have to pass only these 2 attributes to bullet. And if there is constrains in scene they still will work. The downside(i actually don`t think it is) is that animated pieces will collide with the rest of the scene, so they might change their behaviour slightly. You can try to change their collision relationship but I think it is a bit messy and still won`t work as you expect(I think there is an easier way to do it in 14  now). I actually like that they won't behave exactly like animated geo - this way you can detach them from animation procedurally and leave them to behave as regular active pieces.

So, how you compute the matrices? The catch is to update pivot on the first frame to match the centers of your pieces (Centers of mass). On the first simulation frame bullet will adjust pivots to match COMs, so don`t forget about it or as you already saw - your pieces will be slightly off. You can store initial pos and use it to offset your already computed matrices while simulating or you can cheat and build that offset into matrices. How - just create another DOPnet, put your packed animated pieces in it, wire them to bullet solver and set Solve on Creation frame.  Now you have correct COMs and you can use them to offset your matrices.

The next step is to produce correct v and w while in DOPs. v is easy - just substract positions, then multiply them by 1/TimeStep.

w is slightly less obvious as it is a quaternion.

I used to compute it using my own equation. First I computed standard angular velocity equation (http://en.wikipedia.org/wiki/Angular_velocity) on 2 vectors from matrices and got the average of two resluts - this will return proper axis, as using only one will give you shortest path, not the one you need in 3 dimentions. Then I converted it to quat and multiplied it to some number which I found to produce relatively good results (when averaging shortest paths I got only the rotation axis but not the proper magnitude). This worked quite well and the results were almost perfect match.

Better way to compute it is using quaternions. The math is not so easy to understand but the results are exact. There is a catch here also - you have to check if the offset quaternion is between certain degree and flip it , otherwise in some cases your pieces will start to rotate in the opposing direction getting longest rotation path instead of shortest.

 

3)Move pieces using hard constraints - create constraints between 1 piece and some point in space. Then update empty point P and r( or orient in 14) attributes. I think I will use this in 14 if I want to make constraints between animated piece and active one. Again - it may be better way that I`m not aware of.

 

Good luck with this and I hope you may find some of this explanation helpful (:

[Annon]

That was very helpful thank you!

I think it's triggered something in my head that might work. Hopefully I'll get some time tomorrow to take a look.

Thanks

Christian

[Annon]

A quick follow up. I actually have this working now, I'll do some more testing and post up a scene when I'm done.