"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

"Scott Hill" <sco### [at] innocentcom> wrote...
>     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 ?

The issue here is the implementation.  It works by creating multiple copies
of the object (one for each time sample).  It does that by parsing the
motion_blur block multiple times.  Anything outside of the motion_blur block
is only parsed once.  This means that only one, static, copy of your foo
pigment gets created, and this static copy is applied to each copy of the
motion-blurred object.

Granted, this may not be the most intuitive, but I had a limited amount of
time to add the feature.  (I got a brainstorm, based on a suggestion by Ron
Parker, and I implemented it for the fun of it... if people find it useful,
that is a bonus.)  Enhancing the syntax to include features such as what you
ask for would be very difficult.  If anyone wants to do it, they have my
blessing.  However, I will not try that until the re-write for POV 4 gets
started.  The current code was not written with this feature in mind.

-Nathan

Post a reply to this message

"Nathan Kopp" <Nat### [at] Koppcom> wrote in message
news:3a26f8ac$1@news.povray.org...
>
> "Scott Hill" <sco### [at] innocentcom> wrote...
> >     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 ?
>
> The issue here is the implementation...
>
> Granted, this may not be the most intuitive, but I had a limited amount of
> time to add the feature...

    Sorry, I really didn't mean to attack the current implementation - I can
understand why it is the way it is - and, though I do find features of it
annoying, I can work round them. However, people were saying "use MegaPov's
motion_blur" without any caveats - I knew that MegaPov's implementation had
limitations, so felt they needed airing.

> ...However, I will not try that until the re-write for POV 4 gets
> started.  The current code was not written with this feature in mind.
>

    I thought an improved implementation might be on the cards at some
point - which was why I went on to give my opinion of what is wrong with
MegaPOVs implementation - as a programmer myself, I feel that such public
and open scrutinization and discussion of an applications feature set,
limitations and bugs can only benefit future developments of the
application - after all who's in a better position to assess software than
the users of the said software ?

--
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

"Scott Hill" <sco### [at] innocentcom> wrote...
>
>     I thought an improved implementation might be on the cards at some
> point - which was why I went on to give my opinion of what is wrong with
> MegaPOVs implementation - as a programmer myself, I feel that such public
> and open scrutinization and discussion of an applications feature set,
> limitations and bugs can only benefit future developments of the
> application - after all who's in a better position to assess software than
> the users of the said software ?

I agree.  My response was based on the issue that sometimes users are under
the impression that their suggestions will immediately become features.
This, unfortunately, is usually not possible.  I realize that you understand
the difficulty and therefore have a realistic view of the situation, so I
appreciate the discussion and suggestions.

In light of that, I wanted to let all the other users know why the
implementation will stay the way it is, despite the fact that I agree with
you that it could be improved.

-Nathan

Post a reply to this message