CVS, ANSI

radiance-general
1

This is really a collection of notes on various Radiance software
engineering issues that I've gathered up into one message...

I think that who decisions about what code goes into mainline Radiance
is very important. I, at least, want very much to see the physical accuracy
of the simulation maintained; in my view it's the engagement with
the physical behavior of light that makes Radiance so very valuable in
architectural design. (I bow in the general direction of Greg Ward.)

Georg Mischler:
  Speaking more generally, I'd like to put in a strong vote for
  ansifying Radiance completely. Even though this might look like a
  highly tedious task (and probably is), I'd expect it to uncover
  and eliminate at least a one or two dozen subtle bugs throughout
  the code. In the long run, it would make all future development a
  lot easier.

Do I understand that you are thinking of using function prototypes
throughout? Then I agree it's an excellent idea--in fact, I would
like to see clean compilation with strict prototype warnings. The gcc
tool "protoize" might be useful in approaching the problem, but I say
that without experience with the tool. I also agree with Greg Ward
Larsen about the problems of conditional compilation (and so do the
Bell Labs developers of C, see
<http://plan9.bell-labs.com/sys/doc/comp.html>), and hope that whoever
handles the development avoids cluttering the code with conditionals
and their associated reliability problems.

Peter Apian-Bennewitz:
  positively a good idea. IMHO a full rewrite would be a better
  investment, timewise, than an ANSIfication, at least for the existing
  core rendering.

I agree with Greg Ward that this would be lot of work with no
guarantee of improvement at the end. The core of Radiance works
fairly well; I think we could get bogged down trying to perfect it.
Personally, I'd rather see effort spent on new facilities, perhaps on
better support of current graphics technologies, and updating some of
the associated scripts.

Also, tendered very cautiously, it might be worth removing some of the
older system components that are not much used, or at least relegating
them to unsupported status. I think, for instance, we could do
without Imagewriter support.<g>

That said, I will admit that I have had a very rough quarter at
school, and am unlikely to have much time to spend on this until the
fall of 2003, at least.

Randolph

2

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

3

An afterthought to my last message. The process of ANSI-fication should probably include a merge of the Desktop Radiance version, at least insofar as supporting Windows compilation as well. I don't know how much additional time this would take, as I'm not familiar with the changes that were made to the code on that branch. Some of them we might want to include, but I don't know how long it would take to sort it all out. Probably a couple of additional weeks and some good communication with the main Windows branch author(s).

-Greg