Ilya Razmanov <ily### [at] gmailcom> wrote:

> Too many math operators in a row make it difficult for me to remember
> "what was that and what I did it for?" Besides, it allows non-continous
> functions to be created, which, in my particular case, is a disadvantage
> - I'm not going to think of what POVRay will do in areas where function
> is not defined, and debug all this.

You can always just use POV-Ray itself to graph your functions, and then you
will know exactly what will happen.

https://news.povray.org/povray.binaries.images/thread/%3Cweb.5926c5ddec053131c437ac910%40news.povray.org%3E/?ttop=44359
4&toff=900

https://news.povray.org/povray.text.scene-files/thread/%3Cweb.5926c60f1312c693c437ac910%40news.povray.org%3E/?ttop=4435
39&toff=100

https://news.povray.org/povray.text.scene-files/attachment/%3Cweb.5926c60f1312c693c437ac910%40news.povray.org%3E/graphf
unction.pov.txt

- BW

Post a reply to this message

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 - 
your suggest a start.

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 
interpolation more or less for free.

How to more easily handle collections of functions / function code is an 
aim for the yuqk fork. All makes me think implementing Ingo's gradient 
macro collection as an inbuilt function collection, sooner rather than 
later, would be good. Especially, if I get back to playing with 
f_morph2to9fncts() and similar.

Bill P.

Post a reply to this message