We are validating rtrace results on machines with different CPUs (Intel, M1 and AMD) and operating systems (OS and Windows).
Using the same rtrace values (including defaults), we observed that the results are consistent up to the fourth digit, where they start to diverge.
Rtrace is being run with a uniform sky vault.
To check decimal place rounding, we increased the sky glow value by some orders of magnitude and observed that the issue was still present - starting from the fourth digit of the result.
All runs were done using a single thread.
The most significant differences were observed on a windows machine with an AMD processor, which also has the most recent install of Radiance.
Does anyone have any suggestions on what could be going on?
Related to this I wanted to know if there is a way to feed a seed to rtrace so it uses the same sample of random values and returns the same result each time.
If you set -u- in rtrace, then it swaps most calls to the pseudo-random number generator with a low-discrepancy sequence. It also uses a fixed seed value for the random number generator for when it does get called. However, this doesn’t guarantee the same results across systems, as different OS’es (and even different versions of the same OS) may have variations in their random number generator library.
The main point is that MC sampling means your answers are unlikely to agree exactly across machines.
Mathias: I understand what you mean. We did the same sampling and checked that every machine’s defaults were the same.
Diego: That’s an interesting idea. If radiance had its own random generator, we would be able to control the whole pipeline:)
Greg: Based on other threads on the forum, we use the -u- flag in rtrace so thanks for the insight. It makes sense that different systems have variations in the random number generator library.
Appreciate everyone’s assistance in shedding light on this matter.