Motion Blur?
Jamis Buck
buck at cs.byu.edu
Wed Oct 14 14:24:38 EDT 1998
Actually, you are moving both objects simultaneously, because anytime ANY
ray intersects the object (even a reflected ray, or a shadow ray, or
transmitted ray, etc) the blur calculations are performed. This means
that all reflections, shadows, etc will be accurate.
Associating motion with the object itself is a good idea, though. I guess
I thought of making a new object to increase the ease of POV
implementation, but now that I think about it, I can't think of any real
reasons NOT to do it in the object definition itself.
* ----------------------------------------------------- *
| Jamis Buck ---- ICQ # 3482361 ---- buck at cs.byu.edu |
+ ------------------- Homepage: ----------------------- +
| http://students.cs.byu.edu/~buck |
| "Digital Horizons" |
* ----------------------------------------------------- *
| "Suppose you were an idiot... And suppose you were a |
| member of Congress... But I repeat myself." |
| -- Mark Twain |
* ----------------------------------------------------- *
On Wed, 14 Oct 1998, Talbot, Justin wrote:
> Date: Wed, 14 Oct 1998 14:13:24 -0400
> From: "Talbot, Justin" <J.Talbot at questech.com>
> Reply-To: irtc-l at email.niestu.com
> To: irtc-l at email.niestu.com
> Subject: RE: Motion Blur?
> Resent-Date: Wed, 14 Oct 1998 12:19:50 -0600 (MDT)
> Resent-From: irtc-l at email.niestu.com
>
>
> If you constrained the bounding object to be a sphere, then the object
> could move along any spline path, using a sphere sweep as the bounds for
> the blur.
>
> One problem is what happens if you have two objects moving? If you only
> move one object at a time, reflections will be incorrect. You need a
> time component that is consistent for all moving objects.
>
> In POV, I think motion should be implemented as an attribute of an
> object, i.e:
>
> sphere
> {
> <0,0,0>, 1
> attributes...
> motion {
> direction vector
> speed
> user defined bounding box
> }
> }
>
> motion would default to not moving.
>
> Then you would define a global variable, SHUTTER, with the shutter
> speed.
>
> When rendering, add time to the anti-aliasing function. If
> anti-aliasing is off, everything is rendered a time 0. If it is on the
> rays are distributed through out the shutter time period. For
> non-moving objects this would act like normal aa. For moving objects it
> would sample along the path, adding blur.
>
> You would probably want to add something so it only sampled at a
> particular time if the object is in front of the ray. Given the speed
> of the object and the maximum width of the bounding box (or sphere) you
> could define a set of times when the object had a possibility of
> intersecting the ray. Simply reject all rays that fall outside of this
> time zone.
>
> Justin Talbot
>
> Flame me at:
> -edfoley at geocities.com-
>
>
> ----------
> From: Jamis Buck [SMTP:buck at cs.byu.edu]
> Sent: Wednesday, October 14, 1998 10:23 AM
> To: irtc-l at email.niestu.com
> Subject: RE: Motion Blur?
>
> Something I've been considering (for motion blur) is something
> along the
> following lines:
>
> 1) define a new object-type:
> motion_blur
> {
> object{ object_to_move }
> blur_attributes (ie, samples, bounding boxes, etc)
> blur_motion_attributes (direction, speed, etc)
> }
> 2) when a ray intersects the motion_blur object (defined by
> some
> bounding_box), calculate the intersection of the object as
> it
> moves, "samples" number of times.
> 3) return the average of each sample as the color of the ray.
>
> This method would maintain reflections, refractions from other
> parts of
> the scene, and would only render the object in question. At
> least, so
> I've thought. Can anyone point out any problems with this
> model?
>
> * ----------------------------------------------------- *
> | Jamis Buck ---- ICQ # 3482361 ---- buck at cs.byu.edu |
> + ------------------- Homepage: ----------------------- +
> | http://students.cs.byu.edu/~buck |
> | "Digital Horizons" |
> * ----------------------------------------------------- *
> | "Suppose you were an idiot... And suppose you were a |
> | member of Congress... But I repeat myself." |
> | -- Mark Twain |
> * ----------------------------------------------------- *
>
> On Wed, 14 Oct 1998, Key Jay Andrew wrote:
>
> > Date: Wed, 14 Oct 1998 17:01:41 +0100
> > From: Key Jay Andrew <KeyJA at logica.com>
> > Reply-To: irtc-l at email.niestu.com
> > To: irtc-l at email.niestu.com
> > Subject: RE: Motion Blur?
> > Resent-Date: Wed, 14 Oct 1998 09:18:19 -0600 (MDT)
> > Resent-From: irtc-l at email.niestu.com
> >
> > I've been working on extending the almost-most-current version
> of povray to
> > handle motion blur natively, and used it for the 'motion'
> IRTC.
> > Unfortunately, it's not finished yet for all object types and
> rendering
> > options yet. I've been quite busy lately, so there's not much
> hope of
> > finishing it my spare time in the next few months.
> >
> > However, the method it uses is to basically rerender each line
> of the output
> > x-times (user definable), and then average the line before
> outputting it.
> > The motion is defined by adding a motion vector to any objects
> you want to
> > move. It would be possible to write a utility to average a
> set of output
> > images, but that would violate the rules of the IRTC.
> >
> > > ----------
> > > From: Daniel Rohrer
> > > Sent: 12 October 1998 23:31
> > > To: irtc-l at email.niestu.com
> > > Subject: Motion Blur?
> > >
> > >
> > > Does anyone know of a way to get POVRAY to simulate motion
> blur? I seem
> > > to recall a discussion once upon a time where someone hinted
> that it could
> > > be done.
> > >
> > >
> > > Cheers,
> > > Daniel Rohrer
> > >
> > >
> > > ----------------------------------------------------------
> > > Daniel Rohrer 0oooo
> > > 919-962-1724 (UNC)
> > > www.cs.unc.edu/~rohrer ) /
> > > "No day but today"-J.Larson (_/
> > > ----------------------------------------------------------
> > >
> >
> >
>
>
More information about the Irtc-l
mailing list