Multi Weight Enveloping

[thekenny]

Well, no one here? I suppose ILM has?

27206[/snapback]

what I was told from a reliable source that the MWE wasn't as good as advertised. Now that could be one user's perspective on a "implementation" of MWE. I find it difficult to balance development and production... they often don't allow for a good evolution of tools.

oh well.

but it pays the bills:)

-k

[edward]

Well, I said MLE because that's where it says the authors work at in the paper.

[thekenny]

yeah but why does the blendOP flip at the 180 mark in peship's example. even with shortest path it flips...

if something like this works in 'other' packages.... why can't it work here?

-k

[calin_casian]

So I may be a little bit rusty since I haven't use maya for a long time...

Please open the attached file:

Here is a short description for people who doesn't have PLE

-cube1:

-tx:-2

-ty:0

-tz:2

-rx:0

-ry:0

-rz:0

-null1:

-tx:2

-ty:-2

-tz:0

-rx:35

-ry:-6

-rz:-7

-cube3(child of null1):

-tx:0

-ty:0

-tz:0

-rx:0

-ry:0

-rz:0

-cube2(orient constrained to cube1 and 3):

-tx:0

-ty:0

-tz:0

-rx:17.382

-ry:-3.538

-rz:-3.032

-interp Type: Shortest

-W0:1

-W1:1

Rotate cube3 rx: 146 (which is 181 in total)

result: cube2 flips

Change Interp Type to No Flip.

Rotate cube3 rx: 326 (which is 361 in total)

result: cube2 is in a bizarre state(flipped twice), due to gimbal lock or rotation order. It's rotations are rx:81.21, ry:-0.459 rz:173.535. Please someone tell me how I end up with this values when I rotate cube3 only in X

Change Interp Type to Average.

Rotate cube3 rx: 326 (which is 361 in total)

result: cube2 is in a bizarre state(flipped twice), due to gimbal lock or rotation order. It's rotations are rx:81.21, ry:-0.459 rz:173.535. So the same result. Even more when cube3 rx:360 cube2 rx:-165.473 ry:19.162 rz:-32.409. Again can someone explain to me how over a 35 degrees rotation in X I end up with cube2 rx:81.21->-165.473 and so on.

Change Interp Type to Longest.

Rotate cube3 rx: 146 (which is 181 in total)

result: cube2 flips, save as in shortest

Change Interp Type to cache.

Rotate cube3 rx: 326 (which is 361 in total)

result: same as average and no flip

I'm just a normal user going back to maya and try something out. I may not used the orient constraint in the right way that's why I posted the scene so someone with more experience than me can fix it.

take care

calin

ps. I'm sure in the end for every problem there is a solution, it may be dirty but hey if it's working...

Oh I can't upload .mp files so please change the extension from .zip to .mp

blend.zip

[calin_casian]

@peship

Yes I'm not a huge fan of layered rigs, my motto is make it as simple as possible. I think it's just another way of rigging. Why need multiple chain bones with multiple IKs when I can have multiple ik solvers running on the same chain and blend between the solutions.

I don't wanna start any software war but from my perspective I may say that layered skeletons are just a simple hack to get around what's possible and what's not possible in some other packages.

It's been proven by C.O.R.E. that Houdini can be used to create a full CG feature animation w/wo all the differences and that's the important thing ...

About the rotation order, you can use fetch and chops tricks to get around it.

About changing the rotation order for all the animation controls; why not make them right in the first place, make one null change the rotation order and from this point copy and paste. If you need to change the icon go inside the null and have fun...

take care

calin

[Jason]

Just FYI, I've enabled the upload of .ma, .mb and .mp files now

[edward]

yeah but why does the blendOP flip at the 180 mark in peship's example. even with shortest path  it flips...

Since when did "shortest path rotation" means it doesn't flip? "flipping" is implied in the name It chooses the shorter path. So if you rotate past 180, it will flip in order to take the shorter path.

if something like this works in 'other' packages.... why can't it work here?

27256[/snapback]

It doesn't. Not in the same way. If you take into account the previous frame's rotation values, then you can do the right thing. Similar to what the default Transform CHOP would do on rotation channels to ensure continuity. The problem with this approach is that now we're history-dependent.

[thekenny]

Since when did "shortest path rotation" means it doesn't flip? "flipping" is implied in the name It chooses the shorter path. So if you rotate past 180, it will flip in order to take the shorter path.

27276[/snapback]

I was taunting you to reply...honest... thanks though. When I looked at the file and tried it out.. sure enough if flips. I scratched my head and thought... maybe that's okay.. maybe you just dont' go past 180... it that happened while I was rigging i would change what I was doing or hit the animator for going that far.

Based on calin's PLE example "they" have a similar issue.

I guess the biggest thing here is to understand that there is more than one way to do something and in houdini you always have that kind of freedom.

-k

[peship]

Calin, very good example, i should show something like that at the beginning of our conversation.

If you look carefully at the scene you will notice that in this particular case the gimbal lock occurs when you rotate the control object on around 270 degrees +- something. And this without even trying to work around this fundamental limitation, by splitting the rotations between multiple movers.

Now try the same in Houdini - you cant even reach the gimbal lock, because the blendOp will flip before that.

EDIT:

Look, i am not going to bash and point with finger on public places just to have some fun.

What i am saying is that i clearly see several quirks in the character toolset of Houdini, if you can fix them - good for everyone, if not ... that's ok, the life continues