Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!spool.mu.edu!uwm.edu!rutgers!cbmvax!chrisg
From: chrisg@cbmvax.commodore.com (Chris Green)
Newsgroups: comp.graphics
Subject: Re: Motion Blur in Ray Tracing
Keywords: Motion Blur Ray Tracing
Message-ID: <19295@cbmvax.commodore.com>
Date: 25 Feb 91 19:05:39 GMT
References: <471@forum.SUBLINK.ORG>
Reply-To: chrisg@cbmvax.commodore.com (Chris Green)
Organization: Commodore, West Chester, PA
Lines: 24

In article <471@forum.SUBLINK.ORG> work@forum.SUBLINK.ORG (Forum SuperUser) writes:
>There is still, though, a thing that i miss: we have to sample objects
>in different times of the same window and integrate the results, right?
>
>BIG PROBLEM: how do you move objects while time-sampling? Should we store
>several complete (huge) databases of objs at different times? Should we
>transform objs every time we want to sample in time (very expensive!)?
>

	What you should do is this: At each frame, take each object in your world,
and make its bounding volume large enough to contain the entire volume of space
that the object passes through in the time that the "shutter" is open. This is
relatively simple for linear motion, and spline based motion with the
convex hull property. It may be much harder or not solvable for things like
deformations, etc.
	Then, for each ray, stochatically pick a time value for it. Then, intersect
it with the world. When the ray intersects an object's bounding box, move the object
to its proper position for that time, and intersect it normally.
	What you save by this is that for objects moving at reasonable speeds, their
bounding boxes shouldn't be that much larger than they would be if the objects
were not moving.
	This should be integrated into whatever ray optimization scheme you are using.
	Also note that you should account for the motion of the viewer when generating
your rays!


Brought to you by Super Global Mega Corp .com