Designers RADIANCE

Lobby
Design case study involving procedural textures and semi-transparent image maps

The main aim of RADIANCE is to deliver scientifically exact visualisations and corresponding further data (e.g. falsecolor images) of luminous environments. Despite this (or should I say because of this ?) at the same time it allows to create visually appealing images which are hardly achieveable with other types of rendering software (esp. for indoor scenes). A key role in this process is certainly played by the ambient calculation, which - if used properly - can give the images a certain kind of 'softness' and a very unique look.

Berlin Museum Island
The image was rendered for a competition dealing with the design of the urban space around the assembly of historical museum buildings. The lighting should create a quiet atmosphere, emphasizing the big block of the Pergamon Museum which is a sort of "treasure chamber".

Of course, discussing all the background of aesthetically based image generation is not possible here, instead I will focus on some special topics which - amongst others - are important to consider in such a task. In turn, small add-ons and modifications of the standard RADIANCE software are introduced which may be very helpful for all kind of design-based applications.

1. The direct illuminance cache
2. Procedural textures and the secondary ambient material
3. Image maps with transparency control
4. The 'arc' primitives
5. Image size specification
6. Conclusionary remarks, sources


1. The direct illuminance cache

This is mentioned here mainly for the sake of completeness, as it is presented on a separate page. (Direct cache manual) The connection to design-based applications is of course that they usually need high settings of both direct and ambient parameters. Smooth penumbras and shadow-regions without artifacts demand very high values for the direct source subsampling and the so-called threshhold/certainty parameters, it is a kind of "do it good or don't do it" question. In this case direct caching proves most effective as it 'shields' the ambient calculation from this and thus may almost be considered as a necessary measure.

2. Procedural textures and the secondary ambient material

The term photo-realism often appears in conjunction with rendering, and in architecture and lighting visualisation producing a realistic impression of buildings and luminous environments is certainly the key issue. It is nevertheless an image, which is produced, and not a photo. Keeping this in mind, rendering can be viewed as special art of painting, too, with its own typical style, "language", its techniques and methods of abstraction. The visualisation itself can be an artwork.
One way of emphasizing an artistic dimension of a rendering is the use of procedural textures, i.e. mathematically defined color (and/or normal) patterns for modelling various kinds of material (wood, stone, brick walls, etc.). Within RADIANCE, this is possible by the use of the 'colorfunc', 'texfunc' and 'mixfunc' primitive together with special 'cal-files' containing the mathematics. The resulting textures will not be simple copies of real existing things as an imported photo (a RADIANCE 'colorpict') would be, but a unique way of depicting an impression of different material properties. Using mathematical textures gives a rendering a sort of uniform style which is - judged from an aesthetical point of view - preferreable to a non-uniform appearance which often results when scanned photos are used for color and material patterns. Further advantages are, that procedural textures have unlimited resolution and the problem of repeating the same photo again and again to cover a larger area does not appear, too.
Moreover, the simulation of the appearance of a surface in a specific lighting situation strongly depends on a correct considering of the surface normal, which can not be achieved by a simple photo as color pattern at all.
A drawback of using procedural color and normal patterns is, that they need a lot more time to get rendered, as a more ore less lengthy calculation is necessary for each rayhit to get the local color and surface normal. Fortunately, for a wide range of patterns the exact properties are only important for the direct view. This gave the idea of the 'secondary ambient material'. A wood-pattern for example has a sort of 'base color' or average reflectance which suffices to represent the material in the coarse-grain ambient sampling procedure. The same applies to undulated surfaces, which often can be replaced by an even one for the indirect calculation. Of course the criterium for using the method always is that the period of color or normal variation is small compared to the dimension of the object and the surroundings. As said, this is readily fulfilled for most of the patterns appearing in usual visualisation tasks. Of course the secondary ambient material may also be used when a photo is used as image map, thereby saving the look-up in the data file for all ambient sample ray hits. For scenes with large areas covered with such textures (walls, floors) the time saving potential can be quite high, in conjunction with direct caching reduction of rendering time by factors of 10 are possible.

Specifying the secondary ambient material is simply done by adding it as the first string argument to the final material description containing the complete texture. Consider the following example:
void plastic base_color
0
0
5 ... ... ...
void texfunc norm_pat
4 ...
0
6 ... ... ...
norm_pat colorfunc pattern
4 ...
0
10 ... ... ...
pattern plastic wall_mat
1 base_color
0
5 ... ... ...
Currently, secondary ambient materials can only be given to the 'plastic', 'metal' and 'trans' primitive. It is important that in the input file the secondary material is listed before the one in which it is included.
Dependent on the desired appearance, procedural textures can reach some degree of complexity. In general, two layers suitably mixed are necessary (for the color-patterns, not counting additional surface normal functions) to achieve a really impressive look. Some materials however can be modelled with one layer alone, especially if they are looked at from some distance within the scene.
A set of examples (stone and wood patterns, brick walls) is provided together with the cal-files necessary for the pattern generation. With help of the examples it should be possible to start out and modify the textures and create new ones according to specific needs.
Collection of 'virtual' woods and stones. The stone patterns in the middle picture are shown with specular reflection set to zero, to avoid disturbing reflections. In general, specularity should be added, however, to simulate polished stone surfaces. The third picture shows an example of mapping a procedural texture on curved surfaces.
Simple demo arrangements showing the high effect of normal mocifications on image appearance. Apart from the enhancement in realism they are a valuable means of creating a special style and atmosphere within a picture, too.
Applying those textures to objects needs some thinking, too. Especially the wood patterns are very sensitive to position changes, so care has to be taken to rotate/transform them properly to the place where they should appear in the scene. The brick normal patterns contain some simplifications which make them not suitable for a very close view.
Some further information about the supplied textures can be found on a separate page. (Texture hints)

3. Image maps with transparency control

Currently, a RADIANCE 'colorpict' will show transparency (when mapped onto a 'glass' or 'trans' material) dependent on its rgb-values. This is very often useless in practice as in arbitrary photos or generated pictures white patches do not necessarily mean transparency. For this reason, a modified version of the primitive, called 'color4pict' was developed, together with an enhanced RADIANCE picture format ('4-pic') which simply has a fourth channel responsible for transparency control. '4-pics' can be generated from 32-bit Targa files (.tga) with help of a correspondingly updated version of the 'ra_t16' converter. 32-bit Targa files are simply produced by saving an image together with the transparency channel in image manipulation software like 'GIMP' for example. The converter will automatically detect 32-bit Targa files, so typing:

$> ra_t16 -r image.tga image.p4c

will produce a RADIANCE '4-pic', which then can be mapped onto a material with the 'color4pict' function.

void color4pict image_map
8 noop noop noop noop image.p4c picture.cal pic_u pic_v
0
0


Remember that four functions (or noop, if no operation on color values should be performed) have to be listed as the first string arguments. '4-pics' can be applied on the 'plastic', 'metal' and 'trans' material only (of course only the last one makes sense). To get the effect of light shining through the picture the roughness value (5th parameter) has to be zero.
An interesting application is the mapping of '4-pics' on a completely transparent base (6th and 7th 'trans' parameter set to one). By this arbitrary plane shapes (writings, letters for example) can be produced with photo-editing software and imported as objects into RADIANCE.

4. The 'arc' primitives

The number of basic primitives in RADIANCE is rather low. If input is converted from CAD software, mostly polygon-meshes will be used anyway (although they not always represent the best choice in terms of appearance, memory and rendering time requirement). For those writing object descriptions directly, one additional set is now availble, namely arcs of rings, cylinders or cones. In addition to the normal 'ring'/'cylinder'/'cone' parameters, the start and end angle as well as the direction in space, from which these angles are measured, have to be specified. Start and end angle has to be between 0 and 180 degrees. Of course greater angles can be achieved by putting two arcs together.

the 'arc' primitives:

the start and end angle (a0, a1) and the orientation from which they are counted have to be added to the normal descriptions.
examples:
void cylinderarc ca
0
0
12 P0x P0y P0z P1x P1y P1z r a0 a1 sx sy sz

void ringarc ra
0
0
13 P0x P0y P0z nx ny nz r0 r1 a0 a1 sx sy sz

etc, analogously for conearc/cuparc/tubearc

5. Image size specification

As giving the image size in pixels is far more intuitive than the view angles, and control over the exact size in pixels is often preferrable when pictures are postprocessed, integrated/combined with others, etc., the RADIANCE way of overriding the pixel values was changed. Of course, one of the four values (x,y-size, horiz./vert. view angle) is not independent. Now the vertical view angle will be adjusted automatically to suit the given aspect ratio without distortion of the picture. This modification was adopted for 'rview' as well, so now the x/y resolution need to be listed in the parameter set when invoking rview.

6. Conclusionary remarks, sources

The presented material had its origin in ideas and demands occuring during the use of RADIANCE for design based image generation. Self-evidently, the ways of adaption represent an individual choice. This accounts for some lack of systematic structure, too. (Art always is connected to chaos...). Other, and of course more, modifications and enhancements are possible. But because of the complexity of RADIANCE, even small add-ons need a lot of time and digging deep into the code, so the list of changes is still a short one.

Creating visually appealing images is - in its own way - as complex as heeding the scientific exactness of the light propagation modelling. Of course, in contrast to the latter, one has to rely on intuition and 'feeling' together with rational thinking about how to achieve the desired impression. And, not to forget, bring on some patience when exploring the aesthetical dimension of rendering.

Below, you will find links to three archives, one containing the source patches, the other containing the auxiliary stuff (cal-files and demos). The third link contains a small additional goodie, a converter producing IESNA photometry files from European "Eulumdat" standard files, which enables to use those luminaires within RADIANCE, too.

desradsrc.tar
desradaux.tar
eulum2ies.tar

Have fun!

27.08.2002 Carsten Bauer (Berlin) -> biograhpical notes and contact info <-