|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|