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