"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