"Margus Ramst" wrote:
> This method of motion blurring is useful for still images. But IMO it is a
lot
> of wasted effort for animations, where motion exists across frames anyway.

My logic tells me that realistic motion blur never extents that far.
"Overlapping" never occurs. I mean, in the video recorders the light can
only be projected onto one frame at a time. So if you use 25 frames per
second, the motion blur for a given frame will at most range over 1/25
second. Therefore averaging frames will not be realistic.

So if you use realistic settings for the motion blur, MegaPOV's internal
method is always faster (because non-blurred objects are only rendered
once).

Greetings,

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated October 9)
/ Also visit http://www.povrayusers.org

Post a reply to this message

Rune wrote:
> 
> My logic tells me that realistic motion blur never extents that far.
> "Overlapping" never occurs. I mean, in the video recorders the light can
> only be projected onto one frame at a time. So if you use 25 frames per
> second, the motion blur for a given frame will at most range over 1/25
> second. Therefore averaging frames will not be realistic.
> 
> So if you use realistic settings for the motion blur, MegaPOV's internal
> method is always faster (because non-blurred objects are only rendered
> once).
> 

This might be true if a) the camera doesn't move and b) non-blurred parts of the
scene take significantly longer to render than blurred parts.
With MegaPOV motion blur, you'd be rendering the blurred parts - say - 25 times
_every frame_
With the post-processing method you might need to render more frames to get a
smooth blur over a certain time interval - but not anywhere near 25 times more.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg

Post a reply to this message

Ron Parker wrote:

> >Dude try 16 point lights & U will see that area lights are implemented as point
> >lights - or just rifle through the docs/src
>
> Not true.  Try looking at the specular highlight of one sometime.  Or try
> looking at the render time with shadows off.

Then why do the docs say (& I quote)
"Rather than performing the complex calculations that would be required to model a
true area light, it is approximated as an array of point light sources spread out
over the area occupied by the light. The array-effect applies to shadows only. The
object's illumination is still that of a point source. The intensity of each
individual point light in the array is dimmed so that the total amount of light
emitted by the light is equal to the light color specified in the declaration."?
And also why do the area light functions call those for point lights?

--
Bye
Pabs

Post a reply to this message

"Margus Ramst" <mar### [at] peakeduee> wrote in message
news:39EBA039.52BAC165@peak.edu.ee...

> This might be true if a) the camera doesn't move and b) non-blurred parts
of the
> scene take significantly longer to render than blurred parts.
> With MegaPOV motion blur, you'd be rendering the blurred parts - say - 25
times
> _every frame_
> With the post-processing method you might need to render more frames to
get a
> smooth blur over a certain time interval - but not anywhere near 25 times
more.

Would not the blur be identical using either method? So that in order to
approximate the smoothness of 25 rendering passes in MegaPOV, one would need
to average 25 frames?

Andy Cocker

---------------------------------------------------------------
www.mariner9.net

..... for my music and graphics.
---------------------------------------------------------------
'I spilled spot remover on my dog. He's gone now. '
'I went to a restaurant that serves "breakfast at any time."
So I ordered french toast during the Renaissance. '

 - Steven Wright.

Post a reply to this message

"Margus Ramst" wrote:
> This might be true if a) the camera doesn't move

If the camera moves, you cannot get correct results with MegaPOV, so it does
not make sense to compare the render times in that case.

> With MegaPOV motion blur, you'd be rendering the blurred parts
> - say - 25 times _every frame_ With the post-processing method
> you might need to render more frames to get a smooth blur over
> a certain time interval - but not anywhere near 25 times more.

Please explain why. As I see it you need the same amount of samples to get
the same amount of smoothness. So you would indeed have to use 25 times more
images (which will always be slower because non-blurred objects are also
rendered extra times).

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated October 9)
/ Also visit http://www.povrayusers.org

Post a reply to this message

Pabs wrote:
> 
> Ron Parker wrote:
> 
> > Not true.  Try looking at the specular highlight of one sometime.  Or try
> > looking at the render time with shadows off.
> 
> Then why do the docs say (& I quote)
[snip]

The docs say what is Ron saying: area lights have an "area" only in shadow
calculations, specular and diffuse illumination is still that of a point light
source.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg

Post a reply to this message

BigCeef wrote:
> 
> Would not the blur be identical using either method? So that in order to
> approximate the smoothness of 25 rendering passes in MegaPOV, one would need
> to average 25 frames?
> 

Yes, it should be. They both work by averaging, but MegaPOV only traces and
averages together images of the moving object(s), the rest of the scene is
traced only once per frame.
Actually, if your camera shutter time is less than/equal to the time between
animation frames (1/FPS), disregard what I said. MegaPOV motion blur should be
faster for the same level of smoothness - unless the camera is moving, in which
case I suspect you're still better off using frame averaging.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg

Post a reply to this message

Rune wrote:
> 
> If the camera moves, you cannot get correct results with MegaPOV, so it does
> not make sense to compare the render times in that case.
> 

IIRC you can get correct results by putting your entire scene in an union and
moving it instead of the camera.

> Please explain why. As I see it you need the same amount of samples to get
> the same amount of smoothness. So you would indeed have to use 25 times more
> images (which will always be slower because non-blurred objects are also
> rendered extra times).

You're right, of course. I should have seen the bug in my logic already from
your previous post :( Strangely enough it never occurred to me to associate FPS
with camera shutter time...
Of course in practice, the motion blur effect is often exaggerated for artistic
purposes. And if shutter time is greater than clock_delta you _can_ reuse old
inter-frame samples and thus get by with less samples overall. E.g. if shutter
time is 2 x clock_delta you need 1/2 the amount of samples compared to MegaPOV
motion_blur.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg

Post a reply to this message

"Margus Ramst" wrote:
> Rune wrote:
> > If the camera moves, you cannot get correct results with
> > MegaPOV, so it does not make sense to compare the render
> > times in that case.
>
> IIRC you can get correct results by putting your entire
> scene in an union and moving it instead of the camera.

That's rather easy if you just want to fake a linearly moving camera, but it
can be difficult for other movements, and sometimes impossible, for example
if you want to change the camera angle.

> You're right, of course.

> Of course in practice, the motion blur effect is often exaggerated
> for artistic purposes. And if shutter time is greater than
> clock_delta you _can_ reuse old inter-frame samples and thus get
> by with less samples overall.

True.

Hmm, actually I think it can become even faster if you combine the internal
and external motion blur.

In MegaPOV use shutter time equal to clock_delta and don't render any
inter-frames.
Now, if you want to exaggerate the motion blur, just average the already
blurred frames externally to get them even more blurred. (The trail of blur
should match up correctly, but I haven't tested it.)

Of course that way the shutter time will always be a multiple of the
clock_delta, but I don't think that's a problem.

I'll test it now...

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated October 9)
/ Also visit http://www.povrayusers.org

Post a reply to this message

Margus Ramst wrote:
>
> The docs say what is Ron saying: area lights have an "area" only in shadow
> calculations, specular and diffuse illumination is still that of a point light
> source.


______________________________________________________________________
Kari Kivisalo                                  http://www.kivisalo.net

Post a reply to this message

Attachments:
Download 'area_point.jpg' (52 KB)

Preview of image 'area_point.jpg'