You should see ‘Lola rennt’
I agree than you need variation in your walkcycle, but it is useful to have a good base animation that you can modify after to make it more natural.
Well, I’m too tired at this moment. And the patience you show, Harky, and your allways so very gentle mood, deserves a longer answer, but I am really tired. I post just as it’s going to be many hours and I suppose this thread will grow a lot till I can post again…
Bu in advance I’d say :
-there’s several moments that even in a walk cycle it is very importatn: for example, when making the charcter go up and down as goes walaking, you have a huge advantage if you can then pin a bone(in certain way).Or starting to run, in the first impulse… True than in cs I also use “sliding pin bone”, that allows me to pin it to a height, while allowing certain move, but not slide…is hard to explain as it works in a complex way. Anyway, I usually use pure pin joint. It has other button that alows to un(free joint) pin it. As you often need that. I don’t know how, but it does not gives it a problem in the case u mention.but tomorrow I’ll analyze what u say, now is too late for a non english speaker 
then, also in jump anims, crouch -or however the name- pivoting, jumping over a fence, posing a hand in wall as he fells down…a lot… 
In games at least, yep, walk and run is animated in place, but u actually do the exact move in vertical and horizontal, so to match a virtual floor.To expect coders will make it match witha floor is too much to expect
About the foosteps, I’ll agree with Torq…they’re not that useful…
also removes a lot of freedom, in my opinion…
perhaps I notice something…torq comes more from my world, games, and somwhat there are slight differences in how u animate for a game, and how people animate for video, films. Is … different. The cyclic thing is way important in games, and in otehr aspects, many stuff of hi res is not used.
(what nla does, in many cases, is done in the engine)
Well, I’m writting too much and so saying too much nonsense, as I’m terribly tired…tomorrow I’ll reply well (probably shorter
BTW , I know you told me that internally is complex to do that feature in blender…just i re-mentioned -excuse me ;)- because heard there’s coming an animation overhaul: I thought that’d mean more hands and time, but if it’s u alone again, I am afraid I have opened again my huge big mouth again… :S
Oh! I love that movie! except in the US it’s called “run lola run” 
Character animators rarely use “walkcycles” in the manner that you guys are talking about.
True enough… but with Blender’s NLA feature, it is really cool if you can have a character’s walk taken care of while you worry about adding his/her hand jestures, facial expressions and secondary animation on top. Cycling other actions also comes in handy.
Run Lola Run? LMFAO!
extrudeface: I’m not coding at all, actually. I have too many other pans in the fire (plus I’m not good enough at it). I think that Ton will be working on the code cleanup. Hopefully these suggestions won’t be too far afield and they will inspire him to try it.
If he does a nice cleanup job, though (like, duh, of course he will), I’ll be digging back into the sources to try my hand again.
this is very nicely thought out. good to have something in actual writing, instead of just people shouting all at once in forums or irc.
some very strong points there too. also I like the fact that you actually used what is there already, but enhancing it… instead of just inventing something completely new. still looks like blender… only thing that looked a abit tricky to me was the MatchMove thing… I have to read that part again, all these papers are so exhausting… heh.
one thing I would like to add, to this conversation, is the timeline. we have the sound timeline, we have the nla and the widget in buttons panel. but I think it would be nice to have just the timeline-slider, on it’s own.
something that would be just a header bar, with the timeline there, ticks showing frames, maybe different color if there is keyframes, and then ofcourse the pointer where you are now.
.b
I dunno guys.
It’s a nice idea, but I think by being so specific it’s rather limited.
I mean how about when you want to make a quadraped (if that’s how you spell it).
I much rather have more controll of bones. I’ve mentioned it time and again. Why can’t we just have some form of contraints for a bone that says around which axes it’s allowed to rotate (it’s own, global or relative to an object). And then to what degree it can rotate (minimum and maximum).
If we just had that it’d solve a miriad of problems the system has now and it would help in creating all sorts of bone rigged systems… not just people. My priority would be here.
I love the idea about having what in audio software would be a solo & mute switch in the nla… good idea
basse: I suggested an actual animation timeline that shows keyframe locations, but it’s only a one sentence thing in amongst the other stuff and easy to miss. The audio timeline hack works, but it’s still a hack.
macouno: My proposal mostly is for better tools and access to Blender’s current structure. New constraints are actually pretty easy to code (I made the Floor Constraint in a single morning just to see how hard it would be). So, some new, useful constraints would be a nice project for a coder who doesn’t feel up to playing with the Big Boys yet.
Also, I don’t see how this proposal limits you. IMO, it allows you more control and access to the power that’s right now sitting mostly dormant in Blender’s animation structures. The things I’ve proposed would work for bipeds, quadrupeds, centipedes, jellyfish and red-tailed hawks. The only reason you see a biped in the examples is because that’s the only rig I have on hand that I’m happy with.
The ability to pose joints of an IK limbs with FK motion would give you great deal more control over bones than you have now. So would Action Sliders, MatchMove, and an improved, layered NLA.
That’s the odd thing. These minor adaptations which should be easy to code have been talked about since the moment the current armature system was first published. Yet… it’s not been done yet. And since it’s at the root of what bugs a lot of people… maybe it would be a good idea if someone fixed them up. But ehr… no one actually does it.
I’m serious in saying that if I had the time I’d learn to code and fix it myself… but then I don’t so maybe I should just put a sock in it.
I tried to do that but the code was a mess. Ton’s official word is that the Armature/NLA code was pushed way beyond its original design spec. That’s what he said he is going to work on for the next (2.37) release. Looking at what he did with the renderer and the full rewrite of the mesh edit code recently, I’m expecting him to be every bit as good as his word.
These minor adaptations As you say means MAJOR rewrites. As well as you cant make a pig fly, there is limits to where you can extend a system. Blender animation system has been pushed far beyond its limits.
To get an idea of where we are going, most of the existing parts of whole armature code IKAs and the way objects are recalculated when a refresh is needed will be trashed and rewritten. And yet we must stay compatible with previous versions. If rotations limits for the bones have not been coded up to now is simply because the actuals methods used dont permit it. The constraint itself could be certainly added, but i can bet without any risk it’s impossible to insure it works in 100% of the cases. And this would need the new transform functions Theeth is working on.
Harkyman proposals on UI and enhancements seems sound to me and should not be a too daunting task as it reuse in a smart way mostly existing stuff. it’s a well thought and balanced proposal (but a more experienced coder than me with the anim system will have to check all is possible).
But the problem is lower than UI, lag in update of armatures for example cannot be solved without rethinking from the foundations. That’s what we have started (new transform is well advanced, starting on a scheme to insure updates are done in time and allowing better constraints, preparing room for softbodies to name some current projects), but to do this, you need time more than a magic wand.
Future goals as said are animation tools and there is already a lot of work prepared for this. When Ton will dwell in, if the result is half good as what he has done on editmesh (and why should it be only half good), you can expect some surprises.
Thanks lukep - those are pretty much my thoughts, too.
good news
and ehr… personally I wouldn’t mind if it wasn’t backward compatible if the system were really better.
Hey Harkyman! Great plans!
I have a small request. In regard to the after images, could you make the after images that forward in time a different color than those back in time?
Nice proposal overall Harky, but I have a little trouble with a couple of aspects:
This problem always existed in Blender, mainly because of the Posemode system. You couldn’t lock anythink to global space. With posemode gone, this should certinally be made possible, which sould make contacts and touches a breeze.
About the Driven Keys, I don’t think the ones you suggest sound anywhere near as powerful as they coould potentially be. In Maya, you can link any parameters to each other, and add math, so that for example, the rgb values are affected by the x position of the hand bone (silly example, but anything would go). Or cahracter1’s z position is equal to character 2’s y position * 3. (charater1 would then be 3 times faster than character2)
This also means that you could combine vertex keys and bone animations, so as you bend the arm bone, the muscle bulges (according to a bulge vertex key), or as you rotate and open the jaw bone, the face reacts naturally(according to a facial vertex key), and so on and on.
It does suggest this, but a more detailed description of how one would set it up would be interesting. I can’t see how it would work in practice from the mockup and description-
And what about bone types? It would be very useful to be able to make interesting handles instead of having to use regular bones, or even worse, empties. On a complex rig with lots of IK etc, it becomes an utter mess.
About vertex keys, I still have my old proposal lying on the web at http://www.shadeless.dk/ui/morphtargets.htm. If anyone wants review this, please do so. The RVK system is one of the worst aspects of the animation system IMO.
-William
PS
Oh, and why would we need a BaseBone if there is no posemode? It would simply be the parent bone.
This problem always existed in Blender, mainly because of the Posemode system. You couldn’t lock anythink to global space. With posemode gone, this should certinally be made possible, which sould make contacts and touches a breeze.
About the Driven Keys, I don’t think the ones you suggest sound anywhere near as powerful as they coould potentially be. In Maya, you can link any parameters to each other, and add math, so that for example, the rgb values are affected by the x position of the hand bone (silly example, but anything would go). Or cahracter1’s z position is equal to character 2’s y position * 3. (charater1 would then be 3 times faster than character2)
This also means that you could combine vertex keys and bone animations, so as you bend the arm bone, the muscle bulges (according to a bulge vertex key), or as you rotate and open the jaw bone, the face reacts naturally(according to a facial vertex key), and so on and on.
It does suggest this, but a more detailed description of how one would set it up would be interesting. I can’t see how it would work in practice from the mockup and description-
And what about bone types? It would be very useful to be able to make interesting handles instead of having to use regular bones, or even worse, empties. On a complex rig with lots of IK etc, it becomes an utter mess.
About vertex keys, I still have my old proposal lying on the web at http://www.shadeless.dk/ui/morphtargets.htm. If anyone wants review this, please do so. The RVK system is one of the worst aspects of the animation system IMO.
-William
PS
Oh, and why would we need a BaseBone if there is no posemode? It would simply be the parent bone.[/quote]
i read your propsal, and i agree, especially with the criticism of the current rvk system. your plan for a new morph targets would streamline the workflow a LOT.
I second the improvements required for RVK to be useful…
As for Harkyman’s proposal - I like all the features he is requesting, but need a few more to be added/spec’ed out. For example - bones NEED to have restrictions/limitations on their rotation angles. This would make IK alot more feasible as, at the moment, weird things happen too easily. Adding IK constraints such as solving on a plane would also help immensely.
I agree Night, rotation angle constraints would be a boon!
BTW, wth the RVK’s, if anyone has any additions or different ideas, please share.