#tempo_dm
10 messages in this thread
Hello,
I've been trying out your Tempo demo for a couple of weeks. My main use of it
would be for architectural fly-bys and walk-thrus. I've been experimenting with
starting out with a uniform velocity path and then trying to vary the velocity
at very precise locations along the path. Let's say I have a circular path
going around a building and decide to slow down at segment AB (say frame 300 to
frame 600 in a 1200 frame animation) to get a longer look at some important
feature. I go to the velocity curve editor and move the points at these frames
but when I check out the results in the preview I find that the resulting
physical position and length of the velocity change don't match the AB segment
where I wanted the slow-down to occur. What strategy is used to make these
align? In the keyframer I could simply double the number of frames within AB
and scale back down to the original number of frames. Can this be achieved as
easily and accurately in the velocity curve editor? Or is more a fine tuning
tool? Is there much trial and error involved in using Tempo?
Thanks in advance for any feedback you can provide. George Sandoval
Hi George,
Your question is similar to the following answer provided by Rolf…
<< How can I use tempo to be a certin spot at a certain velocity? >>
Answer:
First, set up the path as you would expect (probably with a key at points
A, B, and C). Make sure there are plenty of frames in the animation (path),
scale time if necessary.
Go into TEMPO and enter the velocity curve editor. Set the velocity curve
to be flat at 55 mph for the entire animation. Click OK to apply it (make
sure fit to path is NOT on).
Now go into the preview dialog to see at which frame the car passes point
B. We'll call this frame f.
Now go back into the velocity editor and set the start of the active
segment to frame f and place a node there at 55mph (Make sure the end of
the segment is the last frame). Add another node somewhere between the
previous node and the last node at 45mph.
Switch edit mode to 'Move Point' and click on the node you just made. Now
what you want to do is move this node horizontally (leaving it 45 mph) to
get the 'New Track Length' to equal the 'Original Track Length'. When you
get it, click OK. Again, make sure 'Auto Fit To Track On Exit' is OFF.
That should do it.
Another approach is to actually figure out the time it would take to travel
the remaining distance, BC. If your velocity is going to be linear across
BC then your average velocity is (55mph + 45mph)/2 or 50mph. The distance
from B to C can be found by setting the active segment in the edit velocity
dialog to start at the frame that B is on and end on the last frame. It is
then the value labeled 'Original Track Length', call it d. The time, t,
then is just d miles / 50 mph = t hours. You want this in frames so convert
the hours to seconds and then multiply by your frame rate. To find the
frame to place the third node at, add your result to f.
If you still have problems, make sure 1) you have plenty of extra frames.
Add a whole bunch of frames, you can delete the excess when you finish. 2)
The path is actually created to scale. 3DS doesn't have a unit setting for
miles so set units to feet and make sure the path is actually the right
length.
George:
It looked like Jonas' response has a lot of good info. I don't have time this
minute, but maybe at lunch today, or after work tonight, I'll write up
something on things I have done (to also create architectural
walk-thru/drive-bys).
Dave
Oops! Looks like I didn't make it! Well, I'll _definitely_ do something by
Monday….
Dave
David:
Thanks for responding….I'm looking forward to getting any insights you can
send my way when you get a chance.
George
George:
The following are some things I have learned/deduced/cobbled together regarding
the use of the Yost IPAS Boutique's TEMPO routine for creating architectural
walkthrus (or drivebys). I make no guarantees that anything I say here is
correct, as my usual method is to promptly forget everything I've learned after
finishing a project, so that I have to re-learn it all over again the next
time….<G> I hope this is semi-cogent — I found myself bouncing around,
making corrections and clarifications — so it may be a complete load of
garbage! Anyone who wants to straighten me out on anything — please *DO*.
The worst thing about planning movement is that every decision you make can
pretty much change everything else. So after any bit where a decision is made
in all the stuff below, just remember that you may have to juggle back and
forth between Tempo & KF and your notes to make adjustments to when and where
things are occuring. Without going through a complete case, step by step, it
seems virtually impossible to me, to thoroughly write a generic instruction set
that you can plug into any situation.
In the end, it all comes down to the balancing of three variables: speed of
camera movement, area covered (importance of specific start & end points) and
overall anmimation length. Which is most important to you? I always seem to
find that no matter how slow I make the movement, I'm always told "slower,
slower" by the powers that be.<g> I've used about 10mph for exterior
"drive-by's", and as low as 2.5mph for interior "walk-thru's", esp in tight
spaces. This will take some experimentation on your part, to come up w/
something that feels comfortable — and will likely be influenced by the focal
length of lens you use, and even the vertical angle at which you're pointing
(as non-level cameras make 3-pt perspectives that, in interior spaces
especially, can cause unwanted distortions [which coupled w/ fast movements
mean "grab the barf bag"]). To balance the above items, you'll just have to
start out with _something_, and modify it as you go along.
I find it best to create two dummies (or three, if you require rotations on two
axis). To the first, attach the camera and camera-target. To the second,
attach the first dummy. Use the first dummy for rotation, and the second for
movement along the path. This, in my opinion, _greatly_ simplifies working out
rotations w/o disturbing the other movement.
After you estimate a total time & create the frames in the KF (again, you'll
just have to start w/ a guess based on your knowledge of approximate distance
to be covered and target speed), unless you have some strict time requirement
that will dictate the speed and path start/stops), start with creating the
desired path for the second dummy, without regard to vertice location (ie don't
worry about how verts will affect movement — just how they'll affect path
shape). Use KEYMAN to embed the original path into the dummy. Open Tempo and
select the second dummy, and make sure the settings are for position. Select
the "Velocity" graph type. Hit the "Constant Velocity…" button. This will
tell you what the constant velocity will be for the path you have created,
based on the number of frames you've set in the KF. It's always better, of
course, to _over_ estimate the number of frames required.
Now, you'll have to play give-and-take w/ those three variables (speed, start
and end points, and time). Say you decide on 10mph, as a "constant" speed.
Take out a piece of graph paper and make your own version of Tempo's velocity
curve. Establish an arbitrary 0mph and 10mph on the vertical, and some
arbitrary frame interval horizontally. (This hand-graphing method is of more
use when the overall graph gets more complicated, such as if you're going to be
slowing down in some areas, or stopping and pausing at various points in the
animation.) Perhaps you want to accelerate from 0mph at the animation's
beginning, over 2 seconds (60 frames) continue at a constant speed (10mph) and
then decelerate over 2 seconds to come to a stop at the animation's end.
(Remember, if Tempo told you that based on your path & frame count that your
constant velocity was 10mph, by adding an accel from 0 at the start and decel
to 0 at the end, you're going to stop short of the end of your path — so
you'll either need to increase the speed during the the middle section [the
"constant" velocity part], or add frames to the the middle section [thus
increasing total number of frames] in order to reach the end of the path on the
desired frame.) Assuming that the total frame count is 900 frames, draw a
perfectly horizontal line from frame 61 to frame 840. (I'm assuming that we're
not using frame 0 as a part of the animation.) Then make a curve from 0mph at
frame 1 to 10mph at frame 61. Make a mirror of that curve from frame 840 to
900. Now that you know what your curve should look like (roughly), go back to
Tempo and open the Velocity Curve Editor. Reset it and begin constructing a
curve that contains vertices at the same frames as in the hand-drawn curve
(frames 1, 61, 840 & 899 [not 900 as there is no velocity on the final frame]).
Use the "Adjust" button to adjust the tension of the spline segment at frame 61
& frame 840 to get curves. (An accel curve would best start shallow and get
steep at the the end, while a decel curve would do the opposite.)
If speed isn't your prime concern, check the "fit to track on exit" check box.
This will increase the speed during the flat portion of the curve in order to
match the end position on the original path. If you don't want the speed to
change, embed the spline and exit Tempo. Increase the total frames in the KF
and then play w/ sliding the frame numbers for the beginning of deceleration
and final stop to the right. Apply, and check the preview. As far as I can
tell, playing like this is the only way to determine the number of frames to
add to achieve the goal of maintaining speed and position at the expense of
total time (frames).
After you get something you're happy with, and apply it, you will want to think
about whether you need to alter the TCB settings for the keys. If you're doing
som pauses, you may want to alter the BIAS to 0 at the first key of the pause,
and to 50 at the end to avoid any anticipatory movement. Just make sure to
apply these changes AFTER Tempo, else you'll lose them and have to re-apply
them.
That's the majority I can think of off the top of my head, and from a few notes
I wrote myself. Again, I would not be at all surprised to find that some of my
assumptions are erroneous — and I may have misremembered a thing or two — so
I invite any and all comment.
Dave
PS Redo both the tutorials — they helped me plenty!
PPS After rereading Jonas' post to you while getting ready to post this, I
realize I don't really know that much about it at all…. I think I see
some things in there that will solve some of the questions I came up w/
just while writing _this_!
David,
Thanks for the expansive reply. Appreciate the time you put in. I'm just about
to take a deep breath and delve into it.
I'll keep you informed of any insights gained by experimentation.
Thanks again!!! George
Dave:
Ever consider hiring yourself out to write manuals? :^)
Greg Pyros
Yeah, right Greg! You know, I really ought to sit down & try writing out what
I think I know _before_ I leave a message saying I will — that way, I'll
embarrass myself less. I always seem to find I either knew _more_ than I
thought, or (more often) _less_!<g>
Several times, I've meant numerous times to sit down and write myself a little
guide of things I've figured out, but I never seem to get around to it when I'm
actually _doing_ the thing — and trying to remember later is a perilous
journey!
Dave