dblhelix
-
Posts
457 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by dblhelix
-
-
"500 Internal Server Error
A team of highly trained monkeys has been dispatched to deal with this situation.
If you see them, show them this:"
well?
Did ya show em?
oh you know how it is: the blind one bit me, the deaf one ate the document while the mute one made rude finger gestures.
*sigh*
seriously though, maybe someone should take a peek at that link?
-
thanks!
with fresh eyes, doing my own critique - he'll probably kick back/bend knee more before jump - the head could be a mite too wobbly depending on how strained i want him (interpolation studies..) - strained would mean the dangly right foot would show more cramped energy.
have to do the next motion before deciding; i'd like contrasting energies to accomplish some of the work here.
after the jump up, his foot is lodged under the bench. no one asked, but i just realized it looks odd without shadows to help.
-
thought i'd post animation as well as chatting, for a change.
it's slow&lazy going, had only two days this week for a:m. didn't go back to the asymmetric walk cycle, but figured i could use an invisible platform as ground plane for that cycle, and animate the forward progress of that platform. good for specific walks like limping or walking with a broken heel.
here's showcasing a shaded/wire render;
a middle of a sequence from my inofficial version; there's action both before and after this = there is neither beginning or end in this clip. all critique is welcome, intention should now be clearly visible and separate from newbie blunders.
-
ahhh. it was so good i had to back and watch all the others.
when clicking the third, the family-part, i recieved this error message:
"500 Internal Server Error
Sorry, something went wrong.
A team of highly trained monkeys has been dispatched to deal with this situation.
If you see them, show them this:"
and then a bunch of code. it felt so right, the kind of message you get in Spleenland, that i can't be bothered to worry whether it was a virus...
-
oh.
you.
people.
that city image, let me know when the screensaver comes
stunning.
-
how's the PG13 treatin' ya?
-
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...
-
yupp. character comes alive. nice. it was a good week!
-
thanks!
-
thank you mtpeak2 for the experience of opening a real 3D set, n00b made eyes like never before!
question:
what kind of props are we allowed to add?
or, maybe for the shorter list: what kind of props are not recommended?
-
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.
-
Which one is closest to the effect you are trying to get?
the 16 is closer, since il'' be testing for faster movement.
-
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!
-
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.
-
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.
-
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.
-
"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.
-
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!
-
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.
-
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?
-
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.)
-
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.
-
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.
-
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#
Trem do Pantanal 2020
in Work In Progress / Sweatbox
Posted
must have missed the size of the city image yesterday..
some downloading has taken place.
thank you!