Maya Hair Plugin - GMH2

[Hirazi Blue]

Very impressive...
When will you get around to release the system (and (what) will you charge for it)?

[FXDude]

Thanks!

All that's left is compounding/exposing the "Kristi-lena" styling Ice tree like I did for the StrandCollisionFrameWork, but UN-like it which was put together at the same time as actually making various sims with it, the styling tree hasn't been compounded as it was constantly ever changing or even starting over completely a few times.

Also I didn't investigate further about Furax node, because I though making strips or tubes from strands would have been much trickier than it turned out to be, which I found out only just recently (that it was easy and just as zippy ), so I may give Furax another go at some point.

Otherwise it'll be 499$ .. with a permanent 499$ sale rebate (=0) divided between all the authors of the tools used to make it

[Hirazi Blue]

That's very generous...

[FXDude]

I see it as "give and take"

[rray]

FxDEWD wow that looks like it will be a great hair simulation tool, and it appears so unexpected (I think It deserves a thread of its own)

If you ask me , that's a good question about the GroomTools, that I don't know the answer to yet ^^ but I will investigate!
I think storing a lot of neighbor data was too memory hungry that's why I didn't do it.
It could be that ICE somehow allows to look up everything at frame 1, or if all else fails a fixed copy could be used for looking up neighbors.
But there could be a simpler solution too, for example storing the neighbor locations, not any data. Will have a look if that's possible.

Thanks for planning to release it also with the generous rebate!

[druitre]

Very nice and generous indeed, FXDude. Like you said, there's lots of ICE-stuff around for making hair but nothing focused on a user-friendly workflow. Sure you'd be able to somehow get done what you want but not without loads of digging around and trial and error. All of which you'd likely have forgotten the next time you need to do some hair. Very cool if you have managed to sort this out and present a clear workflow.
Also might add this will be useful for a lot of things besides hair, everything strand and dynamics oriented can benefit.

(BTW, I second Rray's idea this warrants a thread of its own.)

[Mathaeus]

... and the rest is quite literally a fusion of Melena and Kristika (Kristi-lena?) hair.

Thanks for playing with this ! Whatever you think is usable from kH, take it....
These days I'm a bit 'out' of hair-creation-in-visual-programming-system story, my XSI 7.01 is 'conserved' on old machine from 2011. Houdini translation got some attention only by creators of tools, is it better to do it in wrangle or VOP, and so on. Almost zero feedback from final users, so no way to develop the design, further. While actual set is a way more than enough for me.

I have to admit that impossible-to-spell name in English is intentional, idea was to get attention at first, which somehow worked . It's Slavic diminutive suffix at the end, closest translation I think is Little Christine. When we are already about, there are two 'spiritual fathers' , too. Member of old SI-Net, called Hirazi Blue who first asked for compounds. Joe Saltzman proposed a system. So, ideas of streamlining and systematization, are products of community

But there could be a simpler solution too, for example storing the neighbor locations, not any data. Will have a look if that's possible.

I think it is, Melena has 'strand location', but it was tricky to put into cache, it was possible only in certain versions of SI. Should work if caching is avoided.

[FXDude]

If you ask me , that's a good question about the GroomTools, that I don't know the answer to yet ^^ but I will investigate!
I think storing a lot of neighbor data was too memory hungry that's why I didn't do it.
It could be that ICE somehow allows to look up everything at frame 1, or if all else fails a fixed copy could be used for looking up neighbors.
But there could be a simpler solution too, for example storing the neighbor locations, not any data. Will have a look if that's possible.

Lol FxDewd and Cool! And actually, something of the sorts is already used to compute strandvelocity for motionblur, which is something that can be turned ON just before rendering, and will dynamically write strandPositions to then read what it just wrote by by the next frame and compare current strandPositions with those. So indeed I'm curious to try what I think you are saying, like refferring to a cache file written once at the first frame?

Yet for now since it's mostly working, efforts are going go to compounding the styling bit, and then I'll be sure to pick your brains once this first ALPHA (in big bold letters) is out!

Sure you'd be able to somehow get done what you want but not without loads of digging around and trial and error.

Indeed, yet so it seems, regardless of what tools are used, getting fair end to end results seems tricky at best, there are user-friendly tools that can get you up to certain points in a jiffy, and tutorials around covering individual aspects for styling shading or sim, and you see nice hair pics, even some stills of hair in motion, but like when looking for references (usually half CG and and half real) I haven't come across many very (if not almost any) fairly convincing end-results with the aspect of time, other than isolated Houdini clips of hair dropping with heads rotating (witrh pobably pretty complex setups) or million dollar pixar flix.

But with so many intricacies at every level, for simulation, mulitplication or cloning, and finally rendering, getting anything stable across frames with something like tons of hair strands, it's not so surprising.

Which may have been part of the motvation, in SI (and you guys stuff ) an easy to use method seemed quite reachable, not unlike as it actually turned out to be!

closest translation I think is Little Christine.

Little Christine ! I didn't know what Kristika meant but I liked it, but know I like it even more! :]

I think it is, Melena has 'strand location', but it was tricky to put into cache, it was possible only in certain versions of SI. Should work if caching is avoided.

Hum Thanks for the info! Are strandLocation locations in world space?
Right now hairs are cloned using your "Splay" node which together with randomized strand Transforms, are then stuck back to the surface with Melena's "move strand to surface" node, allowing to define distance to clone parent in random directions also with curve profile modulation (of wavy progression) along length, so strands can be gathered up towards the tip of parent clones which are mostly themselves clones with 3-4 levels like that making clumps with wide roots made of mini-clumps.


In any event, I'm anxious (and maybe a bit scared ) to put out something to be tried-out!

[Mathaeus]

Hum Thanks for the info! Are strandLocation locations in world space?
Right now hairs are cloned using your "Splay" node which together with randomized strand Transforms, are then stuck back to the surface with Melena's "move strand to surface" node, allowing to define distance to clone parent in random directions also with curve profile modulation (of wavy progression) along length, so strands can be gathered up towards the tip of parent clones which are mostly themselves clones with 3-4 levels like that making clumps with wide roots made of mini-clumps.


In any event, I'm anxious (and maybe a bit scared ) to put out something to be tried-out!

Well there are reasons why a mix of these systems should *not* work, flawlessly. Let's say if compound relies on custom attribute, if strand array is defined in specific way, so on.
Factory nodes and kH, are considering the point position as first, root position, I think In Melena, root position is first strand, not point position - mix in this case can cause an offset of root position, or in opposite case of overlap of point position and first strand, result is NaN, which can go without visible problems in some renderers, but also can cause all sort of problems in others.
Regarding kH Splay compound, it's for use exclusively in 'fur mode', offset is along emitter surface, relative to emit location (can do overlap with long, curved hairdo), also it expects deformations to be created only by kH deform hair compound.
I think there are only three kH modifiers, *possibly* able to work without kH emitters and 'form' nodes. They are described here, I added them intentionally for use with another systems.
About 'strand location' - let's say you get it by using 'uv to location' to query the curve or nurbs surface. I think it is in world space. While some factory nodes like 'modulate by null' are in object, point cloud space, so, moving entire point cloud can cause mismatch. That's reason for keeping the point cloud on world space zero, all the time.

[FXDude]

Well there are reasons why a mix of these systems should *not* work, flawlessly.

Which is probably why indeed some nodes don't work, so I'll be sure to include a region in the ice tree a bunch of unconnected nodes that do!

I know this duplication method is probably unorthodox, but it's what I found to reliably not change over time and to make the clones look more independent.

Nevertheless, thanks for the pointers! (and for making your great KH system happen ;;) !)

[Hirazi Blue]

@FXDude - if you need an alpha- or beta-tester, I am more than willing to volunteer... ;)

[Mathaeus]

Well there are reasons why a mix of these systems should *not* work, flawlessly.

Which is probably why indeed some nodes don't work, so I'll be sure to include a region in the ice tree a bunch of unconnected nodes that do!

It's possible to create "adapters", where value of missing attribute is just replaced by something static, or, to re-calculate something , let's say ''StrandCount'' of factory or Kh nodes. But, if exact value has to be supplied ( for example, most of kH modifiers are relying on pre - calculated orientation vectors), obviously a plain static value won't be enough. At some point, there should be a design decision, which then creates incompatibilities, something works better something else is worse...
kH generally tries to keep everything in one network, it tries to have as much ''light" hair filler, it also tries to avoid any cumulative, no to so fast calculation - there are negative sides of that, like a bit more complicated structure on guides, it's not so easy (or obvious) to figure out what and how can be animated, orientation vectors are derived from external geometry. Next time I think I'll try something different, but, don't know when this is going to happen. Personally I feel a bit tired of all that visual programming things, to say honestly....

[rray]

I looked a little into groomTools. Almost forgot, thanks for putting it to qegood use.

What might work as a workaround until some location caching is implemented is to use "uv distance" - this distance method should be more stable during animation, even if the surface is deforming. It requires that the emitter has UVs, and that the emitter is plugged into the "hair layer" node.

Two other things I discovered that could cause weird shaky behavior are:

---if you dig into the "hair layer" node, then into "interpolate guides", then at the bottom center you'll find a randomize node that has "animated" checked! this is a bug! it needs to be off! ^^

---The other thing is that the "hair emit" node doesn't like to be animated. It randomizes positions when it's called multiple times and the emitter moves. It should be possible to call it only once by adding a simulation stack and putting the "hair layer" nodes into that.

I would be best if could look at a shaky scrambly test scene and see what's going on. So applying for alpha testing too

[FXDude]

Okay, let me do some minimal housekeeping (previous branch versions etc..) and I'll PM you both the scene as it is!