#Interpolate?
16 messages in this thread
Okay, I made the mistake of starting to fool around with scripting and now I'm
hitting the proverbial programming wall. For some reason I can't quite figure
out the behavior of InterpolateKey.
Here's what I did: I create an object and then set two keys for it, around 2500
x units apart (same y and z). When I try to interpolate evenly along the path,
I don't get even key spacing. In other words, if I place an interpolated key
at every 100 frames (for, say, a 350 frame animation) I get 850 units at the
first key (well, first after key 0), 1650 units at the second (so far, so good,
more or less) and then 2100 units at the third. If I change the length or
number of total frames I still get this non-spaced behavior.
I've set all the tens for the keys at 50, so it shouldn't be calculating ease
in/ease out. Is this not the way Interpolate is supposed to work? Shouldn't it
be calculating the position the object would be at for that frame? I'm using
whole frame numbers so I shouldn't have to use the FracInterpolate, right?
Hi Mike,
<< When I try to interpolate evenly along the path, I don't get even key
spacing. In other words, if I place an interpolated key at every 100 frames
(for, say, a 350 frame animation) I get 850 units at the first key (well, first
after key 0), 1650 units at the second (so far, so good, more or less) and then
2100 units at the third. If I change the length or number of total frames I
still get this non-spaced behavior.nI've set all the tens for the keys at 50,
so it shouldn't be calculating ease in/ease out. Is this not the way
Interpolate is supposed to work? >>
In the following example, I created a position key at 0,0,0 and at frame 30 a
position key of 1000,0,0. In this example, my TCB is set at 25/25/25 and I get
the behaviour that you are looking for. With tension set to 0 or 50, I get the
kinds of results that you describe.
'******
DefPosition MyPosition
framecount=0
for framecount=0 to 30 step 1
InterpolateKey "Object01", framecount, MyPosition
print framecount,MyPosition.x, MyPosition.y, MyPosition.z
next framecount
0 0 0 0
1 33.3333 0 0
2 66.6667 0 0
3 100 0 0
4 133.3333 0 0
5 166.6667 0 0
6 200 0 0
7 233.3333 0 0
8 266.6667 0 0
9 300 0 0
10 333.3333 0 0
11 366.6667 0 0
12 400 0 0
13 433.3333 0 0
14 466.6667 0 0
15 500 0 0
16 533.3334 0 0
17 566.6666 0 0
18 600.0001 0 0
19 633.3334 0 0
20 666.6667 0 0
21 700 0 0
22 733.3333 0 0
23 766.6667 0 0
24 800.0001 0 0
25 833.3333 0 0
26 866.6667 0 0
27 900 0 0
28 933.3334 0 0
29 966.6667 0 0
30 1000 0 0
jonas[adesk]
>In this example, my TCB is set at 25/25/25 and I get the behaviour that you
are >looking for. With tension set to 0 or 50, I get the kinds of results that
you >describe.
Thanks, Jonas, I also got that result. But now I don't understand — shouldn't
tension be at 50? Oh, wait, maybe I get it. That way it moves smoothly
instead of abruptly starting?
I'm actually getting some pretty good results with this script stuff, so maybe
I'll have something to share. With the new reorg, is there any place to put a
script I make?
Hi Mike,
<< TCB a bit confusing.. >>
In your example, do a Paths/Show and modify Tension to be 25, then 0, then 50.
You'll be able to visibly see the interpolated results in the displayed path.
<< With the new reorg, is there any place to put a script I make? >>
Sure.. Place it in the Scripts section(18) of the ASOFT library.
jonas[adesk]
Okay, I think I'm getting TCB okay, but now I have another question (believe it
or not, I held off a week with my REALLY stupid questions).
The path results work okay as long as I don't use DeleteAllKeys. What I'm
doing is saving the end key and key 0, deleting all keys, and then restoring
the end and 0 keys (that way I have a clean path with only a start and end
key).
When I do this, even with TCB set normal (25/25/25) I get the squirrly results
(uneven spacing), even though the resultant path looks okay (now that I know
what to look for, I can see that there is a color difference along the path
when the tension is set differently). When I don't use the DeleteAllKeys
command (even if I go ahead and store the end and 0 keys and create them)
everything works fine. Does this make any sense?
Hi Mike,
<< I get the squirrly results (uneven spacing), even though the resultant path
looks okay.. >>
Post or e-mail me a pkzip of your script and the steps to initialize the scene
and I'll take a look at it.
<< Does this make any sense? >>
Keep it up…:-> you're asking all of the right questions.
jonas[adesk]
Hi Mike,
<< squirrly.. >>
I got through my in-basket and I got to your script. Can you please also pkzip
me the identical *.3ds that you are looking at so we can both be in sync?..
it'll help me out..;:-)
jonas[adesk]
Actually, Jonas, my problems (and priorities) have shifted quite a bit. While
I still think I don't understand why deleting all keys affects the situation,
it turned out I didn't need to do that (I just delete the position keys now
using the Deletetracks command).
My problem now is probably a whole lot easier to solve — just frustrating for
me. After getting my script to correctly work, I can't seem to get IK to work
with it. I wrote the script so that you can simply define a path, curved,
straight, whatever, and then it will take two dummy objects and create a "walk"
that follows the path with the specified number of steps and step height. I
need to polish it for the body bob, hip movement, etc., but for right now it
correctly creates the path I want.
However, I probably don't understand IK (although I thought I did and I worked
through the tutorials) because my legs aren't solving properly, but looking
rather spastic. I have to admit I haven't played with it much (just got the
path generation working correctly tonight after dredging up the parabola
formula) but it's very frustrating. Perhaps I'll import Randy and see if I
can't get him walking correctly.
Anyway, thanks for your help. I'll post my script when I get all the bells and
whistles.
Hi Mike,
<< I can't seem to get IK to work with it. I wrote the script so that you can
simply define a path, curved, straight, whatever, and then it will take two
dummy objects and create a "walk" that follows the path with the specified
number of steps and step height. >>
Are you also affecting a third object directly or indirectly? For body to walk
using IK, the main body must also have position keys, (ie. sliding along the
surface) and then the legs can be solved for with IK using the script solved
dummies. In placing the main body through your script you should be able to
program in nuances like "limp".
<< but looking rather spastic… >>
I know what you mean. Check out my flip.zip in the meshes section of the lib
and note that the joint parameters are changed from their default shipping
state. The first IK solution of this animation looked rather spastic too.. 🙂
I found that even though a limb has the ability to move in 3 or 6 dimensions
that for a particular motion you may want to further restrict and refine the
joint parameters to be ideal for the desired effect. It would be nice to affect
the joint parameters from your script but I don't think that that is feasible
at this time. 🙁
Keep it up.. !
jonas[adesk]
>Keep it up.. !
You may not want to keep encouraging me, as I end up asking these
stupid questions. Just when I think I have it all licked (script
generating smooth keys along any path for both left and right feet,
IK working properly, body bob incorporated) I get confused with the
most basic things.
I had noticed while I was getting this thing to work that increasing
the z direction of my objects would lift them "up" (as per the view
coordinates), with x, y being the "ground". Then I bring in the IK
Dino and try to body bob him, and find that the Master Dum object
treats an increase in Z as an increase along the "ground", although
my "foot objects" (which are not dummy objects) treat an increase in
Z as I had been assuming.
Now to further confuse me, I now notice that the key (in the
KeyFramer) shows a completely different correspondence than I've been
assuming. Am I hopelessly confused? (Well, I know the answer to
that already). Do objects have a relative x,y,z that bears no
relation to the view they're in? Can you straight me out (or at
least get me unstuck)?
>> I had noticed while I was getting this thing to work that increasing the
z direction of my objects would lift them "up" (as per the view
coordinates), with x, y being the "ground". <<
Mike… this is a rather confusing thing, but 3ds treats width, height, and
depth differently internally (and therefore in keyscript and ipas) than it
does in the editor. (ouch… my brain hurts) In the editor we all have
become accustomed to x width, y height, and z depth. This is known as a "left-
hand" system. Internally, 3ds uses a "right-hand" rule, which makes z height
and y depth. (stroke, hemmorage, ack, ack…)
I think (and I may be as hopelessly confused as you) that this can be
corrected in most cases by simply switching y and z in keyscript. All this
is mentioned in the readme for TSE and in Inside 3DS R4 (good stuff on
scripting in this one).
your friend in pain,
– Dan / n-Space, Inc.
ps – this script stuff is great fun, no? <G>
>> I think that this can be corrected in most cases by simply switching y
and z in keyscript. <<
I was just about to post a message inquiring about this. I just started with
keyscripts and this is the work around I've been using. However, your "…most
cases…" worries me. Are there other cases you know of that this won't work
on? Any insight would be appreciated (and would probably save me a few
sleepless nights).
>> (and I may be as hopelessly confused as you) <<
Thanks! I thought it was only me.
Thanks, Dan. Your comments (along with Jonas) as well as my reading and
thinking have gotten me a lot further in my thinking.
And speaking of TSE (which you mention): my success (ha, ha) with scripting so
far has got me thinking about possibly buying it. Any feedback? How much
better (more I can mess up) is it? And how expensive is it? (Always a
consideration, unfortunately).
The only other thing (other than money) that has kept me from getting it is
that I wanted to possibly write something others can use (of course, this may
be an idle dream, but I was quite successful writing tools for others). Any
thoughts?
<< You may not want to keep encouraging me.. >>
I *really* enjoy encouraging the growth of the scripting aficianado
community.
<< Do objects have a relative x,y,z that bears no relation to the view
they're in? >>
This question exposes a very important relationship of objects and how
they view their world. This understanding is necessary for
power-users, and this understanding was not necessary for users until
IK's joint parameters and scripting brought it to the surface.
There are several factors here. The first is the object's view of
itself and it's creation orientation and then what is the objects
orientation as it relates to the scene. In the 3DS Ref. Manual, this
relationship is outlined on pg 7-108. It is also on this page that
the underlying transformation matrix for each object is exposed to
the user.
Additional insights are found on pg. 8-47 under Hierarchy/Object
Pivot. Note the paragraph on pg. 8-47 that starts with Important…
Also, it is briefly touched in the 3DS Readme under Keyscript.
In Dan's reply to you.. "All this is mentioned in the readme for TSE
and in Inside 3DS R4 (good stuff on scripting in this one)."…
Regarding Inside 3DS R4, Phillip Miller went through similar mental
gyrations %-} over this "local coords vs. world coords vs pivot_point
vs. bounding box vs matrices" and then wrote about it in detail. I
suggest "Inside 3ds R4" to all aficianados.
In my bulge script, (that I hope you check out), I was able to use the object's
bounding box in local coords and in world coords in order to solve the
alignment problem of a scaled skin slice.
Great questions.. keep it up.. really ;->
jonas[adesk]
I've both ordered Inside R4 (solely for your script insights) as well
as read the manual once again (but not the passages specifically you
mentioned). I seemed to get the idea that my problems relate to the
fact the object was a dummy object attached and following a
coordinate set to it's parent. If that's the case, I think my script
is nearly ready for prime time.
So… I like this script stuff a lot. Do you have any thoughts on
TSE? I know that Ed has apparently done wonderous things with it and
it intrigues me. I suspect it will solve my only really complaint
with scripting (well, other than the fact I can't pass parameters to
subroutines): being able to create dummy or instance objects.
Hi Mike,
I'd like to add more references..
Check out "Viewing 3D Objects" on pg 7-5 of the Reference Manual. This
one is good and subtle but refers back to your original question..
Phillip likes to have his students in training create a seperate cone
in each of the the 3 different orthographic views(top/left/etc.) .
Now create a cone in the user specified isometric view (user view)
which is orientated different from one of the orthographic views .
You should have 4 cones with different orientations. Now in the
Keyframer, use Hierarchy/Object_Pivot for each of your 4 cones and
compare the Keyframer display to pg 7-5 and note that
Hierarchy/Object_Pivot displays the 4 cones identically even tho'
they were created in the 4 seperate views. 3DS is very consistant
regarding object creation.
jonas[adesk]