Quo Vadis Radiance ...

Hi,

the recent photon-map thread left me - once more - rather puzzled. OK, I haven't any active Radiance-projects going on right now, so I look at the matter from a little distance. But from a distant point you often see things better :slight_smile: Furthermore, I myself have developed a (small) Radiance-addon, and I'm one of the (seemingly still few) people who have already used the photon-map, so I feel the need to add my statements to this discussion .

Concerning the photon-map istelf, I cannot say that much, as I only used it once (reason: see above) for a Visualization case ( a rather challenging one). I patched the code in, made some tests to get aquainted with the option settings and then let it loose on the image. And- it simply worked ! (How boring ....), produced what I wanted to have and what was to be expected by physical reasoning. Hey, isn't that what a tool should do??? There are some drawbacks, one e.g. is the awkward handling, having to produce an extra pmap doesn't sound much but nevertheless is inconvenient. It should go somehow automatically, by setting some controlling options -Px xxx -Pf filename etc etc.. in a .rif file for rad.
The other is not really one, of course one has to learn a bit of new stuff (what means 1 million photons for the current scene, shall I mix 50 or 100 photons in the gathering process, etc.) but these things are more intuitive than some other classic options like -ar and -aa. From my experience in developing the direct cache I know that its not easy to translate the limitations of the machine into parameters which are easy to understand, covering all cases, being only a few etc

So far for this point. Now to the discussion. In some days time we have 2004, not 1984. I've dug deep into the Radiance code and learned a lot by it, but no matter how sophisticated it once was/is, the outside world has moved on. Now we have new tools and concepts (pmap is only one example), which basically make use of the fact that todays machines have far more memory (and higher speed, of course), but - many apologies for the harsh word - instead of integrating them a lot of pea-counting is going on in the discussion.

I can image that, if machines where as capable back then as they are now, something like the pmap would already have been written long ago. Greg himself called for a forward module in the 'Rendering with Radiance' book. This holds especially, as pmap is no exotic stuff, its not some hacking performed by some freak sitting in his cellar behind his machines (OK, in this case it IS programmed by a freak, but thats a different story ... :-)) , there's a research institute behind it, there a validation measurements/caculations going on, apparently being successful in a wide range of cases. So, if pmap right now doesn't support some of the strange transdatafuncwhatever primitives, which maybe one in a thousand users uses once in his lifetime, is that a reason to exclude this tool from the distribution? Was Radiance as complete and almost bug-free as it is now right from the beginning? Work in progress, thats what software is about!

A lot of argumentation has already been layed out in the preceding thread, so I don't need to repeat it. I don't see any technical reason to exclude the tool, especially as it only interferes if switched on deliberately.
But apart from the technical facts, there are other things in life, e.g. there's politics. So far, Radiance is connected to the name of Greg Ward (and LBNL), and I understand that there is a high concern that the program maintains its high quality standard and is kept free of whicky whacky gimmicks. But looking at the complexity of the matter, I doubt that one person alone, no matter how fit he is, will be able to administer and futher develop the software. So the real question is, is there a will to continue the development as a team effort, inevitably including code writen by someone else? What's the alternative? Don't move on and become out-of date and finally forgotten? Not a real alternative, I think...

so long for now

-Carsten

Carsten Bauer wrote:

Hi,

Ahoy, Capt. B! :^)

I patched the code in, made some tests to get aquainted with the option settings and then let it loose on the image. And- it simply worked ! (How boring ....)

Aw, damn, not even a SEGFAULT?!? :^)

pmap is no exotic stuff, its not some hacking performed by some freak sitting in his cellar behind his machines (OK, in this case it IS programmed by a freak, but thats a different story ... :-))

Um, a *post-graduate* freak sitting in his cellar at an SGI mini-fridge, to be precise... :^)
(And I'm only confined to the cellar 'cos I can't move the bloody thing anywhere else!)

So, if pmap right now doesn't support some of the strange transdatafuncwhatever primitives, which maybe one in a thousand users uses once in his lifetime, is that a reason to exclude this tool from the distribution? Was Radiance as complete and almost bug-free as it is now right from the beginning? Work in progress, thats what software is about!

Hear, hear... there's a good point: if the code's not disseminated on the grounds that it's allegedly dodgy or half baked, nobody else (aside from the developer) will test it, consequently it'll *never* mature to the point where it's ready for business (potentially in every sense of the word).

So the real question is, is there a will to continue the development as a team effort, inevitably including code writen by someone else? What's the alternative? Don't move on and become out-of date and finally forgotten? Not a real alternative, I think...

There *are* political issues which need ironing out, and I think that's imperative in order to secure further development (dare I say, survival?) of RADIANCE, not just in the case of pmap, but for other contributions from the community in general. There are potentially hundreds of addons (well ok, maybe dozens... a handful... one???), screaming: "WE WANT IN!" :^)

--Roland

路路路

--
Roland Schregle
PhD candidate, Fraunhofer Institute for Solar Energy Systems
RADIANCE Photon Map page: www.ise.fhg.de/radiance/photon-map

END OF LINE. (MCP)

I want to respond to this thread while it's still warm, because Carsten made a number of excellent points, which deserve special attention. I wish I weren't so preoccupied these days with other projects, but I wouldn't have anything to eat otherwise, so I can't complain....

Out of laziness, I'm going to address these points inline.

From: [email protected] (Carsten Bauer)
Date: December 5, 2003 5:45:11 AM PST

the recent photon-map thread left me - once more - rather puzzled. OK, I haven't any active Radiance-projects going on right now, so I look at the matter from a little distance. But from a distant point you often see things better :slight_smile: Furthermore, I myself have developed a (small) Radiance-addon, and I'm one of the (seemingly still few) people who have already used the photon-map, so I feel the need to add my statements to this discussion .

Concerning the photon-map istelf, I cannot say that much, as I only used it once (reason: see above) for a Visualization case ( a rather challenging one). I patched the code in, made some tests to get aquainted with the option settings and then let it loose on the image. And- it simply worked ! (How boring ....), produced what I wanted to have and what was to be expected by physical reasoning. Hey, isn't that what a tool should do??? There are some drawbacks, one e.g. is the awkward handling, having to produce an extra pmap doesn't sound much but nevertheless is inconvenient. It should go somehow automatically, by setting some controlling options -Px xxx -Pf filename etc etc.. in a .rif file for rad.
The other is not really one, of course one has to learn a bit of new stuff (what means 1 million photons for the current scene, shall I mix 50 or 100 photons in the gathering process, etc.) but these things are more intuitive than some other classic options like -ar and -aa. From my experience in developing the direct cache I know that its not easy to translate the limitations of the machine into parameters which are easy to understand, covering all cases, being only a few etc

So far for this point. Now to the discussion. In some days time we have 2004, not 1984. I've dug deep into the Radiance code and learned a lot by it, but no matter how sophisticated it once was/is, the outside world has moved on. Now we have new tools and concepts (pmap is only one example), which basically make use of the fact that todays machines have far more memory (and higher speed, of course), but - many apologies for the harsh word - instead of integrating them a lot of pea-counting is going on in the discussion.

Funny enough, the first lines of Radiance were entered in the fall of 1985, so I guess it's turning 20 in a year's time.... One of the big reasons that Radiance is still relevant while the rest of the world has "moved on" is that as computers have gotten faster with more memory, it still has the basic efficiency of a system that was designed to run reasonably well on a slow processor with a few megabytes. This means that when it's set loose on today's multiprocessor machines with a gig (or two) of RAM, there's almost no limit to what you can do with it -- and all I had to do for this was allow for really large arrays! (The block sizes and so forth have grown incrementally as the years have gone by.) Since physical simulation will always be able to suck the life out of any computer as the basic problem is technically unsolvable, every year this community welcomes the newer, faster machines with open arms. This is not to say that Radiance is the be-all and end-all of lighting simulation tools. Clearly, it's algorithms could benefit from additional improvements, and the photon map is clearly one example.

I can image that, if machines where as capable back then as they are now, something like the pmap would already have been written long ago. Greg himself called for a forward module in the 'Rendering with Radiance' book. This holds especially, as pmap is no exotic stuff, its not some hacking performed by some freak sitting in his cellar behind his machines (OK, in this case it IS programmed by a freak, but thats a different story ... :-)) , there's a research institute behind it, there a validation measurements/caculations going on, apparently being successful in a wide range of cases. So, if pmap right now doesn't support some of the strange transdatafuncwhatever primitives, which maybe one in a thousand users uses once in his lifetime, is that a reason to exclude this tool from the distribution? Was Radiance as complete and almost bug-free as it is now right from the beginning? Work in progress, thats what software is about!

In a research institution, this is true, and for many years, Radiance was a research tool and nothing more. Now, there are a number of engineering/design firms that rely on it, and subjecting them to new features that are not field-tested is more of a problem than it once was. However, you make a good point. How can the software improve if it isn't allowed to change? Here's where we can look at the process behind high quality commercial software development. As I understand it, real software goes something like this:

A) Maintain and support current version of software with patches, bug fixes, etc., while simultaneously:
B) Developing and testing new version "in house" and with select alpha users who are happy to ride the crest of the wave knowing full well the risk of wiping out.
C) When the alpha testers are satisfied that the new additions are working, release to a larger number of beta testers, who employ the software in the field, until:
D) The new version is considered ready for release. At that point, the old version is phased out, and users are encouraged (if not forced) to upgrade to the new release if they want support.

The obvious problem with the above is that it assumes:

1) There is a large user base from which to pick alpha and beta testers and get money, and
2) There is a large group of closely cooperating program developers with at least one product manager

Neither are the case for Radiance, and we have to face this reality. Our user base is small, there is no money for development, and the number of programmers available to fix problems can be counted on one hand by a tree sloth. Obviously, we need to modify this approach to have a working development pipeline. Here is what we currently have:

A) A few programmers (well, two at the moment) maintain and support a "live" release of the code, which includes bug fixes as well as some new features that may be under construction, but which do not affect the operation/reliability of the main tools.
B) Everyone who wants the latest bug fixes volunteers for both alpha and beta testing by default.
C) A new "official" release is made when the code seems to have more-or-less stabalized.
D) Go directly to A. Do not pass Go; do not collect $200.

The up side of this process is that the next release should be relatively bug-free, because folks all along have been compiling it and using it on various systems. (This was NOT true of the 3.5 official release, which didn't benefit from the accessible CVS HEAD we have now.) The down side is that the developers can't take big risks during development that might impair or corrupt the HEAD code tree. All our check-ins have to be good ones -- a difficult goal when you're attempting any major changes, to be sure. If I weren't using Radiance all the time in my work these days, I would never attempt to modify it -- only fix bugs. Because I do use it, I have some assurance that my HEAD changes are working, so long as my renders proceed nicely, as I don't tend to change code I'm not using at the moment. This is the main benefit of a mature, stable system.

Given that people rely on this software as I do, it would be irresponsible for me to make changes and additions that undermined its basic functionality. When I add some major new facility to the system, I try to make it a separable piece, so that users can choose to apply it or not. If they don't, it shouldn't affect their work. If they do choose to apply a new feature, it should interact with the rest of the system in a predictable way. If there is some feature that is not supported, such as a material type that is just too difficult to deal with, a fall-back solution should be applied and a warning message should appear. Crashing behavior and fatal errors caused by perfectly valid input should be avoided at all costs, especially in the core tools. If the photon map code doesn't support BRTDfunc's (or whatever), they can grab the diffuse parameters and simulated it that way, posting a warning so the user is aware of it. If it is too difficult to post a warning message, we must at minimum document the shortcoming, but we should not prevent the use of a particular model just because it uses an unsupported material. This is my opinion and my practice, not some kind of law. If people disagree, let's hear it.

Many years ago, while I was still at LBL, I made an aborted start on a forward-tracing tool. I abandoned it when I realized that it was a sizeable effort, and there was no funding forthcoming. It wasn't because computers weren't fast enough or didn't have enough memory as Carsten supposes -- the problem was and always seems to be insufficient time and/or money. My concept was to create a tool completely separate from the renderer that would supplant mkillum and work much in the same way, producing illum sources that could then be applied by rpict/rview/rtrace. This would ensure that the existing system continued to work as it always had, without any new options or odd behavior. If Roland had implemented the system in the same way, there would be no hesitation from any of us to include it in the next release, because there would be no risk to existing programs. Users could apply it or not, and they wouldn't have to decide at compilation time whether it was useful or not.

A lot of argumentation has already been layed out in the preceding thread, so I don't need to repeat it. I don't see any technical reason to exclude the tool, especially as it only interferes if switched on deliberately.
But apart from the technical facts, there are other things in life, e.g. there's politics. So far, Radiance is connected to the name of Greg Ward (and LBNL), and I understand that there is a high concern that the program maintains its high quality standard and is kept free of whicky whacky gimmicks. But looking at the complexity of the matter, I doubt that one person alone, no matter how fit he is, will be able to administer and futher develop the software. So the real question is, is there a will to continue the development as a team effort, inevitably including code writen by someone else? What's the alternative? Don't move on and become out-of date and finally forgotten? Not a real alternative, I think...

I couldn't agree more. I don't have time to advance Radiance as I would like to, and no one is paying me to do so, either. I have a family to support and bills to pay, and less leisure time than I would like. LBNL has done its best to support the system and continue development through lean times, but they released it as OpenSource with the express hope that others would take responsibility for its further development. Volunteers, welcome! Trust, however, is still an issue. I have difficulty trusting code I haven't used myself, and the same difficulty recommending it to others when asked. Likewise, LBL has asked me to make sure that all official development efforts maintain the basic program validity, so that they feel safe continuing to have their name and reputation tied to it. Given the circumstances surrounding Roland's photon mapping addition, I have every reason to believe that it performs well and is a useful and valuable addition. However, that isn't the same as saying that I've tried it and it's as solid as the rest of the system.

I am not a dictator, even if I sometimes sound like one. I'm more like a custodian. Radiance is a useful tool despite its age, and I rely on it myself for the majority of my projects. For selfish reasons, I wish to keep it stable, and I'm loathe to trust additions I haven't made myself or assured myself of their sanity. In the process of keeping it solid for my own purposes, I end up keeping it solid for other users as well. Years of reading Schorsch on this list, hearing his suggestions, and seeing his code modifications have brought me to a point of trust, where I can well believe that the changes he makes are not going to screw me up, or screw anyone else up. I trust him to watch over the code while I'm away, so to speak.

I don't think I'm alone with the trust issue. I know a number of groups, who are using Radiance in their work, but still have not upgraded to 3.5 out of concerns of its reliability. They wait until they have some compelling reason to upgrade, and given that new Radiance releases generally have only modest improvements over previous releases, I can't say I blame them for hanging back. On the other hand, maybe a cool new addition is just what's needed to encourage people to upgrade. Who knows?

Why don't we take a survey? Anyone who has read this far has to be interested in these issues, so let's hear from you.

Q1: Have you tried the photon map addition? Why or why not?
Q2: Would you try the photon map if it were added to the HEAD release?
Q3: If the photon map were added to the next official release, would it:
聽聽A) Encourage you to upgrade?
聽聽B) Discourage you from upgrading?
聽聽B) Make you want to wait and see what others thought of it, first?
聽聽C) Make no difference to your decision?
Q4: What features would you really like to see added to Radiance?
Q5: What is your main complaint about Radiance from a user's standpoint?
Q6: What do you think of the current development arrangements?
聽聽Q6a: Would you like to see more people involved in Radiance development?
聽聽Q6b: Would you like to participate in develoment, yourself?

If others agree, I'm happy to accept Roland's code into the HEAD release as a conditional compile. This seems reasonable enough to me; that way, people who want to try it can just flip a switch and give it a go, and those who have no use for it can leave it out. We should learn quickly enough what the problems are that way. I'd like to make a goal of switching on the flag by default in the next official release if we go this route, assuming there are no unresolved problems.

As I said, I would have preferred this as a completely separate tool rather than something built into the renderer. The renderer is complicated enough as it is, and it's quite a challenge to add to it without bending or breaking some other piece -- this is the crux of my hesitation. As an experiment, however, I see no reason not to proceed. We could add it as a CVS branch initially if we want to be paranoid about it, but I'm happy to defer to others on that decision.

-Greg

Greg Ward wrote:

A) Maintain and support current version of software with patches, bug
fixes, etc., while simultaneously:
B) Developing and testing new version "in house" and with select alpha
users who are happy to ride the crest of the wave knowing full well the
risk of wiping out.
C) When the alpha testers are satisfied that the new additions are
working, release to a larger number of beta testers, who employ the
software in the field, until:
D) The new version is considered ready for release. At that point, the
old version is phased out, and users are encouraged (if not forced) to
upgrade to the new release if they want support.

There's a variation of that pattern in use by a growing number
of Open Source projects. They have alternating "production" and
"development" versions, where usually the minor version number
indicates which is which. Even numbers are considered stable.

At one point in the development, the development version will get
branched into the production version. On this branch, there will
only be bug fixes up to the official release, and critical fixes
from the following development branch will be backported after
that. In the development version, there can be snapshot (or
"milestone") releases once in a while, which are usually made
before work on some big new feature is started.

We're not running under CVS long enough for this to be practical
yet, but maybe we could do something similar after 3.6 is out.
I don't know if that would have any negative impact on the number
of testers for the development branch. Seeing the type of people
who ride the front wave right now, I'd expect them to keep doing
the same thing in either case, though. For the others who just
want the most current stable release, having a stable version
available that gets critical bugfixes backported would be an
improvement over what they get with 3.5 right now.

Crashing behavior and fatal errors caused by perfectly valid
input should be avoided at all costs, especially in the core tools.

That's a much clearer phrasing of what I already tried to say.

If the photon map code doesn't support BRTDfunc's (or whatever),
they can grab the diffuse parameters and simulated it that
way, posting a warning so the user is aware of it.

Warnings would be an acceptable start. Maybe a choice for the
user between performance (with warnings) and the apparently very
slow full sampling could be added later, assuming it proves to be
useful.

As an experiment, however, I see no reason not to proceed.
We could add it as a CVS branch initially if we want to be paranoid
about it, but I'm happy to defer to others on that decision.

If we do a branch for this, I'd prefer it to be as short lived as
possible. Although adding the photon map is a big conceptual
step, it appears to be only minimally invasive on a coding level.

-schorsch

路路路

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

Greg Ward wrote:

Funny enough, the first lines of Radiance were entered in the fall of 1985, so I guess it's turning 20 in a year's time....

Wow, fall of '85 I was starting my senior year of High School, busy hamming it up in hopes of being voted class clown for the yearbook -- which I'm fairly certain distracted me from tackling Algebra II that year.

As I understand it, real software goes something like this:

A) Maintain and support current version of software with patches, bug fixes, etc., while simultaneously:
B) Developing and testing new version "in house" and with select alpha users who are happy to ride the crest of the wave knowing full well the risk of wiping out.
C) When the alpha testers are satisfied that the new additions are working, release to a larger number of beta testers, who employ the software in the field, until:
D) The new version is considered ready for release. At that point, the old version is phased out, and users are encouraged (if not forced) to upgrade to the new release if they want support.

F) Ignore the screams of loyal users who have discovered that features they relied upon have been phased out in the new version, and despite the developer's assurances to the contrary, the little lighting design community is being blown off once again. (thank you, Autode$k.)
G) After screams die down, market your pseudo-physically-based renderer to the massive-yet-uninformed architectural community. Call it Viz4.
H) Count money.

Why don't we take a survey? Anyone who has read this far has to be interested in these issues, so let's hear from you.

Q1: Have you tried the photon map addition? Why or why not?

No, mainly because I feel like I'm still learning Radiance Classic. That said, this latest round of discussion about the photon map module really has piqued my curiosity.

Q2: Would you try the photon map if it were added to the HEAD release?

Probably, yes.

Q3: If the photon map were added to the next official release, would it:
聽聽聽聽A) Encourage you to upgrade?
聽聽聽聽B) Discourage you from upgrading?
聽聽聽聽B) Make you want to wait and see what others thought of it, first?
聽聽聽聽C) Make no difference to your decision?

C.

Q4: What features would you really like to see added to Radiance?

Since I only use 20% of Radiance's features now, I'm not really wanting for new features. Shoot, all the stuff is there already; new features would be ease-of-use thingys like a GUI and some automation of existing stuff. This almost always ends up being limiting. Schorsch already did the most amazing job of putting a GUI in front of Radiance that still allows access to the underlying engine. Radiance calculates all kinds of materials, deals with complex models, etc. What else is there? Maybe the ability to select from more sky distributions, such as the Utah sky? Maybe a better rview (excuse me, rvu), one that allows for easier manipulation of the model view? Rshow sounds like exactly this, but I've never been able to get it to run. Maybe all the new features we want already exist (photon map, rshow, direct cache), they just need to be folded into the main Radiance distribution? I have no idea how complicated that would be, but the quality of the install script (and I guess the underlying code) has *really* improved over the last year. If these other goodies could be installed just as easily, you'd be adding some sweet functionality.

Q5: What is your main complaint about Radiance from a user's standpoint?

It's complicated! We all know and appreciate the power of Radiance and the openness of the tools allows for unlimited flexibility; there were plenty of examples of that at the Workshop(s). But that doesn't change the fact that it's totally impenetrable to the novice. If it weren't for the generosity of Greg, Schorsch, Carsten and several others on these lists, I'd never have been able to learn Radiance well enough to use it in my work. I'm grateful for their help, advice and encouragement, but I wonder how many people were scared off once they saw Radiance for the first time?

I believe many folks out there in the lighting design community are not at all interested in how this stuff works. To me, that's surprising, but after being involved in this business for the last decade that seems to be a fair statement. Most folks just want to know if there's enough, or too much, light. Load model, add lights, calculate, print, thank you very much. The thought of command lines and compiling source code is scary voodoo, the domain of people with t-shirts that say "no, I will not fix your computer". As a result, the typical Architectural LD is using Lumen Micro and AGI, unaware that Radiance even exists. And that's a shame.

This complaint of mine is simply a response to the question. I'm not really complaining, and I don't know what the answer is, I'm merely pointing out how the Radiance learning curve looks to Joe Lighting Designer.

Q6: What do you think of the current development arrangements?

Well, it's active, which is good, yeah? I'm not really knowledgeable about these things, but the CVS system seems to be the way this stuff is usually handled...

聽聽聽聽Q6a: Would you like to see more people involved in Radiance development?

This isn't really any of my business either.

聽聽聽聽Q6b: Would you like to participate in develoment, yourself?

Ha. If I knew how to, I would. Let me say this, though: maybe there's a way I can help. Maybe some more tutorials would help the novice users be more willing to dive in? As good as the tutorials are in RwR, not everyone has that book. I like to write, and can generally lighten things up a bit. Maybe a couple of simple baby step tutorials that could get a person to install and compile radiance, followed by some general explanations of how to get started could live on radiance-online.org? This was discussed at the last workshop too. Free time is always an issue, but I'd like to help the cause in some way. Since it ain't gonna happen with my coding skills, maybe I can do it this way. Just a thought.

路路路

----

聽聽聽聽聽聽Rob Guglielmetti

e. [email protected]
w. www.rumblestrip.org

Hi all,

Boy there are some interesting things in discussion. I will weigh in as I can.

Greg Ward wrote:
[snip - people have weighed in with some excellent comments]

Why don't we take a survey? Anyone who has read this far has to be interested in these issues, so let's hear from you.

Q1: Have you tried the photon map addition? Why or why not?

Yes briefly after RW 2002. I was able to compile it and run some of Ronald's examples. Note I also checked out Carsten's "direct cache" as well. To my mind both of these are certainly interesting developments. On the other hand, in our everyday production use, we are dependent on the knowledge we have built up over the years about tweaking parameters in "classic" radiance and managing a production pipeline around the engine. However if these tools were incorporated into a standard release in a manner that would not impact "classic" use and performance, then I would be more likely to work with these add-on on a more regular basis.

Generally, I am interested in anything that helps increase speed of the simulation process and quality of the resultant images. For us this has meant faster hardware over the years and the use of rpiece in single nodes. I have also played around with rpiece on distributed nodes, but I do have concerns about the file locking consistency (whether this is an NFS settings thing, Linux things or Radiance things I do not know).

Q2: Would you try the photon map if it were added to the HEAD release?

Yes and others, if they are incorporated in a way that does not impact "classic" use and performance. To me this could be either as compile time options, command line switches or alternates for commands (ie rpict, rpict_pm, rpict_dc whatever, although I suspect this is not the most efficient thing from a development standpoint).

Alternatively, I like the idea of a stable and development branch as with Linux development. Then you know what is what. And perhaps development can be more aggressive in the development branch (people and other resources for development is an entirely different topic).

Q3: If the photon map were added to the next official release, would it:
聽聽聽聽A) Encourage you to upgrade?
聽聽聽聽B) Discourage you from upgrading?
聽聽聽聽B) Make you want to wait and see what others thought of it, first?
聽聽聽聽C) Make no difference to your decision?

Probably make no difference. I am one of the people referred to elsewhere who is still using the pre 3.6 release of radiance. This has mostly been out of laziness and not needing/wanting to mess with something that works. There are however many new exciting features that I think could be useful. This is also matter of just finding the time as well.

Q4: What features would you really like to see added to Radiance?

As I stated above, at one level anything that could result in increase performance and quality. Some ideas (wish list) could be as follows:

聽聽聽聽* alternate distributed/network rendering strategy - perhaps a
聽聽聽聽聽聽client server mechanism to supplant nfs locking, or some other
聽聽聽聽聽聽locking/sharing mechanism
聽聽聽聽* optimizations to rendering engine to produce faster results - are
聽聽聽聽聽聽there optimizations to the monte carlo solution that could be
聽聽聽聽聽聽considered (I do know that there are variants of monte carlo -
聽聽聽聽聽聽probably though specific to particular problem domains).
聽聽聽聽* mechanism for improving ambient caching performance and reuse - I
聽聽聽聽聽聽know that Chas Erlich had at one point mentioned some thoughts
聽聽聽聽聽聽about some possibility to process ambient data to "smooth" out
聽聽聽聽聽聽results, would it also be possible to have a progressive cache
聽聽聽聽聽聽that can evolve has parameters and other things change?
聽聽聽聽* I like the idea of somehow having photon mapping integrated but
聽聽聽聽聽聽somehow as separated things that then integrates with the mkillum
聽聽聽聽聽聽strategy already included in radiance.
聽聽聽聽* compiled materials - if it makes sense I would like to see the
聽聽聽聽聽聽capability for adding special compiled functions (I know this is
聽聽聽聽聽聽possible in Radiance currently, but how easy it is to do and
聽聽聽聽聽聽compile in the linked functions is not clear) that can be used to
聽聽聽聽聽聽improve performance of procedural materials, likewise is there any
聽聽聽聽聽聽sense in being able to "compile" light source ies data to improve
聽聽聽聽聽聽performance in complex scenes with lots of lighting?

Obviously, I am probably suggesting things that take a lot of time, research and funding to do. And I realize and accept the reality that this is a very small community with limited resources.

Q5: What is your main complaint about Radiance from a user's standpoint?

Well there is a lot to learn, however this has just fueled my personal interest and motivation over the years, so this is not really a complaint but more a indication of my twisted sense of what is fun. But there are probably places where documentation could be provided or extended with examples or even little test cases.

Q6: What do you think of the current development arrangements?

They are what they are. I think by its nature and development, Radiance is something that probably needs a small core developer team. And the reality is that Greg, for as long as he wants and chooses to be involved, is the person who should have final say of what gets included and worked on. I am all for a (hopefully) benevolent dictatorship in this context. It seems to me that the team that has come together in support of continued support and development is pretty self selecting, with a main core of Greg, Georg and Peter, obviously there are others such as Carsten and Roland, who have had the wherewithall to navigate the original code and make developments of there own.

聽聽聽聽Q6a: Would you like to see more people involved in Radiance development?

Only if it is manageable and useful to the development process.

聽聽聽聽Q6b: Would you like to participate in develoment, yourself?

Sure, if there is something useful that I can do.

路路路

--
# John E. de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction

Hi all,

I'm sure there are many good sources of information about the history of the core group of Linux developers, but there is a really good one in the October 2003 issue of Wired magazine. I see many paralells between the Linux and Radiance development efforts... no need to elaborate.

Here are some revisions to the history, as quoted from Jack de Valpine:

聽聽聽Radiance was originally developed with funds from LBNL as well as EPFL, along with some pieces at SGI. *** Greg has said that well over 50% of the time that he spent developing Radiance has been on his own personal time. With current trends, this ratio is steadily increasing. Greg Ward's personal wealth from the sales of Rendering with Radiance--ha!

聽聽聽Greg was/is the main developer of the software and has maintained his involvement as best possible over the years *** Here, here!

聽聽聽As work paid for by the government it had been released for use in industry with no fee for use except if the use was to build and sell an application with Radiance as the engine (I believe this required a separate license with fee from UC Berkeley/LBNL) *** One of the ongoing disputes at DOE (when there was money coming from that general direction) was that Radiance was paid for by US taxpayer money, but most of the users tended to be from outside of the USA. The only reason Radiance remains publicly available today is because that is the way Greg Ward wanted it to be that way. As a scientist at LBL working for DOE, the author of a piece of software has considerable leeway to determine how one's software is to be used and distributed. That being said, Stephen Selkowitz at LBL deserves considerable credit for not getting in the way and anihilating opposition, at some expense (and much benefit) to his career aspirations.

聽聽聽With Greg's departure from LBNL, support for radiance fell off dramatically to the point where ultimately I would suggest the tool was unsupported (and I am sorry that I do not think support/development of Desktop Radiance equals support/development for the core radiance engine) *** I take no bones with this fact. Desktop Radiance was not intended to be a replacement for Unix Radiance. It was hoped that its development would have attracted qualified Unix programmers to provide ongoing support of the Unix core, but this never materialized. Desktop Radiance has been successful in generating considerable interest in Radiance--even if the D.R. software itself is languishing due to lack of support.
There was considerable effort expended by LBL staff to port Radiance to native Windoze, and a separate effort to enhance Radiance for use on the LBL 512-processor Cray T3E with MPP extensions and stereoscopic real-time display of the results. As the program manager, I made sure that these two efforts worked from the same code base. This code is also freely available as part of the OpenSource license. I was the project manager for this effort and despite my attempts to involve Greg in these efforts, he was--understandably--not interested. Another sub-version of this so-called "LDRD" version of Radiance works on the multi-processor SGI Onyx and its version of MPP.

聽聽聽Greg has more recently been in a position to be more involved with Radiance (for better or worse) now over the past few years *** Here, here!

聽聽聽Peter has setup and maintained radiance-online.org *** Here, here!

聽聽聽Radiance has been released under "open source" style license. *** At long last! <self promotion mode on> This has been a long-time personal effort of mine that began before there was anyting called "OpenSource". While at LBL and over the years, Greg and I spent countless hours with the software licensing staff to demonstrate the value of Radiance and to assure them that the code was not "polluted" by copyrighted contributions from others. There was a months-long effort to research patents on pseudo-random ray-tracing owned by the developers of RenderMan. <self promotion mode off> These patents continue to be a major stumbing block for commercialization of Radiance by big-time (i.e., deep pocket) developers. Perhaps this is a blessing in disguise. Interestingly, it was only after the successful sale of 5 or 6 distribution licenses for Radiance at $10,000 each (thank you Georg Mischler and others) that we were able to command the attention of the LBL licensing staff. It was
as if Radiance had to make money for itself to demonstrate its "value" before it was allowed to be successful. About 25% of these funds were deposited into LBL's software licensing legal defense fund. I believe this has had significant influence on LBL's willingness to go along with the OpenSource effort. (Thank you Viviana Wolinski and other LBL licensing staff.)

One reason for stating the above is to illustrate that many aspects software development efforts require the contributions of "coders" and "non-coders" alike. I consider myself to be more of a non-coder. Dealing with licensing issues, coordinating the efforts of other programmers, detailing the input/output requirements of the Radiance core software, marketing, dealing with user issues, developing installation software, testing the software--all of these are the less technical side of programming. It was just a few days ago that the "coders" were stating the need for a test suite. The biggest users of Radiance are mostly non-coder, architects like myself who have some technical programming skills. Greg's survey is welcome and is an appropriate way to democratize his fiefdom. :slight_smile:

If there were two things that I could wish for in this effort to continue the development of Radiance they would be 1.) an acknowledgement of the contributions of non-coders and 2.) a "place at the table" to represent the user's perspective. IMHO, this is what has been missing from Linux development as well as Radiance. How long did it take to get a version of Linux (or Radiance) that did not require a programmer to install? There are plenty of good reasons for this omission of non-coders--no need to open that can of worms. Oops. Too late. The problem is that the non-coders, by definition, do not have the wherewithall to implement their own suggestions, no matter how good the suggestions might be, if the programmers in charge of the code development don't like or agree with the users' point of view. Alas, this has become a modern-day archetype--the Dilbert syndrome.

It is not my intent to complain about anyone's efforts, least of all Greg's. To make the leap to this next stage of Radiance development would require significant cash investment and/or ongoing funding. And to be sure, Greg and I (and others) have gone down that path more than once. Unfortunately, I'm currently not in the position to be making money from using Radiance, and so I can not donate my time to provide support (Darn, what am I doing writing this message?). In my experience, providing non-coder technical support for Radiance is a full-time job. The coder-programmers derive significant benefit through association with the software as a "prime author" whereas support staff generally do not get such recognition. I acknowedge that this is as much a philosophical issue as a programmatic one, and I have no hope of a quick solution.

Long live Greg Ward!

-Chas

P.S. I'm sorry about the HTML that <tags> along with my messages--just Yahoo! detritus that I don't know how to get rid of.

Hey Chas,

Thanks for the additions and corrections.Very helpful and informative.

-Jack

Charles Ehrlich wrote:

路路路

Hi all,
I'm sure there are many good sources of information about the history of the core group of Linux developers, but there is a really good one in the October 2003 issue of Wired magazine. I see many paralells between the Linux and Radiance development efforts... no need to elaborate.
Here are some revisions to the history, as quoted from Jack de Valpine:

聽聽聽1. Radiance was originally developed with funds from LBNL as well
聽聽聽聽聽聽as EPFL, along with some pieces at SGI. *** Greg has said that
聽聽聽聽聽聽well over 50% of the time that he spent developing Radiance has
聽聽聽聽聽聽been on his own personal time. With current trends, this ratio
聽聽聽聽聽聽is steadily increasing. Greg Ward's personal wealth from the
聽聽聽聽聽聽sales of Rendering with Radiance--ha!
聽聽聽2. Greg was/is the main developer of the software and has
聽聽聽聽聽聽maintained his involvement as best possible over the years
聽聽聽聽聽聽*** Here, here!
聽聽聽3. As work paid for by the government it had been released for use
聽聽聽聽聽聽in industry with no fee for use except if the use was to build
聽聽聽聽聽聽and sell an application with Radiance as the engine (I believe
聽聽聽聽聽聽this required a separate license with fee from UC Berkeley/LBNL)
聽聽聽聽聽聽*** One of the ongoing disputes at DOE (when there was money
聽聽聽聽聽聽coming from that general direction) was that Radiance was paid
聽聽聽聽聽聽for by US taxpayer money, but most of the users tended to be
聽聽聽聽聽聽from outside of the USA. The only reason Radiance remains
聽聽聽聽聽聽publicly available today is because that is the way Greg Ward
聽聽聽聽聽聽wanted it to be that way. As a scientist at LBL working
聽聽聽聽聽聽for DOE, the author of a piece of software has considerable
聽聽聽聽聽聽leeway to determine how one's software is to be used and
聽聽聽聽聽聽distributed. That being said, Stephen Selkowitz at LBL deserves
聽聽聽聽聽聽considerable credit for not getting in the way and anihilating
聽聽聽聽聽聽opposition, at some expense (and much benefit) to his career
聽聽聽聽聽聽aspirations.
聽聽聽聽聽聽聽聽聽聽4. With Greg's departure from LBNL, support for radiance fell off
聽聽聽聽聽聽dramatically to the point where ultimately I would suggest the
聽聽聽聽聽聽tool was unsupported (and I am sorry that I do not think
聽聽聽聽聽聽support/development of Desktop Radiance equals
聽聽聽聽聽聽support/development for the core radiance engine) *** I take no
聽聽聽聽聽聽bones with this fact. Desktop Radiance was not intended to be a
聽聽聽聽聽聽replacement for Unix Radiance. It was hoped that its
聽聽聽聽聽聽development would have attracted qualified Unix programmers to
聽聽聽聽聽聽provide ongoing support of the Unix core, but this never
聽聽聽聽聽聽materialized. Desktop Radiance has been successful in
聽聽聽聽聽聽generating considerable interest in Radiance--even if the D.R.
聽聽聽聽聽聽software itself is languishing due to lack of support. There was considerable effort expended by LBL staff to port
聽聽聽聽聽聽Radiance to native Windoze, and a separate effort to enhance
聽聽聽聽聽聽Radiance for use on the LBL 512-processor Cray T3E with MPP
聽聽聽聽聽聽extensions and stereoscopic real-time display of the
聽聽聽聽聽聽results. As the program manager, I made sure that these two
聽聽聽聽聽聽efforts worked from the same code base. This code is also
聽聽聽聽聽聽freely available as part of the OpenSource license. I was the
聽聽聽聽聽聽project manager for this effort and despite my attempts to
聽聽聽聽聽聽involve Greg in these efforts, he was--understandably--not
聽聽聽聽聽聽interested. Another sub-version of this so-called "LDRD"
聽聽聽聽聽聽version of Radiance works on the multi-processor SGI Onyx and
聽聽聽聽聽聽its version of MPP. 5. Greg has more recently been in a position to be more involved
聽聽聽聽聽聽with Radiance (for better or worse) now over the past few years
聽聽聽聽聽聽*** Here, here!
聽聽聽6. Peter has setup and maintained radiance-online.org *** Here, here!
聽聽聽7. Radiance has been released under "open source" style license.
聽聽聽聽聽聽*** At long last! <self promotion mode on> This has been a long-time personal effort of mine that
聽聽聽聽聽聽began before there was anyting called "OpenSource". While at
聽聽聽聽聽聽LBL and over the years, Greg and I spent countless hours with
聽聽聽聽聽聽the software licensing staff to demonstrate the value of
聽聽聽聽聽聽Radiance and to assure them that the code was not "polluted" by
聽聽聽聽聽聽copyrighted contributions from others. There was a months-long
聽聽聽聽聽聽effort to research patents on pseudo-random ray-tracing owned by
聽聽聽聽聽聽the developers of RenderMan. <self promotion mode off> These patents continue to be a major stumbing block for
聽聽聽聽聽聽commercialization of Radiance by big-time (i.e., de! ep pocket)
聽聽聽聽聽聽developers. Perhaps this is a blessing in disguise. Interestingly, it was only after the successful sale of 5 or 6
聽聽聽聽聽聽distribution licenses for Radiance at $10,000 each (thank you
聽聽聽聽聽聽Georg Mischler and others) that we were able to command the
聽聽聽聽聽聽attention of the LBL licensing staff. It was as if Radiance had
聽聽聽聽聽聽to make money for itself to demonstrate its "value" before it
聽聽聽聽聽聽was allowed to be successful. About 25% of these funds were
聽聽聽聽聽聽deposited into LBL's software licensing legal defense fund. I
聽聽聽聽聽聽believe this has had significant influence on LBL's willingness
聽聽聽聽聽聽to go along with the OpenSource effort. (Thank you Viviana
聽聽聽聽聽聽Wolinski and other LBL licensing staff.)

One reason for stating the above is to illustrate that many aspects software development efforts require the contributions of "coders" and "non-coders" alike. I consider myself to be more of a non-coder. Dealing with licensing issues, coordinating the efforts of other programmers, detailing the input/output requirements of the Radiance core software, marketing, dealing with user issues, developing installation software, testing the software--all of these are the less technical side of programming. It was just a few days ago that the "coders" were stating the need for a test suite. The biggest users of Radiance are mostly non-coder, architects like myself who have some technical programming skills.&nbs! p; Greg's survey is welcome and is an appropriate way to democratize his fiefdom. :slight_smile:

If there were two things that I could wish for in this effort to continue the development of Radiance they would be 1.) an acknowledgement of the contributions of non-coders and 2.) a "place at the table" to represent the user's perspective. IMHO, this is what has been missing from Linux development as well as Radiance. How long did it take to get a version of Linux (or Radiance) that did not require a programmer to install? There are plenty of good reasons for this omission of non-coders--no need to open that can of worms. Oops. Too late. The problem is that the non-coders, by definition, do not have the wherewithall to implement their own suggestions, no matter how good the suggestions might be, if the programmers in charge of! the code development don't like or agree with the users' point of view. Alas, this has become a modern-day archetype--the Dilbert syndrome.

It is not my intent to complain about anyone's efforts, least of all Greg's. To make the leap to this next stage of Radiance development would require significant cash investment and/or ongoing funding. And to be sure, Greg and I (and others) have gone down that path more than once. Unfortunately, I'm currently not in the position to be making money from using Radiance, and so I can not donate my time to provide support (Darn, what am I doing writing this message?). In my experience, providing non-coder technical support for Radiance is a full-time job. The coder-programmers derive significant benefit through association with the software as a "prime author" whereas support staff generally do n! ot get such recognition. I acknowedge that this is as much a philosophical issue as a programmatic one, and I have no hope of a quick solution.

Long live Greg Ward!

-Chas

P.S. I'm sorry about the HTML that <tags> along with my messages--just Yahoo! detritus that I don't know how to get rid of.

--
# John E. de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction

Charles Ehrlich wrote:

聽聽聽聽聽聽*There was considerable effort expended by LBL staff to port
聽聽聽聽聽聽Radiance to native Windoze, and a separate effort to enhance
聽聽聽聽聽聽Radiance for use on the LBL 512-processor Cray T3E with MPP
聽聽聽聽聽聽extensions and stereoscopic real-time display of the results. As
聽聽聽聽聽聽the program manager, I made sure that these two efforts worked
聽聽聽聽聽聽from the same code base. This code is also freely available as
聽聽聽聽聽聽part of the OpenSource license. I was the project manager for
聽聽聽聽聽聽this effort and despite my attempts to involve Greg in these
聽聽聽聽聽聽efforts, he was--understandably--not interested. Another
聽聽聽聽聽聽sub-version of this so-called "LDRD" version of Radiance works on
聽聽聽聽聽聽the multi-processor SGI Onyx and its version of MPP.

Is there a URL for this code? Now if I can only get my hands on a Cray... :^)

路路路

--
Roland Schregle
PhD candidate, Fraunhofer Institute for Solar Energy Systems
RADIANCE Photon Map page: www.ise.fhg.de/radiance/photon-map

END OF LINE. (MCP)

It's not on any web site, but we can both talk to Judy Lai at LBNL and see if she can scare it out of the woodworks. I believe this code was included on the CD-ROM's sent to the $10k licensees, who may distribute it as they wish.

-Chas

Charles Ehrlich wrote:

*There was considerable effort expended by LBL staff to port
Radiance to native Windoze, and a separate effort to enhance
Radiance for use on the LBL 512-processor Cray T3E with MPP
extensions and stereoscopic real-time display of the results. As
the program manager, I made sure that these two efforts worked
from the same code base. This code is also freely available as
part of the OpenSource license. I was the project manager for
this effort and despite my attempts to involve Greg in these
efforts, he was--understandably--not interested. Another
sub-version of this so-called "LDRD" version of Radiance works on
the multi-processor SGI Onyx and its version of MPP.

Is there a URL for this code? Now if I can only get my hands on a
Cray... :^)

路路路

Roland Schregle <[email protected]> wrote:

--
Roland Schregle
PhD candidate, Fraunhofer Institute for Solar Energy Systems
RADIANCE Photon Map page: www.ise.fhg.de/radiance/photon-map

END OF LINE. (MCP)

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev