Hair styling

[Owl]

what am i doing wrong here, it seems that houdini interpolates between guide curves in rather strange fasion. There is a screen shot of Shave and haircut in maya and fur in houdini:

guide curves are imported from maya. when i try copying lines over the mesh it works, but not with the imported curves.

Why is it happening and how can i fix it?

P.S. might it be becouse of the sorting? just had an idea, thou couldn't test it yet.

[edward]

<shrugs> post your .hip file (don't forget to lock your file sop)

[Owl]

<shrugs> post your .hip file (don't forget to lock your file sop)

here it is hair_prob.hip

recreated the situation with simple lines - sorting is a problem, as far as i understand fur interpolates between guides according to their order? (correct me if i'm wrong).

Edited September 16, 2008 by Owl

[jason_slab]

here it is hair_prob.hip

recreated the situation with simple lines - sorting is a problem, as far as i understand fur interpolates between guides according to their order? (correct me if i'm wrong).

hey

i had the same problem importing curves from XSI, we eventually tracked the problem down to the Vertices order of some of the curves that where reversed.

if you open up your view port display options you can turn on our vertices numbers to check this.

jason

[Owl]

hey

i had the same problem importing curves from XSI, we eventually tracked the problem down to the Vertices order of some of the curves that where reversed.

if you open up your view port display options you can turn on our vertices numbers to check this.

jason

solved it - i've recreated guide lines with copy and for each sops, seems to fork fine for now.

here is the hip hair_prob_solv.hip

P.S. there was no reverse curves, just wrong primitive order

Edited September 16, 2008 by Owl

[Owl]

i've got another question, how do i lock guide curves on a deforming mesh?

Edited September 16, 2008 by Owl

[edward]

I had lots of help since I was interested in this. Here's what happened after playing with the file.

hair_prob_pin2.hip

[Jason]

I had lots of help since I was interested in this. Here's what happened after playing with the file.

I tried to approach this from the more intuitive approach (ie., no quaternions and matrix math), the way that an average artist would think about it - and that is to group the root points of the hairs and bind them "wrap deformer"-ish to the skin (for which I used the Lattice SOP - we'd still love a proper Geometry Capture & Deform SOP combo). Now I'm thinking that just moving around the roots of the hair (which are Wire Glue Constraints in the simulation) and that the length of hair should just be dragged along behind it.

Unfortunately when you are dragging around the roots by activating "Deforming Geometry" in the Wire Object SOP, it considers the segment lengths of the fur to be changing - and there seems to be no way to lock this length down. We'd need SESI to add the capability to "Use Segment Length At Creation Frame" to do this. Or perhaps the Wire Solver should be made aware of another primitive attribute for "seglength" (alongside the the ones it ready respects, as mentioned in the Wire Object DOP help-card) which should override any dynamically computed segment length.

The binding of the roots of the hair to the skin (using Lattice) is a lot more simple than trying to bind an entire long hair. They're nice and close to skin, making it easy to use a small radius on the Lattice SOP. Even Edwards cool example has the lengths of each hair changing, which would look bad once simmed using the Wire Solver.

One more RFE for the wire solver would be to be able to not solve with springs at all and just do a quick rigid solve of the wire. This should allow you to yank around a curve (including wire collisions) without any deformation.

We should definitely straighten out this pipeline since Houdini doesn't yet have any long hair grooming tools and so a solution is to load guides from elsewhere (like Shave).

Cheers,

Jason

hair_prob_pin_wiresolver_edgelength.hip

[edward]

If you want speed, I think a wrap deformer approach would be the wrong one to take. As for quaternions, it's not like I'm doing anything fancy ... just computing a transform change and then applying to the hairs.

[Jason]

If you want speed, I think a wrap deformer approach would be the wrong one to take. As for quaternions, it's not like I'm doing anything fancy ... just computing a transform change and then applying to the hairs.

Would a wrap deformer only moving 20,000 (root) points be so slow? The lattice could be slow because it's re-capturing every frame, but a properly written Geometry Capture and Deform could be a lot faster, no?

Granted- it's a lot slower than your method "), (but then how could we reinforce the Wrap Deformer RFE? ) ...but far more likely the way an artist would go about it - unless a tool like the one you've created can be made into a nice SOP (like the Align SOP, I suppose).

[edward]

Would a wrap deformer only moving 20,000 (root) points be so slow? The lattice could be slow because it's re-capturing every frame, but a properly written Geometry Capture and Deform could be a lot faster, no?

Granted- it's a lot slower than your method "), (but then how could we reinforce the Wrap Deformer RFE? ) ...but far more likely the way an artist would go about it - unless a tool like the one you've created can be made into a nice SOP (like the Align SOP, I suppose).

I confess that I didn't look at your file until now. If you just want to constrain the root points to the scalp, then after sorting the curves, there's no lattice or quaternion math is needed. We already have the primitive order of the curves matching the point order on the scalp. This means we can just run through the root points and copy the positions from the scalp directly using a single Point SOP.

Anyways, the reason why I went through the trouble of re-orienting the curves in a rigid transform is to solve the wire solver issue you encountered. If you just wireglueconstraint the rigidly transformed hairs, the wiresolver will work.

[Jason]

I confess that I didn't look at your file until now. If you just want to constrain the root points to the scalp, then after sorting the curves, there's no lattice or quaternion math is needed. We already have the primitive order of the curves matching the point order on the scalp. This means we can just run through the root points and copy the positions from the scalp directly using a single Point SOP.

Ah yeah, true. However, for the most forgiving, general solution (really expecting things to be out of order) we might need a wrap deformer, if you agree? Even in that hair set, there are a fair number of wacky primitives in there... just Delete primitives one-by-one and see...

Anyways, the reason why I went through the trouble of re-orienting the curves in a rigid transform is to solve the wire solver issue you encountered. If you just wireglueconstraint the rigidly transformed hairs, the wiresolver will work.

Yeah, I figured yours should work with the Wire Solver properly. At first I wasn't sure that yours was an affine transformation (and so you'd have the same problem I did) but, looking closer, I guess it must be.

[edward]

Anyways, the reason why I went through the trouble of re-orienting the curves in a rigid transform is to solve the wire solver issue you encountered. If you just wireglueconstraint the rigidly transformed hairs, the wiresolver will work.

Er, I should qualify that the wireglueconstraint DOP will also need Constrain to Animation toggle enabled.

[edward]

Ah yeah, true. However, for the most forgiving, general solution (really expecting things to be out of order) we might need a wrap deformer, if you agree? Even in that hair set, there are a fair number of wacky primitives in there... just Delete primitives one-by-one and see...

In this case, I'm not sure why one would want a wrap deformer to copy point positions. If we're talking about deforming all the positions of the curves, then we're into the area of generalized deformation. Note that, Simon ended up (optionally) using the orient attribute in his wrap deformer anyhow. If you insist on using a deformer approach, then yes the lattice points mode can be used. Or alternatively, you can use wirecapture/wiredeform (as attached).

hair_prob_wiredeform.hip

[Owl]

I had lots of help since I was interested in this. Here's what happened after playing with the file.

wow, thanks a lot, thats brilliant

[thekenny]

Would a wrap deformer only moving 20,000 (root) points be so slow? The lattice could be slow because it's re-capturing every frame, but a properly written Geometry Capture and Deform could be a lot faster, no?

Yup it would be slow as the latticeSOP doesn't have a caching method like the "deformSOPs" so there would be a recalculation on inputs for each frame. On a cooking basis it would always be slower then the sop specialized for capture/deform.

I'll try to update my system and see if I can play along. This looks like fun.

-k