You’d think that DF would be much quicker because it simulates a point in time, whereas the annual one calculates for each daylit hour of the year.
What I have noticed is that the queenbee.exe command shows the following prompts for a long time before it finally exits:
Is that normal?
Hi @MaxMarschall,
Annual Daylight uses rcontrib and Daylight Factor uses rtrace. So you cannot simply use the same parameters. The parameters you have there is quite high for rtrace but it still only takes 10 seconds on my computer.
Do you the latest version installed?
Can you check the initial_results folder. I want to make sure that it does not split the grid among 11 workers, which is definitely not necessary with only 140 grid points.
Take a look at the default parameters in HB Radiance Parameter. Here I have the highest default parameters for rtrace (top) and rfluxmtx/rcontrib (bottom).
Hi @MaxMarschall,
Okay, not sure what happened but now it takes a longer time, which is also what I expected. So you can skip the first part (except making sure you have the latest version) of my first answer, and look at the parameters in HB Radiance Parameter instead.
I had no idea that RadPar component existed - Thanks!
It’s difficult to compare since the recipes use two different Radiance programs, but I don’t believe there is anything wrong. The timing associated with the parameters for Daylight Factor is just different. You will probably see a huge jump in time going from _detail_level_ 1 to 2 for rtrace but not for rfluxmtx/rcontrib.
Btw, @MaxMarschall, you should also consider this component if you run rtrace/rpict-based simulations. You can use it to set -ar.
I’m still curious about why the annual daylight simulation doesn’t take MUCH longer than Daylight Factor. After all, don’t they both do similar calculations, just that the annual daylight simulation repeats this for each daylight hour? In which case, shouldn’t it take literally thousands of times longer?
It also still seems to be the case though that reducing the ambient bounces has virtually no effect on runtime. The detail level 2 specifies 6 bounces for both recipe types. When I change it to 5, the combined runtime of the 2 components goes from 3.5min to 3.3min. I’d expect this reduction to be much greater - isn’t the relationship exponential?
@chris and @mostapha it would be great to hear your thoughts too!
I did a little test with the runtimes - is it normal that it plateaus like that?
For your information, the method used by rtrace to calculate illuminance values is deploying what is called “irradiance caching” (a way to calculate the luminance of certain points and then interpolate values for the rest of the points), which is very time-consuming depending on the -ar and -aa settings and your scene size.The rcontrib used in the HB annual recipe does not use irradiance caching, which is why rcontrib goes fasterm and the -ad value must be set to a much higher value.
Hi @IasonBournas, is there a way I can turn irradiance caching off (and would that have a huge impact on the accuracy?), or is that just part of the algorithm?
@chris I’m still concerned about this - I remember in previous versions how increasing the ambient bounces would exponentially increase runtimes - is that no longer the case?
Is it really the case that rays are terminated once they fall below a certain threshold as indicated here?
Hi Max,
You can turn it off if you set - aa to zero. The irradiance caching is used in the indirect calculation, i.e. in the part of the simulation that computes contributions that arrive on a point by means of reflection (diffuse reflection). If you turn that off, you will only calculate direct sunlight onto your points, and miss all that light that bounced its way onto your points. So yes, this is inherent in the algorithm and should be ON.
I’m not sure why you’re asking for my input here since both @mikkel and @IasonBournas are at a much higher level of “Radiance guru” than I am.
But, if you’re just looking for confirmation that the relevant parameters of rtrace (used by the Daylight-Factor/Point-in-time recipes) are very different from those of the rcontrib (used by the Annual studies), then yes. This is true. The responses of the other two gurus here are much better at explaining why this is the case than anything that I can offer.
Regarding raytracing in Radiance, rays are terminated if either one of the following is true:
Ray hits source (e.g. sky)
User-defined number of - ab is reached
Ray weight falls beliw user-defined - lw
This is true for any type of Radiance simulation. So the answer to your questiin is “yes”.
