>   Why? With the "workarounds" you get a nicer result, often even faster.
It's
> also more versatile, as you can scale non-uniformly the blur amount, and
even
> make the blurring amount to follow a pattern (or function). This is not
> possible with the "hack" in megapov.

My tests, using the code from the VFAQ, indicate that the "workaround" shows
serious aliasing, is quite cumbersome to write, is slightly slower, appears
to be less accurate, and cannot be layered.  It seems to be more of a hack
in regards to complexity and end result than the reflection blur in MegaPOV.
The same averaged normal trick works in MegaPOV too, so it's not like having
reflection blur deminishes the versitility of the program at all.  This
applies to many other features in MegaPOV.  Ironically, the issue of
backward compatibility seemed to have been a higher priority in MegaPOV than
it is in 3.5, as least so far in the beta process.  I don't recall ever
having a problem rendering a 3.1 scene file in megapov.

Post a reply to this message