On 2/11/25 11:17, jr wrote:
> hi,
> 
> kurtz le pirate <kur### [at] freefr> wrote:
>>
>> I think I'd have to re-run "make install" with my folder as the target,
>> but I can't see (or I didn't understand) how to do that.
> 
> I too installed yuqk in a convenient place.  write an email, I'd be happy to
> send you a build script and stuff.
> 
> 
> regards, jr.
> 

The script jr uses is good. (Thanks jr).

---

I'll quickly add for others who might see this thread, for a more 
permanent install you should not use the /tmp directory as I did in 
examples - for safety reasons. That directory is generally deleted by 
most unix/linux operating systems during the shutdown/reboot process.

Rather, create a directory somewhere under your $HOME directory where 
you do (aim) your 'make install's. For example, once, in your home 
directory execute the command:

mkdir yuqkBuilds

Then when you run the configuration command use:_a5c25dda

./configure -q COMPILED_BY=... --prefix=$HOME/yuqkBuilds/yuqk_a5c25dda

Later when you do 'make install' all the files will be copied for you 
into that --prefix specified directory. Most important for your issue, 
the 'povray' executable looks to the expected / configured install 
location  for that 'install-level' configuration file.

Lastly, it's very likely in using the yuqk fork, you will have multiple 
versions installed so a wrapper script like 'yuqk' is the way the 
'povray' executable is expected to be run / called.

All that said - there are many alternate methods to set things up. :-)

Bill P.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

> 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.

So, an interesting idea occurred to me.
We can have discontinuous color_maps with duplicate entries specifying cusps.
So how do the values at those cusps get evaluated?

I designed a color_map and a function {pigment {}} to test this.

#declare Gradient =
pigment {
 gradient x
 color_map {
  [0.00 rgbt 1]
  [0.00 rgb 0]
  [0.33 rgb x]
  [0.50 rgb x]
  [0.50 rgbt 1]
  [0.50 rgb y]
  [0.66 rgb y]
  [1.00 rgb z]
  [1.00 rgbt 1]
 }
}

#declare fG = function {pigment {Gradient}}



Results:

Val(val("-inf")) = 0.000, 1.000, 0.000, 0.000, 0.000  [huh?]
Val(-0) = 1.000, 1.000, 1.000, 0.000, 1.000
Val(0) = 1.000, 1.000, 1.000, 0.000, 1.000
Val(+0) = 1.000, 1.000, 1.000, 0.000, 1.000
Val(E) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(0.5-E) = 1.000, 0.000, 0.000, 0.000, 0.000
Val(0.5) = 1.000, 0.000, 0.000, 0.000, 0.000
Val(0.5+E) = 0.000, 1.000, 0.000, 0.000, 0.000
Val(1-E) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(-0+1) = 1.000, 1.000, 1.000, 0.000, 1.000
Val(1) = 1.000, 1.000, 1.000, 0.000, 1.000
Val(+0+1) = 1.000, 1.000, 1.000, 0.000, 1.000
Val(val("nan")) = 1.000, 1.000, 1.000, 0.000, 1.000
Val(val("+inf")) = 1.000, 1.000, 1.000, 0.000, 1.000


Some useful things, plus a puzzling one to think about / decipher in source.

- BE

Post a reply to this message

Attachments:
Download 'colormapvaluetest.pov.txt' (2 KB)

On 2/15/25 16:32, Bald Eagle wrote:
> Some useful things, plus a puzzling one to think about / decipher in source.

Are you running yuqk?

The triple 0.5 entries are not valid if you want to see all three 
values. Rather, perhaps:

   [0.50-E rgb x]
   [0.50   rgbt 1]
   [0.50+E rgb y]

With all 0.5s the middle color effectively doesn't exist in the map.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> Are you running yuqk?

Not at the moment.  Just straight 3.8.

> The triple 0.5 entries are not valid if you want to see all three
> values. Rather, perhaps:
>
>    [0.50-E rgb x]
>    [0.50   rgbt 1]
>    [0.50+E rgb y]
>
> With all 0.5s the middle color effectively doesn't exist in the map.

Well, that was part of the experiment, to see what happened.
0 and 1 work nicely.

It's the -inf that really has me puzzled!

Post a reply to this message

On 2/15/25 19:34, Bald Eagle wrote:
> It's the -inf that really has me puzzled!

Yes, it was that value which caused me to ask. :-)

What I remember is official POV-Ray had code, beyond the pattern-value 
modification code itself, which changed / mangled negative function 
return values ahead of the map handling. I don't remember the details.

It's possible there are differences in how the v3.8 executable you have 
was compiled. On the numerical fringes, compiler's and compiler settings 
can change quite a lot how odd values / NANs behave.

So as to better see what my working yuqk development compile does with 
the values, I changed the color_map to:

color_map {
     [-1.00 rgbt <1,1,0.3,1>]
     [0.00 rgb 0]
     [0.33 rgb x]
     [0.50-E rgb x]
     [0.50   rgbt 1]
     [0.50+E rgb y]
     [0.66 rgb y]
     [1.00 rgb z]
     [2.00 rgbt <1,1,0.6,1>]
}

I get:

Val(val("-inf")) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(-0) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(0) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(+0) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(E) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(0.5-E) = 1.000, 0.013, 0.013, 0.000, 0.013
Val(0.5) = 1.000, 1.000, 1.000, 0.000, 1.000
Val(0.5+E) = 0.013, 1.000, 0.013, 0.000, 0.013
Val(1-E) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(-0+1) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(1) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(+0+1) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(val("+inf")) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(val("-nan")) = 1.000, 1.000, 0.300, 0.000, 1.000
Val(val("nan")) = 1.000, 1.000, 0.300, 0.000, 1.000
Val(val("-0.33")) = 0.000, 0.971, 0.029, 0.000, 0.000

Adding yuqk's 'raw_wave' just below 'gradient x' I get:

Val(val("-inf")) = 1.000, 1.000, 0.300, 0.000, 1.000
Val(-0) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(0) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(+0) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(E) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(0.5-E) = 1.000, 0.013, 0.013, 0.000, 0.013
Val(0.5) = 1.000, 1.000, 1.000, 0.000, 1.000
Val(0.5+E) = 0.013, 1.000, 0.013, 0.000, 0.013
Val(1-E) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(-0+1) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(1) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(+0+1) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(val("+inf")) = 1.000, 1.000, 0.600, 0.000, 1.000
Val(val("-nan")) = 1.000, 1.000, 0.300, 0.000, 1.000
Val(val("nan")) = 1.000, 1.000, 0.300, 0.000, 1.000
Val(val("-0.33")) = 0.330, 0.330, 0.099, 0.000, 0.330

so the +-inf and -0.33 pattern results change with 'raw_wave' in yuqk.

When I run my v3.8 beta 2 compile and compare to yuqk without 
'raw_wave', I get the differences:

yuqk
----
Val(val("-inf")) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(val("+inf")) = 0.000, 0.000, 1.000, 0.000, 0.000

v3.8 beta 2
-----------
Val(val("-inf")) = 0.000, 1.000, 0.000, 0.000, 0.000
Val(val("+inf")) = 0.000, 0.000, 0.000, 0.000, 0.000

Another issue potentially in play is that the official POV-Ray code had 
a small epsilon adder on the pattern return values meant to keep the 
values at 1.0 from snapping back to zero (some of the pattern 
implementations in POV-Ray proper defeated this code by doing their own 
clamping(*)). I don't recall the epsilon value used. The yuqk fork 
handles this 'essentially 1.0' condition with more care / precision.

(*) - I don't remember if gradient x was one of these. The yuqk code 
isn't clamping the gradient return values.

Bill P.

Post a reply to this message