Quo Vadis Radiance - devotion, dollars, development

Hi all,

the feedback is quite overwhelming, I try to keep track of all points....

OK, one more time the money thing :-). Talking about money always produces anger, so lets cool down again. No, Jack, no, I don't even implicitely blame you or others. I can take myself as example. Funding for Radiance from government/institutes was originally justified with a political background, the concern for the enviromment, promoting energy efficient lighting/daylighting etc. . Apparently (thanx to Chas for the comprehensive historical background) it was Greg who made much more out of it then intended and was able to smuggle it out to the public. And now this tool is used in a wide range of commercial applications. But, why should the US DOE have any interest in supporting e.g. me in getting incredibly rich by making nice images of german architecture projects?
Thats why I simply made some hypothetical thoughts about other (commercial )ways of financing software development. Nothing more, nothing less.
In other words, if Greg and Peter and Schorsch now come together and start up a company (the may call it Lightcosoft) and sell the current stuff as 'Radiows 3000 NT', would someone buy it? I imagine that it's too late now for that step. People have accustomed to the things. The folks complain like mad about Autode$k and Microsoft, but at the same time keep on buying their products. On the other hand, everyone praises Radiance, but theres no money for development. Either I miss some important point or things are really that strange.

Now forget about the money. There are other things in life, too, and if you hop into the coffin, you can't take anything with you anyway. Certainly there is much enthusiasm involved when people deal with Radiance, either on the development side or on the users side. But if things don't move or hang around with unclear status or direction, every enthusiasm will wear out sooner or later. I made an interesting observation (quite generally I have learned an awful lot from this current discussion): Jack wrote that he once tested the direct cache but didn't find it suitable (in the present form) for his working environment. On reading this I noticed that this was the *first* feedback at all I've got so far about if or if not this little hack is of any use for people outside the few square meters of my flat. I'm not naive, so I know that this is quite normal, and others face the same problem, but it is simply totally inefficient. If an idea proves useless, the sooner one abandons it and looks for something new, the better, if it proves helpful, the sooner a solid version emerges out of a first test prototype, the better. I dare say that even Greg would have difficulties when developing something without any feedback from the users side. Take this little example as one reason why I kicked off the discussion about some form of coordinating the development.

And as we speak of development: from the repeatedly appearing statements in Gregs answers I assume that he is not reaaaallllllly overwhelmingly enthusiatic about modifications which mess with the core (the radius of the core has of course yet to be defined). Let me simplify it (please correct me if its oversimplified :slight_smile: ): "Do what you want, develop like mad, but make it completely separable, don't touch the core!!!" I have no problem at all accepting this, in fact that's just Gregs copyright for the whole stuff. But at the same time I have doubts if that is physically realistic. I don't need to always speak of pmap or dc here, when I take a look at Jacks whishlist I find many topics calling for quite comprehensive modifications. So once again the same question: to develop or not develop ? One spontaneous solution to the problem (which will secure a good sleep for Greg) would be a new name for a Radiance which is not Radiance anymore because of substantial internal changes.

-Carsten

PS: btw, just one more direct answer to Jack: the idea of different executable-names is a straightforward and feasable way, it is easy to implement into rad with an additional switch for specifying the one to call. At least I do it exactly that way for my work here.

Carsten Bauer wrote:

Now forget about the money.

Yeah. Tell me 'bout it...

There are other things in life, too, and if you hop into the coffin, you can't take anything with you anyway.

Um, some people take their laptops with them. Seriously.
(Presumably they're expecting to find an ISP in the hereafter, too.)

···

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

Carsten Bauer wrote:

... The folks complain like mad about Autode$k and Microsoft, but at the same time keep on buying their products.

Not every architect is as curious and flexible as Jack. Most people stick with the pack, complain and keep their heads down.

....On reading this I noticed that this was the *first* feedback at all I've got so far about if or if not this little hack is of any use for people outside the few square meters of my flat.

While writing rshow years ago in the fairly suitable habitat of a larger research institute (name supplied - ed.) feedback was a problem even there. One would think that users suggest new ideas while using it, having the advantage of in-house development, but that happened only occasionally. Generally only a few users are keen on trying something new, and even fewer have a vision of what they want. Radiance's continously uphill learning-curve doesn't help in this. Consequently, developpers follow the vision in their mind and in case of Greg's that turned out to be fairly usuable for others too.

...
And as we speak of development: from the repeatedly appearing statements in Gregs answers I assume that he is not reaaaallllllly overwhelmingly enthusiatic about modifications which mess with the core (the radius of the core has of course yet to be defined).

I find his thoughts about user's trust in Radiance quite realistic. And supporting other preople's code can be _very_ time consuming. I'm not sure if contributors are prepared to support their contribution over years to come. Even porting rshow to R3.5 and something more modern than Tcl/Tk is a drag, and that doesn't include validations of results.

-Peter

···

--
pab-opto, Freiburg, Germany, www.pab-opto.de