POV-Ray : Newsgroups : povray.binaries.images : Alum : Re: Alum Server Time
2 Dec 2023 19:57:56 EST (-0500)
  Re: Alum  
From: Samuel B 
Date: 21 Sep 2021 20:10:00
Message: <web.614a733fcca1de15cb705ca46e741498@news.povray.org>
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


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.