Multiple windows in 3PM for masterplan evaluation

[Tobias Pedersen]

Hi,

I have recently started working with Accelerad due to its great increase in speed over Radiance. 

Is there a smart/fast way to conduct the 3PM on buildings zones with multiple windows on masterplan level (i.e. many building zones and large context geometry model)?

From https://www.radiance-online.org/learning/tutorials/matrix-based-methods
I realize that it is possible to compute V and D matrices for each windows and then combine results at the end. However this methodology seems rather slow, since you are recomputing the irradiance cache/ambient values in each calculation.

A faster approach is to use the 2PM using the "glass" material in the windows, but then the ability to quickly iterate different CFS (BSDF) is lost.


Lastly thank you for creating Accelerad !

Best regards Tobias

[Nathaniel Jones]

Hi Tobias,

Your question about using the three-phase method for multiple windows is really a Radiance question, as there's nothing different about the way that Accelerad handles this. I see that there is a similar discussion about Radiance happening on UnmetHours.

The multi-phase methods (2-, 3-, or 5-phase) don't make use of an irradiance cache or stored ambient values. There wouldn't be a way to do this between separate view matrices, since the contributions from each window are separate.

Nathaniel

[Tobias Pedersen]

Thank you, this was what I was looking for!

I'm surprised that multi-phase methods don't make use of ambient values. E.g. for a single zone 3PM daylight calculation all light sources will be glow and all raytracing will then be stochastically sampled (https://www.radiance-online.org/community/workshops/2011-berkeley-ca/presentations/day1/JM_AmbientCalculation.pdf). Isn't that when irradiance caching is then used  ?

[Nathaniel Jones]

Hi Tobias,

Matrix-based methods (such as the three-phase method) take a fundamentally different approach to illuminance calculation from the approach outlined in John Mardaljevic's presentation. Traditional light backward raytracing (or distribution ray tracing) works by accumulating all of the light that arrives at each point and then calculating how much is reflected to the viewer. For diffuse lighting, this information can be stored in an irradiance cache and reused. However, by accumulating values in an irradiance cache, information about the original source of the light is lost.

The three-phase method does not accumulate any light at intermediate points in the ray path. Rather, it determines the contribution of each source (which could be a glow or any other material) to the final result. Because there is no illuminance calculation at intermediate points, there is no use for an irradiance cache. The advantage is that the resulting contribution coefficients (or daylight coefficients) may be multiplied by any vector of source brightness to generate the illuminance levels under that condition. This can't be achieved by traditional ray tracing.

Nathaniel

[Tobias Pedersen]

Hi Nathaniel,

Thank you for the elaboration!

I have gotten feedback on radiance discourse, on how to potentially speed up 3PM calculations for zones with multiple windows. And you are correct that irradiance cache values are not used in rcontrib. An option with Radiance is to use CPU multiprocessing, but this does not apply to Accelerad. I guess the ideal solution would be some sort of "contribution coefficient cache". If find any further ideas of how to speed up a Accelerad based 3PM on a zone with multiple windows, they are highly welcomed. 

Many thanks,

Tobias

[Nathaniel Jones]

Hi Tobias,

The GPU parallelism offered through Radiance achieves the same effect as CPU multiprocessing, and for most people GPU parallelism will offer greater speedup because it makes vastly more cores available.

The "contribution coefficient cache" is more or less what Daysim provides. However, as I've pointed out previously, Daysim is slower and less accurate than the three-phase method and does not parallelize well because it requires keeping so much data in memory for each ray.

Nathaniel