Multi Weight Enveloping

[sibarrick]

Anyone had any experience of this technique as an alternative to Pose Space Deformation as discussed in the Houdini wishlist thread.

MWE

The authors discuss it as a superior method.

[edward]

If you're into this, I would rather look at Alex Mohr's stuff instead:

http://www.cs.wisc.edu/graphics/Gallery/SkinFromExamples/

Personally, I don't like the MWE formulation.

[peship]

every tool has its place.

if you dont want armies of shot fixers, going and cleaning-up the characters shot by shot and frame by frame, then better collect some tools.

there are places where the character pipeline is set right. i just left one of them ...

Shot fixers ? What was that ? A cheese ?

...

Let me add few notes about the rigging tools in Houdini.

( maybe with this post i will collect a lot of negative mana )

Look, before adding muscles, PSD's or whatever other advanced stuff, i think you guys ( at SESI ) need to go back and fix the base.

The bones system is really bad. I recently talked with some Houdini riggers ( before that with two of the SESI guys ) and i was surprised that they dont even realise how restrictive is the workflow.

For example - the orientation order of the bones is locked-up and by some reason their local axis is fliped on Z. Why ? I dont know. But as result you cant really make multilayered skeletal structures. Relying on single FK/IK chains is leading to nowhere ( remember the armies of shot fixers ).

Ok, why i'm saying that ( fallow my toughts ) -

if i want to build even the most basic multilayered rig i will need FK bone chane, IK bone chain and blend bone chain. There are production rigs with tons of layers ( for building and automating complex interactions between the skeleton parts, keeping the workflow procedural, etc ), but lets keep the things simple - so we are talking about 3 layers of bones.

Everything will work fine until you try to make movers ( handles, pickers, or whatever objects you call them, which will be available for the animators ) and to control with them the FK bone chain.

The problem appears at the moment when you try to control the rotation of the bones with the rotation of the movers.

So if you try to use the reqular expressions ( ch(..) or vrorigin(..) ) applied to the rotation channels you will be really dissapionted - it does not work right. So, this will put the end of your efforts to do some more advanced rigging in Houdini.

I tried many different things to work around this fundamental problem, but at the end i always needed to script rotations from object to bone and it simply does not work.

If i try to be too "smart" i can scale these movers ( objectOPs ) on Z=-1 and then the vrorigin thing will work, but then the direction of axis Y is inverted - the animators will lynch you.

Btw, i just noticed that something weird is happening when set one of the scale axes to negative value and then grab the transformation handle and move the object around - take a look at the rotation and scale channels - weird ?

Ok once again - the rotation order of the bones must be the same as every other regular transform object. Even better - expose the orientation as transformation channel - so every one can manually tweak it. This is very usefull, really.

One will say - dude, why not using blendOP ?

There are few reasons for that - if you want to do multilayered rigs then you really want to keep the different bone chains in the same local transformation space ( keep the hierarchies consistent ), otherwise you are going to shoot yourself in the foot.

So here is the pain with the blendOP, you cant really use it without destroying the hierachry ( and in this way changing the local transformation space of the bone chains and the consistency of the hierarchy itself ), because to "constrain" something in Houdini you actually want to parent it under the blendOP. Ok, ok, it's not that bad when dealing with objects only ( or bones only ), because you can keep everything in place, and simply add blendOP's, then transfering their transformations using ch/*origin expressions, but this does not work when having bones and transforms ( look at the notes above - locked rotationOrder / flippedAxisZ of the bones ).

Another ultra annoying thing about the blendOP is that when using it to blend orientations, it flips - wow, now that's bad.

Make a simple test - 3 objects, first two connected to a blendOp, the third one parented under the blendOP.

Now when the blendOP is in blend mode, it will flip on +- 50 or 60 degrees on X and on 180 degrees on YZ.

If the blendOP is in Sequence mode, then it will flip on +-180 dergrees on any axis ( if the sequence attribute is != 0.5, then the flip will happen faster in one of the rotation directions ).

Ouch.

The constraints need to affect the constrained nodes without need to break-up the hierarchies and to parent whatever needs to be constrained under the constraints. Let them just edit their transformation matrices.

Actually without powerfull methods for constraining stuff in object level i dont think Houdini is going to do very well on the "character market".

Seems to me that object level and COPs are the most underdeveloped areas in Houdini ...

Let's talk a bit about the geoCapture OPs.

The whole idea that a geoCaptureOp to can operate with a single bone chain only is not good at all. Actually the idea to deal with bones only is kind of too restrictive. All you need to deform points is an objectOp ( a transform point in the space ). Bones, capture reqions, ok - fine, but once again - somethimes its not needed, especially when doing games. Actually as far as i know most of the game translators require everything to be skinned to a simple transform nodes.

Thinking more about that - it will be really nice if the geoCaptureOPs can accept shapes as bones - this is the most strightforward way to make muscles ( at least the sticky layer ). Can you get what i mean ? Deforming the geometry used as bone ( the muscles ) will directly affect the skin. It's way mutch better than using wraps on top of everything for sticky muscles layer, because its consistent with the rest of the capture wieghts.

Another thing i really want to see in the geoCaptureOp - the bind and prebind matrices to be available for the user - so i can manually connect/disconnect my bones to/from them. The ability to connect stuff to them and in this way to edit ( literally preanimate ) this essential for the skin deformations data, brings some nice freedom.

Difficult to explain, but man, bring that stuff here.

If at some point we want to do multilayered rigs, then we need a weightPainting tools supporting that. Can you imagine having 7 bones on top of each other - you are going to MMB clicking forever to get the right one for painting

Scripting - the rigging workflow requires tons of custom tools. The current condition of HScript and Expressions are not going to match this requirement at all. The interface must be 100% scriptable.

You know what should be done ...

Deformers - lots of them, and of any kind. Metaballs, lattice and broken Wire Deformer are just not enough.

Also, make them fast - the current performance of the deformers is slow.

As some sort of ex-animator i can tell you that the way how Channel Editor and transformation handle behave is not going to work very well for animators in general.

The viewport transformation handle is really unhandy. While for the most part we can get used to it and after a while it's not going to disturb too mutch, there is one thing which is really funny ( scary ) - create a bone chain with 3 bones ( you can use any hierarchy of transforms for this little experiment ). Now, select bone number one, then number two then number three - use the rotation handle to rotate them all togather - good - works fine. Now, select the bones as well - nr.3 nr.2 nr.1 - try to rotate a bit around - ouch !

Channel Editor - the curvature type of the animation curves can be set per curve segment instead of per keyframe - now that's really not good.

...

It's kind of silly to complain on public forums, but maybe little online noize can help a bit to realize where we stand.

Maybe not ...

Apologize for any hurt feelings.

[sibarrick]

Another ultra annoying thing about the blendOP is that when using it to blend orientations, it flips - wow, now that's bad.

Make a simple test - 3 objects, first two connected to a blendOp, the third one parented under the blendOP.

Now when the blendOP is in blend mode, it will flip on +- 50 or 60 degrees on X and on 180 degrees on YZ.

If the blendOP is in Sequence mode, then it will flip on +-180 dergrees on any axis ( if the sequence attribute is != 0.5, then the flip will happen faster in one of the rotation directions ).

Ouch.

Deformers - lots of them, and of any kind. Metaballs, lattice and broken Wire Deformer are just not enough.

Also, make them fast - the current performance of the deformers is slow.

Apologize for any hurt feelings.

27115[/snapback]

I think generally Sesi like to hear this stuff, that way they can either improve things or explain some piece of workflow that you are missing. Since there is still not enough info on how you are "supposed" to use a lot of the tools together. It's getting better on how to use them individually but not necessarily the bigger picture.

That's one long post by the way, still trying to get my head around some of it...

Just tried a quick experiment with the blend op, for everything I've used it for I've not experienced the flipping you are talking about. I tried your example, which I wanted to upload but as others have mentioned (and now I believe them) uploads are currently broken. Is it broken with Shortest Path Rotation Blending turned on?

What other deformers are you looking for? I'm still waiting for a wrap deformer and have ended up writing my own, plus some others, but i'm interested if there are any particular ones you are thinking of.

[sibarrick]

If you're into this, I would rather look at Alex Mohr's stuff instead:

http://www.cs.wisc.edu/graphics/Gallery/SkinFromExamples/

Personally, I don't like the MWE formulation.

27111[/snapback]

Actually, I've seen this before, but I'm now re-reading it with a fresh eye.

Thanks for the link. This approach is very related to my own flex system of interpolated joints, and point cloud interpolation of matrices..

All of these papers are making me think of improvements i could try already.

De-coupling the weighting of the rotations and the position blending might lead to better joint formation for interior bends... must try that.

Also now wondering whether after the initial setup and capture whether I can somehow filter the point cloud and remove unneccessary data points so as to greatly increase the speed....

Or in fact if I could interpolate the data points themselves using a PSD (or similar), thus removing the need to recalulate them all for every frame....

hmmmmm..... much food for thought.

[Mario Marengo]

Not much of a muscle-deform/rigging person myself, but this stuff looks very interesting.

Looking forward to your experiments Simon!

[thekenny]

Or in fact if I could interpolate the data points themselves using a PSD (or similar), thus removing the need to recalulate them all for every frame....

I think your system would be able to to the above with a bit of work. From the way I am looking at it you're not that far now. I think it is just how you interp the values to get away from the linear blending.

@peship...

umm.. I've been rigging in houdini since 1.1

I might have encountered similar problems that you mentioned but have just "learned" how to work around them. For interest sake... post little examples of what you want to do, or have tried and I'm sure you will get some of us trying things out.

you raise some interesting points.. which should be considered. However, I have found that Houdini does have a very unique bone/capture system right done to how the solver works. everyone coming from a different pkg gets a bit funked up about it at some point. for the life of me i don't know if SESI would document it fully or if they don't want anyone (other Apps) to know what is going on under the hood.

but that's just me.

-k

[michael]

peship >

why a multilayered rig?

I personally would want to avoid a multilayered rig as much as I could...unless there was a specific reason for it - mocap etc...or games maybe (I don't know)...

[sibarrick]

I think your system would be able to to the above with a bit of work. From the way I am looking at it you're not that far now. I think it is just how you interp the values to get away from the linear blending.

27122[/snapback]

Indeed. What I'm really interested in here is A. making it faster to use, and B. adding that extra layer of fine control.

I really like the idea of PSD etc. where you are able to directly model the adjustments to poses that aren't dropping out of the system naturally.

Yeah linear blending is a pain, i really need to use something more like a NURBs interpolation.

So many things to try so little time....

[peship]

at thekenny

ok, lets see at the next example scene:

http://petershipkov.com/temp/weirdRotationOrders.hipnc

what you have in the scene:

3 simple hierarchies - stright FK chain of movers, ik bone chain, blend bone chain and a IKFK named node with added a spare channel called IKFK use it as blending koefficient.

the very simple math to control each rotation channel of the bones in the blend chain should be something like:

blendFKIK * rotationFK + ( 1 - blendFKIK ) * rotationIK

give it a try.

at sibarrick:

take a look at this scene:

http://petershipkov.com/temp/weirdBlend.hipnc

simply select geo1 and rotate it on X

you can try any options you like for the blendOP.

at arctor:

why multilayered rigs ?

because of the same reason why people render on passes - for better control

the first example coming in mind - imagine - you have couple of bone layers - skinBones, FKbones, IKBones, blendBones, shoulderAutomation, twistBones, jiggleBones, fixBones, etc.

if you have the right toolset you can do your rigging in procedural manner.

Let's say at some point after you started the rig long time ago you want to change the proportions of the left arm - all the layers are designed in a way that they behave as autonomous systems.

Each component has few slots and hooks - so you can attatch to it other layers, and can attatch it to other layers.

If you want to redo some of them - go and do it - just detatch couple of hooks temprary and then attatch them back after you are done with the changes to other layers.

The same goes with the skin joints - they are a separate layer and only they are used to deform the mesh. The final transformation produced by the rest of the layers is applied to them, so even you want to make some major changes in the rig at any time - just unparent these bones and then parent them back to whatever is needed when you are done with the rig changes.

You dont even need to detatch the skin from them.

One will say - but look, you just changed the proportions of the rig, and then parented the skinBones under nodes located on already different positions in the space - this deformed the skin.

Ok, no problem - if the bind/prebind arrays were accessible, with a very simple scripting loop would transfer the data from bind to prebind matrices and this would reset the point positions of the skin internally ( matrix / inverse matrix ) - so the skin is back in the rest pose ...

There are many other reasons, but hey, i think you can get the idea.

As thekenny said - software XXX is poorly documented. This is somehow not an exception. You cant really find a good explanation about how to practice artisan. Better practice it .

[sibarrick]

Hey man, i think you attached the wrong file the two geos have no rotations in them so it works beautifully, it rotates perfectly from 0 to 0

[thekenny]

One will say - but look, you just changed the proportions of the rig, and then parented the skinBones under nodes located on already different positions in the space - this deformed the skin.

Ok, no problem - if the bind/prebind arrays were accessible, with a very simple scripting loop would transfer the data from bind to prebind matrices and this would reset the point positions of the skin internally ( matrix / inverse matrix ) - so the skin is back in the rest pose ...

There are many other reasons, but hey, i think you can get the idea.

Um,

You can do what you describe. You just need to use bonealigncapture hscript command. Sure there a few tricks. If you use the capture pose method for your work you still need to be aware if your rig controllers have animation on them or not. The option for Settings-->Objects-->Capture Pose will place the bones in to their position, but if the controllers have animation going on which was the "capture frame position" then you will be hosed. IHMO the above option doesn't operate as the user would desire. I think it should override everything add just put your bones in the right spot. Anyway..I lost myself.

So now you can capture, paint, animate, unparent, do some thing, reparent.. do some thing, align the captures (thus defining your capture and all that bind/prebind array stuff is taken into accoutn) bingo bango.

I think you just need someone to show how it can be done.

I do have a problem with how some of the OTL controllers we used (on the Wild) couldn't interact with the poseTool when you wanted to snap to FK to IK.. we had to script the rotations from one to the other kind of thing.. so it was a pain.

Just being curious.. what package are you most familar with? (just humor me)

I'll try to look at the file during lunch...

-k

[peship]

You can do what you describe. You just need to use bonealigncapture hscript command. Sure there a few tricks. If you use the capture pose method for your work you still need to be aware if your rig controllers have animation on them or not. The option for Settings-->Objects-->Capture Pose will place the bones in to their position, but if the controllers have animation going on which

[sibarrick]

at sibarrick:

that's right, there is no animation.

just select geo1, press "r", grab the rotation handle and rotate it on X.

whatch out what happens with the "constrained" object.

27166[/snapback]

Oh I see I've never used it as a "constraint" that way, I use it as a blend operation just to blend between existing animations I don't think I've ever tried manipulating the blended object directly (weird, never thought about it before). I still can't get it to flip the way you describe though, it behaves in a completely stable way for me.

If I mix up the rotation to something random on each geo then it starts to do what you describe, however if I insert a null between the blend and the geo3 then all is fine again. Not sure why that should be though...

[Mcronin]

It only seems to flip if you manipulate it with a viewport handle. If you use the parameter field or drive it with a reference it seems to work fine.

[thekenny]

the tool does not matter as far as it allows me to do what i want to do.

in this particular case it does not.

why you think i'm making noise here ? 

I know you are pulling my forum leg here, but i was just curious.

I've seen users from Soft/XSI/Maya/3DMax sit down and try to what they would normally do in package X and scratch their heads at how houdini does things. Example. the IKsolver.. in maya and xsi/soft there are (i believe) two critical vectors for bone fliping. You had to be very careful about these zones and set your rest angle the right way so you could get the best range of motion without flipping. In Houdini there is just one. which is the vector created from the end of the bone chain to the root derived at the rest position.

Just different.

I still haven't looked at your file yet. sorry.

I was just curious where you were coming from. Often it helps when trying to adapt to a Houdini way of thinking. (as lame as it sounds)

-k

[calin_casian]

I don't know if this is what you would expect to see but please take a look at the attached files.

calin

weirdBlend_mod.hipnc

weirdRotationOrders_mod.hipnc

[peship]

hi Calin,

thanks for spending time answering my questions. appretiate it.

about the blendOp_mod:

what you are showing is a local transformation.

i think that a real constraint should work independently by the local space of the object. if i parent the geo5 object you created in your scene under another object and rotate this object you will see that this will change the position/orientation of geo5.

blendOp is doing exactly what is expected by a constraint - it recalculates the transformations along the upstream connection and applies changes to the local space of the constrained object - so the object will always be aligned to whatever is constrained.

sadly the blendOp breaks ( as Mike noticed, when using parameter sliders it behaves better, but still flips on 180 degrees ).

about the orientation order:

i can see what you did, but this rised more questions than answered.

if i change the orientation order of even one handle, then i will need to do the same for all the handles in all the rigs, otherwise when handles from different rigs interact togather ( for example animator attatches a prop to the belt of one of the cg characters ) then we are going to have the same problem like what i show in my example file, but this time not between bone and object, but between two objects with different orientation orders ).

if you leave some of the handles with the default rotation order and you have several ones with changed rotation order this will mess-up the consistency of the pipe.

i can see that you are not rigging in layers, but even that, there are a lot of cases outside of this workflow, where objects control the rotation of the bones. dont tell me that you are always parenting the bones under the handles and you never needed anything else ...

so how you are dealing with that ?

from what i can see you cant do it without changing the rotation order of the handles, do you mean that you are completely changing the rotation orders for all the animation handles in all the rigs ?

sounds weird to me, but maybe that's the key ...

anyone from CORE sneaking around ?

anything to add ?

...

at thekenny:

i am not really sure i'm fallowing you on the ik solvers.

all the ik solvers in maya have integrated aim constraining ( really powerfull ) - so you can manually set the up-vectors used by the ik solvers, in addition there are pole vectors.

usually the pole vectors are more than enough, but with these integrated twist controls you can do weird ( and useless in general ) things.

long time ago a SI3D guy, i was little unhappy when tried XSI ( talking about rigging ). i know that there are issues with the XSI's ik solver, maybe why that SI downgraded to the old SI3D ik solver.

i think ILM "suggested" that

...

man, this talk is getting retarded, are we need a break ?

[sibarrick]

So I take it no one has used MWE?

[edward]

Well, no one here? I suppose ILM has?