This seems to be a perennial topic for this list. I recommend that you review the discussion from Dec. 2003 on this list under the thread "Quo Vadis Radiance" -- most of these points have been hashed through there.
From: "Michael Kruger" <[email protected]>
Peter Apian-Bennewitz wrote:
Doesn't solve the problem that there's no /need/ for CVS
access, does it ?
One could argue that there's no need for CVS because there are
so few developers. And there are so few developers because there's
no CVS access...
Anyone who likes can download the changes the moment they are checked in via Peter's wonderful HTML-based CVS source code access at <http://www.radiance-online.org/cgi-bin/viewcvs.cgi/ray/>. It will deliver diff's, change comments, anything you like. I use it all the time, as it's a much easier interface than CVS and you don't have to deal with commands and remnant files where they don't belong. Any serious changes or additions are marked in the ray/doc/notes/ReleaseNotes file, which may be accessed via:
http://www.radiance-online.org/cgi-bin/viewcvs.cgi/ray/doc/notes/ReleaseNotes
The HEAD release contains yesterday's changes in one bundle. There is generally no need to keep up with the release on a daily or even a weekly basis, because the code simply doesn't change that quickly. I personally prefer it that way, as many developers and many code changes would likely lead to more bugs, need to track them, etc., etc. I don't have time for that, myself. If the majority of folks want it, then the code is OpenSource and I could not and would not stop you from taking that path. Unfortunately, I wouldn't be able to follow you on it.
One possibility is to put Radzilla on such a program, but we need to involve Carsten in that discussion. Since Radzilla is specifically addressing more the artist than the engineer, reliability is deemphasized in favor of coolness, and he has already made numerous changes in this direction. Perhaps Carsten would like some help?
I don't see/feel a large common dominator
between the Radiance users and computer guys used to anon
CVS. Not unless Radiance swims the mainstream of CG and given
today's abstraction level of the rendering core (or the
absence of it) I'd be surprised if that happens soon.
There may not be a common denominator at the moment, but might that
only be because we're missing out on a large audience who are:
a) mainly interested in projects that have a community-based approach,
instead of top-down;
Name a piece of simulation software that was developed by a community. I'm not saying there isn't one, but it seems unlikely given the small target audience and simulation's critical nature.
b) those who need a simple installer & extensive doco; or
Schorsch has been working on a better installer based on SCONS. Have you tried it? Regarding developer documentation, there is a chapter on the website, though it's a bit out of date:
http://radsite.lbl.gov/radiance/refer/srctree.pdf
c) those who require a modular rendering engine that uses CG industry-
standard inputs & outputs?
This is useless for lighting design, as none of the CG industry standards handles photometric data. If you're talking about a new market for Radiance, again I would say that a different direction is indicated. Simulation and art serve very different purposes.
As I see it:
1) If we want radiance to become _really_ popular, then it could do with
Several improvements, like making it much simpler to install, increased
flexibility, exporters, or baking.
What's the point? There are already 100's of rendering tools out there that are better suited to popular tastes. Why try to make Radiance into something it's not? It currently occupies a unique niche, and there are people who depend on it. (Me, for one.) If you turn it into a RenderMan look-alike, you will lose everything that makes it special, and leave those who rely on it at a standstill.
2) These kind of requirements need multiple core developers.
No argument there. A revenue stream would be nice as well. (OpenSource has a poor track record in that area.)
3) I would like to contribute to radiance, but am put off by the
rather exclusive stance the project has over source contribution.
There are reasons for being exclusive, the main one being reliability of the simulations. Again, I refer you to last year's thread. If you have a tool you want to add to the system, CVS access is hardly required. You can ship your contribution to me or Schorsch and we'll be happy to check it in. All we need is the C source and a man page. If you want to modify existing source, that's where reliability becomes a concern. Is this what you have in mind?
I'd really love to see some decent documentation on developing
with radiance. A wiki would be a fantastic step forward. A central
bug, request, & code repository would be ideal.
Documentation is great, but who's going to write it? Rendering with Radiance has a lot of stuff on the algorithms and how they're coded, and that's always the first place to look. If you're after information on how to develop with Radiance, then I'm probably the one to ask. I'm always happy to answer questions, and offer tips if you have something in mind. Offhand, I have no idea what a developer's guide would look like for Radiance, other than the source tree document above.
As for a feature request and bug reporting system, I think it's a great idea. I fix bugs just as soon as I hear about them, which usually happens through the dev or general mailing list these days, or from people who write to me directly. It would be nice to have a central place for reporting and feature requests, though the latter might not get the attention they deserve. I'm not sure how a wiki would work -- until your mention of it, I didn't even know the term.
-Greg
I don't want to put any of your efforts