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

R Fritz rfritz at u.washington.edu
Wed Jul 9 09:22:57 PDT 2008


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

That was basically my thinking; the C++ streambuf template is a  
wonderful thing; one might even be able to get away with using the  
istrstream and ostrstream classes in many cases, preserving the  
existing model with very little effort. The second thought was to (in  
places where operations can be serialized) copy globals to class  
instance variables, thereby encapsulating the existing app in the  
class. This clearly won't work in all cases, but it might work in  
enough to be worth using.

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

If it turns out to be possible, I think there would be a substantial  
gain in the speed of reading of scene description files because of a  
reduction in process creation, especially on Windows, where processes  
are heavyweight. Even on Unix, creating two processes for a common  
operation like xform seems to me a lot of overhead, especially when  
one of those processes is a large modern shell. I agree it would be  
harder to maintain--memory leaks and unbounded pointers are a pain in  
a large app--but not that much harder; large applications do this all  
the time, these days. Hopefully, it could be done with a minimum of  
changes to existing code. I would like to try, at least, provided I  
can find the time.

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

No, that I don't--anyone else? But it seems to me that this is at  
least a plausible approach, and one that preserves most of the  
existing code and model. I very much like the Unix toolbox model.  
Unfortunately, the current widely used UI technologies are hostile to  
that model and I would like to adapt Radiance to work with those  
technologies.

> Anyone else have thoughts on this?

Please!

Randolph




More information about the Radiance-dev mailing list