William F Pokorny <ano### [at] anonymousorg> wrote:
> 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.

Oh well. I don't blame anyone for not using Windows... Not only do we have to
pay for a license, but we're now stuck with mandatory updates whenever M$
decides it needs the community to bug test its code (which is several times a
year). (I've been thinking of eventually jumping ship to Linux. From what I
hear, compatibility with Steam games is high thanks to Proton, meaning I have
fewer reasons than ever to abandon ship.)

> Further, I only once in a while publish a tarball(1) that you currently
> have to compile yourself. (...)

Well, I won't be attempting to compile it on Windows any time soon. It would
probably require Visual Studio. I tried downloading the free version a while
back, and what an outdated, over-bloated piece of work it was, imo :S

> (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.

I'm still not sure I understand. Does the equation restrict values due to its
very nature? Or did you impose a restriction so that it doesn't produce
nonsense?

> > 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! :-)

Lots of interesting patterns in there, but I can't help but to notice that the
bright interior reflections on the lower left portion are gone.

Sam

Post a reply to this message

Alain Martel <kua### [at] videotronca> wrote:
> > (...) I originally used fade_color and supporting statements, but the
> > color was becoming too saturated. (...)
>
> If your colour get to saturated, that mean that your fade_distance is to
> short, so, just increase fade_distance as needed.
> Also, to get realistic results, fade_power need to be 1001 or 1, not 2.

That was probably the issue. I should have just kept the fade_color and added a
colorless absorbing media which would have probably made it look right.
Something to keep in mind for the next render.

Sam

Post a reply to this message

On 9/23/21 6:39 PM, Samuel B. wrote:
> I'm still not sure I understand. Does the equation restrict values due to its
> very nature? 

Well on the negative side sort of, maybe. Generally, I'd say the srgb 
decode equation mangles values outside the zero to one range making it 
hard to control - to get what you want and too easy to not get what you 
want.

> Or did you impose a restriction so that it doesn't produce
> nonsense?

Yes. I think it better users make use of rgb* keywords, where they want 
to work with values outside the 0-1 range so povr forces this.

Bill P.

Post a reply to this message