Hi Thomas,
I'm currently developing a new interface for Radiance for the
free 3D modeling suite Blender.
This looks very cool, Thomas.
Among other things it supports IES data import and the import
of Radiance material descriptions (very limited at the moment).
I love the way you create 3D objects in the scene that represent the photometry...
Both are organized in some sort of "library" backend. Now I'm
looking for a good idea how to organize and populate these libraries.
I think I'll find the most experienced users here on this list so I'm
asking the community at large:
about luminaire data:
*) Which features would you like to see in a data browser?
I think the main thing is to be able to see the critical bits of the file, such as multiplier, photometric type, lamp lumens and quantity, notes, and either a text- or image-based view of the distribution. From there one could be able to edit these bits and save variations on the fixture. A basic-quality rendering of the luminaire would be great too, placed in a box maybe so one could see the distribution in a space (like my ltview utility does). The 3d object representing the distribution is very cool, but having a rendering of the luminaire in a space would also be useful for troubleshooting purposes, especially when using illum spheres and all.
*) Is there a common standard for information exchange beyond
IES, TM14 and Eulumdat(*.ldt)? Particularly I'm looking for
some sort of database for luminaire, lamptype and geometry
data or images. It seems like every manufacturer has it's
own standard and presentation utility.
I know there is a project call "DIALUX" which seems to be
supported by a lot of manufacturers (at least in Europe) but
I don't know if it's actually very popular.
You're talking about a couple of things here. In terms of raw information exchange, the formats you mention are the standards. I'm mostly familiar with the .IES format since I'm in the USA, but many European manufacturers I deal with also make their data available in IES format.
Then you mention a "presentation utility", and a database. These are definitely things that exist, and not in any standard format. I have used Dialux in the past and I know what you are referring to there; they have an internal database that stores information about luminaires including the photometric distribution, picture(s) of the image, and keywords. Basically building on the IES file with more organizational information & fields. I believe the makers of Dialux also publish the format for these databases and that is how the manufacturers have been able to provide downloadable plugins to Dialux. Often, US manufacturers will release calculation software that has an excellent database of *their* luminaires, but allow you to define lums based on any IES file, for obvious marketing reasons.
There is also a product called Photometric Toolbox, made by Lighting Analysts (the people who produce the very popular AGI lighting calculation product). I only used an old version of the program, so this may not be a totally accurate description, but as I recall it was essentially a very detailed photometric file viewer/converter. With this tool, you could look at the raw data in an IES file but have it presented in an easy-to-read manner, with edit boxes for all the parameters, and polar curves of all the planes. It could also convert between type B and type C formats. This is a very useful tool; it's not a database, but an excellent viewer. The functionality of this tool is essentially what I was describing in my answer to your question above. Having this functionality, along with the ability to add extended information to search on like manufacturer, lamp type, mounting, notes, etc, and the ability to then copy any luminaire into a project database, would be great!
*) How do you organize luminaire data in your projects?
Do you pre-select the files to use in the project and only
handle a small quantitiy of datafiles or do you use
(centralized) repositories (by type, by manufacturer)?
I generally collect all the ies files (and converted .rad/.dat files from ies2rad) for a given project and keep them within the job file hierarchy. In general for any given project there will be a manageable amount of files, and it also makes sense because I often modify things like lumen output on a per-fixture basis so libraries don't necessarily work. HOWEVER, that's not to say that having a library of *standard* luminaires from which to select *project* luminaires, as described above, isn't a great, great thing.
about materials:
*) Do you use simple material descriptions or is there no
end in complexity (modifiers, *.cal files etc.)?
I'm a materials wimp; at my previous company I used grey materials, dealing with straight reflectance only. I had my reasons. But I have started at a new company very recently and they use a little more color and use patterns and mixtures a lot more. From what we all see from the Radiance images that get shared in this community, I think the latter case is more the rule than the exception. And the Jedi Masters of cal files on this list have done some pretty amazing things with mixtures & .cal files, so from where I'm standing, I'd say there's no end to the complexity.
*) Do you rely on CAD exporters (and how they handle the material
assignment) or do you hand edit materials?
I make my models so that each layer gets a certain material assignment when I export (I use Georg's radout utility for this).
*) Where do your material definitions come from? Messurements,
handed down for generations and guarded carefully in the family
vault, fiddling until it "looks right"?
all of the above. Again, since I used to do a lot of grey-only renderings, it was pretty straightforward to use intuition and experience to assign a basic reflectance to a material. There are lots of good glass definitions in that Optics5 program, too. But special cases demand special practices, and I have in the past done fancy measurements of one-off glass/diffuser combinations. I think I had some pictures of that setup in my presentation from the 2003 Radiance Workshop.
*) Do you use image based textures?
Sometimes. =8-)
I hope some of you can share their experiences and information
on these things. If you have other ideas or a wishlist for a
Radiance interface I'd be glad to hear about it. I try to keep
the parts of my code as separate as possible so libraries etc.
may be useable without the Blender iterface as well.
I hope this was useful to you, and I hope more people share here as well. Radiance is such an open ended collection of tools, there are as many ways to approach modeling and rendering with it as there are users.
PS: I am well aware of "b/rad" by Francesco Anselmo. So far we
had different targets in developing our interfaces but in
the near future we hope to join our efforts. No one likes
to be second in inventing the wheel 
Sounds good, and hello to you Francesco, I'm glad to hear you are OK in light of last week's event (Greg told me you and yours were OK).
···
On Jul 10, 2005, at 7:42 AM, Thomas Bleicher wrote:
=================
Rob Guglielmetti
www.rumblestrip.org
