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

[Gregory J. Ward]

Hi Randolph,

Just a quick comment on your idea of implementing a mini-shell within  
Radiance's scene description language -- I assume you mean this to  
take care of the "!command" lines in the input, correct?  In any  
case, you should not underestimate the difficulties in converting  
even a small number of command-line tools into library calls, as the  
general assumption of separate process spaces means the use of i/o  
and globals is a big mess to clean up.  Personally, I can't imagine  
it being worth the effort, as there would be no real gain in  
functionality, and worse maintenance headaches down the line.  Taking  
a system like Radiance, which is based on the Unix toolbox model, and  
turning it into a set of library routines, is not a weekend task.  Do  
you know of any examples of systems that have been successfully  
converted in this way?  I'd be interested to hear of any.

I'm curious how a system like Radiance could be fit into a set of C++  
classes.  There must be a way, and I'm not saying it's a bad idea,  
but the general toolbox approach is standardized on a (preferably  
small) set of stream data formats.  I guess you would try to hook the  
output of one object into the input of another, or something like  
that.  It seems feasible, at least in principle.

Anyone else have thoughts on this?

-Greg

> From: R Fritz <rfritz at u.washington.edu>
> Date: July 7, 2008 10:24:21 PM PDT
>
> I've been looking into this. I'm planning a thesis involving  
> Radiance, so I think I'll have some time to put into this. (I am  
> probably rehashing older discussions here; forgive me.)
>
> I'm looking at a cross-platform set of build scripts, which I think  
> are plausible now that we're down to three or four platforms,  
> though I'm going to carefully avoid the problem of building, for  
> instance, X windows components on Microsoft Windows. These proposed  
> scripts are intended to be in addition to current scripts rather  
> than replacements. I think I can make these simple and effective;  
> we'll have to see how well I do.
>
> Perhaps I can embed most of the the existing commands in C++  
> classes. Ideally, all the current code would be left unchanged;  
> this would also be "in addition to," rather than "instead of". The  
> classes could then be invoked from conventional cross-platform GUI  
> code. I am looking at WxWidgets for the GUI, but in principle any  
> GUI classes or functions could be used--even native Windows or Mac  
> classes.
>
> One area where I think Radiance might reap some benefit from  
> changes in the core code--though if the community doesn't want to  
> go this way I'll leave it be--would be to integrate some shell  
> functionality in the processing of the Radiance Scene Description  
> Language (RSDL?) Perhaps we can imagine an rdsl_open() routine  
> which contains a simple non-interactive shell and implements pipes,  
> simple argument quoting, xform, tmesh2rad, gen*, and perhaps a few  
> other operations as built-ins. Anything complicated and shellish  
> rdsl_open() would forward to the system shell, with the  
> understanding that this makes the RDSL code system-dependent. This  
> would enormously simplify Microsoft porting, and might even lead to  
> speed improvements in oconv, since it would trade memory for  
> process creation. Memory is cheap these days; probably cheaper than  
> Unix processes and probably much cheaper than MS processes.
>
> What do people think?
>
> Randolph