On 2/10/25 10:31, Bald Eagle wrote:
> Maybe some text could be sent to standard output stating that before your make
> script exits?
> 

Maybe. Let me review the INSTALL.txt file and think about it.

FWIW. On your question, I added a file called yuqk_wrapper_script to the 
shipped documentation for the next release.

...

> While working on the glory feature that CR posted, it (re)occurred to me that
> having some sort of "flag" to jimmy function / color map behaviour would be a
> useful thing.
> 
> I need to absolutely exclude certain inputs to my texture / color_map, and with
> pov-ray's value-wrapping, and real-valued function results, I find myself
> spending a lot of time trying to do clever things to use values to signify that
> I want to do things "off to the side" of what the main function is doing.
> Because I'm stuck using a mathematical function, not a macro or algorithm -
> which some languages refer to as "functions".
> 
> What I'm wondering is if there's a (future) way to set the result of a function
> like select () to NAN, i, or some other "orthogonal placeholder" that a
> color_map would just "ignore" and maybe set to something like rgbft1.

Interesting ideas as far as I understand what you want to do.

The yuqk fork's pattern value wrapping is somewhat different / extended 
compared to POV-Ray - including some internal changes on the internal 
function / pattern map interface.

We have some ability to 'jimmy map behavior' today in v3.8, but I think 
not quite what you are after.

I'll mention with function{}s you can hard code certain values. It's a 
feature I use to test maps. Rather than:

   function { Fn(...) }

code:

   function { 1/3 }

to see how a map behaves at that value. You can also use select to shift 
certain values which would normally fall within the defined map range, 
but I don't think you're asking for that.

There is too the ability to define the map indexes with functions. I 
suppose you could switch between maps that way. It would be a variation 
on code like:

#include "cfunctions.inc"
#declare Fn01 = function { pigment {
     image_map { "average_00_.jpg" ii_interpolate 2 }
     warp { repeat x flip x }
     warp { repeat y flip y }
     }
}
#declare R = 2;
#declare I = -2/4;
#declare EXP = cf_cmplx(R,I);
#declare PigMap = pigment_map {
     average // This necessary and enabled in yuqk fork
     [function { Fn01(cf_real(cf_pow(cf_cmplx(x,y),EXP)),
                      cf_imag(cf_pow(cf_cmplx(x,y),EXP)),0).red }
      color_map { [0 red 0] [1 red 3] }
     ]
     [function { Fn01(cf_real(cf_pow(cf_cmplx(x,y),EXP)),
                      cf_imag(cf_pow(cf_cmplx(x,y),EXP)),0).green }
      color_map { [0 green 0] [1 green 3] }
     ]
     [function { Fn01(cf_real(cf_pow(cf_cmplx(x,y),EXP)),
                      cf_imag(cf_pow(cf_cmplx(x,y),EXP)),0).blue }
      color_map { [0 blue 0] [1 blue 3] }
     ]
}
#declare Pig00 = pigment {
     average
     pigment_map { PigMap}
}

Bill P.

Aside : An idea / question I've had sitting in my head for some years is 
related to spectral rendering. One of the things spectral rendering 
works around is the color calculation biases within POV-Ray. In other 
words, I believe part of the better looking 'spectral result' comes from 
countering / balancing these calculation biases. I just don't know how 
big that 'due-calculation' portion of the result is.

What I'd like to try are ini / flag options which let the user 'rotate' 
a scene's color space. The resulting images would be normalized and 
combined for the final result a little like the current spectral rig. 
Someday, maybe... :-)

Post a reply to this message