www.si-community.com

P.S.: For the storage of the clumping guide position: Shouldn't it be possible to create a new topology with the new ICE modeling nodes with the smoothed out particle positions? At least that could be a way to store this kind of data. As I never touched the modeling compounds I didn't succeed with creating a topology from just the point positions (add vertex). Sounded easy, but I guess I need to figure this stuff out.

Pancho wrote:Wow!

But for an animation? How would I deform my hair mesh with the animated mesh? For proper results I guess there is no way around animating the (low res) mesh and then subdivide it afterwards (increase the sub d levels via the + key). Hull deformation is way too sloppy. How would this be done inside softimage?

GATOR is your friend, for all sort of transferring the 'classic' operators. Also, in Softimage, model > poly.mesh > subdivision, transfers the classic operators too. But I'd choose GATOR, it's not topology. dependant.
In mentioned 'deform hair' sample from kH3, hair is deformed by deformed copy of emitter mesh.
Shouldn't be hard to make some special ICE cage deformer, it only depends to which level you want to keep the fidelity against performance..

Just me, again, I'd try to avoid curves.

O.k. But is there an alternative for storing the "grown" strands? A curve would survive storing of the softimage file, a strand not. Would I cache the "growth simulation" and reload it at a certain frame. Just wonder whether I could apply dynamics on top of this. That's the reason why I thought creating polygons from strands could help, if there is a way to convert them back into strands.

In the end it comes to storing 10-20 positions per strand. Maps would cost a lot of time and aren't easy to change. Loads of baking. Something like a "Save array" (strandpositions) would come in really handy, if it works for the whole mesh.

I'll try to stay away from curves! : )

Pancho wrote:O.k. But is there an alternative for storing the "grown" strands? A curve would survive storing of the softimage file, a strand not. Would I cache the "growth simulation" and reload it at a certain frame. Just wonder whether I could apply dynamics on top of this. That's the reason why I thought creating polygons from strands could help, if there is a way to convert them back into strands.

In the end it comes to storing 10-20 positions per strand. Maps would cost a lot of time and aren't easy to change. Loads of baking. Something like a "Save array" (strandpositions) would come in really handy, if it works for the whole mesh.

Unless guides are procedurally modeled in ICE, and they resides in modeling stack... I'm afraid no, at least no only-with-ICE-nodes. That's drawback of always live operators.
Curve looks like a most logical way.
Here I feel free to boring you with another sample from kH3, called 'in between curves'. It has what is usually called 'tangent space interpolation'. As long as you have a tangent map,
strands interpolates 'around' the curved surface, so you need much smaller count of curves.
Didn't tried this one with fur, anyway....

Regarding strand count, some external renderers for SI, exactly 3delight that I know, are able to render curves instead of visible strand segments - so strand count could be even 4-5 or something, for simple shape.

Oh the powah! That inbetween curves file looks the friendliest so far and since it has fewer curves with bezier handles to shape the base hair pose then I think I'd like to see what I could do with this technique. It seems way better than any other guide creation system I've used.

Mathaeus, what does this cube filter do in that scene? Anyway, I've been reading all these Kristinka threads today. Extremely interesting. I just have to filter out the stuff that I can actually use and animate from the stuff that is well beyond me at the moment. Thanks!

So the idea with the dynamics with these strands is to maybe create box deformers around the head so I can animate the (shorter) locks of hair? I think I'd like to animate a few strand deformers over sticking strips of geometry to the strands some how and using syflex.

So I've been doing my best to understand the anatomy of these hair setups. (I find this very interesting in case you guys haven't noticed. ) I really want to find a way I can hand animate these nurbs deformers but without creating these "over-head" situations you keep warning us about. Dynamics are cool but I don't think I'd have the time or desire to really sit and tweak settings all day hoping the collisions look good after a 10 minute calculation. (I'll save that time for fluid Point cloud sims) ; so for someone like me I think I can make something look good, stylized and interesting by keyframing simple motions for the deformers.

So lets start with this first setup in the attached pict. What you have is:
(My simplified artist view of this.)

-) A Point cloud stuck onto the contour of a nurbs surface mesh.

-) This point cloud draws strands and conforms to the direction of some curves that somehow represent another cloud of points. The point cloud being the points on the curve?

-) These point cloud curves move-to and follow the contour of another group of nurbs surfaces/deformers.

-) Some of these nurbs surfaces are constrained to the two box nulls in the scene and move with it. I guess they are there as a proxy for where the head and body could go.

Does that loosely describe what I'm seeing here?

So my question is, what would be the best way to keyframe these nurbs deformers (not procedurally but by eyeballing them and placing by hand), which in turn would drive the hair strands. I know how I could do it, but I'm not sure which way would be more efficient; since you often talk about how all these operator stacks are "live" and are therefore constantly being computed per frame. . . . So I guess that means that the more keyframes that get applied to the nurbs deformers "guide containers" we suffer from double transforms or something like that? Or does this overhead only happen if we animate the curves before the nurbs surfaces?

Thanks for any hints on this.

JPWestmas wrote: So my question is, what would be the best way to keyframe these nurbs deformers (not procedurally but by eyeballing them and placing by hand), which in turn would drive the hair strands. I know how I could do it, but I'm not sure which way would be more efficient; since you often talk about how all these operator stacks are "live" and are therefore constantly being computed per frame. . . . So I guess that means that the more keyframes that get applied to the nurbs deformers "guide containers" we suffer from double transforms or something like that? Or does this overhead only happen if we animate the curves before the nurbs surfaces?

Thanks for any hints on this.

Hello,

I hope I'll add some setup, tomorrow or so. Not exactly animating the 'form generators', this is tricky because of good number of distance - dependent queries, moving them could cause 'jumping' from one to another.
More like wrapper mesh, which you generate from NURBS or something else. Just need to take look which way gives a nicer performance.

Thank You for playing with this stuff.

Mathaeus wrote:

JPWestmas wrote: So my question is, what would be the best way to keyframe these nurbs deformers (not procedurally but by eyeballing them and placing by hand), which in turn would drive the hair strands. I know how I could do it, but I'm not sure which way would be more efficient; since you often talk about how all these operator stacks are "live" and are therefore constantly being computed per frame. . . . So I guess that means that the more keyframes that get applied to the nurbs deformers "guide containers" we suffer from double transforms or something like that? Or does this overhead only happen if we animate the curves before the nurbs surfaces?

Thanks for any hints on this.

Hello,

I hope I'll add some setup, tomorrow or so. Not exactly animating the 'form generators', this is tricky because of good number of distance - dependent queries, moving them could cause 'jumping' from one to another.
More like wrapper mesh, which you generate from NURBS or something else. Just need to take look which way gives a nicer performance.

Thank You for playing with this stuff.

Yeah that would definitely help if you would do that.

I'll see what I can find. This is indeed a super nice way to setup a complex wig. Thanks again for all this.

JPWestmas wrote: So my question is, what would be the best way to keyframe these nurbs deformers (not procedurally but by eyeballing them and placing by hand), which in turn would drive the hair strands.

Hello

here you go. Deformations are applied in pairs (that's a usual method in ICE). Static and deformed emitter, static and deformed hull. Everything should stay at zero transform, only deformation is "safe". Hull should be mesh, only. Generally you want higher mesh resolution than strand resolution, smooth hull as possible as well. Because it using as much fast, "faceted" method for transfer.

I've added some test animation.

'deform by hull' node goes anywhere after 'form' nodes (nodes which usually have some geometry input). For reasonable performance, it should go before hair filler. For later use, you just export the node in same folder, where kH stuff is.

Hey man, that's excellent! I was thinking about bringing in some characters I animated in messiah. I assume at this point that I could very well constrain the scalp surface of the wig to the verticies of a head that has point cache on it?? In otherwords, what is the method you use to constrain the scalp triangles to the head triangles? Is it using a point constraint? I'll keep looking ^.^.

JPWestmas wrote:I was thinking about bringing in some characters I animated in messiah. I assume at this point that I could very well constrain the scalp surface of the wig to the vertices of a head that has point cache on it?? In otherwords, what is the method you use to constrain the scalp triangles to the head triangles? Is it using a point constraint? I'll keep looking ^.^.

1:If simple, parent-like connection is enough, you could find one polygon on cached mesh, which doesn't deforms itself. Usually the one on top of the head. Create cluster from this polygon, constrain null to cluster (object to cluster constrain). Don't forget to activate both tangent and normal.
Use null as parent, single deformer for envelope, whatever. kH would like a 'single deformer for envelope'.
I've used this successfully in times of XSI 5 or 6 for attaching to point-cached import from Max.

2:Simplest ICE way would be this one. I've used exactly the same method in post above, but on strands,so you can't use kH node on mesh. That's a non-interpolated, 'faceted' method - but it's fast.

3:For nice smoothed interpolation, a bit expensive... there is a XSI Cage op - if you set fallof to very small value, it's not so expensive.

Thanks for the hints, that's all I really need are pushes in the right direction. That polycluster constraint sound great.

I just did a simple test just now,(I know I take forever) where I exported your head, the hull deform surface and the scalp polymesh emitter to messiah. I put some bones in the meshes and exported the mdd files. Then I brought those cache files back into SI and applied them to the model with point oven, it worked perfectly! The hairs appeared to be stable too!

So pretty happy about this so far.

JPWestmas wrote:
I just did a simple test just now,(I know I take forever) where I exported your head, the hull deform surface and the scalp polymesh emitter to messiah.

poor my head btw if you do something with 'emitter' mesh, like freezing exporting and importing back, there is small ICE node that should reside on this mesh, called 'initialize polymesh emitter' or something, you just re-apply it if was lost, for any reason.

cheers

Mathaeus wrote:

JPWestmas wrote:
I just did a simple test just now,(I know I take forever) where I exported your head, the hull deform surface and the scalp polymesh emitter to messiah.

poor my head btw if you do something with 'emitter' mesh, like freezing exporting and importing back, there is small ICE node that should reside on this mesh, called 'initialize polymesh emitter' or something, you just re-apply it if was lost, for any reason.

cheers

hehe, I meant your second head . Luckily, I didn't have to import the mesh to get the animated deformation to work, I only had to import the point cache back onto the original head and it worked just fine because the point order was the same. =)

What are the equivalent of the version 2 vs version 3 nodes of kristinka?

i have and hairstyle that im using for rendering ( not simulation ) and i am trying to have the old setup to work, in my case i was using a kh2 emit hair ( nurbs emitter and point cloud as styling ) but in the new kh3 emit from nurbs i cant find any way to have the previous point cloud to style as there is no guide in name fuction anymore.

Any Help Apreciated.

Thx

Hidalgo

Hi Mathaeus
So I finally got around to posting some tests I did with the simulation models you gave me. I found that with the one point simulation I still got a lot of penetration of the collision object. The strand dynamics one was a lot better (though a quite a bit of a workflow) However even though it is better I still get some penetration issues. It is not to too bad since the toon shading is very forgiving. Let me know if there is anything I can do to help the penetration issues. Also let me know what you think of the test.
BTW I did try to do Maya Nhair It was easy to learn and set up and the collisions are absolutely great even on a light mesh. The problem is in rendering and getting it to match the mesh when rendering a sequence. If I render a frame it matches perfectly but if I render a sequence it is off even if the Nhair is cached. Maya Nhair is still a work in progress and I have people at Autodesk looking into the problems. Will post that when i get the issues resolved.



[b