"Kata"-- It's a wrap! (nudity)

Head to the end for the latest updates :slight_smile:


This character is an athlete to be featured in an short I have in the planning stages. Initially I’m going for a naturalistic look, though the short will have very stylized lighting and environment. I’d like feedback/suggestions on the anatomy and current state of the skin material.


There is an X-mirror modifier currently in effect in the mesh, so there’s a small amount of midline sculpting I’ll be doing after it’s fully applied (some sculpt tools don’t like the midline mesh edge). Currently a Subsurf modifier at level 1 is applied to the rendering.

Next steps: After completing the armature and rigging (now in progress) I’ll be doing another level of sculpting at very high mesh density to add small surface details that will be applied to this model with a tangent space normal map, and at least one UV-mapped texture to add variegations and blemishes, etc. to the skin material. And of course, hair, always a challenge.

One thing I’ll be trying out after my basic rig is done is muscle-flex emulations (the animations will feature some extreme gymnastics). If anything useful comes of my efforts I’ll post them here as well.

C&C always welcome!

That’s looking great, dude! The anatomy is very nicely done. Although, I don’t think that using a very dense mesh is a good idea for an animation. IMHO you should just use this mesh and use bump mapping to show small details.
Anyways, can’t wait to see that girl all rigged up. Keep it up.

Thanks, Spockless. Maybe I wasn’t clear enough – I’ll be doing a high-density sculpt but not using it for animation. I’ll use it to create a tangent space normal map to add the final fine details (that’s much better than a bump map). Animation will be done with this mesh, which is currently about 10K quads for the half-mesh.

Looks great except the ear. It looks too big to me and placed in the wrong spot.

Oh, I see… I didn’t get that in your first post. Interesting technique :smiley:

After completely re-topologizing (is that a word? is now :smiley: ) this mesh for both polycount and animation efficiency, I’m ready to start experimenting with a soft-body wardrobe and some form of hair (not sure about the best way to go with that yet).


Character is fully rigged, though I’ll probably do some face-rig changes before going to final animations, right now there are a few weak spots, although it’s working fairly well.

Comment/critiques are most welcome.

wow, the body looks perfect. The material looks kinda awkward, though. Maybe you should experiment with SSS, but it would increase render times, so I don’t know if its a good idea for an animation. Keep it up

Thanks, Spockless. The material shown is a temp, as is the lighting. It’s great for modeling, as it shows subtle surface nuances very clearly, but is not very sophisticated. It already has some SSs in it, btw.

I’ve spent the past couple days building some lighting schemes using the YafRay renderer, plus designing her hair & costume, prep for the animation, so my next post will look a lot closer to final.

I’m liking it a lot, but to me the lower legs look odd, the calves seem to thin or too low or something, she seems to have very little volume in the muscles that make up her forearm as well. Just my 2 cents. Still looks ace either way.

Good feedback, Freaky Dude, and much appreciated. Always good to have some “new eyes” after working so long on something, helps break the “all-too-familiar” syndrome.

I think you’re right about the arms, and I’ve gone back to my refs to check some of the basic proportions, made a few adjustments. One of the issues I’ve run into while modeling is the effect subsurfing has on the model – always a bit of shrinkage compared to the actual wireframe, the amount of which can depend on the topology – so I’ve had to “fatten” a few areas beyond what looks right in the native mesh to get it to look best in the render. Makes getting the proportions somewhat more difficult.
The calfs I think are OK as is, though I’ve shortened the thigh length by lengthening the torso slightly. This proportional change may help in regards your observation. Also, everything looks a lot more substantial in different lighting, which I’ll be using in my next posted render.

Thanks again!

Been workin’/strugglin’/learnin’ a lot, finding out what YafRay can do for me, getting a lighting scheme designed, and now, my first hair test. I experimented with particle-based hair but it’s too expensive in system overhead and not as controllable as I’d like, so I went to using soft-body physics on a standard mesh, which will be shaded with an alpha-texture, pretty much just as in game models, though likely with a bump applied as well.

Soft Body Hair Test

To keep render times short, this test has no OSA/AA and no subsurf, so it’s a bit raw, but it shows the physics works pretty well. I plan to add at least one and probably two more layers of “strands” to the final.

Thumbnails show the model rendered with more polish, frames 01, 10, and 17.




Very nice, she almost reminds me of Kate Blanchette(spelling?)

A community member requested a how-to on the soft-body hair concept, so here’s some info:

My character will be in fairly extreme motion during the planned animation, and as designed, has “half a head” of longish hair. This presents the problem of getting the hair to move in a somewhat naturalistic manner during the character’s moves.

I’d already played with Blender’s soft-body physics briefly just to get an idea of its capabilities, and after deciding particle-based hair wasn’t going to cut it for me (or is that haircut it for me??? :confused: ), I came up with the idea of using soft-body physics to get the hair to move with the character.

Soft-body physics is probably most often thought of in terms of cloth-type simulations, and my hair approach actually builds on that. Imagine a “wig” made of fairly stiff cloth, with long strips hanging down from top to sides. Now shade it with an alpha-channel material that gives parts of it a wispy look and you have a fairly decent stylized hair effect (see vid link below). That’s the basic concept I’m developing (this is still a WIP, remember).

http://img165.imageshack.us/img165/883/sbwiggeomst3.jpg

The “wig” modeling was pretty straightforward. I duped a patch from the top of the model’s head as a separate object to start with (Fig 1), then modeled “strand clumps” to hang like flat dreadlocks, plus some bangs. Only these portions of the hair would have any substantial movement. I plan to add some more geometry to give the effect more apparent volume after the basic effect is solid.

The wig was made a child of my character rig’s Skull01 bone, since it has to move with the head. The parenting plays a critical part in the soft-body hair system: Using weight painting, you can restrict the freedom of the soft-body mesh to act like a soft body, making it possible to “adhere” the “scalp-ends” of the hair to the head while letting the “strands” move freely. Weight-painting is the “glue” that holds the wig in place. In the pic, red is full weight (1.0) to hold the “cap” portion in place and transitions to dark blue (0.0) along the length of the hair strand strips. It’s OK to use the extremes of weight here – the soft-body settings allow you to tweak the min/max of the weighting without further painting.

http://img165.imageshack.us/img165/8130/sbwigweightshd8.jpg

One critical part of the weight-painting that doesn’t show clearly in the pic: I added a small amount of weight to the verts at the very tips of the hair strands (about 0.1 or less). This gives the tips a small amount of pseudo-inertia that helps keep the motion more naturalistic.

The soft-body settings were largely arrived at by trial and error, and may be useful only for this model setup. Very important parameters to set are those in the Goal section. These values determine how much of the s-b motion is governed by the wig’s attachment to the Skull01 bone (note that this bone is specified in this section), based on the weight painting values. A weight of 1.0 makes the mesh act like a normal mesh, with the Skull01 bone governing all motion. At weight 0.0, the mesh is completely free to act as a soft body. The trick of weight painting is finding the best distribution of weights, and the minimum and maximum needed, to get the strands moving in a close-to-hairlike fashion.

The other s-b settings govern the character of the hair-strand motion and should be seen only as starting points. Expect to do a lot of tweak and test on these values.

http://img165.imageshack.us/img165/883/sbwigvaluesfd4.jpg

The other half of the soft-body equation involves collision, which Blender calls “Deflection”, because you don’t want the hair strands to intersect with the body mesh. Collision really slows the sim but is a critical factor, so cultivate patience while using it. The pic shows the Deflection settings I applied to the body mesh.

One requirement for Deflection to work that I don’t remember seeing in the wiki Manual is that the two meshes must be on the same layer. The soft-body motion will still work, but if the meshes reside on separate layers, the s-b mesh will intersect the body mesh regardless of Deflection settings. Another tip is that while soft-body physics is enabled, Sculpting Mode doesn’t work, so switch it off if you want to use Sculpting to modify the wig mesh.

Setting up the final specs for the s-b sim takes a fair amount of time because the physics calculations slow real-time playback (Timeline) quite dramatically. With experience you can get a feel for the true look of the effect by watching the playback crawl by and knowing how many frames are being used for the sequence, but to truly evalute the motion, a test-render is called for. Since you’re only interested in the motion characteristics, test runs can be made with all other time-consuming settings (subsurf, OSA and the like) turned off or way, way down, to speed up the test renders.

You’ll probably do some modifications to the wig mesh during testing, because successful Deflection is dependent on mesh density in addition to other factors. You can choose to detect collision between edges or faces or both, but using faces changes the effect pretty dramatically and takes more calculation time. This example uses only edges, and to make sure there are no intersections with the body, I had to restructure the wig mesh a few times. When optimizing the wig mesh, keep in mind more vertices means longer s-b math calculation times.

I’m currently working on the appearance of the hair system, which will eventually be a combination of procedural color, painted texture color, alpha and bump mapping. This vid shows the start of this process:

Soft-body hair with alpha applied (full render test)

I’m not sure that this approach to simulating hair in motion will hold up for very long sequences; that has yet to be tested. It also has a very stylized look that may not lend itself to every project. But it seems a workable solution for some situations.

Hope you found this helpful!

Chip

Woah…nice work!

The reason for that is:
This way you can have a much simpler ( low polygon ) mesh to act as a collision object.
It is quite pointless to search all the toe faces for possible collision :slight_smile:
You could copy your body mesh to a not rendered layer and cut off all parts that don’t need to collide. Make your wig member of both, the rendered and the not rendered layer so it will ‘see’ the proxy collision object. That way you should be able to cut down the simulation times remarkably.
BM
p.s. when i say copy, i mean create a duplicate of the rigged mesh … that way it will animate in sync with the original

Excellent tip, bjornmose, thanks, I’ll give that a try. Anything that speeds up the s-b sim is of high value.

EDIT— that does cut down time/frame on the sim, about 30-50% rough guesstimate. I’m adding more polys to the wig mesh (thinner strands, a fringe at the nape of the neck) so this will help relieve some of that burden.

While we are on it. For moving collision targets the solver settings are not optimal.

1To avoid misses on collision the minimal step size MinS should be something like 10 or more, the positions of the ( collision ) objects then are ( at min ) interpolated in MinS sub - positions per frame.

2The O button should be turned on to have the error calculated with velocities.

3(! IMPORTANT !)
And finally the most critical one: raise the Error Limit (wild guess 0.1 should be possible here unless your lady is 10 blender units tall … then i think 0.5 or so) as high as possible, that is as long there are no visible errors ( as said before collision misses should be cured by MinS not by Error Limit ) go up until the system looses stability. If you turn on the monitor button (M) you’ll get a print on the console how the solver is doing. More than say 200 steps (integration loops per frame) should not be needed with what i see here.
BM
EDIT
if you replace the face by rough sketch of it in the proxy that should give the bang … i doubt you need detailed collision with the eye lids

More good info. Are the nitty-gritty s-b setup details like this published in any coherent form? A lot of the Manual info seems to just touch the surface (pardon the vague pun :wink: )

EDIT–
RE: MinS – trying it now, and the calc time per frame has soared immensely. M reports 461s for the first frame-- way too long for animation of any reasonable length. The hair stands are also not moving properly at all, they seem to just disappear inside the collision mesh(???) I can see how more solver steps would result in more accurate collision performance, but this seems to carry with it other problems that vastly outweigh the collision accuracy benefit.

Also, there’s apparently no way to interrupt the MinS calcs short of a forced quit. That’s rather inelegant.

In Blender. the O button’s Tool Tip is “Old Error Calculation” – what’s this to do with including velocity? In my test so far, the s-b mesh’s reaction already seems tied to velocity – the same motion at 10 frames duration (faster) produces more s-b reaction than at 15 frames (slower).

adaptive step size algo in a nutshell:

  1. set sheduled time step to new dtime
  2. try to advance the sheduled time step, being optimistic execute it
  3. check for success
    3.a we 're fine continue, may be we can increase sheduled time again ?? if so, do so!
    3.b we did exceed error limit --> roll back, shorten the sheduled time and try again at 2.
  4. check if we did reach dtime
    4.a nope we need to do some more at 2.
    4.b yup we’re done

So MinS = 10 sets the first sheduled try to 1/10 frame and i simply can’t believe that this causes a 5 minutes thinking break.

Hum the solver makes an error in positions and in velocities which can be estimated.
So O button tells the solver to use both for step 3.b

Sorry but tweaking an ODE solver wont work like randomly choosing numbers.
And as i said before being too greedy with the error limit chokes the solver completely.

e.g. I you will see something 1236 steps/frame solver time 345s on the monitor print
you know the solver is in the above loop running tiny circles because it can’t reach the demanded accuracy.

bjornmose, you’re obviously talking about the s-b process from an informed viewpoint, perhaps you’re even a developer(?), whereas I’m approaching it from a completely empirical viewpoint, i.e., I judge the “correctness” of settings based on the results I get. Theoretically things perhaps should be just as you say. Put in practice, I’m getting results that raise question about the settings you recommend. It doesn’t matter whether you believe what I’ve stated or not (but what reason would I have to falsify a report on the performance?), but that’s the way it is. I can post screen captures of all the data I’ve reported if it would ease your mind about accuracy/verisimilitude.

You’re also posting answers that assume I have an in-depth knowledge of the s-b system.Please try instead to answer as if I know nothing more than what the Manual provides and the Tool Tips report – 'cause that’s the extent of it. As I asked before, is there better documentation?

Regarding “random” choices of values – that’s a rather rude assumption on your part, dude. Just because they don’t agree with what you consider to be optimum values doesn’t mean they are arbitrary. They were chosen on the basis of available documentation (slim) and trial and error (extensive), checking each variable to see what its visible effect might be (keep in mind that a rather cryptic printout to the console would do little good if it can’t be correlated to actual processes). I found settings that while perhaps not perfect, do seem to fulfill the needs of my project. I’m willing to try other settings, but if they don’t benefit my project’s requirements, I can’t see that they should be blindly accepted as the “proper” way to set up the sim.

Regarding solver time and Error Limit – with the EL at .005, the animation moves in Timeline at about 10-15s per frame max (after using your recommendations about layering, which work very well!), no “choking” at all. I can check the M printout, but the observable facts make that redundant imo. What works, works. And given that the only documentation on Error Limit that I’ve found so far is the Blender Tool Tip (which simply states an inverse relationship between accuracy and magnitude of the EL), it seems that choosing a perhaps overly-low value, if it doesn’t dramatically increase sim time, is quite logical. In light of more complete information about this setting, I can more intelligently adjust its value, which I’ve done.

This is not to say that I don’t value your feedback and information. I’ve tried all your suggestions. Some worked very well, some not so well. And I’m willing to continue trying suggestions, but if something doesn’t work as expected, I’ll report it, and please do not doubt that I’ll report it accurately.

EDIT—
Some approximate M report data:
MinS = 0, MaxS = 0
At EL = 0.10 per your suggestion, solver time on average about 2.5s, peak at about 3s, average steps 50-60
At EL = 0.005, solver time on average about 4s, peak at about 4.5s, average steps 80-90

MinS = 10, Max S = 100
No significant difference in the results above. No visible change in collision accuracy, but that would require a test render to confirm.

Adding the O button calc – small increas in time & steps using 0.10 EL

Seems the EL has some effect on the calc time, but not nearly as large as you suggest, and it certainly doesn’t choke it.

I’ve discovered what apparently causes the immense slowdown I experienced earlier, and may have a bearing on the odd behavior of the geometry: You recommended a MinS of 10, but no MaxS. In the absence of information about what function the MinS and MaxS are performing, I initially set them to a small value spread, MinS = 10, MaxS = 15. This causes a huge increase in time/step (from inspection of the progressive M readout). Having learned more about the function of MinS and MaxS, using a wider range (10 and 100) now makes sense, and also keeps the sim from bogging down. Perhaps you assumed I knew that a wide range is required, but that’s an unwarranted assumption given the apparent lack of documentation about the settings.

BTW, at MinS = 10, MaxS = 15, EL =0.10, the solver ran 15 steps in 1000.070493s.