>> 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
No one was suggesting to implement /all/ of them. Request was to have
just /one/ way of doing blurred reflection implemented "natively" into
> 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
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
Post a reply to this message