POV-Ray : Newsgroups : povray.general : #switch #case in function? : Re: Using splines to map arbitrary value (was Re: #switch #case infunction?= Server Time18 Jul 2024 06:57:31 EDT (-0400)
 Re: Using splines to map arbitrary value (was Re: #switch #case infunction?=
 From: William F Pokorny Date: 19 Jun 2024 09:33:51 Message: <6672de3f\$1@news.povray.org>
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#6672de3f%241%40news.povray.org",
"headline": "Re: Using splines to map arbitrary value (was Re: #switch #case infunction?=",
"dateCreated": "2024-06-19T13:33:51+00:00",
"datePublished": "2024-06-19T13:33:51+00:00",
"author": {
"@type": "Person",
"name": "William F Pokorny"
}
}
On 6/18/24 10:02, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>
>> On your original question about #switch inside a function{} block, I saw
>> your switch by multiplication as good as anything else for clarity.
>
> WFP,
>
> I was trying to think of some additional way to lay things like this out for
> clarity, and I wondered if you might think about a way to evaluate functions in
> a structure like a color_map.
>
> Or perhaps more like a prism or a spline.
>
> Then it would be easy to see what ranges any given function would be evaluated
> in.
>
> function_map {
>       [0.0 FunctionA (x, y, z)]
>       [0.3 FUnctionA (x, y, z)]
>       [0.3 FunctionB (N)]
>       [0.7 FunctionC (j, k)]
>       [0.7 FunctionD (clock)]
>       [1.0 FunctionD (clock)]
> }
>
> What are your thoughts on this type of data structure and how much work would
> require its implementation?
>

For clarity about when each function runs an how they are interpolated -

Handling all those individual function arguments would be messy. We'd
have to deal with vector vs scalar functions. An encapsulating
performance concern is that when any map interpolates / blends you need
the value at both ends of each interpolation segment(*). Needing both
values means two function calls for each interpolation segment - whether
you need the interpolation aspect or not.

(*) Unless you are sitting on an index value or at at one of the ends of
the overall set of interpolation segments. Most implementations grab two
end values to keep the internal code simple. There is some optimization
in POV-Ray's code base; I had to fix a bug where the new to v3.8
blend_mode feature got tangled in one of those optimizations IIRC.

If the interpolations needed are not too complicated and fit into the
available blend_mode, blend_gamma mechanisms, you can implement pigments
which can be used as functions in a way similar to the way splines can
be used in functions for such a purpose.

I have a bell ringing in my head that I played with some sort of
function selection approach in years past. One based on 'gradient x'
while creating isosurfaces I think - green, ugly shapes.

We have user_defined{} pigments / density too with which something might
be doable.

There is in the fork yuqk the inbuilt f_mult1to8pairs() function, which
in part, is aimed at cleaner representations / handling of sets of up to
eight functions each having a corresponding multiplier/boolean. It was
also aimed at being more efficient, but it won't especially be so over
an in function select sequence - unless I get around to implementing
some solid method of passing function pointers into inbuilt functions.

There is too in yuqk f_morph2to9fncts() which enables all sorts of crazy
weights and normalizations of a collection of input functions. I should
get back to play more with this one! Maybe it's more animation related,
but the idea is anything from morphing a sphere into a box to maybe
including shipped shape classes with configuration options. It is,
though, not a simple or especially clean function to use at this point.
Maybe with some practice / refinement.

At the moment, I see a general, clean representation/solution to
combining functions as messy - and an significant chunk of work.

Ah, there is too the 'average' back door to using functions as indexes
which could be used in some simpler cases. Though the overall
representation isn't itself that clean as using functions as variable
weighting indexes is head twisting itself.

We can write macros as Cousin Ricky suggested with a simpler interface
which would write / compile to SDL using select(s).

The thing nice about the spline and pigment_map based approaches is so
long as the need fits into the available feature set, you get