View Full Version : Bone driven skirts
05-26-2010, 02:14 PM
I'm presently trying out all kinds of things to proceduraly drive the animation of skirts on characters.
At present the best setup Ive got is a series of skirt bones placed around the circumference of the skirt wose rotations are driven by float expressions using the R and L thighs rotations (with some averaging and clamping on these rotations). I then have a child on each of these skirt bones which then track the rotations of their parent and add this to themselves with a multiplier to get a bit of 'kick'. This is not physically accurate but look a lot better than if we just skinned the skirt directly to the thighs.
The main issue I am having is the dreaded clipping - my characters thigh in extreme poses clip through the skirt because my skirt bones are trying to average their rotations so that the shape of the skirt does not get too spiky and I'm at present having some brain fade thinking of a solution!
My question is this; has anyone here ever done anything like this and if so have you used a different approach or have any suggestions for me?
05-27-2010, 07:28 AM
From the top of my head, why donīt you try limiting the rotation via the controller, so the skirt doesnīt crash into the legs. You probably already thought of that, so the only thing I can think of is taking those extreme poses bones rotation values and start creating ...ehm, wotsisname... wire parameters to control your skirt bones via body bones.
This is the only thing i can think of right now except for creating some sort of reactor system for the skirt, which is out of question, as you are probably working on an R* project and I donīt know your game engine.
my last company i made chains of 2 bones down the skirt and added ik chain at each joint, this allows the cloth to be pinned to the ground, but you can pull it around to avoid clipping.But this was hand animated.
As to doing it procedurally i would'nt use constraints, i'd build an actual cloth sim and have bones ride it. Simple particle/rod verlet system with spherical collision would do it - and the math isnt too difficult.
The best approach is to to build volumes (very simple spherical), that you can rig joints not to collide with. How you drive the joints is then up to you. Extending these volumes to capsules would help too, but the math is a little more complicated.
Stopping collision is simple as casting a ray from the sphere to a null, checking if its smaller than the radius of the sphere and if so pushing the bone away from the sphere till it reaches that distance.
length = len( n1.pos - sphere.pos)
if length < sphere.radius do (bone.pos = normalize(n1.pos - sphere.pos) * radius + sphere.pos)
something like this roughly.
05-27-2010, 01:38 PM
A guy I used to work with had a hair rig that could also work for skirts. From what little I remember, copies of the hair geometry were converted to cloth, which then drove the bones for the original meshes.
05-27-2010, 02:38 PM
Thanks for the suggestions guys.
What I'm trying to do is drive the animation at runtime so that means no hair stuff and at this point no physics stuff if we can (we do however have quite a sophisticated system of taking max expressions and running those at runtime).
The point being we want to get a set of female animations to drive skirts for females with them without having to use the extra memory footprint handkeyed bones for the skirts would take.
I think I'm going to have to go down the route of putting a big load of conditionals in for the special cases I'm having - this looks great during walks and runs but in poses where the knees are far apart and thighs high (such as in a crouch behind cover) im getting a lot of leg crashing through.
06-01-2010, 01:44 PM
If the clipping is only problematic in a small number of animations, you may be able to get away with blending to a hand-keyed solution on those animations only. I.e. use a procedural system for 90% of the time and then put some metadata on the animations to flag those bones as hand-keyed.
Out of curiosity, is it due to memory constraints that you're trying to keep the amount of keyed data low? I would think performance-wise, it'd be more optimal to transform the bones via keyframe data rather than real-time calculations, at the expense of more data loaded into memory.
06-01-2010, 01:50 PM
It's more about disk size. We've already been at the point where a few megs has made a difference. Plus we dont know if / when these skirt bones will be used so carrying that anim info 'just in case' is not ideal. :(
06-01-2010, 01:50 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
vBulletin v3.0.5, Copyright ©2000-2013, Jelsoft Enterprises Ltd.