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