Confusion about the functions of using rtrace's -af and -n together to accelerate?

radiance-general
1

Hi everyone,

One of the ways I learned in the discourse to speed up the Radiance is to use the -af and -n options of the rtrace command. In the manpage, the -af option will set the ambient file. The main function of the ambient file is to store the indirect illuminance and be used as a means of communication and data sharing between simultaneously executing processes. So, based on my tests and previous answer from @Greg_Ward (Is there a faster way to calculate the illuminance value?), if only use -n options, it will almost not speed up the process. It must use -af and -n options together to speed up the process.

The manpage also shows that “if any calculation parameters are changed or the scene is modified, the old ambient file should be removed so that the calculation can start over from scratch”. So, this means that if the light.rad file, .mat file or room.rad file is modified, it actually modifies the scene. In this case, the old ambient file should be removed.

So, if you use the rtrace command to analyze the same scene multiple times, you can use these two options to accelerate it. But, if you change some main properties of the scene, like the .mat file, light.rad, or room.rad file, you need to regenerate the ambient file. In this way, using these two options will not save time when you want to test the influence of different settings of .mat file.

Consequently, I am really confused about the functions of these two options. What is the significance of using rtrace’s -af and -n together to accelerate the analysis of the same scene? Because it makes no sense to analyze the same scene again and again.

Warm regards,

Hao

2

Hi Hao,

The -af option stores indirect irradiance values in a cache that allows sharing across ray tree evaluations. The method is explained in the 1988 paper on my website, near the bottom. This works well if you have many calculations repeated for an unchanging scene, but is no help as you point out for a solitary illuminance evaluation for slightly changing scenes.

In the latter case, I would recommend turning off the irradiance cache by setting -aa 0. This will switch to a path tracing method that is more efficient for individual calculations. The -n option will continue to be useful, but only if you have more calculations per version of your scene than you have running processes.

Give it a try.
-Greg

1 Like
3

Hi Gery,

Thank you so much for your reply. Your suggestion is very very helpful. I appreciate it.

As for the ambient file, my rough understanding is that it will store the indirect irradiance values and be used for communication and data sharing between simultaneously executing processes. So when I use it for multiple times calculations for an unchanging scene, for the first time it will take a little bit longer time to calculate the indirect irradiance values and generate the ambient file. But after the first time and having the ambient file, it will be faster, because it shares the indirect value (reusing common values), and only calculates the direct value again if I do not set the -aa option and help to communicate between simultaneously executing processes.

In my case, for each scene, it only needs to be calculated once. Therefore, setting the -aa 0, using -af and -n options, the ambient file will not be used to share the indirect value but be used as communication between simultaneously executing processes. As a result, the -af and -n options are still useful to speed up calculation ( calculations more than running processes), and the -aa 0 option prevents reusing indirect values. Am I right?

Kind regards,

Hao

4

Hi Hao,

The first part is correct, but with -aa 0 and only one calculation point, there is no reason to set -n to anything greater than 1, because Radiance has only one ray tree evaluation to allocate to your process. (This is its level of “granularity.”) Even if you had multiple illuminance values you wanted, setting -aa 0 turns sharing off, so the ambient file is not used if specified.

Best,
-Greg

1 Like
5

Hi Grey,

Thank you so much for your reply. So based on your explanation, for a scene, if I want to calculate the radiance value for different settings of the .mat file or the room.rad files which means for each setting, the scene only be calculated once, the options -af and -n are not helpful for speeding up the calculation. In this way, I might need to look for a new way to speed up the whole calculation process. Am I right?

Warm regards,

Hao

6

Yes, that’s correct. There is nothing to stop you from running multiple separate copies of rtrace, as many as you have processor cores, each working on a different illuminance value in a slightly modified scene. It’s just a matter of scripting it properly to avoid file name collisions.

Best,
-Greg

1 Like
7

Hi Greg,

Thank you for your reply and help. I appreciate it. I am trying some new ways to run multiple separate copies of rtrace. But during my previous test, I found an interesting thing: when I use -af, -aa 0, and -n options, the calculation is faster than when I do not use these options.

Cheers,

Hao

8

With -aa 0, you should get the following message if you also specify -af:

zero ambient accuracy so “your_file.amb” not opened

As for the -n option, I don’t know why it would be any faster if you are calculating a single illuminance value. Can you show me your commands, and tell me how long each takes (and how you measure time)?

Cheers,
-Greg

9

Hi Greg,

You are right, when I set -aa 0, it will show rtrace: warning - zero ambient accuracy so “cach.amb” not opened.

For the first case, I used the following command. It needs to take longer time to first generate the cach.amb file and the time is 8 minutes.

time(rtrace -h -I -ov -ab 3 -af cach.amb -n 8 scene1.oct < points1.pts | rcalc -e ‘$1=179*$1’ > lux1.csv)

Foe the second time, I used the following command and it takes 4 minutes.

time(rtrace -h -I -ov -ab 3 -aa 0 -af cach.amb -n 8 scene1.oct < points1.pts | rcalc -e ‘$1=179*$1’ > lux1.csv)

Warm regards,

Hao

10

How many points are in the file “points1.pts”? Also, is your scene completely gray? If not, you should modify the final rcalc command to:

rcalc -e ‘$1=179*(.265*$1+.670*$2+.065*$3)’

to account for RGB contributions to photopic illuminance.

Best,
-Greg

11

Hi @Greg_Ward

In points1.pts there are 1200 pixels. In the scene, the artificial lighting sources are 15 white luminaires, and the RGB values are the same. So, for rcalc I only use the value from the Red channel.

Cheers,
Hao

12

Even if your light sources are all white, the color of other surfaces in your scene will affect the computed irradiance values, so it is better just to use the formula I have given.

Regarding your 1200 points, this is why the -n option may be helpful, and you may get faster results in some circumstances without setting -aa 0. In particular, the variance of a -aa 0 calculation may be considerably larger than the irradiance caching method.

Cheers,
-Greg

13

Hi @Greg_Ward,

Thank you for your reminder regarding the calculation formula. I will follow your advice.

As for the -af, -n and -aa options, I am not sure if this is right or not. In my case, there are 1200 pixels in the pixels.pts. Each time, I will change the lights.rad files and calculate the scene once.

For scenario 1: I use the following command:

rtrace -h -I -ov -ab 3 -af cach.amb -n 8 scene1.oct < pixels.pts | rcalc -e ‘$1=179*(.265*$1+.670*$2+.065*$3)’ > lux1.csv

For the first time, it takes a longer time (9 minutes), because it needs to calculate the indirect radiance and generate the ambient file. For the following calculations (changing the light.rad file), I still use the above command, it takes less than 1 second to finish the calculation because it reuses the indirect radiance stored in the ambient file. However, the results for the following calculation are wrong because the indirect value corresponds to the first light.rad but I change the light.rad file in the following process. To obtain the right results, each time I change the light.rad file, the ambient file should be removed and the calculation should start over from scratch.

For scenario 2: for the first calculation, I still use the same command as above. But for the following calculations, I use the command:

rtrace -h -I -ov -ab 3 -aa 0.00 -af cach.amb -n 8 scene1.oct < pixels.pts | rcalc -e ‘$1=179*(.265*$1+.670*$2+.065*$3)’

In this case, the first calculation takes almost the same time as above. But the following calculation takes 4 minutes or so. Although it shows: rtrace: warning - zero ambient accuracy so "cach.amb" not opened, the ambient somehow facilitated the simultaneously executing processes. In this case, the calculation results are right, but as you said the variance may be considerably large (the test result also confirms this.)

For scenario 3, I use the following command, and each time it takes 8 minutes or so to finish the calculation. Although I use the -n option and I have 8 CPU, there is no -af option, so it will not all the CPUs to calculate but will more than 1 (like 4-5). Am I got it right?

rtrace -h -I -ov -ab 3 -n 8 scene2.oct < pixels.pts | rcalc -e ‘$1=179*(.265*$1+.670*$2+.065*$3)’

Best,
Hao

14

Hi Hao,

For scenario 1, you do need to remove the ambient file between runs, or name the ambient file something different for each version of your scene, to get correct results. Re-using the ambient file when something significant has changed in your scene will give you wrong answers as you noted in your first post.

There should be no difference in run time or accuracy between your scenario 2 and scenario 3, because the ambient file is completely ignored in the last case. 1200 irradiance sample points (not “pixels”) should make good use of your 8 processors in all cases, so I do not understand why you would be seeing different run times in the -aa 0 scenarios.

Regarding your scene changes, are you just changing the intensity (not position) of the lights? If so, there are more efficient ways to go about this using the rcontrib program.

Cheers,
-Greg

1 Like
15

Hi Greg,

Thank you so much for your reply. I appreciate it.

I am also confused about the different running times between scenario 2 and scenario 3. If I have more clues, I will share them here. For my scene changes, I only change the intensity of lights and I will follow your suggestion to try the rcontrib program.

Besides, could you please give an explanation about the function of -aa function? From the manpage, it shows that “This value will approximately equal the error from indirect illuminance interpolation. A value of zero implies no interpolation.” I am confused about the interpolation part. How is indirect illuminance interpolation used here?

Finally, could you please clarify the distinction between points and pixels in the context of lighting analysis?

Best regards,
Hao

16

The irradiance cache (interpolation) method is described in the 1988 SIGGRAPH paper near the bottom of my publications list. The original technique was actually updated to use the Hessian calculation described in this paper by Schwarzhaupt et al., with some modifications described in this talk. Setting -aa 0 turns this interpolation off, replacing it with a strict path tracing approach that is independent of previous calculations at every ray tree.

With respect to the difference between samples and pixels, the second is a subset of the first. Samples are generally any sample position for irradiance, radiance, any kind of evaluation point. “Pixels” stand for “picture elements” and imply that your samples are arranged or will be arranged into an image that is a projection of your scene. That’s all.

Cheers,
-Greg

1 Like
17

Hi Greg,

Thank you so much for your reply and explanation. This has clarified the terms for me. I will review the references and appreciate your assistance.

Best regards,
Hao