[Radiance-general] Radiance Project Organization

[Rob Guglielmetti]

Hi Thomas,

On Jul 10, 2005, at 7:42 AM, Thomas Bleicher wrote:

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

=================
    Rob Guglielmetti
www.rumblestrip.org