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