When i try to render a scene after compiling it on Fedora 38 the program runs
very fast and produces a totally white image. i am outputing the scene as a png
file.

it is povray 3.8 beta 1.


Does anyone have any tips on how to compile the program properly on Fedora 38?

This is the script i use to compile the program.

#!/bin/bash
CXXFLAGS="-Wno-multichar"
../configure COMPILED_BY="RSM"  --with-boost=/usr/lib64 --disable-io-restrictions
--with-boost-thread=boost_thread LIBS=-Lboost_system
export LDFLAGS="${LDFLAGS} -L/usr/lib64"
make clean
make check
make install

Thank you
RSM

Post a reply to this message

hi,

"RSM" <nomail@nomail> wrote:
> When i try to render a scene after compiling it on Fedora 38 the program runs
> very fast and produces a totally white image. i am outputing the scene as a png
> file. ...
> make check

but 'make check' showed the "biscuit" ?

fwiw, I used the following (excerpt from script) to build beta.1:

CXXFLAGS="$BLDFLAGS" \
  ./configure \
  --enable-silent-rules \
  --libdir=/usr/local/lib64 \
  --sysconfdir=/usr/local/etc \
  --localstatedir=/var \
  --mandir=/usr/local/man \
  --without-libmkl \
  COMPILED_BY="$POVRAY_BUILDER"

make
make check
make install

if rebuilding makes no difference, perhaps you could record the
 build process, eg.

  $ script /tmp/build-log
  $ ./mybashscript
  $ exit

and attach that file in the follow-up post.  hope that helps.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "RSM" <nomail@nomail> wrote:
> > When i try to render a scene after compiling it on Fedora 38 the program runs
> > very fast and produces a totally white image. i am outputing the scene as a png
> > file. ...
> > make check
>
> but 'make check' showed the "biscuit" ?
----------
make check did not show the biscuit

i ran the build as root

the make report is attached.

the output was very quick and still resulted in a png file that was totally
white.

when i run this on windows version of povray it works. however i am having other
problems with the windows version where it will try to parse a scene and crashes
with a memory permissions error with some scenes.

Post a reply to this message

i tried to attach the report to this thread but it would not work

please see the message here:
http://news.povray.org/web.6519a52bfee355a638789ea2e542b12d%40news.povray.org

it did not show the biscuit image when i ran the make check

i was logged in as root when i compiled the program
when i ran a render after the compile finished  as a png file
the output was totally white again

i was able to run this on the windows version of povray but i am having issues
with it as well.
on some scenes the render crashed and i get a memory exception error.

Post a reply to this message

hi,

"RSM" <nomail@nomail> wrote:
> ...
> it did not show the biscuit image when i ran the make check
> i was logged in as root when i compiled the program

fwiw (and it should not make a difference), 'root' ought not be needed except
for 'make install'.


> when i ran a render after the compile finished  as a png file
> the output was totally white again
> i was able to run this on the windows version of povray but i am having issues
> with it as well.
> on some scenes the render crashed and i get a memory exception error.

cannot say anything about MS Windows version, but ime self-compiled POV-Ray is
solid and dependable[*].  I've looked through the build log (thanks) but
everything looks .. nominal.  I'm guessing that o/wise you have no problems with
any of the linked-to libraries ?  the only "straw to clutch" I can think of is
that your compiler may be too new ?  try with '-std=c++11' in the CXXFLAGS.
right out of ideas, otherwise.  sorry.

[*] there are known bugs, of course.


regards, jr.

Post a reply to this message

On 10/1/23 13:14, RSM wrote:
> it did not show the biscuit image when i ran the make check

Certainly odd.

The output from make check shows that all the ray -> bounding tests 
failed. If you code up:

//--- test.pov
sphere { 0, 5000
     hollow
     pigment { rgb <0,1,0> }
     finish { emission 1 }
}
//---

and run it by pointing directly to the <build dir>/unix/povray executable:

<build dir>/unix/povray test.pov

Do you see a green render? (You'll need to do this as root (or via sudo) 
as you compiled as root)

Above scene should bypass the bounding and all rays will land on the 
inside surface of the sphere.

Bill P.


Aside: It might be worth doing a build as a regular user. It should be 
you can do everything but a machine level install. In other words, 'make 
check' should run fine.

Aside: You have 16 threads, you can compile faster after configuration 
by using:

make -j16
make check

Post a reply to this message

On 10/1/23 14:06, William F Pokorny wrote:
>> it did not show the biscuit image when i ran the make check
> 
> Certainly odd.

Also...

Is there a reason you are using 'povray 3.8 beta 1' over the newer 
'povray 3.8 beta 2'?

Are you building from the linux / unix tarballs from github? Only those 
support the traditional immediate ./configure build IIRC.

Bill P.

Post a reply to this message

i am using the povunix-v3.8.0-beta.1.tar.gz tarball from github
i am willing to try 3.8 beta 2

do i need to change my settings to compile as a user instead of root?

Post a reply to this message

On 10/1/23 15:08, RSM wrote:
> 
> i am using the povunix-v3.8.0-beta.1.tar.gz tarball from github
> i am willing to try 3.8 beta 2
> 
> do i need to change my settings to compile as a user instead of root?
> 

I'll take you to mean ./configure settings.

It should be most users can just use:

./configure -q COMPILED_BY="RSM"
make -j16
make check

in the <unpacked tarball directory> as a start.

Maybe you need some of those other configure settings you've previously 
used on your machine, but I'd hope configure would sort out most things 
for you on a standard fedora install. Your Fedora 3.8 is relatively old 
though, so maybe not.

Aside: jr's idea about hard setting the compiler version is worth a try 
too - if things continue to be weird, but I'd try a simple ./configure 
to start.

Bill P.

Post a reply to this message

Bill

when i rendered the test.pov image the png file was entirely green.

/usr/local/bin/povray test.pov

another wierd thing that i am noticing with the povray website is that when i
visit the unix section of the list. and choose my original message it only shows
two of the messages however when i go to the recent threads page i see all of
the replies.


i tried pointing to the povray binary directly when i rendered a scene and it
produced a white image

Post a reply to this message

"RSM" <nomail@nomail> wrote:
> When i try to render a scene after compiling it on Fedora 38 the program runs
> very fast and produces a totally white image.

The obvious question now is : what scene are you trying to render?

- BW

Post a reply to this message

this happens on any scene i try to render

Post a reply to this message

i tried beta 2
i tried it with

#!/bin/bash
CXXFLAGS="-std=c++11"
../configure -q COMPILED_BY="RSM"
make clean
make
make check
make install

the output when rendering biscuits.pov is entirely black
the output when rendering the test scene bill provided is green
the output when i try rendering my scenes is entirely white

Post a reply to this message

On 10/1/23 15:45, RSM wrote:
> Bill
> 
> when i rendered the test.pov image the png file was entirely green.
> 
> /usr/local/bin/povray test.pov
> 
> another wierd thing that i am noticing with the povray website is that when i
> visit the unix section of the list. and choose my original message it only shows
> two of the messages however when i go to the recent threads page i see all of
> the replies.
> 
> 
> i tried pointing to the povray binary directly when i rendered a scene and it
> produced a white image
> 
Hi,

Unsure about the web site issue. I mostly use thunderbird. Going to to 
web site forum interface just now (using firefox), I see in the unix 
newsgroup 13 totals posts in this thread - which matches what I see via 
thunderbird though as a couple branches from your original post. So, 
things look OK to me.

Aside: Posts on a topic end up presented as a single sequence on the web 
site interface no matter the newsgroup's hierarchy for the topic.

--

That you see green with the sphere scene test is fair confirmation 
whatever is happening is related to bounding(a).

POV-Ray ships with two bounding methods (1 & 2). What happens if you 
switch to bounding method two using the flag +bm2 ?

Bill P.

(a) - I have not even a guess as to cause...

Post a reply to this message

hi,

"RSM" <nomail@nomail> wrote:
> i tried beta 2
> i tried it with
>
> #!/bin/bash
> CXXFLAGS="-std=c++11"
> ../configure -q COMPILED_BY="RSM"
> make clean
> make
> make check
> make install
>
> the output when rendering biscuits.pov is entirely black
> the output when rendering the test scene bill provided is green
> the output when i try rendering my scenes is entirely white

wow.  completely outside my experience..

just to confirm, the archive(s) you used came from
<https://github.com/POV-Ray/povray/tags/> ?


regards, jr.

Post a reply to this message

On 10/1/23 23:09, William F Pokorny wrote:
> That you see green with the sphere scene test is fair confirmation 
> whatever is happening is related to bounding(a).
> 
> POV-Ray ships with two bounding methods (1 & 2). What happens if you 
> switch to bounding method two using the flag +bm2 ?

Awoke with a few additional thoughts in my head.

1) That +bm2 is a run time, command line flag passed to povray.

2) You could also try the run time flag, -mb, which in v3.7/v3.8 
official versions of POV-Ray turns off most bounding - but not all of it 
as happens in v3.6 and prior. The renders would be slow, but if they 
aren't blank, this would tell us something I guess.

3) You could try my 'povr' fork of POV-Ray... You can find the latest 
source build tarball at:

http://news.povray.org/povray.binaries.programming/thread/%3C64f34751%40news.povray.org%3E/



My version of POV-Ray does NOT yet have the OpenEXR 3.1 patches needed 
to compile and use that library - because I'm not immediately set up to 
test them.

It does have many updates related to the build process and the source 
code.

Take care to not do a 'make install' with it, but rather the test would be:

./configure -q COMPILED_BY="RSM_noEXR" --without-openexr
make -j4
make check

4) It sank in that while the fedora version you have is old, most 
everything else you are using with respect to compiler and libraries is 
recent. Maybe something in all that. I'd make a small bet on boost being 
the culprit, if so.

Bill P.

Post a reply to this message

jr said:
>> just to confirm, the archive(s) you used came from
>> <https://github.com/POV-Ray/povray/tags/> ?
i used the releases from github

bill said:


>>3) You could try my 'povr' fork of POV-Ray...

thank you for the link to your version of povray bill.


>> 4) It sank in that while the fedora version you have is old, most
everything else you are using with respect to compiler and libraries is
recent. Maybe something in all that. I'd make a small bet on boost being
the culprit, if so.;

>>Your Fedora 3.8 is relatively old though, so maybe not.

this is fedora 38 not 3.8
fedora 38 was released in april of 2023


as you said it could be a library related issue. many of the libraries are newer

thank you for your suggestions

Post a reply to this message

On 10/1/23 10:53, RSM wrote:
> When i try to render a scene after compiling it on Fedora 38 the program runs
> very fast and produces a totally white image. i am outputing the scene as a png
> file.
> 
> it is povray 3.8 beta 1.
> 
> 
> Does anyone have any tips on how to compile the program properly on Fedora 38?
> 
> This is the script i use to compile the program.
> 
> #!/bin/bash
> CXXFLAGS="-Wno-multichar"
> ../configure COMPILED_BY="RSM"  --with-boost=/usr/lib64 --disable-io-restrictions
> --with-boost-thread=boost_thread LIBS=-Lboost_system
> export LDFLAGS="${LDFLAGS} -L/usr/lib64"
> make clean
> make check
> make install
> 
> Thank you
> RSM
> 

found this is your /report/ file:

checking for sdl-config... no
checking for libSDL... not found
configure: WARNING: the preview display is disabled

then later in same file:

Built-in features:
   X Window display:          disabled

Post a reply to this message

Ash Holsenback <ash### [at] nomailnone> wrote:
> On 10/1/23 10:53, RSM wrote:

> checking for sdl-config... no
> checking for libSDL... not found
> configure: WARNING: the preview display is disabled
>
> then later in same file:
>
> Built-in features:
>    X Window display:          disabled

i found sdl12-compat and installed it


then i recompiled it

checking for libSDL... yes
checking for libSDL version >= 1.2... 1.2.68, ok
checking for SDL/SDL.h... yes
checking for SDL_Quit in -lSDL... yes

 X Window display:          enabled (using SDL)

when it got to the make check a little window popped up and
the display inside was all black.

when i rendered the sphere that bill suggested as a test i got a green image
when i tried rendering my scenes i got a white image and it rendered very fast.
when i rendered the biscuit.pov i got a black image.

Post a reply to this message

On 10/2/23 08:06, RSM wrote:
> this is fedora 38 not 3.8
> fedora 38 was released in april of 2023

Ah... My old mind glitching. Something it does all too often these days. 
:-)

Bill P.

Post a reply to this message

Le 03/10/2023 à 01:23, RSM a écrit :
> Ash Holsenback <ash### [at] nomailnone> wrote:
>> On 10/1/23 10:53, RSM wrote:
> 
>> checking for sdl-config... no
>> checking for libSDL... not found
>> configure: WARNING: the preview display is disabled
>>
>> then later in same file:
>>
>> Built-in features:
>>     X Window display:          disabled
> 
> i found sdl12-compat and installed it
> 
> 
> then i recompiled it
> 
> checking for libSDL... yes
> checking for libSDL version >= 1.2... 1.2.68, ok
> checking for SDL/SDL.h... yes
> checking for SDL_Quit in -lSDL... yes
> 
>   X Window display:          enabled (using SDL)
> 
> when it got to the make check a little window popped up and
> the display inside was all black.
> 
> when i rendered the sphere that bill suggested as a test i got a green image
> when i tried rendering my scenes i got a white image and it rendered very fast.
> when i rendered the biscuit.pov i got a black image.
> 

Dropping in the discussion;

You might want to compare official code with hg-povray code for display 
( https://github.com/LeForgeron/povray/tree/hgpovray38/unix )
as I made a port for libsdl2 and raw X11 (but you cannot compile for 
both libsdl 1.2 and libsdl 2.0, they are using the same API with 
different interfaces (they fucked it))

IIRC, libdsl2 is far better that 1.2

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 03/10/2023 à 01:23, RSM a écrit :
> > Ash Holsenback <ash### [at] nomailnone> wrote:
> >> On 10/1/23 10:53, RSM wrote:
> >
> >> checking for sdl-config... no
> >> checking for libSDL... not found
> >> configure: WARNING: the preview display is disabled
> >>
> >> then later in same file:
> >>
> >> Built-in features:
> >>     X Window display:          disabled
> >
> > i found sdl12-compat and installed it
> >
> >
> > then i recompiled it
> >
> > checking for libSDL... yes
> > checking for libSDL version >= 1.2... 1.2.68, ok
> > checking for SDL/SDL.h... yes
> > checking for SDL_Quit in -lSDL... yes
> >
> >   X Window display:          enabled (using SDL)
> >
> > when it got to the make check a little window popped up and
> > the display inside was all black.
> >
> > when i rendered the sphere that bill suggested as a test i got a green image
> > when i tried rendering my scenes i got a white image and it rendered very fast.
> > when i rendered the biscuit.pov i got a black image.
> >
>
> Dropping in the discussion;
>
> You might want to compare official code with hg-povray code for display
> ( https://github.com/LeForgeron/povray/tree/hgpovray38/unix )
> as I made a port for libsdl2 and raw X11 (but you cannot compile for
> both libsdl 1.2 and libsdl 2.0, they are using the same API with
> different interfaces (they fucked it))
>
> IIRC, libdsl2 is far better that 1.2

i tried compiling povray-hgpovray38.zip and the renders created files with solid
colors again.

i used libSDL2 as suggested

does anyone have any thoughts on what else could be causing this problem?

should i try Povray 3.7 instead?

would it help if i uploaded the output from the compilation process?

Post a reply to this message

hi,

"RSM" <nomail@nomail> wrote:
> ...
> does anyone have any thoughts on what else could be causing this problem?

you were compiling from an Xterm[*], so your X installation must be ok, I guess.
 can you confirm/verify the working of the various libraries 'povray' will be
linked to ?  (libpng etc, see output from 'ldd' perhaps)

[*] fwiw, I'd prefer doing "root stuff" from a console.  X isn't "secure",
particularly.


> should i try Povray 3.7 instead?

3.7 does, alas, have none of the new "exciting" features of the 3.8; no
dictionaries and no auto-sizing arrays would be the main drawback, as I see it.


> would it help if i uploaded the output from the compilation process?

generally speaking, more details == better.

(of course it may be wasted :-) I _ought_ to have picked up on the missing SDL,
as AH did)


regards, jr.

Post a reply to this message

An interesting thing you might try is setting your output format to a different
file type.  Maybe some library isn't properly set up or installed, ....

- BW

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> An interesting thing you might try is setting your output format to a different
> file type.  Maybe some library isn't properly set up or installed, ....
>
> - BW

I tried the jpg output format and it came back as a totally white image.

Post a reply to this message

On 10/2/23 08:06, RSM wrote:
> thank you for your suggestions

Did any of my suggestions work to solve the bounding issue?


If your answer is no, I have no further ideas for running v3.8 and would 
need to try myself to compile in newer environments to see if I see what 
you see with my povr fork.

If yes, what worked might give me a hint or two as it would point toward 
things I've fixed or change in the povr fork.

(... a couple days away and thunderbird has changed... ;-) )



---
If you've not tried a 'make check' with the povr fork, one weak guess is 
that the issue has to do with the boost::bind.

In the compile output you posted there were messages like:


"...
Please use <boost/bind/bind.hpp> + using namespace boost::placeholders, 
or define BOOST_BIND_GLOBAL_PLACEHOLDERS to retain the current behavior.
..."

That message is a little different than what I 'remember' getting when I 
defined BOOST_BIND_GLOBAL_PLACEHOLDERS in my povr build process back at 
boost 1.74 to avoid the ugly compile time messages for something I 
wasn't going to fix immediately. The bounding code uses boost::bind.

Further, in reading one of the C++ guru's blog's on some other topic a 
year or more ago, I remember his making some comment on the side about 
C++ itself having transitioning through a subtle incompatibility with 
it's 'bind' feature - one that broke behavior with some existing builds. 
If boost 1.78 has internally moved to C++'s bind, maybe POV-Ray v3.8 is 
tripping over whatever the blog's mentioned bind issue was?

All close to a complete guess, but if you want to 'fish' and you've not 
tried the povr fork's build, perhaps try defining 
BOOST_BIND_GLOBAL_PLACEHOLDERS and do anther make check.

It should be you can just edit the 'config.h' file in your root build 
directory after running ./configure so that it contains a line like:

#define BOOST_BIND_GLOBAL_PLACEHOLDERS /**/


Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/2/23 08:06, RSM wrote:
> > thank you for your suggestions
>
> Did any of my suggestions work to solve the bounding issue?
>
No

> If your answer is no, I have no further ideas for running v3.8 and would
> need to try myself to compile in newer environments to see if I see what
> you see with my povr fork.
>
> If yes, what worked might give me a hint or two as it would point toward
> things I've fixed or change in the povr fork.
>
i tried the povr fork and make check works
i did a make install and ran it against a scene i have
i got this error:

Copyright 1991-2023 Persistence of Vision Raytracer Pty. Ltd.
Version 3.8.0-x.povr_96ed7ff3.unofficial
  (g++ 13.2.1 @ x86_64-pc-linux-gnu)
This is an unofficial version compiled by: RSM

Dynamic optimizations:
  CPU detected: AMD,SSE2,AVX,AVX2,FMA3
  Noise generator: avx-generic (compiler-optimized)

Declare=identifier: haswhoosh
terminate called after throwing an instance of 'pov_base::Exception'
  what():  User identifier using only a-z, 0-9 and _ characters.
Aborted (core dumped)

Post a reply to this message

On 10/7/23 09:13, RSM wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:

>>
>> If yes, what worked might give me a hint or two as it would point toward
>> things I've fixed or change in the povr fork.
>>

> i tried the povr fork and make check works
> i did a make install and ran it against a scene i have
> i got this error:
> 
> Copyright 1991-2023 Persistence of Vision Raytracer Pty. Ltd.
> Version 3.8.0-x.povr_96ed7ff3.unofficial
>    (g++ 13.2.1 @ x86_64-pc-linux-gnu)
> This is an unofficial version compiled by: RSM
> 
> Dynamic optimizations:
>    CPU detected: AMD,SSE2,AVX,AVX2,FMA3
>    Noise generator: avx-generic (compiler-optimized)
> 
> Declare=identifier: haswhoosh
> terminate called after throwing an instance of 'pov_base::Exception'
>    what():  User identifier using only a-z, 0-9 and _ characters.
> Aborted (core dumped)
>

By 'make check' works do you mean you see the biscuit scene?


On the parse error.

When configuring add the flag:

--disable-no-lc-identifiers

By default the povr fork doesn't allow lower case identifiers as it is 
often the source of Scene Description Language confusion / problems.


--
I am bothered because your attempted run with the no lower case 
identifier checking core dumped... I think it should be a handled exit 
from the parser with something like:

File 'lower.pov' line 2:
Parse Error:
#declare identifier 'abc' using only a-z, 0-9 and _ characters.
Fatal error in parser: Cannot parse input.
Render failed

Hmm. Maybe what you see happens if certain extra debugging is active... 
My debug compile at the moment happens to use 
--disable-no-lc-identifiers, so I don't have anything compiled this 
instant to test the thought.

Bill P.

B


Bill P.

Post a reply to this message

On 10/7/23 10:10, William F Pokorny wrote:
> I am bothered because your attempted run with the no lower case 
> identifier checking core dumped... I think it should be a handled exit 
> from the parser with something like:

I'd forgotten my own code!

We can make identifier declarations on the command line(a) and these 
happen outside the parser. In the command line code I'm throwing an 
exception on seeing lower case identifiers.

Bill P.

(a) - We can effectively declare identifiers in a few subtle ways other 
than #local and #declare. The #for iteration loop variable is an example 
- but those are handled in the parser.

Post a reply to this message

I have not had time to explore this further on linux.

However I have been able to get 3.8 beta 2 to work on windows.

I will investigate further when i have time.

Thank you to everyone who tried to help me

Post a reply to this message

On 10/23/23 20:04, RSM wrote:
> I have not had time to explore this further on linux.
> 
> However I have been able to get 3.8 beta 2 to work on windows.
> 
> I will investigate further when i have time.
> 
> Thank you to everyone who tried to help me
> 
> 
I wondered. Thanks for the update.

Bill P.

Post a reply to this message

On 10/1/23 10:53, RSM wrote:
> When i try to render a scene after compiling it on Fedora 38 the program runs
> very fast and produces a totally white image. i am outputing the scene as a png
> file.
> 
> it is povray 3.8 beta 1.
> 
> Does anyone have any tips on how to compile the program properly on Fedora 38?
> 
> This is the script i use to compile the program.
> 
> #!/bin/bash
> CXXFLAGS="-Wno-multichar"
> ../configure COMPILED_BY="RSM"  --with-boost=/usr/lib64 --disable-io-restrictions
> --with-boost-thread=boost_thread LIBS=-Lboost_system
> export LDFLAGS="${LDFLAGS} -L/usr/lib64"
> make clean
> make check
> make install
> 
> Thank you
> RSM
> 

FWIW, I suspect you were seeing the g++13 issue with -ffast-math 
discussed here:

http://news.povray.org/povray.unix/thread/%3C66d79724%40news.povray.org%3E/

I got very similar symptoms to yours on the update to the g++13 compiler.

Configuring with -fno-finite-math-only fixed the 'bounding not working' 
issue for me (Ubuntu 24.04).

Bill P.

Post a reply to this message