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