William F Pokorny <ano### [at] anonymousorg> wrote:

> Hi Bill,
> I'm not keeping up well with this thread, but I have a couple thoughts.

It's just some crazy experiments - no worries.   :)

> ---
>
> Remember v3.8 supports color_map blend_mode and blend_gamma modifiers
> which are internal to the color_map definition. These can skew the
> overall color_map behavior.

Yes, they can - there are always complicating factors, but we digitize and
convert things as best we can, given the constraints.   But once it's working,
it would be an interesting layer to add - importing the gamma-sdjusted values
and back-calculating what the original raw rgb values were.
If nothing else, it will be an experiment that will further solidify my
knowledge of color-handling: like all of the gamma and srgb stuff.

> On accessing color_map values out of 'accessible' range(a) we need
> updated POV-Ray source. This has been implemented in my povr fork and
> was discussed back in 2019 here (though you completely hijacked the
> thread for another useful bug/fix :-) ):
>
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5dab3f55%241%40news.povray.org%3E/

You know what they say: "Find out what you're good at, and stick with it!"  :D
I hope you like where the POVRayanese Source Code Liberation Front landed the
plane.  ;)


> (a) As you know, the *_map mechanism in POV-Ray itself has long
> supported  key/index values well outside the [0-1] range,

By "supported", I'm assuming that you mean "doesn't crash".  or "Ignores
out-of-range index values" and "wraps out of range key values back into the 0-1
range".


> but we cannot
> make use of this in any official POV-Ray release due other internal
> limitations.

Maybe we need a vogon_bypass keyword.
"It's a bypass - y'gotta build bypasses."

I have read many of the POV-Ray development discussions stretching way back -
and the long-standing goal of "fixing" things periodically percolates through my
mind.  Once again, there is no user/publicly accessible comprehensive
mission/position statement / goal checklist / idea pile / record of
in-progress/abandoned experiments and results roadmap of how all the POV-Ray
internals work (that I know of)

I'm not necessarily saying that we should do the following, but imagine that we
had such a "full" description, and somehow all of the POV-Ray source code was
lost and we had to start over from scratch.   Would it be easier to achieve the
desired goal(s) starting fresh, or are there serious things we would lose
without untangling and extracting them from the current bramble patch?

Post a reply to this message

On 2/18/23 09:01, Bald Eagle wrote:
>> (a) As you know, the *_map mechanism in POV-Ray itself has long
>> supported  key/index values well outside the [0-1] range,

> By "supported", I'm assuming that you mean "doesn't crash".  or "Ignores
> out-of-range index values" and "wraps out of range key values back into the 0-1
> range".
> 

Users of POV-Ray proper see the wrapping back into the 0-1 range 
behavior(a). This however is due the current pattern code which always 
wraps to a [0-1] repeating ramp_wave(a).

The *_map mechanism, itself, has long supported more - and this what I 
meant. We today cannot get values outside the [0-1] range to it(b) as 
raw, function return values!

Bill P.

(a) Lying a little as there is too some unfortunate one sided clamping 
code code sitting between functions and the pattern mechanism. Plus 
stepping point/value issues.

(b) The povr branch fixed (a) and is has the new waveform modifier, 
raw_wave. With it you can set up say -10 to + 10 *_maps - and make use 
of them. Related, I changed povr's inbuilt aoi pattern to allow return 
the full range of possible perturbed normals (-1 to 1) so users can 
visualize any normal inversion issues due too large bump_size settings.

Post a reply to this message