runcycle become skiing cycle

[dblhelix]

i made a run cycle; a choreography that i saved as an action.

created a new chor for testing speed in relation to distance, imported the runcycle and scaled its length in the view that's all white with only red squares.

prolonged the cycle to span the scene, then proceeded to animate the cycle nailing toes so thom wouldn't ski.

took a break, closed am.

came back, worked on an object in the same project then returned to the finished runcycle across the stage.

thom was skiing.

i cursed "must have scaled something by accident" and did it all over again.

rendered, pondered, took notes and went to bed.

 

today i open the project and whaddyaknow, thom is skiing again. hateful creature. is this gratitude?

 

what am i doing wrong/not doing? i've this nagging feeling there's a workflow issue here again.

only linear interpolation used.

 

just in case:

1sttestfast.prj

[robcat2075]

When i load that and play Runcycletest1 he is moving approximately forward, not sliding in place.

 

What part is not what you expected?

[dblhelix]

What part is not what you expected?

 

there are two projects there. the first shows thom slowly dappity-dapping across the stage.

the second, faster, shows him skiing across the stage.

 

do you have two projects in there? can't control content on this machine.

[robcat2075]

There are two chors in the one PRJ

 

runcyclebuild has him running in place

runcycletest1 has him moving forward.

[dblhelix]

There are two chors in the one PRJ

good!

the forward motion in both was impeccable yesterday before closing am. not so today.

yesterday there was a (remote) chance i'd done something by mistake to cause the change when it happened the first time after closing am, but not today. i open the chor, the motion has changed "by itself" overnight, it seems. which is impossible, so where did i go wrong?

 

i can work around this, but i tend to do any animation as slow first, then speed it up, so i'd really like to understand where the hiccup is.

[dblhelix]

edit,

sorry, the proper forward motion was a different project, not included in the link.

problem remains the same.

[robcat2075]

Here's what i see in the front view.

dblhelixruntestH264.mov

 

I'm not saying Pixar will be calling when they see this, but he does appear to be moving forward and his feet appear to be not slipping very much.

 

Tell me what you mean by "skiing". His feet not lifting much?

[dblhelix]

I'm not saying Pixar will be calling when they see this, but he does appear to be moving forward and his feet appear to be not slipping very much.

 

Tell me what you mean by "skiing". His feet not lifting much?

 

oh, texas..

we up here in the frozen tundra call it skiing when animated feet slip forward and/or back when they should stay put on the ground.

the film looked weirdly ok, but what if you scroll? #theremin music#

[robcat2075]

scroll? you mean scrub thru the timeline?

 

In "runcycletest1" he looks to be moving forward.

[dblhelix]

and slipping forward, backward, whathaveyou.

this was not so yesterday.

i make keys, scale the length of the animation, approve, close am, open am, the keys are visibly there on the timeline - but they have no effect!

i know it sounds weird, but it's twice now.

[robcat2075]

In the movie I put up his slipping is small, maybe less than the length of a toe. Is that what you are referring to?

[dblhelix]

sorry, had to sleep&work&have fun.

 

- - i think i got it; this is cluedo, and it's your nice way of not saying

"a:m - in the study - with character"

 

proceeding to scale the original slow-paced project for each new speed test.

curious as to why the autonomous night-life of keys had no effect here.

[robcat2075]

There's a few things I'm not sure about.

 

You have two actions runcycle(which uses stride length) and runcycle16(which doesn't use stride length)

 

The one with stride length has the stride length mis set. The stride length should represent the distance from toe to toe or heel to heel rather than from rear heel to front toe.

 

Heel to toe will be too big a value and will make the feet appear to slip if you use the action in a conventional manner on a path.

 

Is that why in runcycletest you use the one without stride length and are manually advancing the character?

[dblhelix]

you've been editing?

read your first version, got me thinking and figured out there's been a gargantuan violation in terminology on my side.

thanks for your patience, this should help enormously:

forget cycles.

 

i've this action, let's call it step-action. i make an animation sequence with the step-actions and then i scale the animation shorter. all is good and well.

until i close a:m. starting next session when i open a:m again, the scaled keys look ok on the timeline, but a:m previews and renders an animation that is different than the one it previewed and rendered the night before - from the exact same keys.

 

there!

 

(he has no stride nor is he on a path and this is as it should be. i must have activated something while testing stuff since you say he has stride when walking in place. but it doesn't matter: the first version of long sequence made of chor "runcycle" previews according to given keys, with or without faulty, irrelevant programming. only the scaled version behaves with willfull obstinate soul.)

[robcat2075]

This is one of those moments where text is inadequate to convey meaning.

 

I can sort of dimly envision what you are saying but there are many uncertainties that leave me... uncertain.

[dblhelix]

well, for a n00b, being laughed at goes with the territory, i don't mind.

but i would like to learn.

has anyone else had these twilight experiences?

or can someone just say if a:m renders keys that fall "between" frame lines?

[itsjustme]

well, for a n00b, being laughed at goes with the territory, i don't mind.

but i would like to learn.

has anyone else had these twilight experiences?

or can someone just say if a:m renders keys that fall "between" frame lines?

 

If the keys fall between the frames, you won't see the keyframes when you render at that frame rate...they'll still be there, but they wouldn't be rendered (the frames between the keyframes would be rendered instead). There are several techniques that take advantage of keys between frames...like MUFOOF.

 

Posting your Project file would help people figure out your problem faster, I'm thinking.

[robcat2075]

I'm not trying to laugh at you, but I'm not sure what you are describing.

 

If you have scaled your keyframes and they don't exactly fall on whole frames, you'll still get something rather similar on the nearest neighboring frame.

[dblhelix]

If the keys fall between the frames, you won't see the keyframes when you render at that frame rate...they'll still be there, but they wouldn't be rendered (the frames between the keyframes would be rendered instead). There are several techniques that take advantage of keys between frames...like MUFOOF.

 

Posting your Project file would help people figure out your problem faster, I'm thinking.

 

this is it!

been staring at that page for an hour trying to figure out the implications. i completely understand that it works for machine motion and at propeller speed, with an even dynamic. this was supposed to be the day off, but i have to get testing what logic&frame rates it needs for running. ...am thinking the motion blur is the secret here. is this how they did the speed-of-light possum bros in ice age 2?

 

what other techniques are there? i'm thinking of ways of previewing fast.. the "render animation preview" works with MUFOOF? starting testing there.

 

the project is in the first post, the longer chor has the scaled keys.

[dblhelix]

I'm not trying to laugh at you, but I'm not sure what you are describing.

i'm sort of used to running into problems no one's ever heard of, and being totally puzzled about it myself, every time. like now, it's going to be a sequence with a small man running at what could be described as sewing machine speed. this is animation - the basic problem (frame rate + speed + dynamic) simply can't be that unique? but as you noticed, it was far from ordinary!

[HomeSlice]

the basic problem (frame rate + speed + dynamic) simply can't be that unique?

It isn't unique at all, even in traditional film. That's why the wagon wheels in Westerns seem to rotate backwards sometimes. Or why propellers sometimes appear to stand still when they are, in fact, rotating. Motion Blur definitely helps. Another technique is simply to slow down the motion. I read once that Bruce Lee moved so fast that the camera couldn't capture all his movements, so the director made him slow down.

In story telling, all you have to do is convey the IDEA. You don't have to reproduce a totally accurate version of reality.

[dblhelix]

"and therein, as the bard would sing, lies the rub."

 

it's the ideas that get me into trouble. if the aim was to get thom from stage right to stage left, i'd be done by now. but no, he has to move in a kooky manner plus he'll be carrying something so he has to convey hurry and comedy at a speed that'll allow the viewer to take in the props and the absurdity of the situation. and i want to test different speeds - the animation has to be malleable.

 

from a technical point of view;

drag-select a sequence of keys and the scale handles will appear on the sides of the selection frame.

what is the point, if the resulting scaled keys will not compute properly?

i was sure i just wasn't handling the program, that there was maybe a mode to choose (like, without frame count) or something.

 

planning to save the slow original chor as a model => adding my two actions on that => baking the actions => import that action =>

then treating that action as a cycle to test MUFOOF.

[robcat2075]

I'm looking at the PRJ you posted at the top....

 

action "Runcycle" is about 22 frames long.

 

action "runcycle16" is about 16 frames long.

 

 

Do either of those appear to be the speed of action you want when you play them in the action window? Be specific.

[itsjustme]

from a technical point of view;

drag-select a sequence of keys and the scale handles will appear on the sides of the selection frame.

what is the point, if the resulting scaled keys will not compute properly?

i was sure i just wasn't handling the program, that there was maybe a mode to choose (like, without frame count) or something.

 

They compute properly for the frame rate you have selected...a different frame rate would give you different results. I'm not sure what results you are after, but if you increase the frame rate to the point where your keyframes are all rendered, I'm guessing you'll be close.

[robcat2075]

Also... is "runcycle16" the compressed version of "runcycle"?

[dblhelix]

Do either of those appear to be the speed of action you want when you play them in the action window? Be specific.

 

yes, as in: that is the animation i made. the preview is consequent, repeats the same day after day, shows keys the same way every time. these actions are my starting point. here i built a sequence destined to be scaled shorter, faster in the next phase.

[dblhelix]

They compute properly for the frame rate you have selected...a different frame rate would give you different results. I'm not sure what results you are after, but if you increase the frame rate to the point where your keyframes are all rendered, I'm guessing you'll be close.

 

there's an idea!

never done that before, is this possible in a:m through render settings other than MUFOOF?

like the ultra ultra-rapid scene in the Age of Innocence (Scorsese).

the everyday encounter is reading about conversion from 30fps to 25fps, and that this would best be left to pros. have never needed to test.

[robcat2075]

This is not a problem of keyframes being slightly off of a whole frame. The difference in appearance between a run cycle of 20 frames and the same thing compressed to 16 frames will be slight. It will not result in some significant pose being completely lost.

 

I've made a few changes to the original PRJ. Load this and watch the two chors in it.

 

Tell me how this either is or isn't what you are trying to get. Be specific about which one you are referring to.

 

1sttestfast_RCHmod01.prj

[dblhelix]

I've made a few changes to the original PRJ. Load this and watch the two chors in it.

 

hey, thanks! i never saw your post after itsjustme's. answer to that post is yes, the 16 is a cleaned-up version of 22. the speed is the same.

back in 15-20hrs from this post.

[dblhelix]

Tell me how this either is or isn't what you are trying to get. Be specific about which one you are referring to.

there's your chor "runycletest_compressed speed" and mine, renamed "runcycletest_original speed".

 

yours is a cycle on 16 frames, mine is an action on 16 frames.

 

there is no change in speed, compressed or otherwise?

 

i even tried rendering it, in case there was hidden info travelling in settings but no, not that i noticed.

i'm on v15j+, is this a problem?

 

and you had made the movement symmetrical to be able to use the functions of the cycle - i have worked to make his running lopsided and uneven. which is why i didn't do a cycle. and why i hand animated his progress across the stage. i've sort of been fighting to insert the flawedness of flesh to taint the purity of math.

 

tried to think through the MUFOOF but without result. other than my head hurts. baking the actions didn't work, but it was fun to watch the result for a while. he he. i'm switching to the other, longer project this week, i can't see clear enough into this problem to continue with questions even. back with fresh eyes next week!

[robcat2075]

Tell me how this either is or isn't what you are trying to get. Be specific about which one you are referring to.

there's your chor "runycletest_compressed speed" and mine, renamed "runcycletest_original speed".

 

yours is a cycle on 16 frames, mine is an action on 16 frames.

 

there is no change in speed, compressed or otherwise?

 

"original speed" takes 20 frames to do two steps

 

"compressed speed" takes 16 frames to do two steps

 

Both use the same run cycle action (yours with slight fixes), but there is a pretty apparent difference in how fast they travel.

 

Which one is closest to the effect you are trying to get?

[dblhelix]

Which one is closest to the effect you are trying to get?

 

the 16 is closer, since il'' be testing for faster movement.

[robcat2075]

Which one is closest to the effect you are trying to get?

 

the 16 is closer, since il'' be testing for faster movement.

 

Now we're getting somewhere!

 

You want it faster?

 

In the first PRJ you posted he was taking about 12 frames per two steps in the chor.

 

load this PRJ and look at the new chor "runcycletest_12frame speed". Is that closer to what you want?

 

 

1sttestfast_RCHmod02.prj

 

Notice that in all of the chors his left foot slides forward slightly while it's on the ground but the right foot slides backwards slightly. Is that the "ski" motion you've been referring to?

[dblhelix]

Now we're getting somewhere!

yes, but - - -

 

You want it faster?

yes, b-

 

In the first PRJ you posted he was taking about 12 frames per two steps in the chor.

16 -

 

load this PRJ and look at the new chor "runcycletest_12frame speed". Is that closer to what you want?

very much so, yes, but -

 

his left foot slides forward slightly while it's on the ground but the right foot slides backwards slightly. Is that the "ski" motion you've been referring to?

well yes (can't even tell the left foot slide it's so slight) but - -

 

 

are you trying to highjack the project?!

 

 

:lol:

 

and i'm going to say this as well cause it's even more fun though this is said in earnest:

if you don't have enough work

(taking a moment to give readers the opportunity to get all stitched back up again)

you can have it! it will work in disney-style as well, i should think; the foot motion might benefit from a different type of characteristic (exaggeration) to suit the general goings-on. shall i send you the props? in your style you'll probably make one into an action object, straighten thom's hand, constrain the other into the other hand and then it's just render away.

 

 

ok, all down to earth now:

how did you do the speeding up of your cycle? you didn't scale anything did you?

the leg stretch sort of pops out, when the leg is in its furthest backward-stretch position, it ""slows"" down the experience of speed, regardless of the actual speed. otherwise it's very, very close.

[robcat2075]

In the first PRJ you posted he was taking about 12 frames per two steps in the chor.

16 -

 

 

I counted frames and he was doing two steps in 12 frames. so something is more compressed than you thought it was.

 

 

 

 

are you trying to highjack the project?!

 

 

:lol:

 

I was just trying to ascertain what part of what you had was the part you didn't like.

 

Since the 12 frames per two steps is the speed you want and the foot sliding is insignificant, I'm back to square one on not being sure what you are unhappy with since this is very close to your original chor's result.

 

?

 

 

 

ok, all down to earth now:

how did you do the speeding up of your cycle? you didn't scale anything did you?

 

In all three chors i used your original 20 frame action cycle. It's really 20 frames not 22 frames when the overall action loops.

 

I slightly modified the keyframes on the foot targets so when they are on the ground they are moving at a constant speed with no variation. In "Treadmill" walk or run cycles the ground is moving at a constant speed so the feet must be keyed to move likewise. I didn't fix the problem with the two feet moving different distances. Normally you would have them travel same in a treadmill cycle.

 

Normally you would use an action like that with a path constraint to make A:M handle the problem of matching the prgress thru the animated cycle versus the character's progress over the ground.

 

But it is possible to do as you have done and manually move the charcter forward while he cycles thru his action. I had to experiment to find how far 7(?) cycles of foot steps should carry him.

 

 

If you look at the properties for "Shortcut to Runcycle" on the Thoms in each chor you will see that "Crop Range" is the same in each case: 0:00 to 0:20. Crop Range allows you to set what part of a cycle gets used by a character. I changed that from A:M's auto guess of 0:00 to 0:22

 

I set "Cycle length" different in each chor. Cycle length allows you to set how fast A:M interpolates thru the action contained in the crop range. This is where the "scaling" is happening.

 

You can guess what "repeat" controls.

 

"Chor Range" alters automatically based on what "repeat" and "Cycle Length" multiply out to.

 

In the chor Thom has only a keyframe on his model bone at the start and end of his travel t move him over the distance of seven cycles.

 

I changed the time of the last keyframe to match the end of the "Chor Range" time.

 

 

 

 

 

 

 

the leg stretch sort of pops out, when the leg is in its furthest backward-stretch position, it ""slows"" down the experience of speed, regardless of the actual speed. otherwise it's very, very close.

 

Modify your 20 frame action cycle to make the motion you want and see what the result comes out to be in the chor where it is applied.

 

I ideally if You knew in advance you wanted 12 frame speed you'd make the original action 12 frames. But... there's more than one way to get to your destination.

[dblhelix]

there you are! thought my dial-a-hero gizmo needed batteries changed!

 

I'm back to square one on not being sure what you are unhappy with since this is very close to your original chor's result.

i'm unhappy with not being able to scale a sequence of keyframes, and i was somewhat terrified realizing that you were doing my testing for me. that's an effective repellant for future questions! people need you left right and center and i need to get to grips with this program. i need to understand how to solve problems in it. i need stuff like this:

 

when they are on the ground they are moving at a constant speed with no variation.

the simple stuff that's not in taoam and goes unrealized when all's new.

 

Cycle length allows you to set how fast A:M interpolates thru the action contained in the crop range.

this here is goosepump material; you set crop range at an interval of twenty and set cycle length to 13 and a:m will interpolate this?

that would replace scaling in larger chunks...

[robcat2075]

the simple stuff that's not in taoam and goes unrealized when all's new.

 

I'll just note that the Technical reference (free on pdf) covers almost every detail of A:M. It's not a gripping read, but the facts are in there.

 

Also HomeSlice has made a wiki that I can't find a link to at the moment to that explains every parameter in A:M. Look for that too.

 

 

Edit: http://www.hash.com/forums/index.php?showt...2&hl=tiddly