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

[R Fritz]

> 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.

I haven't seen Rayfront in a few years, so I don't know where it's  
gone; I have seen Ecotect, and it's cranky. And you're right, of  
course, that to overall rendering time improving oconv doesn't matter  
very much, but to the user experience it does matter; people complain  
about oconv delays, even though they're not most of the time it takes  
to use Radiance.

> 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.

The intention is to maintain the existing toolbox, and also have a GUI.

> 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).

Mmmm...I'm aiming at a different user base.

> 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.)

Ow. That's non-trivial. I suppose using garbage collection, and  
trapping the exit() calls in atexit() would resolve most of these  
issues, but it would have to be looked at carefully. Ideally only  
include it in the wrapper code, so that the existing apps would  
continue to work as before. Maybe the Boehm/Demers/Weiser collector?  
Anyone have any experience with it?

Randolph

Ref: Boehm GC, <http://www.hpl.hp.com/personal/Hans_Boehm/gc/>