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