[Radiance-general] Re: CVS, ANSI

[Greg Ward]

I like what Randolph had to say about code conversion.  There is a lot 
of accumulated fluff in Radiance, such as the various printer drivers.  
I never bothered to take them out because they still seem to compile, 
and they don't affect anything (other than taking up a bit of space on 
everyone's systems) since Radiance programs that are never run never 
interact with the rest of the codebase...  This is traditional, 
old-style modularity in UNIX -- a bunch of separate tools that work 
together.  It works well for many of the subproblems in rendering, 
except for the rendering process itself, which requires a rather large 
program to do the job properly.  Thus, we have rpict, rview, and rtrace, 
which could definitely use a bit of ANSI-fication and (in an ideal 
world) a major rewrite in C++.  I have had really good luck porting C++ 
between various platforms, even (shudder) Windows, though the tools 
there are horrible in my opinion, at least the Microsoft offerings.

I should mention that I am currently working on an image browser and 
cataloguer for JPEG and high dynamic-range images on Mac OS X, and I've 
been employing a combination of C++ (for new bits) with links to some 
old ANSI and non-ANSI C modules for reading and writing various 
formats.  I just put up with the compiler noise with the latter, but 
since I know the code works and it requires almost no maintainence at 
this stage, I just ignore it.  Perhaps I've gotten too used to ignoring 
compiler warnings over the years, but I'm sorry, casting every float 
assignment is just so tedious and so ugly, that I just switch certain 
warnings off even in my new efforts.

Rewriting oconv and the core renderers in C++ might be worthwhile, but 
it would take at least 6 months full-time, and would introduce many more 
bugs than it would eliminate.  In fact, I doubt it would eliminate any 
bugs.  I'm sure there are still a few lurking in there, and I'm always 
amazed when I find something that's been wrong with the code for years 
and never surfaced or had a harmless manifestation, sort of like junk 
DNA in an organism that evolved over eons...  And, as much as I'm 
getting comfortable with C++, which has to be the most overblown 
language since ADA, I think such a rewrite would ultimately be slower 
than the current C implementation, however carefully we approached it.

Having said that, if it started raining money over my house tomorrow, I 
would leave my job and devote myself to some serious development work.  
In particular, I've had some ideas brewing for years on a radically 
different approach to rendering, which eliminates explicit geometry 
throughout most of the scene, and uses a mathematical construct (TBD) 
for both geometry and light scattering.  I could see pursuing something 
like this in a Ph.D. program, but my current financial constraints don't 
permit me the luxury of enrolling in one.  Such a renderer, even if it 
worked, would probably be an adjunct rather than a replacement for 
Radiance, which has been carefully tuned for architectural rendering 
applications.

Getting back to ANSI-fication, the main problem I have in modifying the 
Radiance codebase is a lack of knowledge of what works on various 
platforms.  The portability fixes that have accumulated over the years 
are still functioning and useful, many of them, and some are useless.  
Separating one from the other is difficult for me, since I have limited 
access these days to different systems, though the proliferation of UNIX 
flavors seems to have slowed down at least, thankfully.  As long as we 
offer solid support of Linux, FreeBSD (including Mac OS X, my current 
fave) and Solaris, we should do pretty well.  Perhaps the thing to do is 
for each of you who has experience in the relevant systems to put 
together a list of compile problems you've noticed.  We could scour the 
code for #ifdef's and identify ones that can be eliminated or aren't 
working properly.  I have kept these to a minimum, so that shouldn't 
take long.  Third, we could identify useless programs that don't need to 
be supported in the main distribution.  Finally, we can begin on 
function prototypes and header inclusion for ANSI-C, making sure our 
calls are to supported system and library functions, rather than ones 
that may become obsolete.

We're probably looking at a week or two of one programmer's time, and a 
few hours from each volunteer.  Who wants to step forward?

-Greg