No Skin

[amm]

 

 

Hello,

just wanted to show my long time summer project. It is a human body deformation system, completely based on Houdini VOPs. So, no any of usual, pre defined operators here, like skin, blend shape or lattice. Instead, idea is to allow to use anything that fits to particular body part. For now, 2d joints are simple, bone axis based blending - positions are firstly moved to static inverse matrix of bone, then there's some deformation, then they are moved back to animated bone. Spine is a mix of b - spline for center of rotations, while rotations are quaternion SLERP. 3d joints are similar to NURBS blends. Used the things like XYZ distance VOP in animated part, only for shoulders area, because just wanted the very exact shape. And so on. Related to 'pose space deformation' story, something here is PSD, something is not. VOPs are executed one after another, from Childs to parents. More or less, it interprets the matrices as structure of mocap rig, where only the last matrix somewhere around torso, holds a full transformation, while everything else is rotation - but this is not a rule. Influences are result of distances to skeletons, additional NURBS geometry, and groups derived by first two methods.

For getting the matrices, I've used a bunch of in line optransfrom functions, about 80, saved as detail attribute on separated object. Reference pose is one cached frame of that object.

Now the question, why on the earth to create this thing, instead of common solutions. Beside obvious reasons, that I always wanted to created something like, or just
felt boring of same solution for decade(s):
- It's completely independent of topology. No any VOP does something based on point number.
- Parametric 'weighting' allows to use much, much more precise falloffs than manual painting.
- A lot of parameters rely on distances to bone, or between them, so it's quite adaptable by self.
- Custom, by body part method allows a really easy ways to forget the traditional drawbacks of linear blend skinning, like 'candy paper' collapsing.

Of course there are negative points:

- Thing works only in specific 3d app, I don't see reliable way to convert it to skinning for export in game or so.
- Speed. Not so fast, while is much faster than I expected ( whatever that means ). For now, for around 12k quads and quad core i7 machine, it's able to keep 25 FPS, only without operators related to fingers. Otherwise it is around, 10 - 20 ( of course this depends on how heavy are operators). I have to admit, that I cared only about very basic optimization, just to keep the all static calculations separated of animated ones. My wild guess, a lot of forth - back transforms of points to static pose and back, causes the main slowdown (classic skinning don't need that). While is hard to say - more than half of time showed by performance monitor, belongs to 'unaccounted'.
On positive side, it's enough to run the Houdini Poly Reduce, just after file node, to get back into desirable playback. Proxy mesh becomes just by design.

Screen shot shows Houdini network, also a set of NURBS wrappers I've used for various purposes. Also, perhaps the simplest operator, for third finger bone. I hope I'll share a few generic examples of deformation methods I've found interesting, in next few days.

 

Thank you for reading !

Edited September 27, 2015 by amm

[abvfx]

This is great work.

As for speed. I think if you could find a way to bake this into a capture sop that would be amazing.

Edited September 27, 2015 by abvfx

[amm]

Thank You. About Capture SOP, I think the promising method could be applying something like this,  to intermediate layer of about 400-800 elements, then these elements are drivers of something fast to evaluate, like Deform or Point Deform SOP - while weights are generated by machine. Theoretically, such layered system should be especially good for huge meshes. Let's see what H16 will have to offer when it comes to deformations.

For 2d joint deformation, it's easy to get this as a sort of automatic corrective shape, evaluated before Deform SOP. Already had some Softimage ICE compounds for elbows or knees. No big deal to create Houdini version.

[Guest tar]

Let's see what H16 will have to offer when it comes to deformations.

 

 

Have you tested in H15 yet? Twod mentioned Openly CooL deforms, which should mean OpenCL deforms.

[amm]

Have you tested in H15 yet? Twod mentioned Openly CooL deforms, which should mean OpenCL deforms.

 

No, but it shouldn't take long to wait for official version. I also sow this post. Yeah I meant H15, 'H16' is mistake .

[Guest mantragora]

 'H16' is mistake .

 

So you are telling that H16 release is bad? Time to switch to Maya then

[amm]

So you are telling that H16 release is bad? Time to switch to Maya then

As far as I know, there is no Maya 16, so how I could switch... Now I should stop with derailing the thread, I've started....

[old school]

Good deformation from your solution. H15 will make it easier to do this kind of work in a few ways.

 

Looking at your SOP tree, you might be able to tweak out more performance by taking the VOP SOPs and combining them in to one VOP.

 

Try this on a small part and compare in the Performance Monitor.

[amm]

Good deformation from your solution. H15 will make it easier to do this kind of work in a few ways.

 

Looking at your SOP tree, you might be able to tweak out more performance by taking the VOP SOPs and combining them in to one VOP.

 

Try this on a small part and compare in the Performance Monitor.

Thank You. Tried the opposite before few days, to use more of 'smaller' nodes - and this was slower, as you said. For now, almost every deforming VOP SOP is limited by appropriate group, anyway I'll definitively try to reduce the deforming chain.

 

Great news about H15!

[Guest tar]

Looking at your SOP tree, you might be able to tweak out more performance by taking the VOP SOPs and combining them in to one VOP.

 

 

 

Is this because of SIMD?

[MrScienceOfficer]

Combining the SOP nodes into larger VOP networks will gain performance because VOPs are compiled into VEX code thus there's no overhead for every node.

 

SOP's on the other hand are a series of C++ Classes being cooked in a chain, each cook incurs overhead i.e. extra clock cycles for things like getting the next node in the chain, testing what needs to be cooked, locking the inputs; all take time to do, not much, but it can add up.  As well as actually running all the different VEX sources, and what could quickly become ten of thousands of loops being run on points that aren't relevant to the current Vop network, even if it only results in a single if statement on those points, it can really add up, and all of that's before we even get into the topic of efficient memory management.  

 

If all the Vops for the No Skin system sat in a single VOP SOP it would be compiled into a single VEX source and would eliminate an enormous amount of overhead. 

 

 

 

Really awesome work Anto, it's quite impressive.  I'm curious if your system would work if you broke shapes down by muscles?  So rather then having the shoulder mesh you had say the pectoral muscles and the deltoid muscles as separate pieces.  I've been working on something quite similar with volumes, it seems like using the underlying muscle and bone shapes could open the door to far more detailed character work without significant simulation times.

Edited September 29, 2015 by MrScienceOfficer

[amm]

Combining the SOP nodes into larger VOP networks will gain performance because VOPs are compiled into VEX code thus there's no overhead for every node.

 

SOP's on the other hand are a series of C++ Classes being cooked in a chain, each cook incurs overhead i.e. extra clock cycles for things like getting the next node in the chain, testing what needs to be cooked, locking the inputs; all take time to do, not much, but it can add up.  As well as actually running all the different VEX sources, and what could quickly become ten of thousands of loops being run on points that aren't relevant to the current Vop network, even if it only results in a single if statement on those points, it can really add up, and all of that's before we even get into the topic of efficient memory management.  

 

If all the Vops for the No Skin system sat in a single VOP SOP it would be compiled into a single VEX source and would eliminate an enormous amount of overhead. 

Well, it is about ten percent in favor of one VOP SOP, having if - then blocks inside, against four VOP SOPs, each one limited by group (or some combination of groups).

For comparison, 'lock' of static network part, gives about 15 percent speedup, even I'm pretty sure there's nothing per - frame to evaluate, there. Even more interesting is around 15 -20 percent speedup, when input file is converted to points, using Point Generate SOP, all calculations performed on points, then input mesh is driven by points at very end of network - something about point normal, perhaps. And of course, usual view port options.

Anyway, even if I'll get a huge speedup somehow,  higher resolution mesh will eat this 1 point : 1 calculation ratio. So I think it definitively worth to go with layered approach, having a constant number of transformed elements, where transformations are just interpolated on final mesh.

About muscle system, I've considered something better for shoulders and torso, definitively want to add some muscle - like behavior, but, simulation just in order to get the pose, that's simply out of question. Could add some blend shape instead...

Secondary, simulated motion driven by animation, that's another story. Without, really hard to avoid  the 'balloon puppet' effect, imho. But this part belongs to 3d app, not really to subject of thread.

By the way, 'system' is a bit too strong word for this thing. There are some directions, to keep it topology independent and as much parametric, but 'keep it simple' is imperative. Generally I want to be able to change the complete design in let's say less than one weekend, so what fits into bounds, it fits.

 

Thank You!

Edited September 29, 2015 by amm

[MrScienceOfficer]

A few SOPs is likely better then everything sitting in one, minimizing the overhead between nodes is one of Houdini's strengths, and maintainability is more important micro-optimizations.

 

Your layered approach sounds very promising.

 

What I meant with muscle shapes was instead of using shapes like the whole shoulder, you take the contact area between say the deltoid and the skin and make just a surface of it.  Then drive that surface with a single or more transforms so you can scale, rotate and translate it.  Basically exactly what you are doing but breaking it down into smaller anatomically relevant pieces.  No simulation involved.  Very similar to what Naughty Dog did for the The Last of Us. https://www.youtube.com/watch?v=myZcUvU8YWc  (about 18 minutes in)

 

 

Anyway, I've written a bunch of interactive tools that can aid in the building of a rig(for different types of non human characters) with your No Skin not system, if your interested don't hesitate to PM me.  

[amm]

Ok, sow Naughty Dog video. My thing is a bit different, these nurbs surfaces, wrapped around mesh, they do not deforming. There's let's say derivative that deforms. H XYZ distance VOP is used to find closest nurbs uv, u or v is discarded in favor of some constant value, then there are primitive attribute VOPs to find an arbitrary number of cross section along nurbs surface. That's in static phase, later in deforming phase, ' virtual equivalent' of nurbs surface is interpolated along deformed cross-sections (and this is quite fast to evaluate). So no big deal to emulate behavior of muscles - but for now, nurbs surface around shoulder does not follow the natural positions of muscles, it's just a set of cross sections along bicep axis, arbitrary moved according the angle. Perhaps I'll need to have an another, diagonal nurbs, maybe yet another, will see.

 

By the way, just slowly working on a few much generic examples.

Edited September 30, 2015 by amm

[amm]

 

Hello,

Here's small sample scene, having some of blending methods I've used. First one is linear blend, commonly used for enveloping - skinning in 3d apps. I know everyone already knows how it works, but I think it worth to notice again, just a 'linear nature'. In case of two control positions, result is always sitting somewhere on line between them. In case of three, result is always inside triangle, and so on. It can't go 'out' (at least if all weights are in between zero and one), so there's recognizable collapsing effect.

 

Second is what I call here, compensated scaling. Cross section is scaled according the angle of rotation, trying to keep the sharp corners.
This is similar to polygon extrusion methods in furniture modeling. But somehow, its final, shearing result, looks like behavior of human elbows or knees, too. Risky part is an infinite scaling at 180 degree, so it has to be clamped at certain degree.

 

Third is a just a bit simplified 2d joint operator, used for knees and elbows. Basically it is 'compensated scaling', while rotation angle is distributed along length of bones. There are few layers of modulation. For avoiding sharp corner on convex side, all time. On high angles, there's bulge effect, even more rounded convex side, faked collision as well. I enabled the option, for use only as corrective shape, before skinning operator like Deform SOP in H. In case of using only as corrective shape, Deform SOP has to have a rigid, sharp transition, precisely separated by plane, perpendicular to rest pose of child bone. Otherwise it will output something weird.
I've used a very simplified version for fingers, just a linear blend on concave side, compensated scaling on convex.

 

Four is b - spline interpolation ( performed by H Spline VOP), along cross sections, about for or five of them, derived from closest nurbs surface. Used this one for 3d joints, like shoulders, neck, leg - foot interface, partially for fitting the leg deformations to body. Nice part of this one ( not really visible in this small example ) is relative easy way to do some specific, angle dependent deformation on particular cross section, leaving the Spline VOP to workout the rest.

 

Last is a mix of b - spline and SLERP. Instead of interpolating through cross sections, spline is a single curve, used to define the center of rotation. Found this as nice for spine area, because of separated evaluation of position and rotation, also, SLERP could be nicely modulated by gradient. Quaternion interpolation elegantly allows to avoid up vectors and such stuff.

Thank you for reading this, again

 

 

[dedeks3000]

Thank you Amm.

[amm]

Hello

In last few months I found some time to rewrite this thing. HDA with playable model is available for download on Orbolt. What's new:

- real time playback. Precisely for around 15K quads on quad core i7 machine, here is 40+ FPS. I'd believe this makes a competitive speed - quality ratio, against traditional GPU powered skin-blend shape solutions in other apps. This is enabled by reducing a number of serial, one after another evaluations. Also, there are around four sections (legs, spine, arm, head) evaluated independently.  Just for illustration of sensitivity to that speed of evaluation, let's say I had to keep all ramp parameters in static evaluation part.  All operators become more complex as well.

- more unified 'capturing' system, mainly based on deformed planes placed in between bones, directly in Houdini.

Advantages of such system, in my opinion are:

- topology independent.

- parametric nature allows to have precise, exponential or whatever falloffs impossible to get by manual painting of weights.

- ability to completely change the behavior according to certain angle or another condition.

- it can be done only in Houdini  since it happened what happened with Softimage and Fabric.

And bad points:

- skeleton dependent. While just simple Mocap style FK rig is enough, it has to be very exact hierarchy structure, naming, and bone local orientations. At least for now.

- for now, a lot of not-intuitive parameters (not-intuitive = based on internal structure)

- it can be done only in Houdini

In short, thing is still a demonstrator. Anyway if it could be an inspiration for anyone, I'll be glad to help.

 

 

Edited August 18, 2018 by amm