This week I updated my kubuntu 22.04LTS to 24.04LTS, and as a result I had to
reconfigure and recompile povray3.8 beta2.

To my amazement I got this error when running the new executable:
Parse Error: Viewing angle has to be smaller than 180 degrees.

After some DuckDuckGoing I found this solution
https://github.com/POV-Ray/povray/issues/460
and after replacing all HUGE_VALs into HUGE_FINITY_VALs my povray was working
again.

Is anybody going to change this in the povray source code, so that there will be
a new version with this patch?
More general, is there anybody, since Christopher Lipka left, still maintaining
povray?
What is the future of povray?
Is there a future for povray, or is 3.8 beta2 the last official version?

Cheers
Ton.

Post a reply to this message

On 6/21/24 22:44, Ton wrote:
> This week I updated my kubuntu 22.04LTS to 24.04LTS, and as a result I had to
> reconfigure and recompile povray3.8 beta2.
> 
> To my amazement I got this error when running the new executable:
> Parse Error: Viewing angle has to be smaller than 180 degrees.
> 
> After some DuckDuckGoing I found this solution
> https://github.com/POV-Ray/povray/issues/460
> and after replacing all HUGE_VALs into HUGE_FINITY_VALs my povray was working
> again.

If the user posting in that issue was correct about g++13 turning on the 
-fno-finite-math-only along with -ffast-math by default and it being the 
cause of the problem, the safest thing to do is to configure with 
-fno-fast-math (*) or use -fno-finite-math-only as suggested. (I cannot 
reproduce the problem by turning finite-math-only on with my g++11.4 
compiler...)

(*) - Many official linux distribution packages of POV-Ray run without 
the fast-math flag, only O2 optimizations and some other stricter 
compiler flags too. They play it safer with distributed software packages.

---

The wrong thing to do is use the suggested patch posted to that github 
issue! It creates a new macro definition in source/core/configcore.h 
called HUGE_FINITE_VAL which replaces the lines:

#ifndef HUGE_VAL
	#define HUGE_VAL 1.0e+17
#endif

with

#define HUGE_FINITE_VAL 1.0e+17

But, HUGE_VAL is always defined - for 25 years or more - in math.h / 
cmath.h and not by that POV-Ray header file. In other words, we've not 
been using that 1e17 value for eons - and the suggested patch brings 
back that old value...

A real fix needs to look at and understand the cause and the code 
implications in detail, everywhere HUGE_VAL* is used today(**). I know 
we use +-inf, which are valid float/double values, to control code flow 
in more than the one reported problem case.

(**) - The POV-Ray source uses std::numeric_limits too in places - which 
has an inifinity() option. I bet those might be a problem too, if used. 
The right fix for the camera code with the hard parse time fail is 
likely to use std::numeric_limits<double>::max() over HUGE_VAL.

If finite-math-only is on in g++13 with fast-math by default (or due 
whatever), I have to think we have more problems than the one, hard, 
parse time camera error fail.

Aside: The linux distribution folks which opened the github issue have 
backed up to g++12 for their distribution package.

---

I'm supporting my own playpen yuqk fork - and others too, theirs.

There is no official support as far as I know.

Bill P.

Post a reply to this message

On 6/22/24 01:35, William F Pokorny wrote:
> If the user posting in that issue was correct about g++13 turning on the 
> -fno-finite-math-only along with -ffast-math by default and it being the 
> cause of the problem, the safest thing to do is to configure with -fno- 
> fast-math (*) or use -fno-finite-math-only as suggested. (I cannot 
> reproduce the problem by turning finite-math-only on with my g++11.4 
> compiler...)

Update.

I upgraded from Ubuntu 22.04 to Ubuntu 24.04 over the weekend. The 
default g++ compiler is now 13.2.0 and builds do need to use the 
-fno-finite-math-only flag when using -ffast-math (*) with g++13 builds.

Rather than the camera issue, with yuqk, I see the 'bounding not working 
issue' issue reported in some fora here during the past year.

I expect given the different code bases, what will be seen as problems 
with g++13 builds will be varied. This includes introducing problems 
which might not be immediately apparent - the camera issues shows up 
more or less by chance for example, because of a test not really in play 
when it fails...

(I've not gotten around to re-building my collection of official releases.)

Bill P.

(*) - The default linux/unix builds with official releases use 
-ffast-math. The yuqk fork as shipped does not assume any compiler 
flags, but it does recommend -ffast-math with performance builds 
suggested in INSTALL.txt.  (**)

(**) - I've only lightly read up on the current g++13 --fast-math 
issues. However, it looks like gcc/g++ 13 plans to eventually back out 
the library changes creating the POV-Ray g++13 build exposures. 
Practically though, I think it best to always use -fno-finite-math-only 
when using -ffast-math with g++13 given we might not 'see' all the 
possible problems.

Post a reply to this message