> Gilles Tran <gitran_nospam_@wanadoo.fr> wrote:
>>>  I don't remember seeing even one single post suggesting some concrete
>>> rendering algorithm idea which could be implemented in povray.
> 
>> My point exactly :)
> 
>   I don't think you meant that point with the same meaning as I did...
> 
>> With all the developers currently discussing the future 
>> of POV-Ray, the major selling point of a renderer (i.e. rendering quality) 
>> is mysteriously absent. And when one person dares showing up with some 
>> interesting ideas and a working piece of software, the poor guy gets told 
>> off because he *** gasp *** made the mistake of pressing twice on the send 
>> key.
> 
>   I think POV-Ray needs new algorithms which will make it produce prettier
> pictures *faster*, not slower. You said it yourself that the algorithms used
> in that program may produce cool results, but you could take a trip around
> the world in a boat before the image is ready.
> 
>   I'm not saying POV-Ray couldn't benefit from this. I'm saying that POV-Ray
> would benefit *more* from algorithms which make it faster, and thus they
> should have a higher priority.
> 
>> Implementing them is certainly challenging, but finding interesting 
>> algorithms and looking at their various practical implementations is not.
> 
>   As I said, it's easy to suggest all kinds of features, but there doesn't
> seem to be many volunteers for actually doing the hard work of studying the
> algorithms and presenting some concrete proposals on how to embed them in
> POV-Ray.
> 

I personally want quality. And easy-to-distribute radiosity. If I want 
speed I can use my renderfarm. Radiosity is unusable on it, you know 
what happens if you render an image in tiles with (current) POV-Ray 
radiosity: brightness differences between tiles.

Post a reply to this message