In article <3e8e209c@news.povray.org>,
 "Tim Nikias v2.0" <tim### [at] gmxde> wrote:

> We're talking about the same thing. Yes, I'd have to
> generate the speed myself, from two different stills.

I don't know how you can get that from what I said. I'll try to make it 
simple: you are going at it backwards. You specified the object, so you 
must already know how fast it is going. Compute the speed from your 
object parameters, not from the generated frames.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

> [snip] You specified the object, so you
> must already know how fast it is going. [snip]

There's the problem. I'm not the one specifying the
object. I'm just the guy scripting an algorithm which
will take objects and transformations as input, and
compute the speed from that. Crude method, but
works fine so far (doesn't work with objects centered
on the origin and rotating about, the solution to that
is to break it into pieces which get moved around).



--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

>
> > We're talking about the same thing. Yes, I'd have to
> > generate the speed myself, from two different stills.
>
> I don't know how you can get that from what I said. I'll try to make it
> simple: you are going at it backwards. You specified the object, so you
> must already know how fast it is going. Compute the speed from your
> object parameters, not from the generated frames.
>
> --
> Christopher James Huff <cja### [at] earthlinknet>
> http://home.earthlink.net/~cjameshuff/
> POV-Ray TAG: chr### [at] tagpovrayorg
> http://tag.povray.org/

Post a reply to this message