[Radiance-dev] thoughts brewing...

[Gregory J. Ward]

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