As most of you know, Christoph Reinhart's Daysim program offers an efficient means to perform annual simulations based on a modified version of Radiance. I am planning to meet with Christoph (for the first time) on Monday to discuss how this calculation might be incorporated into the main distribution. I confess that I haven't spent much time looking at the modifications, but from my understanding of the method, it requires conditional compiles in a lot of different routines, which makes me nervous.
So, I was thinking there might be a less invasive approach that would enable not only programs like Daysim but other applications as well, such as optical and daylighting systems design.
The basic idea I'm considering is to introduce some new "recording" material type(s) that will output ray path "relationships" discovered during the rendering/tracing process. Each ray that intersects a surface with the given material will be stored in a named data file as:
origin_x origin_y origin_z odir_x odir_y odir_z
dest_x dest_y dest_z ddir_x ddir_y ddir_z
weight_r weight_g weight_b
The origin and direction would correspond to the initial primary ray, and the RGB weights could be computed accurately, corresponding to the transmission and reflection of all surfaces encountered along the way. Using floats, this data amounts to 60 bytes/ray, which is going to add up quickly, so I'd probably offer the option of outputting to a program rather than a file, which could do the processing on the fly.
In a program like Daysim, we might create a recording source that captures the sky intersections and correlates them to particular origin points, either on an image or a workplane or whatever. These correlations could then be applied in a daylight coefficient approach.
Note that the above will not work for diffuse interreflection unless -aa is set to 0, so we don't hide contributions by the caching process. However, I think this is something we can live with -- it's still more efficient than computing a great many runs for different sky sources, as John Mardaljevic and others have been doing successfully for years.
This method has the advantage that it requires only minimal, isolated, and easy to maintain changes to the source code. The main change is in the use of the rcol member of the RAY struct, which will now mean one thing going out (the ray coefficient) and another thing coming back (the ray value -- its current meaning). To this we add a material type and corresponding module to record the ray relationships -- not a big deal.
With such an addition, it should also be possible to use Radiance for certain optical design problems that it hasn't been able to do before -- ones where we are attempting to characterize some complex input/output relationship. However, not having thought about these problems before, I'm hoping to get some feedback before I do this as to things I might be forgetting.
-Greg