Jump to content

Delta Mush


edward

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
Link to comment
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
Link to comment
Share on other sites

  • 3 weeks later...

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
Link to comment
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.

Link to comment
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?

Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
Share on other sites

  • 3 months later...
  • 2 weeks later...

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
Link to comment
Share on other sites

  • 1 month later...

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? 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...