Maybe someone still remembers that I promised to experiment with 
the following idea: Instead of tracing all pixels one could try to 
interpolate some of them. 

In an effort to save rendering time (and reduce image quality as 
an unavoidable side effect), I wrote a patch for UNIX povray. 

The patch and some images (with and without interpolation) together 
with a short explanation about how it works are available at 
http://www.cip.physik.uni-muenchen.de/~wwieser/ani/povray/ipt-patch/

Please check the above page. 
I don't know if further development of this patch is worth the effort. 
Any comments or ideas welcome. 

Wolfgang

Post a reply to this message

> Please check the above page. 
> I don't know if further development of this patch is worth the effort. 
> Any comments or ideas welcome.

	The concept and realisation look pretty good, and you probably
had some hard/fun time making it, so for that matter it's worth doing
it  :-)
	However, as you admit yourself, the results are a bit frustrating,
especially for regular geometries like checker, and those weird artifacts
on projected shadows for instance. The last 'benchmark' scene renders pretty
well actually, probably because it contains less of those regular patterns.
Of course the sky looks a bit odd, but in this exemple your patch is
definitely a time-saver for reasonnable results.
	I wonder how much time one could save when testing radiosity
parameters on a complex scene... Could you rerender the benchmark.pov
with radiosity turned on ? Will it still be 66% faster ?

Post a reply to this message

Quoting myself...
>     I wonder how much time one could save when testing radiosity
> parameters on a complex scene... Could you rerender the benchmark.pov
> with radiosity turned on ? Will it still be 66% faster ?

	Does your patch actually work with radiosity ?
	(maybe I should check myself, but it's time to sleep  :-) )

Post a reply to this message

Nicolas Calimet wrote:

> Quoting myself...
>>     I wonder how much time one could save when testing radiosity
>> parameters on a complex scene... Could you rerender the benchmark.pov
>> with radiosity turned on ? Will it still be 66% faster ?
> 
> Does your patch actually work with radiosity ?
> (maybe I should check myself, but it's time to sleep  :-) )
>
Okay, I switched on radiosity: 

Vanilla povray: 
  1439.17user 4.31system 24:51.09elapsed 96%CPU

Patched povray: 
  Traced 53415 (294 invisible) of 110592 pixels (48.3%).
  814.07user 2.72system 13:49.35elapsed 98%CPU

Wolfgang

Post a reply to this message

Wolfgang Wieser wrote:

> Nicolas Calimet wrote:
> 
> 
>>Quoting myself...
>>
>>>    I wonder how much time one could save when testing radiosity
>>>parameters on a complex scene... Could you rerender the benchmark.pov
>>>with radiosity turned on ? Will it still be 66% faster ?
>>>
>>Does your patch actually work with radiosity ?
>>(maybe I should check myself, but it's time to sleep  :-) )
>>
>>
> Okay, I switched on radiosity: 
> 
> Vanilla povray: 
>   1439.17user 4.31system 24:51.09elapsed 96%CPU
> 
> Patched povray: 
>   Traced 53415 (294 invisible) of 110592 pixels (48.3%).
>   814.07user 2.72system 13:49.35elapsed 98%CPU


So, so far, it looks worst... guess we need to wait for the final result.

Post a reply to this message

Could you post the difference between the "real" and the interpolated 
images?  That could really help us see where the artifacts are.  i 
remember someone doing that on a tutorial about radiosity to show the 
exact effects radiosity was having.

Post a reply to this message

Ben Birdsey wrote:

> Could you post the difference between the "real" and the interpolated
> images?  That could really help us see where the artifacts are.  i
> remember someone doing that on a tutorial about radiosity to show the
> exact effects radiosity was having.
>
In case you already calculated the differences, feel free to send me 
the data as PNG via private e-mail :)

Wolfgang

Post a reply to this message

Nicolas Calimet wrote:

>> Please check the above page.
>> I don't know if further development of this patch is worth the effort.
>> Any comments or ideas welcome.
> 
> The concept and realisation look pretty good, and you probably
> had some hard/fun time making it, so for that matter it's worth doing
> it  :-)
> However, as you admit yourself, the results are a bit frustrating,
> especially for regular geometries like checker, and those weird artifacts
> on projected shadows for instance. 
>
Well, some artifacts may be tolerable but what happened to the checker 
on the left definitely is NOT. 

Does anybody have good ideas on how one could calculate a good aproximate 
of the image with about 6-10% of the pixels?

I read about some other people implementing "progressive evaluation" 
which means that the final image is equal to the completely traced image 
(because all pixels are actually traced) but you get a very good 
approx of the image with only 6-10% of the pixels traced. 
However, they use tricks like projecting the boundary of objects on 
the viewport. Could that be done easily with POVRay?

It would be an idea to implement just that. It would be better than 
mosaic preview and one could stop after, say 15% if one wants to create 
a rough animation. Hope this does not result in annoying flickering 
artifacts...

Wolfgang

Post a reply to this message

> However, they use tricks like projecting the boundary of objects on 
> the viewport. Could that be done easily with POVRay?

	Maybe the code for light buffers could help ? IIRC the lights
are projected on each side of the bounding boxes, so something similar
might be done for the viewport... (I never looked at this code).

Post a reply to this message

Nicolas Calimet wrote:

>> However, they use tricks like projecting the boundary of objects on
>> the viewport. Could that be done easily with POVRay?
> 
> Maybe the code for light buffers could help ? IIRC the lights
> are projected on each side of the bounding boxes, so something similar
> might be done for the viewport... (I never looked at this code).
>
AFAIK the light and vista buffers are made up of rectangles. 
But here, we would need the real object boundary, projected on the 
"film of the POV camera". 

Wolfgang

Post a reply to this message