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

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

So, I just tested NAN and inf out of curiosity, and it seems they both default
to zero in the color_map.

Bummer.  I suppose that's better than the render failing.

Post a reply to this message

Attachments:
Download 'color_map experiments.png' (24 KB)

Preview of image 'color_map experiments.png'

On 2/10/25 18:59, Bald Eagle wrote:
> So, I just tested NAN and inf out of curiosity, and it seems they both default
> to zero in the color_map.

It should be the +-inf values work - so long as you use yuqk's raw_wave 
value pattern modifier (it's actually a pattern-value modifier bypass).

See attached scene file.

Bill P.

Post a reply to this message

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

On 10/02/2025 19:25, kurtz le pirate wrote:
> 
> The hard part is over. I don't have time now. I'll continue later :) :)
> 


A little bit hs, sorry.

The program works. I have created a folder "yuqk_a5c25dda" in my $HOME 
folder. Files ares :


louis@Jammy:~/yuqk_a5c25dda$ tree
.
├── bin
│   └── povray
├── etc
│   └── povray
│       └── 3.8
│           ├── povray.conf
│           └── povray.ini
└── share
     ├── doc
     │   └── povray-3.8
     │       ├── html
     │       └── NowShippedAsSeparate_DocAndAid_tarball
     ├── man
     │   └── man1
     │       └── povray_yuqk.1
     └── povray-3.8
         ├── icons
         ├── include
         │   ├── arraycoupleddf3s.inc
         │   ├── arrays.inc
         │   ├── arraystatistics.inc
         │   ├── cfunctions.inc
         │   ├── crystal.ttf
         │   ├── cyrvetic.ttf
         │   ├── forkversion.inc
         │   ├── functions.inc
         │   ├── math.inc
         │   ├── munctions.inc
         │   ├── povlogo.ttf
         │   ├── rand.inc
         │   ├── setidtypes.inc
         │   ├── shapes.inc
         │   ├── strings.inc
         │   ├── timrom.ttf
         │   ├── transforms.inc
         │   ├── ttffonts.cat
         │   ├── vectoranalysis.inc
         │   ├── vectors.inc
         │   └── version.inc
         ├── ini
         │   └── povray.ini
         ├── scenes
         │   ├── biscuit.pov
         │   ├── fog
         │   │   ├── Bridge.inc
         │   │   └── fog.pov
         │   └── rtr_kla.pov
         └── scripts
             ├── render_anim.sh
             ├── render_scene.sh
             ├── rerunpov.sh
             └── runpov.sh


I add "~/yuqk_a5c25dda/bin:" in the PATH variable.



Asking the version for povray, i get :

povray: cannot open the system configuration file:
/tmp/yuqk_a5c25dda/etc/povray/3.8/povray.conf: No such file or directory
Persistence of Vision(tm) Ray Tracer    (see --license)
Copyright 1991-2025 Persistence of Vision Raytracer Pty. Ltd.
POV-Ray (yuqk) 3.8.0-x.yuqk_a5c25dda.unofficial
This is an unofficial version compiled by: louis
...
...

povray is still looking for the configuration file in the construction 
folder /tmp/yuqk_a5c25dda/...


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.



Any help ?




-- 
kurtz le pirate
compagnie de la banquise

Post a reply to this message

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.

Post a reply to this message

Damn.
I like that tree command!   :)

Post a reply to this message

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