POV-Ray : Newsgroups : povray.pov4.discussion.general : Feature Adjustments: Area lights and Jittered Reflection/Refraction Server Time
29 Mar 2024 01:49:32 EDT (-0400)
  Feature Adjustments: Area lights and Jittered Reflection/Refraction (Message 6 to 15 of 15)  
<<< Previous 5 Messages Goto Initial 10 Messages
From: Warp
Subject: Re: Feature Adjustments: Area lights and Jittered Reflection/Refraction
Date: 22 Mar 2010 16:20:29
Message: <4ba7d10c@news.povray.org>
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

From: clipka
Subject: Re: Feature Adjustments: Area lights and Jittered Reflection/Refraction
Date: 22 Mar 2010 19:09:50
Message: <4ba7f8be$1@news.povray.org>
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

From: Warp
Subject: Re: Feature Adjustments: Area lights and Jittered Reflection/Refraction
Date: 23 Mar 2010 15:14:31
Message: <4ba91317@news.povray.org>
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

From: clipka
Subject: Re: Feature Adjustments: Area lights and Jittered Reflection/Refraction
Date: 23 Mar 2010 17:02:34
Message: <4ba92c6a@news.povray.org>
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

From: scott
Subject: Re: Feature Adjustments: Area lights and Jittered Reflection/Refraction
Date: 24 Mar 2010 04:19:35
Message: <4ba9cb17$1@news.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

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

From: John VanSickle
Subject: Re: Feature Adjustments: Area lights and Jittered Reflection/Refraction
Date: 24 Mar 2010 20:57:58
Message: <4baab516$1@news.povray.org>
clipka wrote:

> 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.

Pixar's docs indicate that shooting one reflected ray and/or one 
refracted ray for each intersection that has reflection and/or 
refraction in the shader, and one shadow ray for each intersection for 
each light source, is enough; anti-aliasing is accomplished by jittering 
the light sources and the reflected and refracted rays, and setting the 
overall anti-aliasing level high enough to reduce granularity to an 
acceptable level.

Regards,
John


Post a reply to this message

From: Warp
Subject: Re: Feature Adjustments: Area lights and Jittered Reflection/Refraction
Date: 25 Mar 2010 03:40:17
Message: <4bab1361@news.povray.org>
John VanSickle <evi### [at] hotmailcom> wrote:
> Pixar's docs indicate that shooting one reflected ray and/or one 
> refracted ray for each intersection that has reflection and/or 
> refraction in the shader, and one shadow ray for each intersection for 
> each light source, is enough; anti-aliasing is accomplished by jittering 
> the light sources and the reflected and refracted rays, and setting the 
> overall anti-aliasing level high enough to reduce granularity to an 
> acceptable level.

  In order to get a grain-free smooth result, you would have to shoot
something like 50 rays per pixel or more (depending on the scene and the
amount of blurriness). Think about how long it takes for a scene to render
with that much antialiasing.

  Just sending all the reflected rays at once, however, can be much faster
in simple cases because it's done only for the reflecting surface. For example,
this image took just a few minutes to render:

  http://warp.povusers.org/pics/Rubiks_Revenge2.jpg

-- 
                                                          - Warp


Post a reply to this message

From: John VanSickle
Subject: Re: Feature Adjustments: Area lights and Jittered Reflection/Refraction
Date: 25 Mar 2010 07:56:29
Message: <4bab4f6d$1@news.povray.org>
Warp wrote:
> John VanSickle <evi### [at] hotmailcom> wrote:
>> Pixar's docs indicate that shooting one reflected ray and/or one 
>> refracted ray for each intersection that has reflection and/or 
>> refraction in the shader, and one shadow ray for each intersection for 
>> each light source, is enough; anti-aliasing is accomplished by jittering 
>> the light sources and the reflected and refracted rays, and setting the 
>> overall anti-aliasing level high enough to reduce granularity to an 
>> acceptable level.
> 
>   In order to get a grain-free smooth result, you would have to shoot
> something like 50 rays per pixel or more (depending on the scene and the
> amount of blurriness). Think about how long it takes for a scene to render
> with that much antialiasing.

The Pixar doc I'm referencing says that they usually need to sample from 
16 to 64 times for each pixel.

The doc is here:

   http://graphics.pixar.com/library/DistributedRayTracing/paper.pdf

Additionally, their method also includes adjusting the rays shot for 
motion blur and focal blur, and it turns out that the overall AA level 
needed is simply the maximum required by any of the effects in play, so 
that the total cost is no greater than that of the most expensive effect.

>   Just sending all the reflected rays at once, however, can be much faster
> in simple cases because it's done only for the reflecting surface. For example,
> this image took just a few minutes to render:
> 
>   http://warp.povusers.org/pics/Rubiks_Revenge2.jpg

Perhaps this can also be handled (and really, should be handled) by 
allowing the user to specify higher AA levels for certain areas of the 
screen that are believed to require it.  If one object has a great deal 
of fine detail, the user should be able to specify a high AA level for 
the pixels that cover it, without forcing the whole frame to be sampled 
at that high level.

It should be simple enough for a user (let's say in POV-Ray) to specify

aa_box {
   <-1,4,2>,<0,5,3>
   aa_level 5
}

and the renderer, prior to rendering scene objects, would mark the frame 
buffer so that the pixels covered by this box get sampled at an AA level 
of five instead of for the overall scene level.  If two such boxes with 
differing AA levels overlap, the overlap area is sampled at the higher 
of the two rates.

Regards,
John


Post a reply to this message

From: Warp
Subject: Re: Feature Adjustments: Area lights and Jittered Reflection/Refraction
Date: 25 Mar 2010 09:13:27
Message: <4bab6177@news.povray.org>
John VanSickle <evi### [at] hotmailcom> wrote:
> >   Just sending all the reflected rays at once, however, can be much faster
> > in simple cases because it's done only for the reflecting surface. For example,
> > this image took just a few minutes to render:
> > 
> >   http://warp.povusers.org/pics/Rubiks_Revenge2.jpg

> Perhaps this can also be handled (and really, should be handled) by 
> allowing the user to specify higher AA levels for certain areas of the 
> screen that are believed to require it.  If one object has a great deal 
> of fine detail, the user should be able to specify a high AA level for 
> the pixels that cover it, without forcing the whole frame to be sampled 
> at that high level.

  It would still be slower because the amount of rays would be doubled.

  If, for example, in the above image something like 30 rays were spawned
for each reflected ray, it means that the total amount of rays traced to
for one camera sample would be 31 rays (the ray sent from the camera plus
the 30 reflected rays sent from the surface).

  However, if there was a mechanism to say "if a ray hits this surface,
perform antialiasing in such a way that 30 reflected rays will be produced",
it would mean that 30 sample rays, instead of 1, would have to be traced
from the camera towards the surface, and for each, a reflected ray would
have been traced, making the total amount of traced rays 60 (30 rays sent
from the camera, plus 30 reflected rays), almost double than above.

  Not that being able to specify antialiasing settings on a per-object basis
is a bad idea. It's just not necessarily the most efficient way of calculating
blurred reflections in all cases.

-- 
                                                          - Warp


Post a reply to this message

From: MessyBlob
Subject: Re: Feature Adjustments: Area lights and Jittered Reflection/Refraction
Date: 19 Nov 2010 21:05:00
Message: <web.4ce72ba97d905778addfbead0@news.povray.org>
"scott" <sco### [at] scottcom> wrote:
> 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:

Neat!
I usually resort to micro-normals. This method gives a high degree of control,
but results are not perfect: it's computationally expensive to smooth out the
roughness, and surfaces always appear 'bitty' with adaptive anti-aliasing, the
only workaround being to force more rays with focal blur, or to render a larger
image size than is finally needed, then re-sample down.

When thinking about prospective extensions to POV-Ray, I always think "How would
this 'exception branching' affect the speed of the core renderer for all the
other functions?"  The decision of whether to implement a specific feature has
to rely on the answer to the questions:
a) "Will scene rendering time improve for most users for most scenes?" and
b) "Will the quality of the render be better than it can currently be?"

If the answer to both is "yes", then there's a fairly good case for inclusion.

As an extension to the above questions, I also wonder how fast a stripped-down
POV-Ray would be, if all the conditional branches (that are not relevant to a
scene) are removed from the code. The natural end-point of this line of thought
it 'JIT compilation', which would allow more 'specialisations' to be included
without affecting generic performance - and this is where the seemingly opposed
approaches (generic outsourcing to implicit shaders, and optimising for
specialised needs) need not be opposed! :o)

p.s. I speak as if I have contributed to POV-Ray code; I haven't. This is just
my 'developer brain' applying to POV-Ray.


Post a reply to this message

<<< Previous 5 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.