|
|
Skeleton Animation Question
About Truespace Archives
These pages are a copy of the official truespace forums prior to their removal somewhere around 2011.
They are retained here for archive purposes only.
Skeleton Animation Question // Tech Forum
Post by Electric Jim // Aug 13, 2008, 3:32pm
|
Electric Jim
Total Posts: 98
|
I'm starting to play with animating a character I have rigged, and am seeing something odd with the locks in the feet. Though they remain still as I pose my character, when I scrub through the animation the feet move, even though full locks are active on them. I've verified that I can get the same behavior with at least one of the characters from the Character library, so I figure I'll ask my question in terms of that character.
Try this simple experiment: In an empty scene, add the 'Bobby' and 'Tank girl with handles' characters from the Characters library. In Frame 0, activate the full locks on both sets of feet and record a keyframe. Move to a later frame and grab each character by the chest and pull it forward (so he or she looks like Olympic ski jumpers do, while they lean forward as they fly through the air). Record a keyframe at this frame. Note that at both keyframes, each character's feet stayed appropriately locked in place because of the locks on their feet.
Now scrub back and forth through the animation's range. When I do so, I see that one of Tank Girl's feet slides around during the course of the animation, though both of Bobby's feet stay appropriately "planted in place" as his body leans forward. The sliding foot always end up in the correct location at the keyframes, but it visibly moves in-between.
Normally, when I see things aligning at the keyframes but moving in-between, I'd expect this to be due to to a non-straight-line interpolation type for the FCurves (so overshoot and so forth would be expected). But as far as I can tell when I examine things with the FCurve tab, everything looks nice and linear there. (I've also seen some reference in a recent thread to making sure that any handles that are used don't have "Posing only" selected for them. But I made a point not to use any handles during this test; I dragged directly on bones, instead.) Could someone explain to me why one of Tank Girl's feet is slipping around, and how to stop it from doing so? (Then, I hope, I could apply the same fix to my own figure, whose feet are moving around much more when I scrub through his animation, even though they're nice and solid when I pose him.)
Thanks for any help you can provide. |
Post by 3dfrog // Aug 13, 2008, 5:59pm
|
3dfrog
Total Posts: 1225
|
Try going into ik handle mode by clicking add ik handle icon, then select the handles on the feet and use the slider in the panel to change them to ik. Do it for all the feet handles. Hope that fixes your problem :) |
Post by Electric Jim // Aug 14, 2008, 12:57am
|
Electric Jim
Total Posts: 98
|
Thanks for the suggestion. :) Unfortunately -- or perhaps fortunately -- I've checked both the 'Bobby' and the "Tank girl with handles' characters, and the handles on their feet already have their sliders fully over to 'IK' (as opposed to 'FK').
I say "perhaps fortunately" above because my character doesn't have any handles on the feet at all, just locks, so I knew that couldn't be the issue in my case, anyway. Though it is possible that the problem with my character is a different phenomenon from whatever I'm seeing with Tank Girl, because my character's feet slide a lot more. In fact, on closer inspection I think it looks like the motion of my character's limbs may all be correct relative to the chracter itself, but the character itself has some overall motion associated with it which is making the feet dip below the level of the floor simply because the character as a whole happens to be dipping downward at that moment. (I have my character go from a standing position to a sitting one, so his overall center of gravity is moving downward.)
Maybe this is associated with the fact that my character is primarily a segmented one, in which all the meshes except the feet are attached rigidly to specific bones rather than in a deforming sort of way to the skeleton as a whole. Only the feet are attached to the skeleton as a whole, so they can be deformed by the two different bones I have in the feet -- to get toe movement. So maybe trueSpace is doing something funky/unexpected with the pivot point of the character, or something similar...? Hmmm, more for me to look into... |
Post by Electric Jim // Aug 14, 2008, 3:36pm
|
Electric Jim
Total Posts: 98
|
Attached is a zip file of a simple test scene that demonstrates my problem.
It has a small skeleton -- well, the pelvis and legs of one, anyway -- for which two keyframes were recorded (the first in a "standing" position, and the second in a "sitting" one). If one jumps back and forth between the two keyframes, he can see that at each keyframe the bottom leg bones are in the same position -- as they should be, given that each of them has an activated Full Lock on it.
But if one plays the animation or scrubs through it, he'll see that the figure as a whole sort of "floats" as it shifts from its "standing" configuration to its "sitting" one, so the two "locked" leg bones don't stay in place throughout the animation. These locked bones stay planted in place as they should when I construct any new static pose, but because the whole skeleton moves during the in-between frames whenever the resulting animation is scrubbed or played back, things clearly don't look correct.
I need the figure to look like it's standing in place, on non-moving bottom legs, as it leans back into its sitting position. (Or, in general, does anything while standing in place.) Would someone more knowledgeable than I be able to take a quick look and tell me what I'm doing wrong, i.e., what I need to do to keep the whole body from "floating" during the animation, so the legs look properly anchored to the ground? Thanks.
P.S. In case this matters: You will note that the "body" on which the skeleton acts is just comprised of a bunch of rectangular cubes, with each cube attached rigidly to an individual bone. (There is no mesh attached to the skeleton as a whole, so nothing gets deformed as the skeleton is posed. The cubes just get moved and rotated.) This is a simple approximation of the segmented character in my original "problem" scene. |
Post by W!ZARD // Aug 14, 2008, 11:59pm
|
W!ZARD
Total Posts: 2603
|
I run into this wandering foot problem too. It's a major frustration. I've resort to the old 'non-naked nude' strategy of not actually showing the feet in frame. If you're seen Beowulf you'll know what I mean - when he was naked there was always something obscuring the ...er... more sensitive parts.
This is rapidly becoming my favourite thing for Caligari to fix - provide some way of firmly locking/nailing/sticking feet to the ground so that the foots stillness takes priority over other animation settings. |
Post by Electric Jim // Aug 15, 2008, 2:11am
|
Electric Jim
Total Posts: 98
|
Thanks for the response, Wiz!
I totally agree with your statement that locked bones need to take precedence when the IK solution is being calculated. When limbs that are clearly supposed to be "attached" or "firmly planted" to something external aren't, it's very obvious.
In my particular case, though, I've come to realize it's not just the "standard" problem of sliding feet, though sometimes that's a problem even when just creating a static pose. Rather, my problem is that the figure as a whole is moving -- or perhaps I should say, is not moving -- during the animation, so it ends up not looking as if it's pivoting on the locked bones. This doesn't seem to be the case with the built-in characters -- though, as I mentioned in a post above, I do see at least some "standard" foot slippage with some characters -- so I'm wondering whether it's something specific to the sort of "segmented", "non-deformed" character I've constructed, or what. I'm hoping this is actually just some option I didn't know to select or deselect, so I can move on and just worry about the "standard" type of foot slippage. :) |
Post by W!ZARD // Aug 15, 2008, 2:46am
|
W!ZARD
Total Posts: 2603
|
You welcome El Jim. I was wondering if there was some sort of conflict between the locks on the feet and the master bone (usually the hip) when it comes to key frames.
Bear in mind I have no idea what I'm talking about but it would seem logical to me that key Frame calculations must involve some sort of mathematical reconciliation between the position of the hips (which may well be key framed with Bezier Interpolation) and the foot )whose position may be key frames with linear interpolation). It seems likely to me that at some stage tS must average out or round of values in order to achieve a useful calculation. Perhaps it's this rounding off of values that causes the foot movement?
I just rigged a six legged walking machine and put a simple lock on each of the six feet. I can move the entire machine around beautifully with no foot movement in real time but I've not yet tried Key Framing anything with it. This leads me to suspect it's something to do with the Key Framing rather than the skeletons themselves.
Disclaimer - I really don't know what I'm talking about here but that has never stopped me from coming up with a plausible sounding theory!! |
Post by Igor K Handel // Aug 16, 2008, 5:31am
|
Igor K Handel
Total Posts: 411
|
Continuing the "maybe this is a plausible hypothisis" theme.
Jim I checked out your example file. the first thing that stuck me was that while there are 2 IK full locks on the lower legs, but there is no actual IK.
As I understand it (and also from the full name of the locks) "IK locks" need ik in order to know the chain limits? Not sure this is the answer but I ask myself, how does IK lock know what to lock if there isn't actually a IK chain?
hence the slipping (plausible?)
I have been working under the assumption that in FK (which I assume is how you Keyframed the example) In true non handle FK each joint gets rotated individually until the desired pose is achieved. This doesn't need locks, because only 1 joint at a time is ever rotated. So I ask myself is this why locks full name is "IK Locks"... this to me would be plausible. Carrying on this theory and the way FK works in all other apps I have used, it implies to me that locks shouldn't or needn't work with FK, they just aren't needed. May be completely off the mark, but seems plausible to me.
There is a gray area here as in TS FK can actually be manipulated through an IK handle and fk effects all the joints in the IK chain. This is like no other app I have used and to me TS FK (with handle) is actually IK but with different arc interpolation at time of animation playback. Arcs versus straight line movement. (at animation)
My suspicion for your example is that because you have locks but no IK the locks are actually not doing anything other than misleading into thinking they are green they are locking?
like Wiz this is all conjecture.
Try either true FK one joint at a time no locks involved, or full IK WITH the locks locked.
I begin to wonder if TS approach of using locks as indicator to ik of where one end of an IK chain is, is possibly leading to the many basic problems we are all having, hard to pin down.
All other apps I have used the user first choses a joint for IK handle, then another joint in order to set the chain length from the handle.
In a way TS leaves the length of chain completely open and flexible, because in reality the IK CHAIN only actually becomes a true chain when it has 2 ends. Until a lock is selected currently the IK chain has only got one end.. how can it know where the chain is? There is no such thing as a single ended chain.
As an aside
In addition in other apps there is an ability to move any joint's pivot point to anywhere the user choses. This is a further permutation of a two ended chain with a handle.
Being able to move the pivot point of a joint in an IK chain gives the ability to offset a IK handel from its actual point of connection. It also gives an ability to offset the other end of the chain in order to give the second end a pivot point not actually at its final joint location. A good example of this is setting the heel IK Pivot point to the ball of the foot. This gives an automatic rotation at the ball when the leg is lifted or dropped using the leg IK handle. This is a semi automatic way to get believable ground interaction with the foot. Often this gets snapped to a different joint further along the chain (in a foot setup for example) but this aspect is somewhere further down the evolution of TS rigging. Some other apps even have a constraint that allows the distance of the feet joints to be stopped a user set height above the grid. this gives an instant automatic ability to create believable footroll when the foot interacts with a groundplane or the grid level. Also makes animating feet interaction on stairs a lot cleaner.
Hope at least some of this makes sense
IK |
Post by W!ZARD // Aug 16, 2008, 7:39am
|
W!ZARD
Total Posts: 2603
|
I woke up this morning and there was this fully fledged master plan for creating a good walk cycle in tS just sitting in my brain! Of course it didn't work in reality!:D
But it has given me some ideas and so far they seem (stress on the seem) to be working OK. If I get it sussed and simplified and repeatable I may do a tutorial vid or something... but I need to refine it and test it so don't hold your breath!
I've been pottering around with it all night (in between stopping to watch New Zealand pick up some Olympic Medals in the Rowing, cycling and shot put! Exciting stuff - and I'm not even a sport-head!:D
More info (about walk cycles not Olympic Medals) tomorrow. |
Post by Electric Jim // Aug 16, 2008, 8:30am
|
Electric Jim
Total Posts: 98
|
Hey, IK; thanks for looking into it.
If I understand you correctly, the hypothesis is that the animation in my sample file was created with Forward Kinematics (FK) instead of Inverse Kinematics (IK), so the IK locks do not have quite the effect I was expecting them to have. However, my understanding of trueSpace's methods is that when dealing with bones, there are essentially two ways to animate using FK: (1) Rotate an entire limb using FK by selecting a joint with the 'Dynamic pose' tool and dragging on the rotation arcs of the joint's navigation widget that appears (or entering new numeric rotation values for that joint in the panel stack); or (2) Use an IK handle for which the Interpolation slider (in the panel stack) is not all the way over to the 'IK' setting. In contrast to these methods, I believe that clicking and dragging directly on a bone with the 'Dynamic pose' tool is supposed to work solely in terms of IK.
Now, in my sample file, the animation was performed just by clicking on the top-most bone (i.e., the one at the top of the "wish-bone" branch) with the 'Dynamic pose' tool and dragging down-and-back to make the figure assume a "sitting" position, for the second keyframe. As I understand things, this should define the animation solely with Inverse Kinematics, so the locks should act the way I expected them to act. (There are no handles in the scene, and I didn't use any joints' navigation widgets at all.)
Perhaps my undestanding is incorrect, and clicking-and-dragging directly on bones with the 'Dynamic pose' tool doesn't work purely in terms of IK, as I thought it did...? (If there's a statement to this effect in the manual and I missed it -- just as with that one other thread -- I'll really feel like a doofus...! :) But upon skimming through the manual again, I don't seem to see any statements to this effect.)
By the way: Feel free to delete the single animation clip that's in the sample file and start over, to see whether you get the same results I did. Or to modify the file in any way you see necessary, to get the simple "sitting down without floating" animation I'm looking for. If you get the animation without the "floating effect", then I can focus in on what's different in your case from mine, or what changes you had to make to get it to work. :)
Wiz: I'll certainly look forward to any instructions/tutorials/vids/etc. you generate for producing a walk cycle. (Producing a nice walk cycle probably would have been the next animation task I was going to start fiddling with, after playing with changing between basic poses.) :) |
Post by Electric Jim // Aug 16, 2008, 2:26pm
|
Electric Jim
Total Posts: 98
|
All my "I appear to have found a solution" posts seem to start with "I don't really understand why this works, but...", and I guess this one won't be any different. So, <ahem> here goes: I don't really understand why this works, but I appear to have found a solution.
As stated above, it's my understanding that manipulating bones directly would be considered an IK (as opposed to FK) manipulation. But mulling over Igor's post, and considering the fact that many of the built-in characters have IK handles on their feet, made me want to see what would happen if I merely placed IK handles on the bottom leg bones of my test skeleton (in addition to the full locks that were already there).
For each handle, I started out setting the 'Speed vs Quality' slider all the way to 'QL' and the 'Interpolation' slider all the way to 'IK'. I left all the associated check boxes unselected, except for 'Use global locks'. I didn't actually do anything with the handles -- meaning I didn't click on them or manipulate them in any way -- while creating the animation. As before, I created my two keyframes, with the second ("sitting") one being achieved just by clicking and dragging on the top-most bone with the 'Dynamic pose' tool. Now, I find that the unwanted "floating" effect appears to be gone when I play back the animation or scrub through it. There's just a touch of "standard" foot slippage -- i.e., the locked leg bones don't stay absolutely, 100.00000% still, but they're probably 99.9% still -- but the figure is now essentially pivoting on its locked leg bones as it leans back into the sitting position, as it's supposed to be. (Rather than sort of "floating" around as it sits back.)
If including IK handles on the locked bones is supposed to be necessary to keep the character from "floating" during the in-between frames, I hope this sort of information gets added to the manual (along with a good explanation of why it's necessary, because it's still not clear to me). If not, I hope it gets addressed in the upcoming patch.
In any case, I can now try applying this idea to my original scene, and see how it goes... :)
P.S. If anyone's interested, a zip file of the updated test scene is attached. As always, thanks for your time. |
Post by Igor K Handel // Aug 17, 2008, 1:18am
|
Igor K Handel
Total Posts: 411
|
Jim I notice that in your latest experiment you don't mention that you set the foot locks to on?
If this IS the case (IE you didn't activated the locks, I wonder whether the sheer act of adding an IK handle at the foot (which by default has no other end until a lock is set?) defaults an unspecified IK chain length to IK handle and the final furthest away joint from it(in this case the topmost joint)
Perhaps if this IS correct theory then it might go some way to explan why now you have a behaviour closer to what you (and I and Wiz I guess) expected?
On the other hand if you DID set the feet locks it implies that the complete IK chain was from handle (the bottom of leg) to bottom of leg(where the locks are.. Hmm a zero length IK chain. This would be baffling as to how it would help.
Did you set the locks?
IK
Edit i reread and locks were on so I refer to zero chain length comment earlier in post?
Quick question are locks placed with the bone or the joint selected, I wonder if this has any bearing also? |
Post by Igor K Handel // Aug 17, 2008, 1:52am
|
Igor K Handel
Total Posts: 411
|
Still confusion all round ref Fk and IK. I believe we are all interpretting the TS Fk IK in different ways, I suspect there is some accuracy in all our theorys but also some inaccuraccys in all of them too (myself included)
This is ref the post prior to last Jim made.
For the purpose of pinning down the difference between IK and FK it would be best not to use a mid setting on the IK/FK slider, I reckon for now this adds a further variable, to an already wooly area for all of us. Go for full IK or full FK.
(1) Rotate an entire limb using FK by selecting a joint with the 'Dynamic pose' tool and dragging on the rotation arcs of the joint's navigation widget that appears (or entering new numeric rotation values for that joint in the panel stack); or (2) Use an IK handle for which the Interpolation slider (in the panel stack) is not all the way over to the 'IK' setting. In contrast to these methods, I believe that clicking and dragging directly on a bone with the 'Dynamic pose' tool is supposed to work solely in terms of IK.
My understanding to date is that having slider set full to IK is the same as using dynapose, not specifically picking joints and just dragging bones? The two are interchangable?
My belief is currently that with interpolation slider at fully FK, if I rotate a joint using its widget, only that joint will rotate, but obviously the position (not rotations) of joints lower in the heirarchy, will move. That is how Fk is in all other 3D apps I have used as well so it would make sense.
But when the interpolation slider is set to fully FK and I grab a wrist that has an IK handle what is happening eludes me. I suspect that the FK setting is ignored, and the IK handle is taking preceedance, beats me?
Ref reading the manual. Also been there numerous times. Very surface instructions, but then this should be a straightforward process. In normal circumstances these would be enough, but as no-one appears to be able to predict the outcome of IK setups, either we need more info or there is a gremlin that needs ironed out.
IK |
Post by W!ZARD // Aug 17, 2008, 3:09am
|
W!ZARD
Total Posts: 2603
|
I've not done much with IK but I was under the impression tS let's you use both as required. Use IE to set your general position and then use FK to fine tune the pose for keyframing.
I'm still exploring this area myself though....
I wonder if the amount of flexibility tS offers for character animation can actually confuse things! |
Post by Igor K Handel // Aug 17, 2008, 3:41am
|
Igor K Handel
Total Posts: 411
|
Ok I have done a couple of little tests to eliminate some of the grey areas.
Have established several definites
1.
When adding locks it is not relevant whether the joint or bone is clicked the lock always links itself to the topmost joint of the selected bone at creation time.
2.
Dynapose IS an on the fly full IK tool. To demonstrate to yourself
Make an arm. Add a postion lock to top joint. Add IK handle to wrist and activate top lock to automate with the ik handle. For this experiment I have interpolation set to full IK. Only option checked is Global. Set elbow joint limit to something sensible.
Now ctrl C copy the whole thing to date. Move it over parrallel to origonal.
In Object mode select the first arm. NOW still in object mode (not dynapose) drag IK handle and observe motion. Now click dynapose and try again... Same motion. Ok now move slider all the way to FK. Still in dynapose grab a bone this time and observe.. It's identical to full IK. Ok now delete the IK handle. Use dynapose to drag bones.. in theory we are still in full FK.. Note that what you are actually getting is an on the fly full IK reaction, which appears to move the end of the chain dynamically depending on which bone is selected. As long as the top rotation lock is on whichever bone is selected becomes the temporary IK Handle (and hence the bottom end of the chain). So in dynapose we don't even need to create IK handles at all, as long as there is a lock for other end of chain it's all done on the fly!
Use the copied arm to try altering 1 option at a time compared to the origonal arm. Keep jumping back and forth to confirm the outcome/ different reaction if any.
The only time FK is true FK is when only a joint is selected and the rotation widget used. It is not relevant whether there is an IK handle or whether there is no Ik handle. It is also not relevant the slider setting for FK /IK. The minute we touch a IK handle in any mode... or when in dynapose a handle OR bone OR joint we are instantly in full IK mode.
my conclusions.
Because Dynapose is flexible on the fly full IK the only reason to even add IK handles is for ease of grabbing when bones are inside a model. Perhaps also when a chains need inverted.
The only real effect of sliding the interpolation between fk/ik is the arcs/ straight line movement keyframed in the final animation. The actual posing stays identical where ever the interpolation slider happens to be its not relevant to dragging around.
Phew some progress at last!
Let me know how you get on and what you think
IK |
Post by Electric Jim // Aug 17, 2008, 6:24am
|
Electric Jim
Total Posts: 98
|
Hey, guys.
Wiz: The same thought -- that perhaps we were being given too much flexibility (or at least too little explanation) -- had also (reluctantly) crossed my mind. But, as I explain below, I've concluded instead that the problem with which we're dealing here is really just a bug.
IK: I'm glad to say that it sounds like your conclusions pretty much match what I thought: Dragging on the bones directly utilizes IK, and using a joint's navigation widget to rotate an entire limb utilizes FK. Your observation about IK handles that "The only real effect of sliding the interpolation between fk/ik is the arcs/ straight line movement keyframed in the final animation." makes sense to me, too. (I hadn't really considered the details of that slider before, but just figured that if it was all the way over to IK it shouldn't be imparting any "FK-ness" to the motion. Since I wasn't using handles in my test scene anyway, I knew that couldn't be the crucial issue for me.)
Sadly, this leaves us in the position of not seeing any reason that adding "untouched" IK handles to the bottom leg bones of the test scene should have an impact. But it does.
Even more sadly: Although placing such "untouched" IK handles on the feet or legs -- I tried both -- of my "real" scene's character does indeed appear to eliminate the overall "floating effect", as with my test scene, the residual foot slippage is extremely noticeable when the animation is scrubbed or played back. Moreover, I'm seeing that other bones with locks on them are also incorrectly moving during scrubbing/playback, even though they remain properly fixed in place during posing. (So if you just jump from keyframe to keyframe, you don't have any indication that they'd be moving in-between those keyframes.) This is extremely disappointing, as I think it is essentially a deal-breaker for using skeletons for animation in this version of trueSpace.
One of the big fixes in version 7.6 that made me so happy, and gave me such a strong sense that trueSpace was getting to the point where it really would be usable for character animation, was that the problem of having locked bones moving around during posing appeared to have been fixed -- or at least, drastically improved -- relative to version 7.51. But now I see that although they remain still (or very nearly still) during posing, they still move all over the place during playback. (In a sense, this is worse than having such "slippage" manifest itself during the posing phase, because at least in that situation I could tell that it would be pointless to try animating different poses because we couldn't even get one pose set up stably. Now, one could waste all sorts of time happily keyframing different poses, and then on playback see the sort of in-between movement that makes the animation unusable. This is essentially what happened with me once I (finally) got my character correctly rigged and started playing with animating poses. Hence, this entire thread.)
I'm reluctantly forced to conclude that until this issue is fixed, it would be pointless for me to play with skeletal character animation, anymore. Clearly, people who use skeletons to set up still scenes can still fruitfully do so. But the thing that has really been "rev'ing up the engines" of my little hobbyist's heart has been the idea of finally being able to produce neat little character animations with tS. <Heavy sigh.> :o On the bright side, as a (not very "high-powered") programmer myself, I could easily believe that whatever "slippage"-related fix got implemented by the developers in the "posing" code simply failed to get included in the "scrubbing/playback" code. (Along, perhaps, with the code to correctly keyframe the enabling/disabling of IK locks, which I'm not 100% certain is being done...?) So it may well be very likely that such a fix will be included in the upcoming patch. (Because my bug-related posts don't generally seem to get any responses from the developers, we'll probably just have to take this on faith and think positive thoughts.) :)
In the mean-time: As you concluded for yourself a while ago, IK, it's probably time for me to start delving into the other aspects of tS, as I fervently hope that the upcoming patch fixes this crucial aspect of trueSpace's functionality. (Hmmm, maybe I'll start constructing my own list of important bug fixes and feature implementations -- such as being able to keyframe cloth animation, which was also a big disappointment to me in this version -- so I can post it in the "Feature suggestions" forum...)
See ya on the forums ("fora"...?), guys; take care. :) |
Post by W!ZARD // Aug 17, 2008, 9:12am
|
W!ZARD
Total Posts: 2603
|
Well I've just pulled another all nighter trying to get usable walk cycle. I can get something close but definitely no cigar. I have determined that the IK handles don't really seem to have much of a purpose that makes sense to me as any part of the character acts as a handle for pulling things around.
I can find no way to firmly nail a foot to the ground so that it stays put - which means any animation which shows a foot in contact with the ground looks ... well, sloppy.
It's all very well that I can run my character over with a physical sim vehicle but I just want to be able to get my guys to walk convincingly from one side of the screen to the other.
If there is a methodology we are not aware of we need to be informed and shown how to make this most fundamental animating operation work. If there isn't such a methodology I need to be told now before I waste yet another evenings work.
So come on Caligari - can your software be used to make a character walk? If so how, If not when will this be fixed.
We need to be able to firmly fix those feet and we really need to be able to animate ankle joints or foot bones along a visible spline path.
The Fcurve editor works a treat for simple actions but seems to be useless for effectively working with a skeleton.
I'm one of Caligaris biggest supporters but my time is valuable and I cannot afford to waste night after night of work trying to get a simple walk cycle. That time is money. I need to know if it's possible and if so how.
I'm off to bed now it's 7:10 AM Monday morning and after another 10 hour session and still no progress I am not happy. |
Post by Jack Edwards // Aug 17, 2008, 9:31am
|
Jack Edwards
Total Posts: 4062
|
Have you guys tried using Custom Bezier or linear interpolation between keyframes where the foot is stopped?
What about my feature request idea that locked joints generate linear (or optionally custom bezier) keyframes? |
Post by Stem // Aug 17, 2008, 2:47pm
|
Stem
Total Posts: 199
|
Have you guys tried using Custom Bezier or linear interpolation between keyframes where the foot is stopped?I have not tried custom, but the linear does keep the foot in place (that is on "crazy bob", I have not got around to finishing rigging my own model)
- Stem |
Post by W!ZARD // Aug 17, 2008, 3:41pm
|
W!ZARD
Total Posts: 2603
|
Ok, I've had 6 hours sleep and I can't stop thinking about walk cycles. It takes a baby a long time to learn to walk properly so I'm prepared to give it some time. At this stage I'd really like to know if it's possible!
@ Jack - "Have you guys tried using Custom Bezier or linear interpolation between keyframes where the foot is stopped?". I've tried this but I think there must be some hierarchical arrangement that overrides the linear interpretation on the foot in favour of the position of higher joint/bones. Some technical info from Caligari would help clarify how this works.
@ Stem - "I have not tried custom, but the linear does keep the foot in place (that is on "crazy bob", I have not got around to finishing rigging my own model)" That sounds encouraging Stem. Would you mind telling us a bit about how you achieved this?
Meanwhile, I'm off to Google Walk Cycles and see what, if anything I can learn.
A thought occured to me during thre night that one possible solution (for some circumstances) would be for Caligari/MS to commission a small selection of high quality walk and run cycles for inclusion in the tS Libraries. This would at least give us a base to work from when using BVH compatible skeletons.
The 'Mike Moves' library is all very well but how often does anyone need a 'slip on banana skin' motion? |
Post by Electric Jim // Aug 17, 2008, 4:21pm
|
Electric Jim
Total Posts: 98
|
Jack: Thanks for your interest. For my own scene, I can confirm the same type of situation that Wiz related in response to your question. Here are the details:
As a test I keyframed an IK movement of my character's arm, with a full lock active on the character's shoulder. Because of the full lock, one wouldn't expect any motion to be transmitted down below the shoulder as I create and keyframe the new pose. And, indeed, during posing everything below the shoulder remains still. On scrubbing or playback, though, my character's feet clearly move a bit between the two keyframes, as if he were standing somewhat on his toes. By the time of the second keyframe his feet & legs are back where they started, so if you looked only at the keyframes, you wouldn't see any movement in the legs.
Now, when I look at the FCurves for each part of the left and right leg limbs in my character's skeleton, everything is straight horizontal lines, implying that nothing in the legs should be changing. Yet, as I described above, when I scrub through the animation or play it back, the movement is clearly there. Wizard's description that it seems as if something were over-riding the unchanging linear interpolation implied by the FCurves seems right on the mark.
Also note: What I describe here is a mild case. I've produced examples where the (supposedly fully locked) shoulder itself tilts and moves in-between the keyframes, producing much more significant changes in the over-all pose of the body than the minor "standing on tiptoes" example I describe above. And in that situation, I also couldn't see anything but straight horizontal FCurves for the parts of the skeleton that shouldn't have been moving. |
Post by Jack Edwards // Aug 17, 2008, 5:53pm
|
Jack Edwards
Total Posts: 4062
|
Interesting Electric Jim, unless it's a case of not zooming in far enough to see the motion, that sounds like a serious playback problem. :(
I agree with Wizard, it would be very useful to more everyday motions included. I think that concept could be applied to the entire TS content libraries. Too much of the included content is tutorial based and not much of it is useful for real world projects. The bitmap, material libraries, and object libraries are a clear example of that. Who needs Halloween bitmaps for textures??? Better would be much more generic noise and real world based texture maps.
Regardless of that, the character animation tools need to work correctly. |
Post by Stem // Aug 17, 2008, 6:10pm
|
Stem
Total Posts: 199
|
Hi,
Well I have only been looking at making "crazy bob" walk at the moment.
I just made a simple basic walk cycle, on scrubbing through I did see both feet moving as mentioned (like he was skiing) I went to the fcurve and selected the right leg (limb1) and below is the fcurve:-
I then changed to linear and the feet nailed as they should. I was making a vid to show but TS stopped responding (probably because I was trying to make the file size small using divx, so I lost the scene. |
Post by W!ZARD // Aug 17, 2008, 6:50pm
|
W!ZARD
Total Posts: 2603
|
Interesting Electric Jim, unless it's a case of not zooming in far enough to see the motion, that sounds like a serious playback problem. :(
I agree with Wizard, it would be very useful to more everyday motions included. I think that concept could be applied to the entire TS content libraries. Too much of the included content is tutorial based and not much of it is useful for real world projects. The bitmap, material libraries, and object libraries are a clear example of that. Who needs Halloween bitmaps for textures??? Better would be much more generic noise and real world based texture maps.
Regardless of that, the character animation tools need to work correctly.
Good call Jack :D. Re your last statement; I'm not sure if the animation tools are actually working correctly or if they are just so powerful and flexible it's a matter of knowing how to use them correctly. One things for sure - it's a large area of potential development.
@Stem - sorry you lost your scene. At least it's promising that you were able to get the feet to lock as they should. |
Post by Jack Edwards // Aug 17, 2008, 6:59pm
|
Jack Edwards
Total Posts: 4062
|
BTW Wiz, I agree with the arguments about the TS animation system trying to give the user too many control options without any guidance as to the "simple" way to do things.
When working with a program like Maya it has built in rigging setups for things like elbows and knees that can be quickly added to a skeleton. Maybe if TrueSpace had a default rigging that could be dropped on a joint or group of joints that have a common behavior that could simplify rigging setup?
If we think about it, there are really only a few commonly used joint types and making built in rigs that address these joint types would save a lot of work and frustration. |
Post by W!ZARD // Aug 17, 2008, 7:53pm
|
W!ZARD
Total Posts: 2603
|
BTW Wiz, I agree with the arguments about the TS animation system trying to give the user too many control options without any guidance as to the "simple" way to do things.
When working with a program like Maya it has built in rigging setups for things like elbows and knees that can be quickly added to a skeleton. Maybe if TrueSpace had a default rigging that could be dropped on a joint or group of joints that have a common behavior that could simplify rigging setup?
If we think about it, there are really only a few commonly used joint types and making built in rigs that address these joint types would save a lot of work and frustration.
Yeah but I am anticipating that this will be a short term situation - the limb library is a step in that direction and I suspect that in time this will be a very powerful and useful way of dealing with adding limbs (with preanimated clips too!).
I've been asking for an anatomically correctly proportioned skele with accurate joint limits for ages but we still have only the tutorial objects, Binky, Bob and Tanky.
Anyway I've not yet given up.... |
Post by Jack Edwards // Aug 17, 2008, 8:04pm
|
Jack Edwards
Total Posts: 4062
|
LOL I bet if someone wants to make one Caligari'd be happy to add it. :p |
Post by W!ZARD // Aug 17, 2008, 8:15pm
|
W!ZARD
Total Posts: 2603
|
LOL I bet if someone wants to make one Caligari'd be happy to add it. :p
Chuckle! I'm working on it - I just wish I knew it was possible beforehand!;) |
Post by Stem // Aug 17, 2008, 9:36pm
|
Stem
Total Posts: 199
|
Hi,
I managed to find a little time and remade the walk, it is not very good, but was only intended to show the feet staying in position. |
Post by Jack Edwards // Aug 17, 2008, 9:53pm
|
Jack Edwards
Total Posts: 4062
|
Those feet definitely aren't moving. ;)
The trick to getting a more natural motion should be in the foot roll motion and the hip swaying. |
|
