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
"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
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
Again, determining where to spawn new rays is not the heaviest process in
Post a reply to this message