POV-Ray : Newsgroups : povray.binaries.animations : meteor fly-through (and motion-blur comparison) Server Time
1 Jun 2024 13:55:59 EDT (-0400)
  meteor fly-through (and motion-blur comparison) (Message 31 to 34 of 34)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: John VanSickle
Subject: Re: meteor fly-through (and motion-blur comparison)
Date: 28 Jan 2013 20:03:18
Message: <51071fd6$1@news.povray.org>
On 1/27/2013 10:29 PM, Kenneth wrote:
> John VanSickle <evi### [at] KOSHERhotmailcom> wrote:
>
>>
>> ...the 180 degree blurring has
>> one benefit:  You only have to render half as many frames to achieve the
>> same level of blurring.
>>
>
> Yes indeed. My animation code block is set up to do that as well; but for this
> animation I originally rendered *all* the motion, as I didn't think of posting a
> '180-deg version' until later. Then it was just a simple matter of skipping
> frames during the averaged re-rendering. BTW, the re-rendering process goes
> *fast*, as it can be run at POV-Ray's lowest-quality setting. Just images
> projected on the front of a box, with ambient 1.0.  Not very *elegant*, but
> extremely useful.

POV-Ray is a rather flexible post-processing tool.  I've done fades, 
wipes, masking, and titling.

For instance, in a few of my IRTC animations I have a warp gate open up 
in space, revealing the yes-it-was-stolen-from-Babylon-5 hyperspace, and 
then ships use the gate to transit from one space to the other.  I have 
one rendering of the ship and the gate in normal space, another 
rendering of the ship and the gate in hyperspace, another rendering that 
is just a mask, and then a final rendering to transition from the normal 
space view where the mask is black to the hyperspace view where the mask 
is totally white.

You can see the two animations where I do this here:

http://www.irtc.org/anims/2004-10-15.html
http://tc-rtc.co.uk/imagenewdisplay/animation/index92.html

Regards,
John


Post a reply to this message

From: Kenneth
Subject: Re: meteor fly-through (and motion-blur comparison)
Date: 31 Jan 2013 10:25:00
Message: <web.510a8b819618bbb7c2d977c20@news.povray.org>
John VanSickle <evi### [at] KOSHERhotmailcom> wrote:

>
> You can see the two animations where I do this here:
>
> http://www.irtc.org/anims/2004-10-15.html

Is this one supposed to be so short? The file is only a couple of seconds long;
looks like it has been truncated.

> http://tc-rtc.co.uk/imagenewdisplay/animation/index92.html

Very cool. Some nice effects there; the wormhole/hyperspace thing is really
good. And I do like your acceleration/deceleration of the camera pan. My own way
of doing that is kind of cumbersome (and not wholly effective.) For the
acceleration, something like

#if(clock >= .2)
and using
pow(ceil(..multiplier.. *(clock - .2),0,1),2)  (...I *think* this is right...)

but also having to figure out what this block should be to smoothly reverse the
process, for the deceleration. The pow(...) thing is needed for the smoothness
of course, but it also makes it difficult to figure out the right value to use.
Do you have a more elegant and controllable means to do this, that you simply
plug in whenever it's needed?  Maybe one that I could steal?  ;-)


Post a reply to this message

From: Alain
Subject: Re: meteor fly-through (and motion-blur comparison)
Date: 31 Jan 2013 16:03:43
Message: <510adc2f$1@news.povray.org>

> John VanSickle <evi### [at] KOSHERhotmailcom> wrote:
>
>>
>> You can see the two animations where I do this here:
>>
>> http://www.irtc.org/anims/2004-10-15.html
>
> Is this one supposed to be so short? The file is only a couple of seconds long;
> looks like it has been truncated.
>
>> http://tc-rtc.co.uk/imagenewdisplay/animation/index92.html
>
> Very cool. Some nice effects there; the wormhole/hyperspace thing is really
> good. And I do like your acceleration/deceleration of the camera pan. My own way
> of doing that is kind of cumbersome (and not wholly effective.) For the
> acceleration, something like
>
> #if(clock >= .2)
> and using
> pow(ceil(..multiplier.. *(clock - .2),0,1),2)  (...I *think* this is right...)
>
> but also having to figure out what this block should be to smoothly reverse the
> process, for the deceleration. The pow(...) thing is needed for the smoothness
> of course, but it also makes it difficult to figure out the right value to use.
> Do you have a more elegant and controllable means to do this, that you simply
> plug in whenever it's needed?  Maybe one that I could steal?  ;-)
>

Why don't you use a spline to move the camera. You set the control 
points according to where you want the camera to be at a given time. If 
the control points are far apart, the amera move fast, if they are close 
toggeder, the movment is slow, and if there are coincident points, the 
camera stops.

You can use a second spline for the look_at point, with possibly a 
control for the zooming or banking...
A direction length or angle can be included as a fourth vector component.


Alain


Post a reply to this message

From: Kenneth
Subject: Re: meteor fly-through (and motion-blur comparison)
Date: 31 Jan 2013 21:55:00
Message: <web.510b2d999618bbb7c2d977c20@news.povray.org>
Alain <kua### [at] videotronca> wrote:

>
> Why don't you use a spline to move the camera. You set the control
> points according to where you want the camera to be at a given time. If
> the control points are far apart, the amera move fast, if they are close
> toggeder, the movment is slow, and if there are coincident points, the
> camera stops.
>

Yes, a spline is useful for doing as you say, and produces nice smooth movement.
In most of my own animations, though, I use clock values (or frame numbers) with
some math.  Just a personal preference, I guess. It seems easier to control, in
a more precise way. With a spline (an easy-to-use natural spline, for example)
if you change or move a control point, it causes the curve there to change in a
not-so-intuitive way (based on the control points to either 'side' of it.) Which
may or may not produce the exact effect you're trying to get. Using just clock
values instead, I can start a camera movement precisely where I want in the
animation, without wondering if the movement is actually going to start several
frames behind or ahead (as might be the case with a smooth spline.)

However, I do imagine that adding several identical spline points close together
could probably solve that--'breaking' the curve there, or uncoupling it from the
previous control point. It's not as 'intuitive' as I would like, but I'll give
it a try.


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.