Thanks, Alex.  MotionBlur wasn't what I thought it was.  Does anyone know
of a program that does post processing motion blur without having to render
5 or 10 times the number of frames?  I don't want to used the motion_blur
{} megapov thing 'cause it's way too slow.
Tia!

-- 
H.E. Day
<><

Post a reply to this message

H. E. Day <Pov### [at] aolcom> wrote:
: Does anyone know
: of a program that does post processing motion blur without having to render
: 5 or 10 times the number of frames?

  It's not possible to calculate post-process motion blur.

  Well, ok, you can calculate _something_, but it's extremely limited:

  - Only motion blur of an object moving exactly parallel to the viewing
    plane and facing exactly the camera all the time. No motion blur of
    an object moving also in the depth-axis nor changing position with
    respect to the camera, nor rotating, nor changing shape, nor changing
    other features (like color, brightness)... Just think about a rolling
    pool ball...

  - Post-processing can't use sub-pixel information and thus the result will
    be more coarse (it's the same difference as the antialiasing made by
    povray, which calculates sub-pixel information by sending more rays per
    pixel, compared to just blurring the non-antialiased image afterwards
    with a painting program).

  - If some other object reflects or refracts this moving object, the
    reflection/refraction of the object will not be motion-blurred.
    If the object is behind a transparent object, it can't be blurred
    correctly. Specially if the moving object is partially behind a
    transparent object, the blurring will be horribly wrong.

  - If the moving object is partially transparent, the scene seen through the
    transparent part will be wrongly blurred (shouldn't be blurred at all
    if the scene is static). Also if the object is reflecting, the reflection
    will be wrongly blurred.

:  I don't want to used the motion_blur
: {} megapov thing 'cause it's way too slow.

  The motion blur in megapov is suprisingly fast.
  Ok, if your moving object is very complicated and takes a lot of time
to trace even without motion blur and it takes a lot of image area, then
the motion blur makes it slower, of course. However, it will still be faster
than calculating n frames and averaging them.
  For simple objects which render fast, the motion blur in megapov is just
excellent.
  The syntax of the motion blur of megapov makes it also very easy to
calculate the exact amount of blurring per frame (ie. it simulates the time
the shutter is open). By other methods you would have to calculate the
amount of blurring by hand. This can be pretty hard if the motion of the
object is not constant.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

|   It's not possible to calculate post-process motion blur.

Untrue.  Take a look at the link:
http://www.revisionfx.com/mblur.htm 
And you will see that pp motion blur is indeed possible (if not desirable).
 As for objects only moving according to the camera plane, I guess you've
never used photoshop.  There is a  filter - radial blur - that allows you
to do rotation and zooming blurs, all very fast.  All I'm looking for is a
freeware product to do the same thing in a animation.
Hope that explains what I'm looking for a bit better.

H.E. Day
<><

Post a reply to this message

On 23 Nov 2000 16:51:51 -0500, "H. E. Day" <Pov### [at] aolcom> wrote:

>And you will see that pp motion blur is indeed possible (if not desirable).
> As for objects only moving according to the camera plane, I guess you've
>never used photoshop.  There is a  filter - radial blur - that allows you
>to do rotation and zooming blurs, all very fast.  All I'm looking for is a
>freeware product to do the same thing in a animation.
>Hope that explains what I'm looking for a bit better.

Maybe The GIMP can help you.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

H. E. Day <Pov### [at] aolcom> wrote:
:  As for objects only moving according to the camera plane, I guess you've
: never used photoshop.  There is a  filter - radial blur - that allows you
: to do rotation and zooming blurs, all very fast.

  Since photoshop can't create new information from the 3D-object from a
2D image, the rotation will always be limited to a rotation parallel to
the viewing plane.
  This is seldom the case. Just think about the rolling pool ball. You will
probably not make it roll exactly parallel to the viewing plane.
  The point is that when the object rotates, new features from the "other
side" will become visible while other details in the other end of the
object will rotate behind the object.
  For example, think about the number in the pool ball. At the beginning of
the motion-blur path the number may be just in the other side of the ball
(and thus not visible) and when the ball rotates the number comes to the
visible side.
  No 2D-program can generate this kind of extra information to a 2D image.

  As for the zooming blur, you forget that zooming and moving the object
in the depth-axis are two completely different things.
  When you zoom, you are just scaling the 2D image bigger or smaller. No
new details are calculated.
  However, when you move an object in the depth-axis, the shape of the
object is changed due to perspective. An object very near to the camera has
a different shape than an object far away from the camera. For example, if
you look at the earth from very close distance, you can see only eg. 10% of
its surface. If you look at the earth from far away, you can see a bit less
than 50% of its surface.
  This means that moving an object in the depth-axis can bring more information
or hide some information (or both).
  Again, no 2D-program can do this.

  Another thing is that when an object is moving, it can go partially behind
another object (or come from behind another object). Again, no 2D-program
can simulate this.

  And all what I said in my previous article...

  And as I said, megapov's motion blur is just magnificent. Incredible.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

>   It's not possible to calculate post-process motion blur.
[snip the limited cases where it's possible to simulate it]

	I recently found a page talking about some possible method
which should have been implemented and tested. Unfortunately, neither
algo is discribed in detail, nor source-code is available...

http://techweb.kingston.ac.uk/research/vision/foci/postprod.html

	The whole page is interesting, some funny MPEG-1 animations.
You also can directly jump to the "Motion blur" section.


*** Nicolas Calimet
*** http://pov4grasp.free.fr

Post a reply to this message

|   And as I said, megapov's motion blur is just magnificent. Incredible.
Warp, warp. My man.

Which do you think I'll be more likely to use, complex objects or simple
ones?

Uh-huh.

It's me, buddy. :)
--
H.E. Day
<><

Post a reply to this message

In article <01c05674$40cdd440$617889d0@daysix>, "H. E. Day" 
<Pov### [at] aolcom> wrote:

> Which do you think I'll be more likely to use, complex objects or simple
> ones?

Complex ones. Which means it is even more likely that post_process 
"motion blur" won't do what you want.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

"H. E. Day" <Pov### [at] aolcom> wrote in message
news:01c05674$40cdd440$617889d0@daysix...
> |   And as I said, megapov's motion blur is just magnificent.

    Too right, accept for the fact that you can't do something like this :

#declare foo=
pigment { color clock }

motion_blur {
 sphere { 0 1 pigment { foo } }
}

--
Scott Hill.
Software Engineer.
E-Mail        : sco### [at] innocentcom
PGP Key       : http://pgpkeys.mit.edu:11371
Pandora's Box : http://www.pandora-software.com

*Everything in this message/post is purely IMHO and no-one-else's*

Post a reply to this message

In article <3a2196f5@news.povray.org>, "Scott Hill" 
<sco### [at] innocentcom> wrote:

> "H. E. Day" <Pov### [at] aolcom> wrote in message
> news:01c05674$40cdd440$617889d0@daysix...
> > |   And as I said, megapov's motion blur is just magnificent.

Actually, Warp said that. :-)


> Too right, accept for the fact that you can't do something like this :
> 
> #declare foo=
> pigment { color clock }
> 
> motion_blur {
>  sphere { 0 1 pigment { foo } }
> }

Actually, that is a good thing...motion blur is only applied to what you 
specify it for, which is far better than having it applied to 
everything, whether or not you want it. Maybe if "blur_clock" was used 
instead of "clock" this would be less confusing...a warning or error 
could be generated when it is used outside of a motion blur block.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Well, perhaps a 'blur_clock' might be useful, but if I have understood it
correctly, it would not fit in the ideology of the motion blur syntax.

  As far as I have understood it, you just make an animation as usual,
eg:

...
object
{ MyObject
  #if(clock<.5)
    translate <clock*clock*10, clock, 0>
  #else
    translate <clock*10+2.5, .5, 0>
  #end
}
...

  Then, if you want motion blur, you just enclose the moving object with
the motion_blur block:

...
motion_blur
{
  object
  { MyObject
    #if(clock<.5)
      translate <clock*clock*10, clock, 0>
    #else
      translate <clock*10+2.5, .5, 0>
    #end
  }
...

and set a proper global_settings at the beginning of the file. Eg:

global_settings { 10, clock_delta }

  You don't have to do anything else. That's enough. And you get a perfect
motion blur which takes into account the amount of movement in each
frame.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <3a22146e@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Well, perhaps a 'blur_clock' might be useful, but if I have understood 
> it correctly, it would not fit in the ideology of the motion blur syntax.

Perhaps, but it seems to confuse people that things outside the 
motion_blur block don't get blurred(Why? I don't know...). A 
"blur_clock" keyword would make the difference in what is happening 
clearer, though it wouldn't actually add any functionality. Well, it 
would make some things a little more convenient, you wouldn't have to 
save the clock value in a variable to use in things you don't want 
blurred any more...
Blurring something wouldn't be much harder, you would just have to 
replace "clock" with "blur_clock" in addition to enclosing the object 
with a motion_blur block. On the other hand, it might cause problems 
with include files or macros that use clock directly...it probably isn't 
worth adding.


> and set a proper global_settings at the beginning of the file. Eg:
> global_settings { 10, clock_delta }

That's not a proper global_settings...you forgot "motion_blur" before 
the 10. :-)

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

"Chris Huff" <chr### [at] maccom> wrote in message
news:chrishuff-DDBD75.16570227112000@news.povray.org...
> In article <3a22146e@news.povray.org>, Warp <war### [at] tagpovrayorg>
> wrote:
>
> >   Well, perhaps a 'blur_clock' might be useful, but if I have understood
> > it correctly, it would not fit in the ideology of the motion blur
syntax.
>
> Perhaps, but it seems to confuse people that things outside the
> motion_blur block don't get blurred(Why? I don't know...).

    Well, try rendering the 'Motion Blur.pov' file that I've posted in
povray.text.scene-file - once with motion_blur on and then with motion blur
turned off (just comment out the motion blur line in global_settings{...})
(actually you only need render the first couple of frames each time - the
problem can still be seen clearly). Compare the two results and you'll see
that the motion blurred version is all wrong - the movement of the sphere is
taken into account, but the rotation on the pigment isn't.

    The problem is that you can't do :

#declare foo=
motion_blur {
 pigment {...
}

or even :

motion_blur {
#declare foo=
 pigment {...
}

See ? Of course, in this simple example, if you move the full pigment
definition into the sphere you get correct motion_blur, but what if you have
50000 spheres, all using the foo pigment ?

This is only a very simple example, but it highlights a very annoying
'feature' of MegaPOVs motion_blur implementation.

--
Scott Hill.
Software Engineer.
E-Mail        : sco### [at] innocentcom
PGP Key       : http://pgpkeys.mit.edu:11371
Pandora's Box : http://www.pandora-software.com

*Everything in this message/post is purely IMHO and no-one-else's*

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
:> global_settings { 10, clock_delta }

: That's not a proper global_settings...you forgot "motion_blur" before 
: the 10. :-)

  Oops! :)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <3a233819$1@news.povray.org>, "Scott Hill" 
<sco### [at] innocentcom> wrote:

> Compare the two results and you'll see that the motion blurred version 
> is all wrong - the movement of the sphere is taken into account, but 
> the rotation on the pigment isn't.

No, the motion blurred version is still correct...the "foo" pigment 
isn't in the motion_blur block, so it shouldn't be blurred any more than 
the motion of the object it is applied to blurs it. If you put it in the 
same block as the sphere you will get the results you expect. Being able 
to decide exactly which things get blurred is a very useful feature...it 
might actually have been easier to implement things so the whole scene 
file was parsed multiple times, without using motion_blur blocks, but 
that would slow things down, require more memory, cause a lot of 
redundant data, and be less flexible.


>     The problem is that you can't do :
> #declare foo=
> motion_blur {

Yes, this could be a problem...it would probably be a good idea to 
completely disallow using the motion_blur keyword in a #declare or 
#local statement, and output a warning when you use variables within a 
motion_blur block, that they are only useful in that same block. Maybe 
make them local to the block instead of/in addition to outputting a 
warning.


> See ? Of course, in this simple example, if you move the full pigment 
> definition into the sphere you get correct motion_blur, but what if 
> you have 50000 spheres, all using the foo pigment ?

Then you put 50000 spheres in the motion_blur block...and pray you have 
enough memory to render 50000 motion_blurred spheres.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

"Chris Huff" wrote:
> If you put it in the same block as the sphere you will get the
> results you expect. Being able to decide exactly which things
> get blurred is a very useful feature...
>
> Then you put 50000 spheres in the motion_blur block...and pray you have
> enough memory to render 50000 motion_blurred spheres.

But what do I do if I truly want all objects in my scene to be blurred?
My scene is very complicated, so putting a motion_blur block around every
object is not an option. And when I try to put a single motion_blur block
around my entire scene I get the following error:

object <----ERROR

character.inc:555: error: No matching } in motion_blur, object found
instead.

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" <run### [at] inamecom> wrote in message
news:3a255cee@news.povray.org...
>
>                                 ....when I try to put a single motion_blur
block
> around my entire scene I get the following error:
>
> object <----ERROR
>
> character.inc:555: error: No matching } in motion_blur, object found
> instead.
>

    I wasn't even aware of that, I am now though. Any more coals out there
for the fire ?

See my reply to Chris for more...

--
Scott Hill.
Software Engineer.
E-Mail        : sco### [at] innocentcom
PGP Key       : http://pgpkeys.mit.edu:11371
Pandora's Box : http://www.pandora-software.com

*Everything in this message/post is purely IMHO and no-one-else's*

Post a reply to this message

"Chris Huff" <chr### [at] maccom> wrote in message
news:chrishuff-4C4199.06002529112000@news.povray.org...
> In article <3a233819$1@news.povray.org>, "Scott Hill"
> <sco### [at] innocentcom> wrote:
>
> > Compare the two results and you'll see that the motion blurred version
> > is all wrong - the movement of the sphere is taken into account, but
> > the rotation on the pigment isn't.
>
> No, the motion blurred version is still correct...the "foo" pigment
> isn't in the motion_blur block, so it shouldn't be blurred any more than
> the motion of the object it is applied to blurs it. If you put it in the
> same block as the sphere you will get the results you expect.

    Sure, but, because the sphere is defined as having the foo pigment, does
it not make sense that the animation on the pigment should get blurred along
with the motion of the sphere ? Basically, IMO, the implementation of
motion_blur {...} is not as intuitive as it could be, nor is it consistent
with much of the rest of POV's script language - e.g. if I insert a scale
statement, after the pigment statement, in to the sphere block then, in an
intuitive manner, the pigment gets scaled along with the sphere.

>
Being able
 > to decide exactly which things get blurred is a very useful feature...
>

    Don't get me wrong, I have no problem with the flexibility that the
selective motion_blur brings - but should that flexibility be at the price
of the consistency and intuitiveness of the language ?

>
> >     The problem is that you can't do :
> > #declare foo=
> > motion_blur {
>
> Yes, this could be a problem...it would probably be a good idea to
> completely disallow using the motion_blur keyword in a #declare or
> #local statement

    Well, that's basically what it does now - and that's exactly the crux of
the problem.

>
> > See ? Of course, in this simple example, if you move the full pigment
> > definition into the sphere you get correct motion_blur, but what if
> > you have 50000 spheres, all using the foo pigment ?
>
> Then you put 50000 spheres in the motion_blur block...and pray you have
> enough memory to render 50000 motion_blurred spheres.
>

    Well, I'd use a #while loop, but that's getting off the point... Maybe
that should have read "but what if you have a library of 50000 different
objects and you want to show one copy of each object, all using the same foo
pigment ?" Apply motion blur and a _copy_ of the foo pigment to each of the
50000 objects or just wrap the lot up in one big motion blur statement and
use a #defined foo pigment - which is more intuitive, which is more
consistent with the rest of the language and which is easier/quicker to
use/write ? Hmm, I know which I'd pick.

--
Scott Hill.
Software Engineer.
E-Mail        : sco### [at] innocentcom
PGP Key       : http://pgpkeys.mit.edu:11371
Pandora's Box : http://www.pandora-software.com

*Everything in this message/post is purely IMHO and no-one-else's*

Post a reply to this message