The Persistence of Vision Raytracer (POV-Ray).
This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.
Attached to Project: POV-Ray
Opened by Thorsten Fröhlich - 2012-05-28
Last edited by Thorsten Fröhlich - 2013-03-25
Opened by Thorsten Fröhlich - 2012-05-28
Last edited by Thorsten Fröhlich - 2013-03-25
FS#244 - Crand is disabled in 3.7 code
Turns out the crand feature, which depends on a real random number generator (and hence has threading issues) was disabled early on during 3.7 development, and hasn’t been fixed yet. The code is commented out in line 2426/2427 of trace.cpp.
The 3.6 code (for comparison) did not use a "real" random generator, but a classical pseudo-random (FRAND –> POV_RAND: a 32 bits generator returning only 15 bits) (congruent generator with classical coefficient *1812433253L + 12345L from the literature). (it is not exactly the posix.1-2001 values: * 1103515245 + 12345 )
And that generator was not exclusive: also used for photon-jitter... (Hint: seems the photon code of 3.7 also dropped jitter code so far)
Back to code, the 15 bits where transformed into a 0 to 1 (not included, probably) double.
Basic question for Crand's implementation: does it have to be replayable ? (render twice, same picture) (that impacts animation a lot).
The answer is: No. Directly from the documentation.
Jitter & Crand in wiki documentation
So, I would suggest any of drand48() or erand48() (according to how the initialisation should be done: srand48() or none), even if they are tagged as obsolete by SVID 3. (but they are conformant to SVr4 and Posix.1-2001)
There is also a bit of pseudo-random generator in boost (taus88 seems faster and with a better period than even rand48) (boost::random::uniform_01 is what we need)
Neither of those RNGs is appropriate, as they are by definition not thread-safe and won't help here at all. Thread safety is, after all the issue, not the choice of RNG! I have a local patch using thread data to store the RNG offset, but I am not perfectly happy with the result yet. Probably I will use the block number to seed the RNG, but first I have to route that to the thread data...
Thorsten has checked in a change by now that should fix this issue (#5689)