POV-Ray : Newsgroups : povray.general : Motion Blur : Re: Motion Blur [NOTE : Followup-To: set to p.unofficial.patches!] Server Time
4 Nov 2024 13:02:37 EST (-0500)
  Re: Motion Blur [NOTE : Followup-To: set to p.unofficial.patches!]  
From: Scott Hill
Date: 30 Nov 2000 01:01:23
Message: <3a25ed33@news.povray.org>
"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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.