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.

Secondly, area lighting does not allow the area light to have only one 
sub-light.  This should be allowed.  The user can then use a jittered 
single-source light and higher anti-alias sampling to smooth out the 
difficulties.

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). 
The distribution of the rays should of course be variable, allowing for 
effects from perfect specular reflection (the mirror-clear reflection of 
the current version) at one extreme, to diffuse shading, all the way to 
ambient shading.

Regards,
John

Post a reply to this message

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.

> 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

-- 
                                                          - Warp

Post a reply to this message

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

clipka <ano### [at] anonymousorg> wrote:
> >   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.

  Adding jitter to reflected rays is way too specific of a request. It's once
again one of those "let's add yet another special case" to accompany the 500
special cases already in the code.

  A more generic solution which would allow doing that, among many other
things, would be much better.

  For example, one simple method to simulate a "poor man's blurred
reflection" is to weight the color of the reflected ray according to its
length: This way details which are far away from the object will be reflected
less and details which are close will be reflected more strongly. In many
situations this gives a good illusion of blurred reflection on glossy
surfaces.

  However, adding such a thing as a *specific* feature (with its own
keywords and dedicated functionality) is a bad idea. It once again clutters
the overall rendering engine with yet another tiny feature.

  I strongly oppose adding such a specific minute features. POV-Ray already
has enough minute special cases. What it needs is more generic solutions.
The generic solution can then be used to jitter the reflected rays or weight
their color according to their length, if one wants.

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:

>   For example, one simple method to simulate a "poor man's blurred
> reflection" is to weight the color of the reflected ray according to its
> length: This way details which are far away from the object will be reflected
> less and details which are close will be reflected more strongly. In many
> situations this gives a good illusion of blurred reflection on glossy
> surfaces.

Doesn't sond any less specific to me than doing it the proper way by 
jittering rqays.

>   However, adding such a thing as a *specific* feature (with its own
> keywords and dedicated functionality) is a bad idea. It once again clutters
> the overall rendering engine with yet another tiny feature.

I strongly disagree about that particular feature being "tiny".

>   I strongly oppose adding such a specific minute features. POV-Ray already
> has enough minute special cases. What it needs is more generic solutions.
> The generic solution can then be used to jitter the reflected rays or weight
> their color according to their length, if one wants.

So how would that generic does-it-all solution look like?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:

> >   For example, one simple method to simulate a "poor man's blurred
> > reflection" is to weight the color of the reflected ray according to its
> > length: This way details which are far away from the object will be reflected
> > less and details which are close will be reflected more strongly. In many
> > situations this gives a good illusion of blurred reflection on glossy
> > surfaces.

> Doesn't sond any less specific to me than doing it the proper way by 
> jittering rqays.

  Which was exactly my point. There are tons and tons of little tricks one
can use in rendering in order to get diverse effects. Adding all these little
tricks as hard-coded features (with their own keywords and their own internal
core implementations) clutters the already-cluttered core renderer more and
more.

  Instead, if a more generic solution is devised where the user can specify
how the object is rendered, it would allow the user to do things like
jittering reflected rays and/or weighting them according to their length
using one single generic feature of the core renderer. This is the idea of
pixel shaders in 3D hardware, and this is what POV-Ray needs.

  The advantage of this is that the core renderer keeps simple, and the
feature will be more versatile: Countless new variations can be added
without having to explicitly hard-code them into the core renderer. The
same generic feature could be used for a tons of other things as well
(eg. portal textures, ambient occlusion, etc etc).

  My point here is that the generic solution allows doing what he wants
(jittering reflected rays) *and* tons of other things as well. Everybody
wins.

> >   I strongly oppose adding such a specific minute features. POV-Ray already
> > has enough minute special cases. What it needs is more generic solutions.
> > The generic solution can then be used to jitter the reflected rays or weight
> > their color according to their length, if one wants.

> So how would that generic does-it-all solution look like?

  Effort should be put into designing such a "material shader" (or whatever
it might be) instead of adding more and more tiny features which just clutter
the core renderer.

  The current user-defined functions are a step towards the correct
direction. For instance, instead of adding more and more specific patterns
to the core renderer, user-defined functions (and the function patterns
which can be created from them) allow the user to create their own patterns
using mathematical expressions. This opens up countless possibilities which
hard-coded patterns don't allow. That's the right idea.

  (I'm not saying that the "material shader" feature should work exactly
like function patterns, but the *idea* is sound.)

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:

>> Doesn't sond any less specific to me than doing it the proper way by 
>> jittering rqays.
> 
>   Which was exactly my point. There are tons and tons of little tricks one
> can use in rendering in order to get diverse effects. Adding all these little
> tricks as hard-coded features (with their own keywords and their own internal
> core implementations) clutters the already-cluttered core renderer more and
> more.

No one was suggesting to implement /all/ of them. Request was to have 
just /one/ way of doing blurred reflection implemented "natively" into 
POV-Ray.

>   Instead, if a more generic solution is devised where the user can specify
> how the object is rendered, it would allow the user to do things like
> jittering reflected rays and/or weighting them according to their length
> using one single generic feature of the core renderer. This is the idea of
> pixel shaders in 3D hardware, and this is what POV-Ray needs.

I don't think POV-Ray /needs/ it.

Nor do I think that the user should have to dive deep into a complex 
shader language to achieve simple effects.

>   My point here is that the generic solution allows doing what he wants
> (jittering reflected rays) *and* tons of other things as well. Everybody
> wins.

Then why don't you clearly state from the start what direction /you/ 
suggest to go, instead of just stating something along the lines of 
"that's not the right direction"?

>   Effort should be put into designing such a "material shader" (or whatever
> it might be) instead of adding more and more tiny features which just clutter
> the core renderer.

Tell me, how would you for instance make sure that no excessive number 
of rays will be shot for blurred reflections in a shader based approach?

I think material shaders are a nice-to-have to achieve a vast number of 
effects, but there are some "essentials" that IMO should be kept in the 
core to allow for optimizations.

If you go for a swiss army knife, don't expect the best pair of scissors.

>   The current user-defined functions are a step towards the correct
> direction. For instance, instead of adding more and more specific patterns
> to the core renderer, user-defined functions (and the function patterns
> which can be created from them) allow the user to create their own patterns
> using mathematical expressions. This opens up countless possibilities which
> hard-coded patterns don't allow. That's the right idea.

... leading to comparatively slow code, yes.

I know, there are some pretty fast virtual machines out there, making 
use of just-in-time compilation and what-have-you. Still, they /do/ add 
some overhead to interface to something like POV-Ray.


I don't oppose your proposal to add some highly flexible extension 
mechanisms to POV-Ray - be it texturing, object definition or 
what-have-you - but I do oppose your proposal to "outsource" virtually 
all of POV-Ray's features to such extension mechanisms.

This is not a browser, where speed is not an issue. This is a raytracing 
software, where high performance at least in common situations is a 
necessity.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> No one was suggesting to implement /all/ of them. Request was to have 
> just /one/ way of doing blurred reflection implemented "natively" into 
> POV-Ray.

  "Jittering reflected rays" is not the same thing as "blurred reflection".

  Besides, "jittering reflected rays" is way too specific. What if you want
blurred refractions? Wouldn't those also need support for jittering? And
what is the function that defines how much the ray is jittered? Should it
be jittered evenly on a hemisphere, or should it follow some kind of cosine
weighting function?

  What if you want the amount of jittering to depend on something (such as
a pattern or the slope of the surface)?

  A more efficient way of getting blurred reflections would be for many
jittered reflected rays to be spawned on the first recursion level, but
only one on subsequent recursion levels. Wouldn't it be nice to have
support for this too?

  You can't simply keep adding individual features. You need a more generic
solution which allows the user to specify what he wants.

> >   Instead, if a more generic solution is devised where the user can specify
> > how the object is rendered, it would allow the user to do things like
> > jittering reflected rays and/or weighting them according to their length
> > using one single generic feature of the core renderer. This is the idea of
> > pixel shaders in 3D hardware, and this is what POV-Ray needs.

> I don't think POV-Ray /needs/ it.

  It needs it way more than a bunch of individual, limited features.

> Nor do I think that the user should have to dive deep into a complex 
> shader language to achieve simple effects.

  That's what include libraries are for.

> >   My point here is that the generic solution allows doing what he wants
> > (jittering reflected rays) *and* tons of other things as well. Everybody
> > wins.

> Then why don't you clearly state from the start what direction /you/ 
> suggest to go, instead of just stating something along the lines of 
> "that's not the right direction"?

  I did so from the beginning.

> >   Effort should be put into designing such a "material shader" (or whatever
> > it might be) instead of adding more and more tiny features which just clutter
> > the core renderer.

> Tell me, how would you for instance make sure that no excessive number 
> of rays will be shot for blurred reflections in a shader based approach?

  Odd question. The user specifies how many reflected rays are spawned on
each recursion level.

> I think material shaders are a nice-to-have to achieve a vast number of 
> effects, but there are some "essentials" that IMO should be kept in the 
> core to allow for optimizations.

  I don't think jittering reflected rays is such an "essential" feature.

> >   The current user-defined functions are a step towards the correct
> > direction. For instance, instead of adding more and more specific patterns
> > to the core renderer, user-defined functions (and the function patterns
> > which can be created from them) allow the user to create their own patterns
> > using mathematical expressions. This opens up countless possibilities which
> > hard-coded patterns don't allow. That's the right idea.

> ... leading to comparatively slow code, yes.

  Determining where to spawn new rays or what to do with their returned color
is not the heaviest process in raytracing.

> I don't oppose your proposal to add some highly flexible extension 
> mechanisms to POV-Ray - be it texturing, object definition or 
> what-have-you - but I do oppose your proposal to "outsource" virtually 
> all of POV-Ray's features to such extension mechanisms.

  Not all of them. Just the highly specific ones which are not so essential.

> This is not a browser, where speed is not an issue. This is a raytracing 
> software, where high performance at least in common situations is a 
> necessity.

  Again, determining where to spawn new rays is not the heaviest process in
raytracing.

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:

>> Then why don't you clearly state from the start what direction /you/ 
>> suggest to go, instead of just stating something along the lines of 
>> "that's not the right direction"?
> 
>   I did so from the beginning.

Well, actually, reading your postings again, you didn't even say /that/. 
You just replied to the OP's message, "try this" and "try that", instead 
of taking his suggestions serious.

But I don't intend to discuss this any further.

Post a reply to this message

> 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

MCPov allows you to do exactly that, using a simple "mc_reflect" keyword in 
the finish block.  It takes parameters for the number of rays to spawn and 
the "burriness" of the reflection:

http://pagesperso-orange.fr/fidos/MCPov/samples/sample_05.jpg

Personally I think MCPov style ray spawning should be included in the core 
POV, I guess the only tricky bit is figuring out a decent SDL syntax that is 
easy to use, but also allows enough flexibility.

Post a reply to this message