On 9/21/21 8:05 PM, Samuel B. wrote:
> ... Is there a binary of povr for Windows, or am I just not seeing it?

No, it's a linux / unix / macos only effort. I don't use windows.

Further, I only once in a while publish a tarball(1) that you currently 
have to compile yourself. I've not yet gotten to what I want to be my 
initial, public, git repository. It's my playpen, but hope some find 
bits of the play/work useful.

(1) - To povray.binaries.programming

>> because my povr branch now doesn't allow srgb channel specifications
>> outside the 0-1 range.
> Is that why the image is darker overall? 
Yes.

(Why the clamping, btw?)

It isn't about clamping values, but rather restricting the srgb* keyword 
use to values which make sense. There is an underlying equation - and it 
runs for any input channel value - but only values in the [0..1] range 
make sense.

//--- Limit srgb use to [0..1] range!
#version 3.8;
global_settings {assumed_gamma 1.0}

#declare RGBSun  = srgb 1.30*<2, 1.99, 1.97>;
#declare RGBSun_0 = rgb 1.30*<2, 1.99, 1.97>;
#declare RGBSun_1 = rgb 4.58*<2, 1.99, 1.97>;
#declare RGBSun_2 = srgb <2.0, 0.9, 0.8>;
#declare RGBSun_3 = srgb <2.0,-0.9,-1.8>;

#declare SRGBSun  = srgb <1.0, 0.45, 0.4>;
#declare RGBSun_4 = 9.16*SRGBSun;

#debug "\n"
#debug concat("srgb 1.30*<2, 1.99, 1.97> = rgb <",
     vstr(3,RGBSun,",", 0,-1),">\n")
#debug concat("rgb  1.30*<2, 1.99, 1.97> = rgb <",
     vstr(3,RGBSun_0,",", 0,-1),">\n")
#debug concat("rgb  4.58*<2, 1.99, 1.97> = rgb <",
     vstr(3,RGBSun_1,",", 0,-1),">\n")
#debug concat("srgb      <2.0, 0.9, 0.8> = rgb <",
     vstr(3,RGBSun_2,",", 0,-1),">\n")
#debug concat("srgb      <2.0,-0.9,-1.8> = rgb <",
     vstr(3,RGBSun_3,",", 0,-1),">\n")
#debug "\n"
#debug concat("9.16*SRGBSun              = rgb <",
     vstr(3,RGBSun_4,",", 0,-1),">\n")
#debug "\n"

#error "Parsing test. Stop early."
//---

> 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?
Yes, I expect you are correct.

Attaching another image. Here playing with one of the prototype normal 
patterns in povr's bevy normal wrapper. It's kind of a non-drifting(1) 
wrinkles rotation about a specified axis (or was it toward a point...). 
Anyhow, it's perturbing/mangling the normal and for the image use a 
negative bump to intentionally 'sometimes' invert the normals. Doesn't 
represent anything real, but I think it looks neat! :-)

(1) - Elsewhere I posted about our current "normal wrinkles pattern bias."

Bill P.

Post a reply to this message

Attachments:
Download 'sam_bevy_normal_6_negbmp.jpg' (49 KB)

Preview of image 'sam_bevy_normal_6_negbmp.jpg'