On 6/2/25 10:03, Bald Eagle wrote:
>> (*) The *_map code in all recent versions of POV-Ray can handle
>> arbitrary pattern return ranges.
> Huh?

I mean the *_map mechanism itself has long supported -inf to +inf index 
ranges. It is the 'pattern modifier' code in front of it which does not 
- in official releases of POV-Ray (*).

The yuqk fork has 'function_interval' which supports a -1 to 1 range 
along with all the other existing pattern modifiers; plus 'raw_wave' 
which bypasses the 'pattern modifier' code altogether'.

// yuqk is required for raw_wave
#version 3.8;
global_settings { assumed_gamma 1.0 }

#declare ElectricBlue = srgb <0.4902,0.97647,1>;
#declare ElectricBrown = srgb <0.7098,0.38431,0.34118>;
#declare ElectricCrimson = srgb <1,0,0.24706>;
#declare ElectricCyan = srgb <0,1,1>;
#declare ElectricGreen = srgb <0,1,0>;
#declare ElectricIndigo = srgb <0.43529,0,1>;
#declare ElectricLavender = srgb <0.95686,0.73333,1>;
#declare ElectricLime = srgb <0.8,1,0>;
#declare ElectricOrange = srgb <1,0.20784,0.01176>;

sky_sphere {
     pigment {
         function { +1/0 }
         raw_wave
         color_map {
             [val("-inf") ElectricBlue]
             [-9.0        ElectricLime]
             [-6.0        ElectricIndigo]
             [-3.0        ElectricCyan]
             [+0.0        ElectricCrimson]
             [+3.0        ElectricGreen]
             [+6.0        ElectricLavender]
             [+9.0        ElectricOrange]
             [val("+inf") ElectricBrown]
         }
     }
}
//---


It happens I was looking at the parametric code back in late March / 
early April at first with respect to updating my documentation with 
respect to the gradients used, but as I looked at the code I was both 
reminded of bugs/limitations and I managed to find a few more playing 
around. I'd also like the surface to be UV map-able in some standard 
way. I put the work back into my head to let things rattle around for a 
while more.

Jerome implemented the only fast, general way I know to get performance 
in a release of hgpovray38 (**). He implemented a feature that turns the 
parametric equations into a mesh prior to ray tracing - which can be 
done somewhat easily though much more slowly in today's SDL as well. And 
there are external packages for working with parametric equations too 
(with mesh output) though I've not played with any of those in years.

Bill P.

(*) - Lying a little. The potential pattern in official v3.8 implements 
'raw_wave' in a completely internal way for just that feature.

(**) - Lying a little more. Five or more years ago I created three image 
files I used directly as a kind of tri-cache, via functions as the 
parametric inputs. It worked as a speed improvement and kinda / sortof 
worked as an ugly result. The up front limitation was having no really 
deep bit depth image format. A 32 bit float format is available in the 
yuqk fork's function created color image feature as of ... sometime in 
the last year IIRC. Not gotten back to playing with parametric caching 
by image based functions using that improved bit-depth yuqk feature.

The mesh and uv range caching, of course, are always approximating the 
parametric with respect to a good double float calculated result.

Bill P.

Post a reply to this message