This is a thread that comes from odforce. I don't think it is up here yet, apologises if it is.

Meshsmooth, brought up the topic of “skinwrap” a new tool in 3DSMax that allows deformations of high res meshes with low res ones, and wanted to know if Houdini could do such a thing.

“Yes” of course it can everyone said just use the lattice sop in point mode. I thought the same thing. However on further examination it proves to be more than this, or else it has one very big limitation.

The lattice sop only looks at the delta between rest and deformed states and then just adds a weighted amount of this delta onto the deforming input mesh. However for this to work as a full blown animation deformer it needs to look at the full transform for each point not just the delta. And maybe it needs a option to normalise the point weights too, either way at the moment it doesn't work properly. Basically at the moment if you rotate the deformed mesh by 180 degrees you don't get the input meshed deformed in the same way, all the points just pass through themselves, naturally, since they don't know they've been rotated.

So it seems Max does have a powerful new feature that Houdini doesn't, and further more I think it would be a very useful tool to have, especially when dops come out. With something like this properly implimented you could do your sims on low res geometry and then use it to deform the high res stuff, rather than having to pump the high res stuff itself through the sim.

Anyway, what do you think Sesi?

One way to get that transformation would be to have an coordinateSpace frame of reference on the deformed and on the rest. That difference will give you the information you are looking for. I've done this in the past with complicated networks where I set up a number of deformSOPs and made them deform something I set to be “N”.

while this works the only sop which can deform these new vector attributes is the DeformSOP. I'm almost thinking that for the performance hit you could do so much more if every sop transformed arbitrary vector attributes like a normal.

I'm sure you could do some VexSOPs to get you part way there, but it would be faster if it was internally solved.

Sound crazy?
-k

Not so crazy. Definately worth a look see.

Read the odforce thread on this very subject. I also watched the videos and came to similar conclusions:

Skinwrap:
- lo-res geometry to deform hi-res target geometry
- lo-res verticies are used as “clusers” to deform the hi-res geometry

Pros:
- obviously the display/plaback vs. render thing.
- Solution for cloth solvers to manipulate a lo-res geometry then transfer to high-res.
- Great for games as you can slide other sets of clothes procedurally over a “base surface”. I believe this is the intent. Building alternate levels and characters in games is a big time waster. This certainly addresses that.

Cons:
- Loss of detail in the high-res geometry is inevitible in their solution, especially in areas that undergo considerable deformation. This is inevitable and is a welcome restriction given the positive games implications.

What I Don't Buy:
I don't buy in to the lo-hi res driver thing as cool as it is for everything. The main reason to go hi-res is more control and detail to work with. In characer animation, at some point with clothing you want direct control for the cloth, the folds, how the cloth twists around the shoulder, etc. Attribute transfer and point clouds allow you to move the correct attributes from the lo-res to the high-res for further refinement and editing.

How to implement such a feature?
I would do what Ken Ouellet suggested: Complete the wire capture and wire deform tools as follows:
- Support for arbitrary meshes along with curves.
- Tools to support Curve tools in object viewport as with the capture weighting tools. They should feel seamless.
- Capture tools to work along with deform SOP and capture regions. We would have true point clusters then, not just zero weight bones. The Deform SOP would consolidate all the deformations and would provide a nice, fast solution. Include paint weighting to the wire tools and we have the ability to capture with bones AND geometry with full paint and point weighting.


The most accurate way to mock up this tool IMHO would be to align zero length bones to each point in the lo-res grid oriented with per vertex co-ordinates, capture and deform. Deform the lo-res grid would transform the bones aligned to each point. All bones would get a global pill size with per bone radial adjustments. We could have this with just points if the wire capture/deform tools were fleshed out to their logical conclusion.

I total agree with the idea that the deform sop should be able to take all capture types and apply them in one hit. I'd love to see the ability to mix bone capture and wire capture in one. And with the added ability to paint capture weights just as you can with bones, yes please. The problem with the wire deformers as is, is that they don't store transforms they store deltas. Take a look at my skin sop on exchange, in the example file I include a comparison to what the wiredeform sop does, it ain't pretty once you start rotating the wires around. My current solution is to use frames of reference at each point, this works very nicely, and they all get stuffed into a point cloud for efficiency. It sure would be nice though if this type af thing were intergrated.
I thought about mocking it up with zero length bones, but it just seemed like a total nightmare to implement and involved far too many nodes…. :?

At the moment I'm working on a mock up of using curves as “capture curves” the control points of the curves are parented to the bones so that the curves can smoothly deform as the bones move around. To me it seems the logical extension of bones that they can be based on curves and so can either act as rigid bones ( as the current ones are) or as flexible deformers. I'm pretty sure you'd get much more organic deformations and there would be less need for painting weights. Anyway watch out on exchange for a demo. ( it's holding up the hair system at the moment but it's more interesting…. )

WireCapture doesn't store deltas, it stores UV coordinates of your rest geometry to the closest point on the capturing primitive. It is then weighted according to the distance. We then deform using a coordinate space formed by the tangent and the normal at the captured UV coordinate on the rest capture primitive and the deformed capture primitive.

What you're likely seeing instead is that fact that since WireCapture was originally conceived to deal with facial deformations, it doesn't normalize the weights found in the wireCapt attribute. If you hand normalized this attribute and change the deform method to Weighted, you will likely fix the problem that you're seeing and essentially behave like bones minus the UV part.

Nope, tried that doesn't work for me. Maybe you could download the file from exchange and modify it so that it works. I've had a quick look at this and I can't see quite what you mean by hand normalising the weight attribute, but I'm using weighted blends anyway.

From what you say I think I can now make more sense of what i'm seeing. When I use wirecapture and rotate my wires by 180 degrees in y, the deformed geometry “rolls” around, is this because you are only using a normal and a tangent? I think what you need is a fixed frame of reference, which is what I've written.

Perhaps the options you mention needs to be added to the wirecapture?

When we were prototyping a facial system it was done with set of bones shrinking and expanding on a spline. That spline was sort of fixed, but over shoot was builtin on the tail and head of the spline. It worked well, was very viewport centric but was slow, and the overhead of a large number of bones and problems getting a nice weighting solution for each cluster of bones was time consuming.

I think Simon has something with a rest frame for the wireCapture. I konw it doesn't help but for a user it would be ‘easier’ if they ‘felt’ like the familar bone tools and weighting method. Tell me again why the weights are not normalized? (I've only had one coffee this morning )
-k

When we were prototyping a facial system it was done with set of bones shrinking and expanding on a spline. That spline was sort of fixed, but over shoot was builtin on the tail and head of the spline. It worked well, was very viewport centric but was slow, and the overhead of a large number of bones and problems getting a nice weighting solution for each cluster of bones was time consuming.

I think Simon has something with a rest frame for the wireCapture. I konw it doesn't help but for a user it would be ‘easier’ if they ‘felt’ like the familar bone tools and weighting method. Tell me again why the weights are not normalized? (I've only had one coffee this morning )
-k

@Ken: For an example of what normalized weights would do, try taking a grid with lots of points and capturing just the middle of it with a single bone. Now move the bone down and see what happens. You get a hard line of the capture region.

@Simon: I see what you mean now. Yeah, you're right. The wires are never gonna cut it for example. It's not so much that it doesn't form a coordinate space as the way it figures out how to transform a point from the rest coordinate space to the deformed one.