Warp schrieb:
> John VanSickle <evi### [at] hotmailcom> wrote:
>> Currently, it appears that while shadow calculations are based on the 
>> position of individual lights in the area light, shading calculations 
>> are based strictly on the center point of the area light, which means 
>> that the diffuse lighting and highlights will appear as if based on a 
>> point light source.  Shading should be calculated based on the location 
>> (including adjustment for jitter) of each sub-light in an area light.
> 
>   Try using the 'area_illumination' keyword in POV-Ray 3.7.

Not complete though, as described in feature request FS#46 
("area_illuminate in area lights is not taking fade_distance into 
account", see bugs.povray.org)

>> Thirdly (and I am sure that this has already been suggested), allowing 
>> jitter of reflected and refracted rays would very easily implement 
>> blurred reflections and refractions, making some nice effects available 
>> (with a sufficiently high anti-aliasing level in the overall render). 
> 
>   Try
http://wiki.povray.org/content/Knowledgebase:Language_Questions_and_Tips#Topic_13

... which would be a good answer to a user asking how such an effect 
could be achieved in current POV-Ray, but pretty much misses the mark as 
a response to a feature request for POV-Ray 4.

I do pretty much agree with the OP. Especially, it would be desirable to 
have some way of simulating blurry refraction/reflection without either 
(a) requiring to render the scene N times and averaging the resulting 
shots, or (b) exponentially increasing secondary, tertiary and N-ary 
rays (as well as shadow rays for area light sources) like the "Topic 13" 
solution does.

The idea behind this is that it is no good to shoot e.g. approx. 4 
prinary ray for each pixel (for AA), but 4x10 = 40 secondary rays for 
first blurred reflection, 4x10x10 = 400 tertiary rays for second blurred 
reflection, and maybe another 4x10x10x10 = 4000 shadow test rays for 
area lights, when you could instead shoot e.g. 20 primary rays, 20x2 = 
40 secondary rays, 20x2x2 = 80 tertiary rays, and 20x2x2x2 = 160 shadow 
test rays.

(Note also that primary ray intersection tests are somewhat faster than 
secondary, tertiary or N-ary ray intersection tests, due to the use of 
vista buffers.)

Or, even better yet, shoot 4 primary rays for AA, 4x10 = 40 secondary 
rays for first blurred reflection, 4x10x2 = 80 tertiary rays for second 
blurred reflection, and 4x10x2x2 = 160 shadow test rays for area lights. 
This implies that POV-Ray would keep track of the number of "path 
forks", and drastically reduce the number of N-ary rays shot after the 
ray has split up into a certain number of paths.

To implement such a scheme, it would be helpful to have a dedicated 
mechanism for blurry reflections and refractions; plus, it would also 
reduce memory consumption, be more flexible (the "Topic 13" approach 
becomes complicated when more than 255 (plus/minus 1) samples are 
desired at the first reflection), and definitely more user-friendly. And 
it's not like it would be an exotic feature for just a small number of 
users - I'm convinced that it would be commonplace if all you'd need to 
do was specify "blurry { 0.1 }" or something of similar complexity in 
the texture block (and e.g. "blurry { 0.1 samples 20,2 }" to override 
the default settings for the number of samples on first and N-th 
reflection/refraction).

I honestly see no point in /not/ having such a feature in POV-Ray. In my 
eyes, the fact that something can be achieved with more complex SDL 
constructs is not a particularly strong argument, and becomes moot or 
even absurd when such constructs lead to significantly higher computing 
time than could be achieved with a clever "native" support.

Another possible argument for not having a particular feature in POV-Ray 
would be excessive code complexity, but I don't see that for blurred 
reflection/refraction.

The last argument I can imagine is that the feature would be of benefit 
only to a small number of POV-Ray users, but I don't see that either in 
this case. If it was, why would the POV-Ray knowledgebase feature it in 
a topic?


(As a side note, I consider the "Topic 13" solution sub-optimal even for 
POV-Ray 3.x, especially with shots in which blurry-reflective/refractive 
objects take up a large amount of space in the image, and/or which use 
strong antialiasing or focal blur anyway. In such cases (and actually in 
general), I prefer to have only a single "micronormals" layer, and let 
antialiasing or focal blur alone take over the task of generating a high 
sample count.)

Post a reply to this message