|
|
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 Stem // Aug 17, 2008, 9:58pm
|
Stem
Total Posts: 199
|
The trick to getting a more natural motion should be in the foot roll motion and the hip swaying.Oh yes,.. I just made that to show the feet staying in place.
I have a night off tonight, so I will try and get "Crazy bob" walking correctly.
- Stem |
Post by Igor K Handel // Aug 18, 2008, 2:50am
|
Igor K Handel
Total Posts: 411
|
Hi guys am back for more :D. What is it about the closeness of getting this to work that is so addictive, it's like even away from pc at odd times suddenly a thought comes, hey what if just tried this, maybe that's the problem. Obsessive behaviour problem looming lol?
Am intrigued to know what it is that Stem has done that is different to everyone else? Any chance of having another go at a vid Stem?
Agree with Wiz on the Fcurve editor, great for general anim but for character skele stuff it's well cumbersome at best.
I'm coming at the pre-made skele and walk cycle things with a different wish. For me rather than have it all done for me I would much prefer the ability to make my own custom skeletons, and create my own anims with it from scratch.
Sure I might re-use some saved rigs/limbs, but longterm I reckon that creating, (and maybe saving limbs etc) a skeleton from scratch gives me much more flexibile options down the line. Getting a workable system that can make this a sensible workflow is the priority for me. Working with Poserish type premade stuff for me holds little appeal, and certainly won't help to improve my rigging skills. I can completely see where you are coming from, I just have different aspirations. both options would obviously be ideal!
Incidently I was looking online for a free horse skeleton Mesh. In total after hours searching I found 1 for approx $20+ and all the others were $200-$500+++. Easier to find Red Rum:D Hmm definite opportunity there for someone to make some $$
Ref types of joint. There are only 3.. single axis, 2 axis and 3 axis. (+ fully locked for other reasons) To be fair Ts has all 3 options.
I agree that IF pre-made motions is your thing, Banana skin slippage is not exactly up there on the list of useful movements lol
Having said all of that. If the system and our education can be got to the point that we can comfortably (and repeatedly) make our own predictable rigs, and our own anim cycles, it opens up a whole load of opportunities for libraries to be built and shared by us the TS users ourselves. (which I would like). Caligari wouldn't need to provide any, there would be loads available through us.
Once this all gets ironed out I predict a large and ever expanding library of user made anim clips and rigs. In turn I would like to think that would encourage more users to get involved in this aspect of TS. Just gotta get these startup teething problems ironed out.
This sucker aint beating me ... Grrh ...this WILL get tamed
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.
This I believe is the single most time consuming part for all of us. None of us can pin down if it's something we are doing or if it's a software issue. Somehow resolving the answer to this aspect will move things on a very big step.
IK |
Post by W!ZARD // Aug 18, 2008, 4:43am
|
W!ZARD
Total Posts: 2603
|
Glad your still with us Igor. Yeah there is something compelling about it - the whole walk cycle issue is seriously tweaking my problem solving urges! I've had another extremely long day at it today and I'm definitely making progress - the only problem is that about half of it is backwards!:D
Correct me if I'm wrong but in a standard BVH compatible skele there are 20 joints each with 3 rotation values and 3 location Values times 24 frames - that's 4320 parameters to set or - putting it another way 4320 potential places to go wrong!!
I've found several methods which have helped immensely although it's scarily easy to get messed up. First tip is to set up all the parameters for the first frame and then copy those keyframes onto the last frame (I'm using a 24 frame cycle). return to the first frame and copy the skeleton and select the mirror tool to reverse it. Go to the 12th frame and use your reversed skele as a template to set up the next Keyframes It's a little more involved than than and very easy to screw up but does give you a good visual reference for creating symmetrical(ish) poses to key frame.
I've also figured out how to access the 'Invisible' check box in the Object renderr attributes and export it up to the top level (scene level) of the LE. Once that's done I can hide my reference skeles of show them with a single click - brilliant!
I'm using mostly FK for this part and I've lost count of the number of times I've had to start over but I figure by the time I'm finished I'll have a good grasp on character animation!!
So my weekly beer allowance has been thrashed over the last few days but I fell I'm getting there slowly.
I agree completely with everything you said in your last post Igor - once we get a few working walk cycles completed we'll be up and running....;) |
Post by Electric Jim // Aug 18, 2008, 7:11am
|
Electric Jim
Total Posts: 98
|
Thanks for continuing to look into this issue, guys. In case they're of some use, here are some pics meant to help clarify what I see as the problems. I created a simple, two-keyframe animation. In the second keyframe, beside moving the left arm (which isn't really of interest, here), I made the figure lean back into a seated position by dragging on the IK handle at the base of the spine.
Note that in the two keyframes (Frames 0 and 30), the lower leg segments have essentially identical angles: Straight up (vertical). This reflects the fact that when I set the second pose from the first, the lower legs stayed (almost) perfectly still, thanks to the presence of the locks. (And, though we don't know why, the handles I had to place on the feet, as explained in previous posts in this thread.)
But during playback, in Frame 15, between the two keyframes, the lower legs are clearly at an angle -- and the ankles, to compensate, must also be at an angle. (Although the feet have not stayed absolutely, perfectly still as I wanted them to, they have stayed "mostly" still, so the ankles must be at an angle, to compensate for the rotation of the lower leg.)
In addition to having the lower legs undesirably move despite the full locks that are on them, I believe this behavior doesn't jibe with the FCurves for the legs. In the overall left leg graph, the two FCurves that are obviously angled are for the hip and the knee. This makes sense, because those two joints certainly had to rotate to achieve the pictured position. But the ankle FCurves -- on which I've zoomed in, in the remaining pic -- are still completely horizontal, indicating no movement. This is what I wanted to happen when I created the animation -- i.e., the knee and hip rotations exactly cancelling each other so the lower leg (and ankle) did not move at all -- but it's not what is depicted in the pic for Frame 15. If this is inconsistent, as I think it is, then this is a problem. (On the other hand, if I'm simply misunderstanding something, can someone clarify for me why I should be expecting the locked lower legs to move, and how the ankles are moving though their FCurves are horizontal and flat?) (By the way: Just to be sure, I did select all the keyframes for both leg limbs in the FCurve tab, and apply Linear interpolation, before making these screengrabs.)
Now, from "eyeballing" the FCurves for the overall leg limb, it looks like the slopes for the hip and knee joints are exactly the opposite of each other (as they would need to be, to keep the lower leg still). But is it possible that rounding error (or some similar mathematical imprecision) is causing them to not be precisely matched (but to a sufficiently slight degree that it's not obvious to the eye), so the "left over", uncompensated, rotation ends up being transmitted down to the lower leg?
As always, any explanation/clarification is appreciated. |
Post by Igor K Handel // Aug 18, 2008, 7:51am
|
Igor K Handel
Total Posts: 411
|
You are correct about the number of Keys being set Wiz. It's actually a potential problem that is looming for us somewhere down the line. Other apps I have used very simply allow for selection of a specific joint to be recorded, even going down to only rotations, or only translation on a specific axis etc. By default TS in it's most straightforward keyframing mode auto keyframes absolutlely everything on every joint, every keyframe. This creates a truly massive amount of un needed keyframes, all mostly straight lines as no actual movement happened on many many joints. I know we can keyframe individual joints using anim tracks, but its not a great approach when it comes to a character with so many joints and associated tracks/channels. it would be infintely preferable if TS only keyframed channels that have had changes, and nothing else. Easier to edit, easier to see, and less memory intensive, plus less cleaning up prior to render.
Somewhere down the line when this all gets to the point of animating properly all these zillions of keyframes are going to be wasting so much mem resources that everything will bog down horrendously if not crash TS. As it is at the minute the visuals of a curve are swamped by siily numbers of straight lines in the fcurve editor, seeing which channel has a curve in order to pick the channel is tedious at best. I can only assume that this will be addressed in the future. Character/ skeletal anim is really pushing the current anim capabilities way beyond what the fcurve editor is currently set up to cope with, from an ease of use perspective. Again I can only assume this will be addressed in the future, assuming the character anim potential of TS is to be further strengthened.
I actually thought of your mirror/ ghosting option awhile back. I was thinking along the lines of pasting two hand drawn poses of the extremes onto plane objects as references. You are more tenacious than me, as I ruled this out as a practical way for basic anim in everyday use.
For me it is such a broad workaround that its not practical for everyday use.
When I was a kid my father made old fashioned acetate sheet cell animations for the BBC. Our house was full of literally thousands and thousands of em. (the show was I believe called "The grumbleweeds, could be mistaken it was 40+ years ago) The ghosting approach is actually going back to that system. Make 2 cells of extreme positions, then sort out the inbetweens, re-use over and over, while translating the background cells to give the illusion of moving forward in the world. Ok now the inbetweens are automated(tweening) Ik etc, but this should not be the way to get a result, in 3D anim on a pc in 2008 lol. It's just too labour intensive. This method is still used quite a bit in 2D anim apps (Toon Boom springs to mind) Copying and pasting keyframes is to be expected, but having to faff about with ghost skeletons as references is for me not "cricket" lol. As you say it's fraught with potential for errors as well.
I admire your tenacity and no doubt you will get a walk cycle out of it, but as to it's longterm practical usability..hmm
The expression "preaching to the converted" springs to mind :D
Your lucky your beer allowance lasted this long, mine was blown out of the water about when I got to TS IK handles and locks. Four weeks ago maybe? That was before I even started looking at the fcurve editor lol
As the Midwife says
Keep on pushing.... another deep breath
IK |
Post by Igor K Handel // Aug 18, 2008, 8:31am
|
Igor K Handel
Total Posts: 411
|
Jim
I almost knew what you were going to say as soon as I glanced at a pic of an inbetween frame that hadn't been keyframed..
My expectation of your example is that at frame 15 on the ankle rotation it should not be showing a flat Fcurve. The ankle rotation gradually increases as the IK drives both the knee and ankle rotations so the fcurves should be showing straight line increasing values for both, no flat lines. Frame 15 as the midpoint should be showing a point halfway up a smoothly increasing fcurve for both the ankle rotation and the knee rotation.
I wonder is there some background jiggery pokery going on in the calculation of any joint that has the actual IK handle associated with it? The other day I noticed an oddity with the numeric readout of the joint to which an IK Handle was attached.
As long as I have understood you correctly you're definitely not wrong, theres just something funky going on in the software.
Our posts obviously crossed, all of us scratching our heads in bewilderment on different sides of the globe. World beer sales hitting record highs.
Ik
Ps I like your example man, very colourful. My testing sessions tend to be somewhat more minimalistic (read lazy) I'd never get a job in a crash dummy environment, as I'd just slap a load of skeletons in the test cars :D
IK |
Post by Igor K Handel // Aug 18, 2008, 10:41am
|
Igor K Handel
Total Posts: 411
|
Oh dear I have found another gremlin.
Make a biped rig, full lock at top of back, in my case out of interest rotation locks on upper arms. Make the hands so they can rotate around their own axis(twist).
Now slap 1 IK handle on the waist. we are not going to use it but set to fK.
into dynapose and manually set top back full lock on. If you like set the upper arm lock on one arm. Now grab opposite hand bone (IE on the fly IK) and keep wiggling around the hand bone axis(twist). Note the opposite arm.. It sometimes slowly rises up ignoring full top of spine lock, AND its upper arm lock!!yay levitation.
Everything is bleeding through 2 locks.
Ok now delete the waist IK Handle that hasn't even been used.
Do the same experiment you did before.. the bleed through has completely vanished, rock solid!!??????????????????????????????????????????
Will copy n paste this over to bugs
IK (sigh) |
Post by Electric Jim // Aug 18, 2008, 11:15am
|
Electric Jim
Total Posts: 98
|
IK: Yeah, I think the idea of locks (as opposed to having to specify an explicit IK chain length from the terminating bones, as in various other programs such as Blender) may end up being one of the great strengths of trueSpace's vision of bones. When combined with the idea of handles that can be associated with specific locks, it packs a lot of power and flexibility into a relatively straight-forward idea.
But until the rest of the bugs get ironed out of the implementation, my guess is that most of the problems we have with skeletal animation will be related, one way or another, to locks.
About my example guy: Thanks. :) Believe it or not, he's actually what I'm hoping to be able to animate, once all the bugs are sufficiently addressed. I call him "Dinky Little". He's actually just my version of what ya got when ya went through one of the simple exercises in an old book by George Maestri. ("3D Character Animation", I think it's called. I'd have to check. It was written back when tS4 or so was around, and it had the neat characteristic of trying to offer examples and guidelines across a wide range of 3D applications, including trueSpace.) Ever since then, I've kept the idea of eventually animating him as a sort of 3D cartoony stick figure in the back of my mind. I'm still hopeful things will get straightened out before long (with the next patch, if we're lucky), and at long last Dinky Little shall LIVE!!! Mwahahahaha...! <cough, sputter, drink a glass of water>...Uh, sorry. :) |
Post by Stem // Aug 18, 2008, 12:12pm
|
Stem
Total Posts: 199
|
In case they're of some use, here are some pics meant to help clarify what I see as the problems. .
Hi,
I was seeing this problem after creating a simple rig,.. and as "Crazy bob" does not show this problem I have been looking closely at how that rig is built.
So from that, I have now build a simple rig (just body/legs) but the IK/locks work as would be expected and the feet stay in position when it sits. There was no need for me to use linear
As the info for this is within the "Crazy bob" rig I will now see (now I have a little understanding of what TS is expecting in this release) if I can make the setup easier for this sitting, but also what to see if I can now rig for a walk without a need to convert to linear.
- Stem |
Post by Stem // Aug 18, 2008, 2:19pm
|
Stem
Total Posts: 199
|
Hello again,
Well, I have not yet found an easier way to rig the legs so that it can be sat down without the feet moving (well not with 2 keyframes).
So I will post the info of the rig (which is basically the rigging for "Crazy bob" (now I know why he has the name lol))
I have attached a pic of the setup/info and also attached a scene file with the anim (to save trying to explain), it is only the lower part of a rig, so dont expect anything fancy (just info).
This by the way, is what I call "over complicated"
- Stem |
Post by Electric Jim // Aug 18, 2008, 4:43pm
|
Electric Jim
Total Posts: 98
|
Thanks for the input, Stem. I'll try playing with your setup when I get the time. (And if we're lucky, maybe the up-coming tS patch will let us accomplish our goal with a less complicated configuration...!) :) |
Post by Jack Edwards // Aug 18, 2008, 4:48pm
|
Jack Edwards
Total Posts: 4062
|
Something to keep in mind is that 2 keyframes doesn't tell TS which way to rotate to get to the 2nd keyframe. 3 keyframes are a minimum.
Also of important note is the FK vs IK setting for the handles. I can't find the post now, but Tomasb stated that it was important to set it to FK for correct IK in certain situations. Argh can't remember now... but maybe 3DFrog remembers what Tomasb was talking about. You'll notice in the videos for the manual that TomG has that value set to FK when he creates the handles.
Also if you watch the videos for the manual it's interesting to note that the locks can be set to be on or off automatically when using the handle, as well as that the locks appear to be setup to work as brackets, the first active rotation lock encountered begins the lock while the second rotation lock active ends the locked area -- that is only the area between the two active locks is actually locked. |
Post by Stem // Aug 19, 2008, 3:10am
|
Stem
Total Posts: 199
|
HI Jack,
Something to keep in mind is that 2 keyframes doesn't tell TS which way to rotate to get to the 2nd keyframe. 3 keyframes are a minimum. But on a model with joint limits that allow only one direct from 1st key_frame to the 2nd why should it be a problem?
Also of important note is the FK vs IK setting for the handles. I can't find the post now, but Tomasb stated that it was important to set it to FK for correct IK in certain situations. Argh can't remember now... but maybe 3DFrog remembers what Tomasb was talking about. You'll notice in the videos for the manual that TomG has that value set to FK when he creates the handles.I did try various combinations (as I think other have), but I decided to follow the setup as show from "Crazy bob and bob" models from the TS library. If those model are incorrectly setup then I would ask who has built them and why are they in the TS library as examples.
Also if you watch the videos for the manual it's interesting to note that the locks can be set to be on or off automatically when using the handle,That is how I have set the small rig I posted, as example, the Handle on the waist is directly connected to knee rotation lock and the foot full lock. It can easily be checked by going into "add/modify handle" select the waist handle and the knee and foot locks turn green.
as well as that the locks appear to be setup to work as brackets, the first active rotation lock encountered begins the lock while the second rotation lock active ends the locked area -- that is only the area between the two active locks is actually locked.I have not yet looked at all possibilities from the chains, but it is interesting.
At the moment there are too many problems and questions in this area. As with the example I have posted, which is based on Crazy bob, it will allow certain movement and the feet will remain fixed/locked, which is what is expected. But attempting a walk cycle will give problems unless the movement is set to linear, and after more checking do find (as previously posted by others) that in fact there is a need to set the entire rig as linear or again the locks on the feet do not correctly work, if there is in fact a need to set the entire rig to linear, then I would consider that a problem.
For me, I would not have a big problem if rigs do need to be set up in such a complex way, I just need them to only need one setup, so then I can sit the rig, walk cycle the rig and/or whatever without having to go back and start making changes due to the locks not keeping in place in-between key_frames.
- Stem |
Post by Stem // Aug 19, 2008, 3:17am
|
Stem
Total Posts: 199
|
And if we're lucky, maybe the up-coming tS patch will let us accomplish our goal with a less complicated configuration...!) :)I think it is more of just being able to accomplish a simple goal with a rig. If there is a need for a seemingly complex setup then once the setup is known and shown, then it is not really a setup problem. It is more at the moment that there are no direct answers being provided,.. maybe no one at caligari knows or maybe it is a bug they do not want to admit. Whatever it is, better info and/or correct working of IK/FX and locks is needed.
- Stem |
Post by Igor K Handel // Aug 19, 2008, 3:30am
|
Igor K Handel
Total Posts: 411
|
Must admit I wonder why more than 2 keys are needed.
Always worked on the assumption that like other apps, if first keyframe is set then interpolation to the second will be shortest distance travelled from the first.
ik/fk choice in the handle in TS as I understand it purely dictates whether the keyframed playback is in arcs or straight lines.
I guess if we do need 3 keyframes, I better ask why as it's a new one to me?
Cheers
Ik |
Post by W!ZARD // Aug 19, 2008, 5:33am
|
W!ZARD
Total Posts: 2603
|
Must admit I wonder why more than 2 keys are needed.
I guess if we do need 3 keyframes, I better ask why as it's a new one to me?
Cheers
Ik
Key Frames are like beers - You can never have too many!;) |
Post by Jack Edwards // Aug 19, 2008, 5:39am
|
Jack Edwards
Total Posts: 4062
|
Custom Bezier should be an ok alternative to linear for interpolating between fixed position/rotation keyframes, but where you want to non-linear motion coming into or out of the fixed position.
If you're getting correct results with 2 key frames then no-problem I guess. I think for somethings TS uses Euler rotations and they can be ambiguous at times. So it's always helpful to not make TS guess the shorter distance... since it may not be the one intended. |
Post by Electric Jim // Aug 19, 2008, 6:05am
|
Electric Jim
Total Posts: 98
|
I think it is more of just being able to accomplish a simple goal with a rig. If there is a need for a seemingly complex setup then once the setup is known and shown, then it is not really a setup problem.
For me, the important point in the long term is that the rigs act as they are supposed to act, i.e., in a manner that is consistent with the stated definition of their behavior. Then, any rigs I construct based on this understanding -- including ones that may be for characters with a body structure very different from those of the built-in characters (such as "Crazy Bob") -- should work in a predictable manner.
For example, my understanding is that a full lock (assuming it's enabled) is defined as something which prevents the bone to which it's attached (and any bones on the far" side of the lock) from moving or rotating when one or more bones on the "near" side of the lock are manipulated, either through the use of the 'Dynamic pose' tool or the use of an IK handle. (As far as I know, there is no additional "nuance" to this behavior which is "supposed" to have to be taken into account.) My choice of where to place full locks, which handles (if any) to associate them with, when to enable/disable them, etc. is based on this understanding. If a full lock doesn't act consistently with this description, then either the implementation needs to be corrected ("bug fixed") so it does, or the description given for it needs to be changed/corrected/clarified so we can then change the way we construct skeletons so as to still get the final behavior that we want (assuming that it's still possible to do so, given the re-defined behavior). -- Or I need to be relieved of my misunderstandings regarding how it's "supposed" to work. :)
My full hope and expectation, of course, is that Caligari will (eventually...! :) ) get things to work in a way that is consist with the descriptions given for the operation and interaction of bones, locks, and handles. Until then, I view the use of rigs that are more complicated than we believe they should have to be as temporary work-arounds. While such work-arounds are certainly appreciated, I definitely hope that we eventually will be able to replace their use with simpler rigs that work they way they are "supposed" to, according to the definitions provided by Caligari. If not, then constructing useful rigs will always be an inefficient, experimental, hit-or-miss process that, I'm guessing, is not the intention of Caligari. :) |
Post by Stem // Aug 19, 2008, 6:38am
|
Stem
Total Posts: 199
|
I agree with what you put forward, it is what I have mentioned, but:-
I view the use of rigs that are more complicated than we believe they should have to be as temporary work-arounds. While such work-arounds are certainly appreciated, I definitely hope that we eventually will be able to replace their use with simpler rigs that work they way they are "supposed" to, according to the definitions provided by Caligari. The small rig I posted is not a "workaround", it is based on "crazy bob" rig. So for me that shows a need to set rigs in that way, it is unfortunate(and possibly a bug) that such rigging is no good for walk cycles unless the full rig is set as linear.
We will see what the patch brings. |
Post by W!ZARD // Aug 19, 2008, 7:25am
|
W!ZARD
Total Posts: 2603
|
Well I've managed to make a walk cycle of sorts with negligible foot slippage. It was time consuming and painstaking - and it doesn't look at all natural - but the feet work pretty well.
A big part of the equation was understanding exactly what happens in a walk cycle then figuring out how to sequentially pose and keyframe everything. Now I've done one I've learned that it IS possible! Yay!
I found that it's similar to modeling in that you first block out the major movements and then continually refine and adjust until you get a usable result.
I think that I should now be able to make another one much faster, having developed some tools and resources to assist and having taught myself some shortcuts.
I'm off to bed now but I'll be posting an account of my adventures with learning to walk sometime in the next few days. |
Post by Stem // Aug 27, 2008, 3:53am
|
Stem
Total Posts: 199
|
The trick to getting a more natural motion should be in the foot roll motion and the hip swaying.Hi Jack,
I have been looking at this again, I have made some slight changes to bobs feet bones and limits, then attempted to make a walk, the results as shown (up to now)
I should of changed the weight of the bone influence on the skin, but just trying to try and get bob walking better. One of the main problems is having to use linear to keep bobs feet still during the keyframes as I wanted to keep keyframes to a minimal (150 frames with 11 keyframes)
I think I will now wait to see what the patch brings to help with character anims
- Stem |
Post by Jack Edwards // Aug 27, 2008, 4:49am
|
Jack Edwards
Total Posts: 4062
|
Hi Stem you may want to use a custom bezier instead of linear. That way you can ease into things that should be smoother but still set the curve to be flat between the keyframes that are motionless. A sharper change can add bounce or weight to the step though.
Another tip would be that the body needs to rise when the leg is straight up and dip at the stride's widest point. Also the hip should rotate side to side with each leg step. For example when stepping forward with the right leg the right side of the hip would come forward as well, being the most forward at full stride as the right leg would be the most forward and the left leg the most backward. |
Post by Stem // Aug 27, 2008, 4:59am
|
Stem
Total Posts: 199
|
HI Jack,
Hi Stem you may want to use a custom bezier instead of linear. That way you can ease into things that should be smoother but still set the curve to be flat between the keyframes that are motionless. A sharper change can add bounce or weight to the step though.I have been avoiding the custom, but will need to look more at that.
Another tip would be that the body needs to rise when the leg is straight up and dip at the stride's widest point. Also the hip should rotate side to side with each leg step. For example when stepping forward with the right leg the right side of the hip would come forward as well, being the most forward at full stride as the right leg would be the most forward and the left leg the most backward.The current rigging/limits do cause some problem with tearing skin, I did make some adjustments but need more to help with that movement.
I will have another attempt when time to see what I can do.
- Stem |
Post by Jack Edwards // Aug 27, 2008, 7:31am
|
Jack Edwards
Total Posts: 4062
|
BTW, Stem, you are very close and the animation is already looking pretty good. ;) |
Post by Stem // Aug 28, 2008, 4:01am
|
Stem
Total Posts: 199
|
Hi Stem you may want to use a custom bezier instead of linear.
Hi Jack,
I have taken some time to look at the custom bezier in the FCurve, this will not work for a character rig (like bob) unless you end up changing all of the rig, which is simpler just to make all the rig linear, which then as the problems of bad movement (as shown in my last example).
So not to be "moaned and groaned" at, saying I am just "moaning and groaning" let me explain what I am currently seeing, and see if I can explain it in an understandable way.
OK, to basics, so I have some ref to fall back to.
When animating a simple cube, lets say in just an X direction, and we first keyfame the cube at 0,0,0, then we move the keyframe (in the dopesheet) to say keyframe 15, then make another keyframe (the cube is still at 0,0,0), now, we move the frame to say 30, move the cube to say 10 in X then make another keyframe. OK, now when we scrub through that simple anim we will see the cube move backwards between 0-15 due to the bezier. Now going into the FCurve we can select the matrix and look at the "tx" the problem is easy to see, as the tx/ty/tz are showing relative movement from its last position, so it is quite easy to simply set a custom bezier at the second frame and set it to 0 to stop the unwanted movement.
Now on to a rig such as BOB.
Please correct if my finding are incorrect, but if they are then please advise with correct info (TIA)
The position of the joints are controlled by:-
tx/ty/tz which is a relative distance from that joint to its parent joint. If those values change then it is the length of the bone between those 2 joints than will change. Certainly unwanted in a rig like bob, so they need to remain constant.
rx/ry/rz these control the rotation of the joint
sx/sy/sz. These are a little confusing in a rig, they do control the size of the joint, but that also as a knock on effect of changing the length of the bone between it and its child, also rotation is affected. So those I expect to remain constant in a rig like bob.
So from that, there is only the rotation of the joints that can be edited so as not to pull poor old bob apart. But as editing those movements does not actually stop positional movement on that joint, and rotation and position from the parent and child also affect its position, there is little can be done simply by editing one joint rotation FCurve.
Now, the locks. I have been trying to find some ref as to their position, either an absolute or relative position, but in my editing those values It does not appear to change the movement of bob. My first thought on this was that the locks would be controlled similar to a simple cube, as in movement on the locks would of been relative to its last position, then movement on the rig would of been relative to that possition, but that can add other complications when more than one lock is enabled,.. but to be able to edit a lock or joint, so as to keep it in position then I would really expect some back ref to it position of origin (as with the simple cube), but as it is, there just appears to be relative ref up and/or down the chain.
I have gone back to basics on this, so as not to confuse myself, and looked at this from simple chains of joins as I mentioned here (http://forums1.caligari.com/truespace/showpost.php?p=78022&postcount=10). But no progression with the custom bezier on Bob.
Now, there could be some ref to the character root for all other relative positions, but as the root is also in constant motion, then I cannot see how a lock could take position directly from that.
- Stem |
Post by W!ZARD // Aug 28, 2008, 4:44am
|
W!ZARD
Total Posts: 2603
|
Well I would not call that moaning and groaning Stem - this is an articulate and concise description of a specific problem that Caligari can take action to fix (well I hope so anyway!).
What you describe here is exactly what I and others have found. There is a clear need for some serious attention to the whole Lock/IK system. The essentials of a good IK system are clearly there but the way it is currently implemented makes things somewhat difficult.
For me a large part of the problem appears to come from a conflict in the hierarchy of joint positions. The foot position is secondary to the hip/root bone position. Additionally, the apparent logic of the system appears to leave the Hip/Root world position on one level (that of the Actor) and subsequent bone and joint positions on a sub-level (that of the Skeleton).
FWIW here is a method I am using that seems to avoid the bone stretching and position hierarchy conflicts (if that's what they are).
Firstly I keep all the skeleton and overall Actor position keyframes on the same level - that of the Actor. I do this by activating Dynapose, posing the character and exiting Dynapose before recording the Key Frame.
Secondly I avoid using IK for all but the most general movements. Instead I use FK - this is slower but also far more accurate.
Thirdly, I avoid all use of joint restraints. I reason that the more freely the skeleton can be moved the less likelihood of conflict arising between Locks, joint limits and position hierarchies.
Clearly this is not an optimal solution but it does mean that I am able to create keyframed character animation without bone stretching. It limits my ability to use physics with characters because there are no joint limits (although of course I can easily create a copy of my character and add joint limits should interaction with physics be required).
Until such time as the IK issues can be addressed it is still quite possible to make effective character animations using this approach.
Hope this helps.
~W~
EDIT - Note that I use the FCurve editor almost not at all as I tend to keyframe every frame
- especially for things like foot position - this means I don't have to concern myself with interpolation types to the same degree. again, it's not particularly elegant but it does work! |
|
