Please see the attached tarball and previous announcements in this fora 
and INSTALL.txt for suggestions on compiling and running via wrapper script.

A reminder the povr fork is not POV-Ray. As time pass it's less likely 
existing POV-Ray scenes will work without modification.

Bill P.

---

--------------------- povr-3.8.0-x.povr_7c1adb79.tar.gz  Mar 04, 2023

A povr specific fix for an 08 Feb 2023 post by Chris R to beta-test with 
the title: Spline causing 3.8 beta 2 to crash.

Adding new includes in version.inc and forkversion.inc. These includes 
make use of fork_str() and fork_val() parser constants - when available 
- to support running modified versions of POV-Ray alongside nominally 
POV-Ray release aligned compiles. See the include files for more 
information and example usage. In other words, these additions enable 
users to set up conditional behavior with respect to particular forks in 
their scene description language (SDL) files.

Adding reflection block keyword inv_pnormal_cure to expose and 
explicitly make available fixes / modifications to reflected rays any 
time a normal{} block is used in a texture / material. The current 
available options are 0-5,11. See postings to v4.0 discussion forum for 
more information. The default was left at (1) which was the previously 
'secrete to users' three-way set of internal fixes. Yes, the code being 
exposed here in the SDL has long been twiddling with reflected rays and 
so reflection results. The effects are mostly muted where the bump_sizes 
are small and the reflections not near tangent to the surface.

Adding reflection block specific intensity_max. Applies specifically to 
reflection as handled with 1-n layered textures and unavoidably overlaps 
somewhat with the finish blocks overall intensity_max if it too is active.

Hacked a patch for openexr read with large floats. Problem values being 
those larger than about 2^16. Causing unavoidable speckling / blotchy 
patches both light and dark per color channel - depending on features 
used. What was seen for issues depends some on -ffast-math equivalent 
compiler settings. Added code a more controls around EXR_PRESCAN_PATCH 
(defaulted on) and POV_PIGMENT_DEBUG (defaulted off) settings. The 
latter becomes active with POV_DEBUG compiles and it looks for similar 
+-inf channel issues coming from anywhere - necessary because some of 
our colour (ie colour.h) code attempts to fix up bad color channel 
values and tends to hide issues, like the openexr one here, in doing so. 
The hack patch should be removed for code correctly handling exr files 
with larger full float values on move to exr 3.0.

Created an official normal block pattern called micro from the bevy 9 
test bed and corrected a bug not initially picked up in the original 
bevy 9 implementation where the result in x somewhat mangled.  It's 
depends on Anti-Aliasing (AA) for overall effect. Use: normal { micro 
0.01 }.

Added a fix to code setting up for the use of Intersect_BBox to avoid 
floating point exceptions causing unstable downstream numerical issues. 
Maintaining the ability to use --ffast-math with this fix a win for 
performance, but the fix is itself somewhat costly - especially given 
the exposure for most users is not that common. Perhaps better can be 
worked out later - understand the gains and impacts of Intersect_BBox first.

This version of the source code is configured with the useless zeroing 
of vector components due our vector.h template code turned off. Much 
work done to find needed initializations to zero (or other values) being 
hidden / obfuscated by the previous behavior. NOTE! Odds are good I 
missed something somewhere. Expecting this true, added a new 
configuration option in --enable-vector-zeroing which restores the 
previous zeroing behavior on vector construction / allocation. Aside: 
The broader adoption of vector.h in v3.8 is 2-3% of that 16% v3.7 / v3.8 
slowdown that came with that commit moving more strongly toward C++ 
methods. See: github GH363 / #363.

Fixing background/skysphere radiosity bug which had been, unfortunately, 
long mitigated by the extra initializations of vector components to zero 
in vector.h.

Minor cleanup in internal functions and vm. A few run time asserts made 
compile time static. Added static asserts to prevent the VM's integer 
opcodes from being compiled should someone turn on that compile option - 
the implementation is not complete with respect to POV-Ray in total.

Attempted to restore a little run time error reporting in the VM. The 
error reporting has long been disabled unsure when this happened 
(v3.7/v3.8?).

Reworked the sphere.cpp code in moving away from DEPTH_TOLERANCE, 
EPSILON to gkMinIsectDepthReturned or gkDBL_epsilon. Expected accuracy 
for the shape should be better by about two orders of magnitude. We have 
still the issue spheres, like sphere_sweeps and a few others eliminates 
transforms where the sphere's internal representation can be changed to 
represent the same thing.  This approach is likely faster, but it hurts 
numerically.

In testing POVMS with an active POVMS POVMS_NO_ORDERED_STREAM_DATA to 
see if performance faster as expected, I found a bug where I'd not 
previously gotten the float to double right. The option surprisingly was 
not faster though certainly looks like it should be. Likely why it's set 
as is and the bug fix likely useless practically.

Adding explicit internal initializations of INormal and PNormal where 
missing in preparation of trying to eliminate the mostly useless 
initializations to zero in vector.h.

Additional code clean up for compiler warnings. Changing DBL to double, 
FLT to float. Old generic EPSILON to gkMinIsectDepthReturned or 
gkDBL_epsilon as appropriate. No intended change in behavior, but at the 
very edges internally there could be as related to EPSILON.

While cleaning code corrected (at least better) old off center cubic DF3 
interpolation (12) at the edges. Wrap was wrong - is wrong in the v3.8 
release code give POV-Ray proper never adopted the off-shift fixes many 
years ago.

Turning off additional asserts for normal compiles. Many non debug 
parser ones especially were set soft rather than disable. The povr 
branch approach is normal compiles without asserts and a possible second 
compile with asserts and much more run time checking when issues pop up. 
Removing the asserts speeds up the parser so it is faster on average 
than the v3.8 release one.

Post a reply to this message

Attachments:
Download 'povray-3.8.0-x.povr_7c1adb79.tar.gz' (1855 KB)

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Please see the attached tarball and previous announcements in this fora
> and INSTALL.txt for suggestions on compiling and running via wrapper script.
>
> A reminder the povr fork is not POV-Ray. As time pass it's less likely
> existing POV-Ray scenes will work without modification.

great, cheers.  "todo", in the coming days.


regards, jr.

Post a reply to this message