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