#Camera "flight" with POV
15 messages in this thread
Perhaps some of you can help me out with a rather interesting problem… (Seem
to remember something like this out of my 2nd year Physics book…)
I'm intrigued with the idea of creating an animation which emulates the pitch,
yaw, and roll of an airplane in flight. (Classic animation, right?) It occurs
to me that manipulating the CAMERA description in a POV scene file (some
combination of changes to the LOCATION, SKY (or ROTATE), and LOOK_AT vectors)
over time should do it.
I've already created the basic scene elements for POV which will remain more or
less static as the CAMERA moves, and I've downloaded Phillip Sherrod's RTAG
animation control interpreter.
Now… I ain't no NASA Engineer… BUT…
It would seem to me that there are a few things to consider:
1) LOCATION — I was thinking of describing the "flight path" in the
three components X, Y, and Z using Phillip's SPLINE function.
2) PITCH/YAW — Maybe I can simply use points along the same SPLINE
curve to look ahead some (i.e. point LOOK_AT at SPLINE(X,Y,Z) at curframe + 1).
This is sort of like what you do when riding a roller coaster. Always looking
ahead down the track a ways.
3) ROLL — (This is the really tough one.) Should I use the SKY vector
or the ROTATE command to modify the CAMERA description for roll? ROTATE may
work if the pitch and yaw are properly tangent to the SPLINE curve, but I've
seen unpredictable results with this in some (casual) experimentation. Perhaps
using a unit SKY vector with components in the direction of any acceleration
(e.g. towards the center of a turn) might be better. Either way, it sounds
like the amount of roll at any time, T, should be proportionate to the 2nd
derivative of the function describing the flight path at the same time T.
(Digging way back for that one…)
Has anyone out there tried anything similar to this using POV and/or RTAG? Any
pointers, ideas, reference materials?
Thanks much,
– Mark
There are 2 Replies.
Read action !
Items 1 & 2 are the way to go. Use location and look_at. Also sky is your
best bet rather than rotate but I'm not sure the best way to do it. Perhaps
you could compute an accelleration vector, add it to sky and normalize it.
There is 1 Reply.
Read action !
Chris –
Thanks for sanity check on this…
Is this something that you've done before?
I think by biggest challenge will be in finding the direction and magnitude of
the acceleration vector along the SPLINE path. Do you know of any decent
sources that might help me better understand the type of SPLINE interpolation
used in programs like AutoCAD v12, RTAG, and others?
– Mark
There is 1 Reply.
Read action !
I'm not sure if this will give the right effect or not, but
here's the acceleration:
SPLINE(T+1)+SPLINE(T-1)-SPLINE(T)*2
Where T=Time (Frame number) and SPLINE(T) is the current X,Y,Z
coordinates.
You may get better/smoother results if you average the look_at
and acceleration values for 2 or 3 frames before you use them.
Read action !
Mark,
As Chris says, you've got the right idea on steps 1 and 2. At least that's
what I did using RTAG on a simple "roller coaster" animation, and it worked
quite well. Sharp turns can get the view swinging wildly left/right,
though.
As for rolling, you're on your own. "2nd derivatives" require digging too
far back for me. (It has occurred to me many times that if I knew about
POV-Ray and Polyray in highschool, I would've paid much more attention in
calculus class.)
Another problem I ran into is acceleration control. I just don't see how to
do it using splines, which seem to want to interpolate a fixed number of
evenly spaced points between control points. (I think oversampling might be
an answer, but I never tried it.) If you or anybody else has ideas on this,
I'd love to hear 'em. Good luck.
Oh, here's another tip if you're not doing it. Use one of the new POV-Ray
wireframe modelers to rough out your scene and place spheres for spline
control points. It's the quickest way to visualize your flight path.
Yours, Douglas
There is 1 Reply.
Read action !
> It has occurred to me many times that if I knew about POV-Ray and Polyray in
> highschool, I would've paid much more attention in calculus class.
No kidding… Now I kick myself in the behind when I'd actually like to put
that knowledge to work. Although I can't see POV-Ray on an Apple IIe, can you?
(I guess that dates me pretty well, eh?)
Eric seems to have come up with a nice approximation for the acceleration
magnitude, now, what will I do about direction… I guess that approximation
will be used for each component, really, so I should just be able to add 'em
up.
I know someone here at work that is an aviator. I bet he'd be intrigued by
this…
> Another problem I ran into is acceleration control.
What exactly do you mean by oversampling in this case? Acceleration along the
SPLINE I end up using may be a bit too much work for what I want to do here,
but I may be hard-pressed to come up with anything realistic and interesting
without it.
Thanks for your suggestions…
-Mark
There are 3 Replies.
Read action !
For direction, try LOOK_AT(SPLINE(T+1)) or
LOOK_AT(SPLINE(T+1)+SPLINE(T)-SPLINE(T-1)). I think the second one
will giver better results.
In order to vary the speed, you can calculate 100 times as many
spline points, and then increase T by SPEED/100 (and use int(T) in
all SPLINE statments). For a rollercoaster, SPEED = sqrt(H-Y).
Where Y = the hight of the camera, and H is some hight HIGHER than
the highest point on the ride. The higher H is, the faster the
ride. Hmmm, that ignores friction. For a rollercoaster with
friction, SPEED = sqrt(H*POW(F,T)-Y). Where F=friction (just under
1.0 , around 0.999 is reasonable). Note: If H is too low, and/or F
is too far below 1.0, you will get an error, SQRT(negative number).
If you use E=H*POW(F,T)-Y (or E=H-Y) and
SPEED=sqrt(abs(E))*sign(E)*sign(SPEED(T-1)), you won't get the
sqrt(negative) error, and the camera will run backwards if it can't
get over a hill (like a real roller coaster, and it you are using
friction, it will rock back and forth and come to a stop at the
bottom).
P.S. sign(X)= if (X<0) then return -1 else return 1
or sign(X)=X/abs(X) (You may want to test for X=0 first, and
return 1 if X=0, but if X ever equals 0, it means SPEED=0.)
P.P.S I can imagine cases where this might get stuck and act real
weird when it can't make it over a hill and tries to back up.
Hmmm… E=H*POW(F,T)-Y (or E=H-Y) and SPEED=sqrt(abs(E))*D should
work (start with D=1), but each frame test if sign(E) < 0, and if
it is then DON'T change T, but make D=-D. I just realized the
camera will turn around in all the examples where it goes
backwards. In the spline statements, if you change T+1 to T+D and
T-1 to T-D,
the camera won't turn around when you back up.
Ask if anything is confusing.
Read action !
Mark,
> I can't see POV-Ray on an Apple IIe, can you? (I guess that dates me
> pretty well, eh?)
When _I_ was in high shool, <g>, the latest thing in personal computers was
the Altair. It used 8 rocker switches for input, and eight LEDs for output.
It had very limited graphics capabilities. Although I must admit, the
thrill I got in making those little LEDs "chase" themselves was not unlike
the thrill I get today creating a photo-realistic raytracing. It all
depends on your expectations, I guess <g>.
> What exactly do you mean by oversampling in this case?
Good question. I was confusing RTAG's splines with another method of
splines I had played with. In RTAG, you _can_ calculate the spline at any
point between the start and end-points, apparently. No problem.
In a roller-coaster animation, ideally the velocity of the camera would
depend on its altitude.
Yours, Douglas
Read action !
Mark,
Boy, what a perfect segue! I've been meaning to drop a hint about "3-D
Computer Animation" by John Vince (Addison-Wesley, ISBN 0-201-62756-6). I
picked it up this weekend and have been learning a lot! Very well written. He
explains the basics, but doesn't sugar-coat the important stuff. It's also an
excellent basic book on rendering principles. There is no program code, or even
pseudo-code, as far as I've seen so far, but the concepts are explained well
enough that it's not neccessary. Highly recommended from someone who's been
struggling to understand the math for a long time.
You might also be able to get some technical information about flight dynamics
from Chris Lampton, author of Waite's "Flights of Fantasy". Chris hangs around
the VR area. I don't know how much he personally knows about flight, but the
book contains an elementary flight simulator, so I'd guess that he's at least
reasonably well-versed in that area.
Dan
PS: I was out of high school, the Navy, and college before the PC Jr. came out.
And I'm not the oldest one around here!
There is 1 Reply.
Read action !
Boy… Thanks, for the comments and ideas, guys… I guess <g>.
Eric — Think all that went a little too quick for me. I'll be sifting through
that for a while yet. Your "stream of conciousness" approach to physics is a
new one for me I must say… You have some nice insights.
Douglas — I think the closest I've come to the Altair is that LightBright toy
where you stick colored, semi-clear pegs through black paper on a light box.
Not quite the same, I guess. (Although, there's kind of a ray trace type thing
happening with a LightBright. <g>)
Dan — We've got this place in San Jose, CA (a little north of me) called
Computer Literacy Bookshops that will undoubtedly have the books you mentioned.
I will pick it up. (For those of you that aren't familiar, these bookshops,
there are only two, are almost _twice_ the size of the average B.
WaldenDalton's. Silicon valley has quite an appetite for the stuff.)
Thanks again all,
– Mark
P.S. If this thread goes on much longer we're sure to find somebody who'll
start off with something like… "When _I_ was a kid, _we_ took notes on stone
tablets with a sharp rock and a big one for a hammer… And we _liked_ it
too!…"
There are 2 Replies.
Read action !
Mark, If you enjoyed Eric's "stream of conciousness physics", wait'll Jeff
Bowermaster gets a little free time and starts his poetry going again <g>.
Stick around… you'll see what I mean.
BTW: The stone tablets broke too easy. And you think harddisks are bad…
Read action !
>>When _I_ was a kid
… we didn't even *have* stone tablets. Everything was molten.
We just swam around all day…
>>And we _liked_ it too!
Back to reality (well, not *exactly REALITY* but…), sorry my message came
out as a stream <g>. I was composing it on line.
The main point was create alot of spline points, and then use
the one that is closest to where you want to be. That way you can
have a variable velocity. Maybe it would be easier to think about
if you changed "T" (time) to "D" (distance) in the spline formula.
Then you add velocity to distance to get the new spline point.
If you're not doing a roller coaster, you'll need to define the
velocity and how you want it to vary. I got a little carried away
with the roller coaster, and getting it to run backwards <G>.
If you're not doing a roller coaster, you can forget everything
at the end that referred to hight and friction. The other equations
should be exactly what you want.
Question away! I love this stuff <G>
There are 2 Replies.
Read action !
>> The main point was create alot of spline points, and then use
>> the one that is closest to where you want to be. That way you can
>> have a variable velocity.
So… Because the SPLINE function in RTAG can interpolate points inbetween, I
will actually supply only the minimum number of control points needed to create
the basic path I'm looking for, right?
Also, when you say "velocity", you really mean "speed along the path", yeah?
I think I'll get those books Dan spoke of, and start with some serious
experimentation…
Thanks again for all your help…
– Mark "Born in the Primordial Soup" Campbell
There is 1 Reply.
Read action !
>>the SPLINE function in RTAG
I haven't used RTAG yet… maybe someone else will jump in
and answer…
>>"velocity", you really mean "speed along the path"
Yes
Read action !
I had a thought on this velocity issue you've been tossing about. Howabout
using a spline to map the velocity curve you want and maintain speed per unit
time (ie. frame) to get the current position in your spline path. You might
have an animation that is not frame oriented but destination oriented.
Mike Hoyes
Read action !