Am 06.07.2012 16:47, schrieb Cousin Ricky:
> clipka<ano### [at] anonymousorg> wrote:
>> Am 06.07.2012 02:22, schrieb Cousin Ricky:
>>> clipka<ano### [at] anonymousorg> wrote:
>>>> If we're talking about dull surfaces, then mu - as stated above, POV-Ray
>>>> does not natively support dull (aka blurred) reflections.
>>> This is probably not a good idea (yet?) anyway. Best to let the users weigh the
>>> various methods and tradeoffs.
>> Well, I personally think blurred reflections are a /great/ thing to
>> have. They can really make or (in case of their absence) break a scene
>> (especially if they're in tune with the highlights parameters).
> I agree; I just don't know that we've agreed upon the best way to implement it.
It seems plain as hell to me that the only reasonable way to implement
it is some kind of oversampling with jitter added to the reflected ray.
And it seems also plain as hell to me that the only reasonable way to
handle the resulting heavy blow on render performance is to integrate
all oversampling-based mechanisms into one bigger picture, encompassing
anti-aliasing, focal blur, media, fog, area lights, subsurface light
transport, and blurred reflections/refractions. As it is now, all of
these features do their own full-blown oversampling, thus having a fully
multiplicative effect on render time each, even though oversampling
could be much more "lazy" whenever additional oversampling is performed
somewhere "closer" to the camera anyway.
That, in my opinion, is the only reasonable way to implement it.
As for syntax, parameterization should obviously make it easy to
properly "synchronize" reflection and highlight parameters, ideally in
such a way that the very same values used in both the reflection
"blurriness parameter" and specular roughness produces the most
realistic match (not the phong_size BTW, as specular highlights are the
better choice when it comes to realism); adding fresnel support for
highlights would be highly desirable as well.
Some additional parameters might be added to control the oversampling,
though I think they can just as well be deduced from the blurriness and
strength of reflection.
All in all, aside from the choice of keywords and other syntax details,
I think that after giving it thorough thought, there are no notable
things to disagree about.
(Speaking of Syntax, copying the MCPov one for the sake of scene
portability is definitely a no-go; not only is it far away from all
traditional POV-Ray syntax patterns - it also uses a totally
intransparent "blurriness" parameterization, and the oversampling
parameterization is rather poor as well.)
Post a reply to this message