Please see the attached tarballs, previous announcements in this forum 
and INSTALL.txt for suggestions on compiling and running via wrapper script.

Note. The yuqk_DocAndAid_a5c25dda.tar.gz and 
yuqk_Examples_a5c25dda.tar.gz files will be attached to a response to 
this posting.

A reminder the yuqk fork is not POV-Ray. As time passes, it's less 
likely existing POV-Ray scenes will work without modification.

Note. Those using g++ compiler version 13 or later must add the compiler 
flag -fno-finite-math-only, if using the flag -ffast-math.

Note. Those compiling to the c++20 (or later) standard must currently 
use the -fno-char8_t compiler flag.

Bill P.

---
---------------- povray-3.8.0-x.yuqk_a5c25dda.tar.gz  February 06, 2025
yuqk R18 v0.6.12.0

Removed a dynamic_cast in render time bump_map image value access code, 
which significantly improved performance.

Added the inbuilt function f_lcm() accepting up to six integer values 
plus a use count integer with values 1 thru 6.

Added the inbuilt function f_gcd() accepting up to three integer values 
and a match value. Returns the greatest common denominator found when 
the match value is 0. Otherwise it returns 1 when the gcd is equal to 
the match value and 0.0 otherwise.

Deleted the f_leopard pattern. The leopard pattern itself was recently 
updated so as to be much more flexible making the inbuilt function obsolete.

Moved the minimum C++ compiler standard to c++17 (has long been c++11).

Added the inbuilt function f_round() which itself is a wrap of 
std::lround().

Deleted the f_onion pattern. The onion pattern itself was recently 
updated so as to be much more flexible making the inbuilt function obsolete.

---
Re-worked the image_indexed_textures{} feature so it more reliably works 
with image formats supporting channel depths > 8 bits or channel values 
 >1.0.

- Texture list entry 0 is always the default background / unmapped 
region texture. Further, rather than wrap when palette registers/indexes 
exceed the number of textures in the list, yuqk maps these also to the 0 
texture entry.

- Adding support for color channel depths > 8 bits by specifying texture 
list of longer than 256 entries. (The 0.0..1.0 red channel multiplier 
becomes 65535.0 rather than always 255.0)

- High dynamic range images, which often have .red or .grey values > 1.0 
in typical use, can exploit this support by using the .red or .grey 
values directly as index values into the texture list.

- Removed a dynamic_cast in render time image value access code, which 
significantly improved performance.

- Additional parse time checks for valid map types, etc.

- Added warp{} parsing support missing always since warp{}s added.

- Rather than casting map image float values to integers, yuqk now 
rounds using std::lround() which makes interpolations more usable / stable.

- Negative .red / .grey channel values, which have never been handled 
explicitly, are now treated as equivalent positive index values after 
rounding.

- Fixed bugs in imageutil.cpp's InterpolateBicubic() and Interp() where 
the code by numerical noise was sometimes flipped into an index 
calculated mode.

---

Renamed the material_map{} feature image_indexed_textures{} - which is 
what it always has been. Confusion was created when later support for a 
material{} feature was added. The material{} feature encapsulates 
texture{}s and interior{}s via identifier references.

---

Completed the move of image input modifier keywords to ones with 'ii_' 
prefixes. These are keywords used with the bump_map{}, image_map{}, 
image_pattern{} and material_map{} blocks / features of POV-Ray to 
modify how the image is mapped to surfaces or shapes.

The complete list of 'ii_' prefixed keywords is: ii_all, ii_filter, 
ii_interpolate, ii_map_type, ii_offset, ii_once, ii_repeat, ii_transmit, 
ii_use_alpha, ii_use_color, ii_use_colour and ii_use_index. The 
'ii_offset' and 'ii_repeat' had previously been created where there was 
long existing, but undocumented, image input features called offset and 
repeat in the POV-Ray source code.

The following keywords with respect to the R17 release state have been 
renamed so as to have the 'ii_' prefix: all, interpolate, map_type, 
once, use_color, use_colour and use_index. In other words, un-prefixed 
forms of these keywords no longer exist.

The keywords 'ii_filter' and 'ii_transmit' now exist alongside the 
keywords 'filter' and 'transmit' which are still used with the channel, 
dot access syntax for color vectors and with little used, old style, 
color definitions.

The keyword 'ii_use_alpha' now exist alongside the keyword 'use_alpha' 
used within the finish{} block.

---

Post a reply to this message

Attachments:
Download 'povray-3.8.0-x.yuqk_a5c25dda.tar.gz' (1702 KB)

On 2/7/25 00:15, William F Pokorny wrote:
> Note. The yuqk_DocAndAid_a5c25dda.tar.gz and 
> yuqk_Examples_a5c25dda.tar.gz files will be attached to a response to 
> this posting.

Bill P.

Post a reply to this message

Attachments:
Download 'yuqk_docandaid_a5c25dda.tar.gz' (694 KB) Download 'yuqk_examples_a5c25dda.tar.gz' (462 KB)

Installing on fairly fresh MINT install.
Looks like I need to install certain libraries first.

===============================================================================
Configure POV-Ray (yuqk) version 3.8.0-x.yuqk_a5c25dda
===============================================================================

---------------
  Environment
---------------

------------
  Programs
------------

-------------------------------------------
  Attempt dump of compiler built-in specs
-------------------------------------------

-------------
  Libraries
-------------
configure: error: cannot find a suitable PNG library

Post a reply to this message

installed a bunch of packages.

Needed to hammer on the libpng-dev thing

sudo apt install build-essential zlib1g-dev
cd
mkdir src
cd src
wget
https://ppa.launchpadcontent.net/linuxuprising/libpng12/ubuntu/pool/main/libp/libpng/libpng_1.2.54.orig.tar.xz
tar Jxfv libpng_1.2.54.orig.tar.xz
cd libpng-1.2.54
../configure
make
sudo make install
sudo ln -s /usr/local/lib/libpng12.so.0.54.0 /usr/lib/libpng12.so
sudo ln -s /usr/local/lib/libpng12.so.0.54.0 /usr/lib/libpng12.so.0

Then I installed libtiff-dev
and then everything was fine




===============================================================================
Configure POV-Ray (yuqk) version 3.8.0-x.yuqk_a5c25dda
===============================================================================

---------------
  Environment
---------------

------------
  Programs
------------

-------------------------------------------
  Attempt dump of compiler built-in specs
-------------------------------------------

-------------
  Libraries
-------------

-----------------------
  Language constructs
-----------------------

----------------------
  Language functions
----------------------

---------------------
  Compiling options
---------------------

---------------------------
  Floating Point Features
---------------------------

-------------
  Makefiles
-------------

--------------------------------------------------------
  Definitions setting POV-Ray (yuqk) run time messages
--------------------------------------------------------

===============================================================================
POV-Ray (yuqk) 3.8.0-x.yuqk_a5c25dda has been configured.
===============================================================================

See the file config.log for more detail.
See the file INSTALL.txt for more build options and information.

Post a reply to this message

doing make, and I get a lot of:

/usr/bin/ld: disp_x11.cpp:(.text+0x2085): undefined reference to
`XGetVisualInfo'
/usr/bin/ld: disp_x11.cpp:(.text+0x2096): undefined reference to `XFree'
/usr/bin/ld: disp_x11.cpp:(.text+0x20b3): undefined reference to
`XCreateColormap'
/usr/bin/ld: disp_x11.cpp:(.text+0x2126): undefined reference to `XCreateWindow'
/usr/bin/ld: disp_x11.cpp:(.text+0x218b): undefined reference to
`XSetWMNormalHints'
/usr/bin/ld: disp_x11.cpp:(.text+0x21c5): undefined reference to `XSetClassHint'
/usr/bin/ld: disp_x11.cpp:(.text+0x21e7): undefined reference to
`XCreateBitmapFromData'
/usr/bin/ld: disp_x11.cpp:(.text+0x220c): undefined reference to
`XCreateBitmapFromData'
/usr/bin/ld: disp_x11.cpp:(.text+0x224a): undefined reference to `XSetWMHints'
/usr/bin/ld: disp_x11.cpp:(.text+0x2261): undefined reference to `XSetIconName'
/usr/bin/ld: disp_x11.cpp:(.text+0x2287): undefined reference to `XCreateGC'
/usr/bin/ld: disp_x11.cpp:(.text+0x22a0): undefined reference to `XSelectInput'
/usr/bin/ld: disp_x11.cpp:(.text+0x22b0): undefined reference to `XMapWindow'
/usr/bin/ld: disp_x11.cpp:(.text+0x22da): undefined reference to `XCreateImage'
/usr/bin/ld: disp_x11.cpp:(.text+0x2302): undefined reference to `XInitImage'
/usr/bin/ld: disp_x11.cpp:(.text+0x2410): undefined reference to `XPutImage'
/usr/bin/ld: disp_x11.cpp:(.text+0x2420): undefined reference to `XFlush'
/usr/bin/ld: disp_x11.cpp:(.text+0x2583): undefined reference to `XPutImage'

any ideas?

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> doing make, and I get a lot of:
>
> /usr/bin/ld: disp_x11.cpp:(.text+0x2085): undefined reference to
> `XGetVisualInfo'
> ...
> any ideas?

guessing the header files for the various X libraries are not installed ?

also, see inbox.


regards, jr.

Post a reply to this message

So, I noticed in the installation instructions there is the command:

../configure -q COMPILED_BY="name" CXXFLAGS="-O2" --prefix=/tmp/yuqk_427af17e

when in fact the package I was trying to compile/install was
povray-3.8.0-x.yuqk_a5c25dda

Once yuqk gets installed, I guess the program is still called povray, since the
make check runs the following:

../unix/povray +i./scenes/biscuit.pov -f +d -p +v +w320 +h240 +a0.3 +L./include

I'm guessing that for routine rendering, I can use alias to make something like
"yuqk biscuit.pov"
use the full path to yuqk povray and &1 to render whatever .pov file I throw at
it.

Post a reply to this message

On 2/9/25 09:52, Bald Eagle wrote:

Hi,

First - first, thanks for attempting to build the new yuqk fork release.

---

First, I think what jr suggested about missing headers is a probable 
cause. IIRC (probably not), someone else was missing usual x-windows 
libraries too somewhat recently, on trying to build and saw a similar issue.

Except my 'first' reaction is how did this invalid build state slip past 
the x-windows configure (autotools) code...

Do you still have your config.log file? Near the bottom do you see the 
lines:

#define HAVE_LIBSDL2 1

#define BUILTIN_XWIN_DISPLAY "enabled"

Have you otherwise sorted out the cause yourself?

I'm, vaguely aware the underlying x-windows (Xorg) system is slowly 
being changed to something called Wayland. When I next can, I'll spend 
some time digging around. Last I knew there were no linux distributions 
shipped with Wayland as the default (user have to switch to do it 
themselves), but maybe that has changed and with it something about the 
'effective' windowing build support with linux distributions.

As a near term fix, you can install the sdl2 development libraries (if 
you have not) and it should be if you can use '--without-x' when you 
configure and build with the SDL2 preview window support instead. The 
yuqk default is to build and run with X windows, but it will always 
enable the newest SDL* windowing library too as part of the build, if it 
is available (and the user hasn't set a configuration option to disable it).

You can also build and run with no preview window capability at all by 
disabling both X and SDL previews.

> So, I noticed in the installation instructions there is the command:
> 
> ../configure -q COMPILED_BY="name" CXXFLAGS="-O2" --prefix=/tmp/yuqk_427af17e
> 
> when in fact the package I was trying to compile/install was
> povray-3.8.0-x.yuqk_a5c25dda
> 

Yeah, that's a bit confusing. Let me go clean it up for the next 
release. Ah, it's pervasive. I'll put it on the list to add something to 
yuqk's 'make dist' process to update it to the current commit string for 
each release.

> Once yuqk gets installed, I guess the program is still called povray, since the
> make check runs the following:
> 
> ../unix/povray +i./scenes/biscuit.pov -f +d -p +v +w320 +h240 +a0.3 +L./include
> 
> I'm guessing that for routine rendering, I can use alias to make something like
> "yuqk biscuit.pov"
> use the full path to yuqk povray and &1 to render whatever .pov file I throw at
> it.
> 

The expectation is that yuqk's 'povray' executable will be run using a 
wrapper script. There is an example script in the root directory of the 
unpacked source code called 'yuqk'. The internals of which are updated 
to point to your install location for the release prior to copying the 
script to you $HOME/bin directory, for example. You can also update that 
'yuqk' script in place as a way to quickly run without doing a 'make 
install'.

(Yep, I see too this another place where I should automatically update 
to the current release's commit string)

The yuqk fork is changing significantly release to release. The 
expectation is those using the yuqk fork will end up having many yuqk 
scripts in there $HOME/bin directory each pointing to a small install 
location of about 5MB.

I myself have: yuqk_3317dfc0, yuqk_9871ed6e and yuqk_a5c25dda wrapping 
builds / installs of the last three yuqk fork releases. I also have 
several development wrapper scripts pointing to different build 
configurations of development code at any given time (Something 
autotools supports well) - FWIW.

I hope my rambling of some help.

Bill P.

Post a reply to this message

On 07/02/2025 06:15, William F Pokorny wrote:
> Please see the attached tarballs, previous announcements in this forum 
> and INSTALL.txt for suggestions on compiling and running via wrapper 
> script.
> 
> Note. The yuqk_DocAndAid_a5c25dda.tar.gz and 
> yuqk_Examples_a5c25dda.tar.gz files will be attached to a response to 
> this posting.
> 
> A reminder the yuqk fork is not POV-Ray. As time passes, it's less 
> likely existing POV-Ray scenes will work without modification.
> 
> Note. Those using g++ compiler version 13 or later must add the compiler 
> flag -fno-finite-math-only, if using the flag -ffast-math.
> 
> Note. Those compiling to the c++20 (or later) standard must currently 
> use the -fno-char8_t compiler flag.
> 
> Bill P.

I'm also trying to install this latest version on my
ubuntu 22.04 LTS'vm.

With ./configure, the compilation goes well but I get this message at 
the end:
--------------------
configure: WARNING: All program feature using the OpenEXR library are 
disabled



However, the OpenEXR package is (seems) installed. I don't know if I can 
continue if I can continue with the rest of the installation.


One idea ?
Thanks





ps: don't forget that I'm a great linux beginner.




-- 
kurtz le pirate
compagnie de la banquise

Post a reply to this message

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

> Have you otherwise sorted out the cause yourself?

Yes.  It was a direct result of trying to use the wrong commit string.

> > ../configure -q COMPILED_BY="name" CXXFLAGS="-O2" --prefix=/tmp/yuqk_427af17e
> >
> > when in fact the package I was trying to compile/install was
> > povray-3.8.0-x.yuqk_a5c25dda


> > it.
> >
>
> The expectation is that yuqk's 'povray' executable will be run using a
> wrapper script. There is an example script in the root directory of the
> unpacked source code called 'yuqk'.

Maybe some text could be sent to standard output stating that before your make
script exits?


> I hope my rambling of some help.

It gives me a better idea of how to follow along.
I still need to get back into the linux mindset, and have some sort of mental
picture regarding where things are stored, how to access them, etc.

There's a lot of chown, chmod, ./filename, unfamiliar select/copy/paste
touchpad/keystroke combos, etc. that I have to familiarize myself with to adopt
a better workflow.


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.

Post a reply to this message

On 2/10/25 10:12, kurtz le pirate wrote:
> With ./configure, the compilation goes well but I get this message at 
> the end:
> --------------------
> configure: WARNING: All program feature using the OpenEXR library are 
> disabled
> 
> 
> However, the OpenEXR package is (seems) installed. I don't know if I can 
> continue if I can continue with the rest of the installation.
> 

The missing support only matters if you need to read or write .exr 
images with your scenes.

In a terminal window what do you see with the commands:

   pkg-config --print-errors OpenEXR
     ()

   pkg-config --modversion OpenEXR
     (3.1.5)

   pkg-config --cflags OpenEXR
     (-I/usr/include/OpenEXR -pthread -I/usr/include/Imath)

   pkg-config --libs OpenEXR
     (-lOpenEXR-3_1 -lOpenEXRUtil-3_1 -lOpenEXRCore-3_1
       -lIex-3_1 -lIlmThread-3_1 -lImath-3_1)

What is within the ()s is what I see on my Ubuntu 24.04 machine.

Bill P.

Post a reply to this message

On 10/02/2025 16:45, William F Pokorny wrote:
> On 2/10/25 10:12, kurtz le pirate wrote:
>> With ./configure, the compilation goes well but I get this message at 
>> the end:
>> --------------------
>> configure: WARNING: All program feature using the OpenEXR library are 
>> disabled
>>
>>
>> However, the OpenEXR package is (seems) installed. I don't know if I 
>> can continue if I can continue with the rest of the installation.
>>
> 
> The missing support only matters if you need to read or write .exr 
> images with your scenes.

OK, it's not mandatory for the time being.
So I will continue.


> In a terminal window what do you see with the commands:
> 
>    pkg-config --print-errors OpenEXR
>      ()
> 
>    pkg-config --modversion OpenEXR
>      (3.1.5)
> 
>    pkg-config --cflags OpenEXR
>      (-I/usr/include/OpenEXR -pthread -I/usr/include/Imath)
> 
>    pkg-config --libs OpenEXR
>      (-lOpenEXR-3_1 -lOpenEXRUtil-3_1 -lOpenEXRCore-3_1
>        -lIex-3_1 -lIlmThread-3_1 -lImath-3_1)

Same answer for the four orders:

Package OpenEXR was not found in the pkg-config search path.
Perhaps you should add the directory containing `OpenEXR.pc'
to the PKG_CONFIG_PATH environment variable
Package 'OpenEXR', required by 'virtual:world', not found


> What is within the ()s is what I see on my Ubuntu 24.04 machine.

But, on my 22.04 the command : 'sudo apt-get install openexr' say :

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
openexr is already the newest version (2.5.7-1). <<<<<<<<<<<<<<<
The following packages were automatically installed and are no longer 
required:
   libwpe-1.0-1 libwpebackend-fdo-1.0-1
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.



;)



-- 
kurtz le pirate
compagnie de la banquise

Post a reply to this message

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

On 2/10/25 11:35, kurtz le pirate wrote:
> But, on my 22.04 the command : 'sudo apt-get install openexr' say :

I believe the package you need is: libopenexr-dev

Bill P.

Post a reply to this message

On 10/02/2025 17:44, William F Pokorny wrote:
> On 2/10/25 11:35, kurtz le pirate wrote:
>> But, on my 22.04 the command : 'sudo apt-get install openexr' say :
> 
> I believe the package you need is: libopenexr-dev
> 
> Bill P.

Finally, it's getting better. I had to make mistakes as always.

I redid these steps;
- ldconfig
- reboot
- ./configure
- make
- make check
- make install


I did see the little window with the "cookies".





For the moment, the executable is still in
"/tmp/yuqk_a5c25dda/bin"



------------------------
./povray --version say :

povray: cannot open the user configuration file:
/home/louis/.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

Built-in features:
   Supported image formats:   gif tga iff ppm pgm hdr png jpeg tiff openexr
   Unsupported image formats: -

Compilation settings:
   Build architecture:  x86_64-pc-linux-gnu
   Built/Optimized for: x86_64-pc-linux-gnu
   Compiler vendor:     gnu
   Compiler version:    g++ 11.4.0
   Compiler flags:
     -pipe -w -fno-enforce-eh-specs -O2 -pthread


--------------------------
./povray --libraries say :

povray: cannot open the user configuration file:
/home/louis/.povray/3.8/povray.conf: No such file or directory

Boost 1.74, http://www.boost.org/

libjpeg 8.0, Copyright (C) 1991-1998, Thomas G. Lane.
Modified 2002-2009 by Guido Vollbeding.

OpenEXR 2.5.7 and IlmBase 2.5.7,
Copyright (c) 2002-2011 Industrial Light & Magic.

libpng version 1.6.37
Copyright (c) 2018-2019 Cosmin Truta
Copyright (c) 1998-2002,2004,2006-2018 Glenn Randers-Pehrson
Copyright (c) 1996-1997 Andreas Dilger
Copyright (c) 1995-1996 Guy Eric Schalnat, Group 42, Inc.

LIBTIFF, Version 4.3.0
Copyright (c) 1988-1996 Sam Leffler
Copyright (c) 1991-1996 Silicon Graphics, Inc.

zlib 1.2.11, Copyright (C) 1995-2017 Jean-loup Gailly and Mark Adler




The hard part is over. I don't have time now. I'll continue later :) :)

ps : I took notes and orders throughout the installation. I'll format 
them and give them away if they help other mad people. LOL !!




-- 
kurtz le pirate
compagnie de la banquise

Post a reply to this message

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