With regard to recent work by Jonathan Bush,

It occurred to me that a fairly typical and frequently used operation in
constructing scene code is the remapping of a value in one domain to a value in
another domain (typically 0 to 1).

Rather than puzzling out single-use formulas for doing such a conversion, it
would be extremely convenient, especially to new users, to have a set if inbuilt
functions specifically for this purpose.

A basic set of formulas, proposed by Freya Holmer
https://www.youtube.com/watch?v=NzjF1pdlK7Y
is suggested for use below:
//------------------------------------------------------------------------

// Freya Holmer
#declare Lerp    = function (Start, End, Value) {(1 - Value) * Start + (End *
Value)}

#declare InvLerp = function (Start, End, Value) {(Value - Start) / (End -
Start)}

#declare ReMap   = function (OldMin, OldMax, NewMin, NewMax, Value) {Lerp
(NewMin, NewMax, InvLerp (OldMin, OldMax, Value) )}

//------------------------------------------------------------------------

While hunting down this code, I found a functions.inc file by WFP that had some
internal remapping functions (presumably for use in isosurfaces in povr/yuqk)
but the accompanying documentation was pretty complex, dense and hard to follow,
but it suggests that there are other remapping schemes may be desirable.

Similarly, an example scene to demonstrate/illustrate how <u, v> values get
remapped to <x, y, z> values on a parametric surface would likely be of interest
and use to those trying to understand how uv-mapping works.

Also, IIRC, there is some spline-based animation code, perhaps written by Rune
Johansen that employs some extensive remapping functions.

The point of this thread being that certain operations widely considered to be
basic operations in computer graphics should be inbuilt in yuqk / 4.0 rather
than require an awareness of multiple include files and other external libraries
by users as part of the rather steep learning curve.
Also, the power and speed of compiled source code, and the algorithmic nature of
source-code "functions" would reduce significant frustration in trying to write
complex scene code, and make POV-Ray more attractive and competetive in the
larger computer graphics community.

- BW

Post a reply to this message