"Bob H."
<per### [at] aolcom?subject=PoV-News:%20&body=Relating%20to%20POV-Ray:%2
0> wrote in message news:39ea8227@news.povray.org...
> The red background, bad thing for jpg type (lossy) compression.
> The blurring looks good.  Not terrible at 9 minutes a frame, not
wonderfully
> quick either.  As I understand it the blur is pretty much a multiple
render,
> no real optimization I don't think anyway.  I'm sure more of such
animations
> would be tried by people were it fast.  Good luck on it.

Thanks for the info Bob. I got your post when only 4 frames into the anim,
so I was able to alter the background colour.
Yeah, a multiple render I believe, the object is parsed many times, 25 in
this case. Maybe overkill, but I wanted super-smooth blur.

All the best,

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

Not bad! My tests with tornados has me using 150+ samples for the blur. More
because I didn't want to use a high fidelity object for the funnel. When I
was doing props I kept the count between 16 and 32.

Grim

Post a reply to this message

BigCeef wrote:

> Well, I was just experimenting further, and I found that by replacing the
> 4x4 area light with a point light, the render time per frame fell from 50
> mins to 9 mins! No way did I expect the area_light to hit render time so
> badly. Must be the way the motion_blur is calculated.

Dude try 16 point lights & U will see that area lights are implemented as point
lights - or just rifle through the docs/src
--
Bye
Pabs

Post a reply to this message

BigCeef wrote:
> 
> Ok. Not a fascinating image, but my first play with motion blur. I'm really
> pleased. It's part of a 50 frame anim which I've yet to render... and at 50
> mins per frame on my p200, I'm not looking forward to it... hehe
> 

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.
Here, a much more practical solution is to render the frames without motion
blur, and then average a number of consecutive frames together to get the
blurring. One utility that can do this is Warp's Targa averager:
http://www.students.tut.fi/~warp/PovUtils/average/

-- 
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" <mar### [at] peakeduee> wrote in message
news:39EAECAB.FD3EE0AA@peak.edu.ee...

> 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.
> Here, a much more practical solution is to render the frames without
motion
> blur, and then average a number of consecutive frames together to get the
> blurring. One utility that can do this is Warp's Targa averager:
> http://www.students.tut.fi/~warp/PovUtils/average/


Yeah, I agree...that's the method I've always used previously...I just
wanted to try this out.

The anim's finished, and can be seen in slightly modified form, at:

www.mariner9.fsnet.co.uk/Art/motion-test.htm

All the best,

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

I can hear it "Whirling" now... =)




BigCeef wrote:

> Ok. Not a fascinating image, but my first play with motion blur. I'm really
> pleased. It's part of a 50 frame anim which I've yet to render... and at 50
> mins per frame on my p200, I'm not looking forward to it... hehe
>
> I'll post it at my site when it's done.
>
> All the best,
>
> 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.
>
>  [Image]

Post a reply to this message

On Mon, 16 Oct 2000 18:21:02 +0800, Pabs wrote:
>BigCeef wrote:
>
>> Well, I was just experimenting further, and I found that by replacing the
>> 4x4 area light with a point light, the render time per frame fell from 50
>> mins to 9 mins! No way did I expect the area_light to hit render time so
>> badly. Must be the way the motion_blur is calculated.
>
>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.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

"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