Jump to content
edward

Delta Mush

Recommended Posts

For those of you who went to SIGGRAPH this year, might have seen the Delta Mush talk given by R&H:

http://dl.acm.org/citation.cfm?id=2614144

 

It took me <5 min to reproduce in Houdini using the Edit SOP's reference input. Figure I'd share it as it seems other people have been posting the same in their favourite package. The "deltamush" node in the file was created with this command: cd /obj/tube_object1; sopcreateedit deltamush smooth1 INPUT

And then I rewired it into the setup shown.

deltaMush.hip

  • Like 2

Share this post


Link to post
Share on other sites

Ah "Reference Input"; so that's what you can use it for! ;)

 

Yes, there is also a QLib implementation for Houdini out there.

Share this post


Link to post
Share on other sites

That's a cool idea... Although I was aware of the "reference geometry" input of the Edit SOP, I always felt that there should be something similar, but more general-purpose, in terms of "surface space" editing. So, having this in qLib scratches more than one itch, so to speak. :) (I couldn't have guessed that it could be done using a simple Edit SOP, though :))

 

What you can find right now in qLib:

- there's a gallery item ("Point Wrangle: delta mush utility"), which is a PointWrangle SOP preset, containing the necessary math for converting to/from "surface space" (or whatever you'd like to call it)

- gallery items for smoothing/relaxing geometry (a pointcloud- and a topology-based one), and there's a Smooth Points qL SOP that wraps it all up in a single node

- a "Displace by Delta qL SOP", implementing delta mush as a single node

 

Having a single-node delta mush is fast (all is packed inside a single VEX block), but we're also planning to have a capture/deform pair implemented (to allow for more in-between trickery), as this is pose-based deformation territory, where many interesting things can happen. ;)

 

---

 

Yes, the actual math behind delta mush is pretty easy. It is not the math, but the effort it took that matters, though -- the time they took experimenting and (production-) testing, and concluding "hey, this works!" This is what we all got from it, not just the deformer math. ;)

Edited by riviera

Share this post


Link to post
Share on other sites

hey i came back after checking the "Qlib", i must say its really neat, i can't believe i miss this tools, thanks alot

 

now the only idea left in my head is the adjustable nature of voodoo, i see how the user can adjust the bones after capturing the geometry.

anyone have idea about that?.

 

im currently trying to create a python callback to copy values form "adjust rig" to "bind rig".

Edited by willow wafflebeard

Share this post


Link to post
Share on other sites

now the only idea left in my head is the adjustable nature of voodoo, i see how the user can adjust the bones after capturing the geometry.

anyone have idea about that?.

 

As far I as understand it, that's because they don't paint weights. All the weights are recomputed procedurally on the fly using their volume/geometry procedural-based capturing method. In Houdini, this is sort of like capturing using the cregions except Voodoo has a lot more options than just regions. So when you adjust the bones, this adjusts the cregions, and the Capture SOP will just recompute the weights.

Share this post


Link to post
Share on other sites

So is all facial animation done via blendshapes. that can be a nightmare right? Because of the collision of multiple shapes.  

Share this post


Link to post
Share on other sites

I didn't say that at all. I was replying willow's post about capture weights. Capture regions define an area of influence that dictate how the skin deformation is performed. Blendshapes is an entirely different technique.

Share this post


Link to post
Share on other sites

Yea,I asking if they don't paint weights anymore for the face, if so then that would mean none, or close to no bones in the face. Which leaves only blendshapes for facial animation (that I know of).

Or did R&H still use bones and paint capture regions in voodoo when it came to facial animation?

Share this post


Link to post
Share on other sites

Yea,I asking if they don't paint weights anymore for the face, if so then that would mean none, or close to no bones in the face. Which leaves only blendshapes for facial animation (that I know of).

Or did R&H still use bones and paint capture regions in voodoo when it came to facial animation?

 

they said in the vimeo videos that its a library of blenshapes from a generic face , mapped in a new face

i want to steal the opportunity to ask again. would it be beneficial to add a muscle system on the face?. or blendshapes are better

 

 

As far I as understand it, that's because they don't paint weights. All the weights are recomputed procedurally on the fly using their volume/geometry procedural-based capturing method. In Houdini, this is sort of like capturing using the cregions except Voodoo has a lot more options than just regions. So when you adjust the bones, this adjusts the cregions, and the Capture SOP will just recompute the weights.

 

we could try pressing the recapture button in python after the bone adjument is done right?, but we still have to paint weights, specially with muscles, and regarding that is there a way to eding metaCapture of boneCapture in vops they are pt attribs right, but it seems to clamp ti to 1float whenever i bind it back.

Edited by willow wafflebeard

Share this post


Link to post
Share on other sites

Unfortunately, it's not currently possible to edit capture weights (of any type) in VEX/VOP.

 

For facial rigs, I've seen both bone based rigs, muscle based rigs, as well as blendshape based rigs. I'm not sure I can say offhand which is "better". I think it all depends on the quality of the rig, the expressions you want, and possibly other trade offs like performance, etc. I think usually the important thing is make sure each facial part deforms plausibly. Different methods can achieve this.

  • Like 1

Share this post


Link to post
Share on other sites

i see, so paintless weights are not possible yet. am i correct, unless someone makes their own capturing sop. :mellow:

we better just put this one on the wishlist of H14.

 

thanks for the info ed

i will probably go into the wishlist tread to give some thoughts

Edited by willow wafflebeard

Share this post


Link to post
Share on other sites

Sorry, why are paintless weights not possible? I don't think we even added painting capture weights until H5. It's can be more work to use just capture regions for weighting, but it's been done before.

Share this post


Link to post
Share on other sites

prodecural editting of weights, i should say. because i was thinking of adding weighs based on region then filtering it using geometric connectivity, but since the attributes are not editable, i thought it would be impossible.

 

so say the regions of the forarm will not paint unto the side of the body simply because they are far neighbors

Edited by willow wafflebeard

Share this post


Link to post
Share on other sites

I hope you like this.

I think you forgot to compute point matrices for deformed geometry. Right now if you rotate the object deltas wont rotate.

Edited by rayman

Share this post


Link to post
Share on other sites

I think you forgot to compute point matrices for deformed geometry. Right now if you rotate the object deltas wont rotate.

Thank you for reminding me. I checked, it really can not rotate. Then I checked the algorithm, it was no problem. The problem was in the edit node. If you rotate a geo who was edited by an edit node it will be break. I think use bones rig or other way to deform it will no problem. Maybe I misunderstand you.

Delta Mush_rotate.rar

Edited by aty84122
  • Like 2

Share this post


Link to post
Share on other sites

For those of you who went to SIGGRAPH this year, might have seen the Delta Mush talk given by R&H:

http://dl.acm.org/citation.cfm?id=2614144

 

It took me <5 min to reproduce in Houdini using the Edit SOP's reference input. Figure I'd share it as it seems other people have been posting the same in their favourite package. The "deltamush" node in the file was created with this command: cd /obj/tube_object1; sopcreateedit deltamush smooth1 INPUT

And then I rewired it into the setup shown.

I'm trying to figure out something. If I manually create the Edit SOP, nothing happens at all when I wire it up. However, when I create the Edit SOP using that command in the textport - it works as it should. Why is that? 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×