Hair

Hair

A good place to start is John Bigboote's tutorial.

However, now he is moving away from using dams. From Source:

I am moving away from hair dams, unless they are concealed below the surface of the model. I have been using the new FakeAO feature and it does not ignore 100% transparent geometry, so the dams show. HOWEVER, on something like a skull, or scalp, or like in Rob's ball test above... I would CERTAINLY copy/paste the scalp/emitter geometry and scale it down just underneath and weight it the same as the head- remove the emitter from it. This will help the hair from penetrating the head.

I used small individual patches, placed just above the scalp- lots of them in a grid pattern (I'll show pix this week) with transparency set to 100%. I used 10-14 CP's with a Angle limit set between30-60 degrees. I set the Hair System density to about 60%, but correspondingly set the 'Hair Emitter' density higher... to 10-15. I set the mass a little higher than the default 1... try 1.5 ish. I set the drag up higher too... say 30-40%

If you are using grooming to try to get the hair to bend around the face... It will work but you will sacrifice in the dynamics department... another way to accomplish this would be to place a FORCE in the models bones system... parented to the head... and adjust its magnitude to 1000-2000ish. Since you gave the hair a high drag factor, it should be affected by the force.

Baking Hair

Source: Hair is a particle system. When you choose to "bake particles" in the chor, an extra file is created in the project directory with the name of the particle system eg hairmaterial.par, along with an index into the .par file (called .pai). The .par file contains the values for the dynamic hair splines, so that, in theory (and works most of the time), hair will not be recalculated on the fly, and one can then observe the behavior of the hair/particle systems in real-time, as well as, in theory (not so sure about this), save on render time (maybe). Presumably data for sprites are also stored in similar files, with the name spritematerial.par. The name of these files are referenced in the chor, under the name of the group that that has an associated particle/hair system, after baking.

I have found that funny stuff happens if one tries to turn particle systems on/off individually: the .par files, .pai indices can get corrupted - so it is better to rebake, rather than fool with that switch. Also be careful about sharing project directories, as baked files will get created in the last project saved, and for someone like me, who doesn't work with projects, that can make a mess, if the same model is used in multiple chors.

When making changes in the animation, you have to re-bake the scene. It's best to bake at the end 1) to see what corrections you might need based on dynamic hair movement, because you can play the animation in real-time and 2) maybe? to save on render time later perhaps - ie doesn't have to be recalculated.

Note that it is not necessary to bake particles (hair) before rendering - and I find that sometimes it works better, ie more consistent, to NOT bake. If you have problems with hair rendering funny, unbake if you've baked, or try baking if you haven't baked.

Baking of hairs(and particle systems) is highly recommended if you plan to use NetRender... because the processors can solve the hair dynamics differently and give you 'flicker'.

After I baked my hair and reload the scene I find it's got the classic hair-stretched-a-mile-long look that I've seen before. Anyone know how to get that not to happen?

Some things that sometimes work:

I sometimes find that this clears up if I save the chor (after baking) & then restart A:M.

I have in general found that it is best to be on frame 0, before baking, or starting a render. (with hair or anything). It is best to render after restarting A:M in general, always. With my current animation, I am noticing that it is NOT good to bake before rendering. I only experienced the hair stretch problem after baking. But hadn't experienced it before then in this particular chor, if I didn't bake. I am running 32bit, and run only 1 render thread

I also have observed that in previous versions (and maybe the release version), if it didn't clear up by going to frame 0, then sometimes the act of going to frame 1, and then back to frame 0 might clear it up.

EDIT: the other thing that may or may not have anything to do with anything - is to unhide any hidden models in your chor before baking, rendering. That is a workaround, for a current bug, that I reported, that Steffen has fixed for the next release, and he let me know that the workaround was to unhide all models for my particular problem (non-related models getting corrupted after "Bake Dynamic Systems").