William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/19/21 7:09 PM, Samuel B. wrote:
> > Here's the source code (minus luminous bloom):
>
> Cool. Thank you for posting the code.
>
> I used your scene to do a little crude bench-marking of my povr branch.

Thanks, Bill. Is there a binary of povr for Windows, or am I just not seeing it?

> To create the attached image, I changed:
>
> #declare RGBSun = srgb 1.3*<2, 1.99, 1.97>;
>
> to
>
> #declare RGBSun = srgb <1, 0.99, 0.97>;
> #declare RGBSun = 2.7*RGBSun;
>
> because my povr branch now doesn't allow srgb channel specifications
> outside the 0-1 range.

Is that why the image is darker overall? (Why the clamping, btw?)

> Plus, I changed the crystal's normal to the povr branch's quilted normal
> - but still scaled very small - and aiming for a blurred reflection.

Right away I can see that the quilted pattern seems superior in this instance.
The reflection on the plane starts out much sharper, whereas the granite pattern
I used starts out way too blurry.

> Given you are using camera blur to over sample, I wanted to see how
> povr's big jitter would compare time wise. The big jitter approach took
> 2.4x longer to render at +a0.0 +am2 +r4 +j62.111 than your blur samples
> method of oversampling. I can tell from the render statistics I was too
> aggressive at r4 - as I shot roughly 2.7x more rays. I'd say the mothods
> are in the ballpark performance wise, with other differences in control
> and result which might matter or not. FWIW.

The blur is exaggerated in your render compared to mine, so perhaps the
performance would be more comparative with a reduced bump_size and lower +r
value?

Sam

Post a reply to this message