[Radiance-dev] Radiance cross-platform issues & GUIs, oh my!

[Gregory J. Ward]

Hi Randolph,

 From a performance standpoint, the vast majority of time is spent on  
the ray-tracing part for most of what people do using Radiance.   
Hence, there's not much point in optimizing the loading of scene  
files or connecting up the various subordinate utilities in dynamic  
libraries.  You simply won't save much over shelling out the commands  
and reading and writing the files or connecting up pipes (or whatever  
the Windows equivalent is).  If 99% of the time is consumed by rpict  
or rtrace or rvu, why bother optimizing the rest, especially if it's  
a ton of work?  You don't need dynamic libraries to create a GUI --  
schorsch has done quite well using Rayfront to generate the necessary  
inputs and parameters for Radiance commands and running them as  
separate processes.

You also have to think about what kind of functionality you are  
trying to add with your GUI.  A big reason Radiance is used in so  
many disciplines is thanks to the toolbox model, which allows you to  
combine programs in all sorts of ways the authors never intended.  A  
GUI typically defeats this benefit, unless you follow a data flow  
model in your interface.  Give the user a menu, take away 1000  
opportunities.  It makes the easy things easy, but the difficult  
things become impossible.

Judicious use of make and the oconv -f option ameliorates most of the  
pain of loading hierarchical Radiance scene descriptions, as the  
commands are only run the first time (or when the scene changes).

Having worked both on GUI applications (mostly Photosphere) and  
command-line tools, I know the programming paradigm is very  
different.  Lots of things will get you in a monolithic application  
that simply were not a problem with a set of tools.  Although I'm  
generally pretty good with memory, I don't usually free stuff in a  
tool when I know I'll need the memory until the process exits.   
What's worse, I will call exit(1) when something goes wrong, and  
error handling is generally much less robust in a tool environment,  
since individual processes are considered expendable.  I have  
extensive error management in Photosphere compared to Radiance, and  
it's not something that's easy to add as an afterthought.  You can  
play some games like "#define exit(s) my_return_jump(s)" using  
longjump(3), but you end up with a real mess in terms of memory leaks  
and the like.  (I've had to do this with the JPEG library, so I know.)

-Greg