Crystal Palace Form•Z model and Radiance rendering documentation

Table of Contents

1.Narrative
		a.Project History
		b.The building and the model
		c.Building Symbols
			1.Special concerns: grouping and triangulation
			2.Special cases
		d.About Radiance
			1.Converting to .rad files
			2.Laying out and transforming scenes
			3.Rendering
2.Production Notes
		a.Introduction
		b.Scene Geometry
			1.Form•Z Model
			2.File Conversion
		c.Surface Materials
		d.Light Simulation
		e.Rendering
			1.Group I: geometry directly exported from Form•Z models
				a.Symbols
					i.File name conventions for symbols
					ii.Rendering
					iii.Shell scripts to view different sides of a symbol
						a.Command usage
				b.Non-symbols
					i.Notes for non-symbols
						a.Galleries
						b.Roof
						c.Canvas
						d.Trimandflag
					ii.File name conventions for non-symbols
			2.Group II: Other parts of the Crystal Palace that cannot be exported from Form•Z models
				a.Canvas
				b.Floor
					i.Instance
				c.Trees
		f.Crystal Palace Complete Model
3.Images
4..obj Files

Narrative

Project History

The IATH Crystal Palace model was created as part of Michael Levinson's "Monuments and Dust" project. The original goal was to create a virtual model of the building that was inhabited with objects from the exhibition and linked to textual and illustrative discussions. While we still hope to do this, it has not yet proved feasible. After some reworking of the original goals, static and animated renderings of the building were produced by Chris Jessee. The digital model of the building was built in Form•Z, using scans of architect Joseph Paxton's contruction designs.

The model was intended to give users an idea of how the building was put together, what it looked like, and why it was a culturally and architecturally important feat. The Form•Z pictures did accomplish this, but they were not as realistic as they might have been. The group intended to use Radiance to add better lighting effects, but time, staffing, and equipment restraints delayed the work. Form•Z is a good tool for producing 3D geometry models, but it cannot reproduce the complex reflective and transmissive light that suffused the real Crystal Palace. The building had over a million feet of glass providing a vast source of light and heat for the more than 13,000 exhibits on display, so a good virtual model needs detailed lighting effects. We therefore decided to revisit the model with Radiance software, which renders much more realistic and effective lighting simulations. David Cosca and Chris had already developed a workflow model. Ying Yao was assigned the task of creating a Radiance model of the building, using Chris's works as her raw material.

The building and the model

Building Symbols

The Crystal Palace was modular, built on grid of 24' x 24' units. Paxton's revolutionary idea was to design an integrated system of basic parts that could quickly be manufactured by specialized, dedicated machinery and then assembled by a group of unskilled workers as each part arrives on the site. This industrial age model of efficiency is also used in modern 3D software tools. Form•Z and Radiance both have a few primitive symbols (box, cone, sphere, etc.) that can be repeated millions of time to create large, complex designs. Paxton's design lends itself to digital modeling, since it relies on a set of frequently used small components that are assembled into a more complex whole.

The resulting model is in several .fmz binary files (.fmz is the Form•Z proprietary file format). Form•Z allows users to extract and save information in several other formats, however, so Ying was able to identify the small components (called symbols) and save them into .obj files (a text file format that describes the location of points and polygons in space). The .obj format can be used by Radiance and several other graphics applications.

Special concerns: grouping and triangulation

When creating symbols from Form•Z files, there are several optional "Decomposition" settings that one can use to get the proper information in the new .obj file. One concerns grouping, which had to be set properly in order to preserve color assignments. Another concerns triangulation and the depth of information about the faces that make up an object's surface. The "Triangulate" option decomposes each polygonal face on the surface into a collection of triangles. The difference can be seen below in two different versions of the canvas roof covering.

Figure 1: CP object without triangulation

Figure 2: CP object with triangulation

The extra information is not always necessary and can greatly increase the file size. However, it can be critical. Objects with curved surfaces, such as the canvas, may not render correctly if the surfaces are not adequately described, as shown below. To avoid any later problems, we checked each symbol to see if it triangulation was needed.

Figure 3: Form•Z-rendered canvas without triangulation:

Figure 4: Form•Z-rendered canvas with triangulation:

Special cases

These symbols don't necessarily correspond to the physical elements in the building: in some cases they are collections of smaller elements. For example, door panels are made up of a door and a vent panel and while it might seem reasonable to represent these two elements as symbols in their own right, it is equally reasonable to limit the number of symbols. So, striking a balance between accuracy and convenience the entire panel is treated as a single symbol. In some cases, it was simpler to avoid symbols altogether and just create a single element, as in the two large transcept windows.

In the case of the largest parts of the building, the roof and the floor, some some shortcuts had been required in the Form•Z model. Paxton's original design called for greenhouse-like glass panels on the roof, to bring light and warmth into the exhibit space. Almost 300,000 10" x 49" panes of glass were laid out on a wooden framework, with gutters to drain off rain.

Figure 5: Crystal Palace roof

Unfortunately, the plan worked too well, and the space quickly became intolerable. The design was adjusted to include canvas covers on the glass panels:

Figure 6: Crystal Palace roof covered with canvas

Pieces of canvas stretched across the glass gables diffused the light and gave shade. A seam along the trough between the gables directed rain into the gutters. The revised roof was thus composed of thousands of pieces of glass, a wooden framework, and wooden gutters and entirely covered with canvas. Accurately modelling this geometry in Form•Z demanded far more memory and space than were available. The shortcut was to build a "solid" roof of polygons with texture mapping and coloring which approximate the actual structure. However, the Radiance model needed an accurate roof if it was to correctly model the light shining through fabric, glass, and wood into the building. It therefore uses two symbols, a 24' piece of roof and a 20' piece of roof that meets the gutter at the edge, that can be used to determine proper lighting conditions inside the building.

Similarly, modelling the planks in the wooden floor in Form•Z would have taken far more time and space than available, so it has a simple polygon floor. Radiance has four symbols of varying image tiling patterns that can be laid out and repeated to give the illusion of a plank floor.

About Radiance

Radiance is a Unix-based ray tracing software system that computes radiance values for a given scene and can be used to predict lighting levels and appearance in a space. Input values describe the surface geometry and materials of objects in the scene and the light sources in the space. The software calculates the light levels and renders an image. Outdoor light sources can be described according to time of day and latitude and longitude.

For more information on Radiance, please see the Radiance web site at <http://radsite.lbl.gov/radiance/index.html>.

Converting to .rad files

The .obj files then had to be converted into the Radiance-compatible .rad format. Radiance provides a command-line conversion program, called obj2rad, for converting .obj files to .rad files. In most cases, this produced a satisfactory result.

Laying out and transforming scenes

The .rad files could now be put together into scenes. Radiance images are built of scenes, which are used to calculate lighting intensity levels and reflection. Scenes contain objects, whose surfaces are a certain color and texture, reflect and absorb a certain amount of light, and occupy a given position in space. The xform command-line tool builds and transforms objects to form a scene (which will be in the .rad format). A scene may be created from one or more rad files. Scenes are used to generate octree files that describe the interaction of the compound surfaces (octree files are binary data structures computed from one or more scene description files).

Rendering

Radiance images were rendered with the rad command. Ying used .rif files to render multiple images drawn from varying combinations of scenes and materials. A .rif file can contain commands, pointers to .rad files and library files, and parameter values.

The resulting .pic files show different parts of the building from different angles. [need more information here about this stuff]

Production Notes

Introduction

Radiance is a lighting simulation engine that calculates light levels and renders images. Rendering is the process of taking a description of a three-dimensional geometry and generating a two-dimensional image from a specific viewpoint. The input required for this simulation is a description of the geometry, material, and light sources of a scene's three-dimensional surfaces. Rendering an image requires additional specifications for the desired viewpoint, direction, and angles. In the following sections, we will discuss in detail the model and rendering of the Crystal Palace with the Radiance software.

Scene Geometry

Form•Z Model

Most parts of the Crystal Palace model were first built in Form•Z, a three-dimensional form synthesizer software. These Form•Z models can be exported and saved as .obj files.

The following exporting options were used:

Platform:	MS-DOS
Group Method:	By Color
Export Method:
Solid/Surfaces:	Object
Parametric Objects:	Preserve Controls
Export Visible Layers Only:	checked
Transformation:	Coordinate Systems: Normals point outward: checked Scales: X: 1.000 Y: 1.000 Z: 1.000
Decomposition:1	Subdivide Concave Faces: checked Triangulate Faces: checked Triangulate Options: Triangulate All faces: checked
Attributes:	Preserve Face Color: checked

File Conversion

The .obj files must be converted to Radiance scene description .rad files. To do this, use the RAdiance obj2rad utility:

obj2rad *.obj >*.rad

Surface Materials

Although the geometry model is important, it must be supplemented by a description of surface materials, which determine how the light interacts with the geometry. The master.mat file contains a description of all materials in the scene.

master.mat:

Defines the property of materials

Light Simulation

A scene will not be visible until at least one light source and a background are defined.

sky.rad:	Specifies the luminaries, time, date and sky conditions.
outside.rad:	Specifies the outside conditions.

Rendering

The actual renderings of Crystal Palace are divided into two groups. In the first group, the geometry can be directly exported from Form•Z models, whereas in the second group, the geometry data files are generated using Radiance operations. In the following sections, we will discuss their rendering in detail.

Group I: geometry directly exported from Form•Z models

Most parts of the Crystal Palace geometry can be directly exported from the current Form•Z models, these include ones made from Form•Z symbols and ones from non-symbols. We will discuss them in the following sections.

Symbols

Due to the repetitive nature of the Crystal Palace model, symbols were created in a Form•Z library for the parts used in multiple locations. The following table shows the symbols exported from Form•Z models, their corresponding Radiance scene description file names and whether or not triangulation was necessary on the symbols when exported from Form•Z models.

In addition, most of the symbols were created in only one quality setting, whereas a few other symbols were designed in multiple quality settings with the extension of '_ld', '_md' or '_hd' on the symbol name. Notice that for those with only one detail setting: even though they were saved in the file CP_low_detail.zlb, they were already close to the original building design with no need to add more details. For the symbols designed in multiple detail settings, the ones with high qualities were closest to the original building design, and the lower detail ones were created to reduce the size of exporting geometry. For the rendering of the Crystal Palace, the medium detail symbols were used if more than one version were available.

Quality Setting
LD:	Low Detail
MD:	Medium Detail
HD:	High Detail

LD Symbol Name (22)	lib/(*.rad)	Triangulate?
48truss_ld	48truss_ld_tri.rad	Y
72truss_ld	72truss_ld_tri.rad	Y
canvas	canvas_tri.rad	Y
col2.3_ld	col2.3_ld.rad	N
col4.5_ld	col4.5_ld.rad	N
col6-10_ld	col6-10_ld.rad	N
door	door_tri.rad	Y
doorpanel	doorpanel_tri.rad	Y
flag	flag.rad	N
floorboard1	floorboard1.rad	N
floorboard2	floorboard2.rad	N
irongirder_ld	irongirder_ld_tri.rad	Y
roofframe_ld	roofframe_ld.rad	N
roofglass_ld	roofglass_ld.rad	N
walledge	walledge_tri.rad	Y
walledgesingle	walledgesingle_tri.rad	Y
wallpanel	wallpanel_tri.rad	Y
winpanel	winpanel_tri.rad	Y
winpanelup	winpanelup_tri.rad	Y
wood_ld	wood_ld_tri.rad	Y
woodcol	woodcol.rad	N
woodcolup	woodcolup.rad	N

MD Symbol Name (4)	lib/(*.rad)	Triangulate?
col2.3_md	col2.3_md.rad	N
col4.5_md	col4.5_md.rad	N
col6-10_md	col6-10_md.rad	N
xbraceSmall_md	xbraceSmall_md.rad	N

HD Symbol Name (4)	lib/(*.rad)	Triangulate?
col2.3_hd	col2.3_hd.rad	N
col4.5_hd	col4.5_hd.rad	N
col6-10_hd	col6-10_hd.rad	N
irongirder_hd	irongirder_hd_tri.rad	Y

All symbols were rendered at four different views; namely, front view, right side view, back view, and top view. To avoid the confusion caused by light source, instead of changing the light source and viewing positions, the geometry of the objects were rotated by using the Radiance operation 'xform' as described below, and cameras are set facing to the south with the light source coming from the southwest. The time was set to be 2:30pm on May 1.

File name conventions for symbols

Directory:	view_symbol_ld/ (low detail symbols) FRONT/ RIGHT/ BACK/ TOP/ view_symbol_md_hd (medium detail and high detail symbols) FRONT/ RIGHT/ BACK/ TOP/
Radiance input file:	master_{symbolname}_viewlabel.rif
Octree file:	build_{symbolname}(_tri)_viewlabel.oct
Image file:	pics/build_{symbolname}(_tri)_viewlabel_vw#.pic
Smaller image file to fit screen:	pics/smallpics/build_{symbolname}(_tri)_viewlabel_vw#_small.pic
PostScript file of the smaller image:	pics/smallpics/ps/build_{symbolname}(_tri)_viewlabel_vw#_small.ps
Progress Report:	REPORT/progress_{symbolname}(_tri)_viewlabel.txt
(Optional standard output: REPORT/out_{symbolname}_viewlabel.txt)

Rendering

'Rad' is an executive program that reads the given rfile (.rif file) and makes appropriate calls to oconv and pfilt to render a specific scene. Variables in rfile give input files and qualitative information about the rendering desired that together enable 'rad' to intelligently set parameter values and control the simulation.

Command to render image:

nice rad master_{symbolname}(_tri)_viewlabel.rif &

OR

nice rad master_{symbolname}(_tri)_viewlabel.rif >&out_{symbolname}_viewlabel.txt&

Note that (_tri) is needed only if the triangulation was done on the symbol.

View file:

{symbolname}_vw#.vf (viewlabel can be: front, right, back, top; vw# can be: vw1 (front), vw2 (right), vw3 (back), vw4 (top).)

To view different sides of the symbol:

View of object	Xform	Radiance Description File	View File
Front	none	{symbolname}(_tri)_front.rad	{symbolname}_vw1.vf
Right	rz -90	{symbolname}(_tri)_right.rad	{symbolname}_vw2.vf
Back	rz 180	{symbolname}(_tri)_back.rad	{symbolname}_vw3.vf
Top	rx 90	{symbolname}(_tri)_top.rad	{symbolname}_vw4.vf

Command:

cd ~/view_symbol_ld/FRONT/ 
nice rad master_{symbolname}_front.rif >&REPORT/out_{symbolname}_front_vw1.txt
cd ~/view_symbol_ld/RIGHT/
nice rad master_{symbolname}_right.rif >&REPORT/out_{symbolname}_right_vw2.txt
cd ~/view_symbol_ld/BACK/
nice rad master_{symbolname}_back.rif >&REPORT/out_{symbolname}_back_vw3.txt
cd ~/view_symbol_ld/TOP/
nice rad master_{symbolname}_top.rif >&REPORT/out_{symbolname}_top_vw4.txt

Output images:

Front view:	build_{symbolname}(_tri)_front_vw1.pic
Right view:	build_{symbolname}(_tri)_right_vw2.pic
Back view:	build_{symbolname}(_tri)_back_vw3.pic
Top view:	build_{symbolname}(_tri)_top_vw4.pic

Shell scripts to view different sides of a symbol

As mentioned earlier, to render an image, additional information for viewpoint, direction and angles is desired. This information is stored inside of view .vf files. Due to the large number of symbols and similarity of the operations on the symbols, some Perl and shell scripts are created to automate the generation of Radiance input (.rif) and geometry description (.rad) files and semi-automate the generations of the view (.vf) files. However, the file naming conventions should be followed in order to use the scripts and consequently the files generated by the scripts.

Specifically, once the Radiance input files (e.g. master_{symbolname}_front.rif) are created for the "Front View" of the symbols, the .rif files for the other views of the objects can be generated using the Perl scripts listed in the following table. However, for the different view (.vf) files, contents may vary. Specifically, the "gen_vf_viewlabel.pl" is only to copy and rename the {symbolname}_vw1.vf in the corresponding view directory, and the contents of the new view file might have to be edited when necessary. For example, to view the top of the object: first of all, the object will be rotated 90 degrees around the x-axis; secondly, if the objects are not symmetric about x-axis, the viewpoints may need to be translated, in other words, the contents of the new view (.vf) file will be changed. Similarly, to view the right side of the object, the viewpoints would most likely be changed when the object is not symmetric about the z-axis.

Command usage

Command	Directory	Generate .rif file	Rename .vf file only	Generate .rad file
cd ~/view_symbol_ld/	RIGHT	gen_rif_right.pl	gen_vf_right.pl	lib/Conv_right
	BACK	gen_rif_back.pl	gen_vf_back.pl	lib/Conv_back
	TOP	gen_rif_top.pl	lib/Conv_top	gen_vf_top.pl
cd ~/view_symbol_md_hd/	RIGHT	gen_rif_right_md_hd.pl	gen_vf_right_md_hd.pl	lib/Conv_right
	BACK	gen_rif_back_md_hd.pl	gen_vf_back_md_hd.pl	lib/Conv_back
	TOP	gen_rif_top_md_hd.pl	gen_vf_top_md_hd.pl	lib/Conv_top

1. To render one symbol:

   Here is an example listing a series of commands to use.

   cd ~/view_symbol_ld/FRONT
   emacs master_{symbolname}_front.rif
   emacs {symbolname}_vw1.vf

   (lib/{symbolname}_front.rad should already be converted by 'obj2rad' after .obj file is exported from Form•Z model.)

   cd ~/view_symbol_ld/TOP
   gen_rif_top.pl

   (master_{symbolname}_right.rif will be created and ready to use)

   gen_vf_top.pl

   ({symbolname}_vw4.vf will be created; however, the content may need to be changed when necessary.)

   lib/Conv_top

   ({symbolname}_top.rad will be created and ready to use)

2. To render multiple symbols:

   To render a series of the symbols in a particular view, use the following shell scripts, respectively. After the output .pic images are created, the Perl script (~/bin/gen_small_ps.pl) can then be used to reduce the size of the images and then convert the smaller .pic files into the printable PostScript .ps files. (The subdirectories /smallpics and /smallpics/ps should already be created in the pics/ directory).

   cd ~/view_symbol_ld/FRONT/
   task_front &
   cd pics/
   ~/bin/gen_small_ps.pl
   	   
   cd ~/view_symbol_ld/RIGHT/
   task_right &
   cd pics/	   
   ~/bin/gen_small_ps.pl
   
   cd ~/view_symbol_ld/BACK/
   task_back &
   cd pics/      
   ~/bin/gen_small_ps.pl
   
   cd ~/view_symbol_ld/TOP/
   task_top &
   cd pics/       
   ~/bin/gen_small_ps.pl
   
   cd ~/view_symbol_md_hd/FRONT/
   task_front &
   ~/bin/gen_small_ps.pl
   
   cd ~/view_symbol_md_hd/RIGHT/
   task_right &
   cd pics/  
   ~/bin/gen_small_ps.pl
   
   cd ~/view_symbol_md_hd/BACK/
   task_back &
   cd pics/   
   ~/bin/gen_small_ps.pl
   
   cd ~/view_symbol_md_hd/TOP/
   task_top &
   cd pics/
   ~/bin/gen_small_ps.pl

Non-symbols

For other parts of Crystal Palace that are not composed of symbols in the Form•Z library, the parts are selected and saved as .obj files from Form•Z.

Notes:

When exporting from Form•Z, the Guides Layer should not be exported as structure; it was created for design purposes. The following table lists the layers exported from the Form•Z models, their corresponding Radiance data files, and if the triangulation was done. In addition, the floor and canvas sections listed in this table were directly exported from Form•Z models; they need to be re-designed as discussed later.

Object Name:	lib/(*.rad)	Triangulate?	Notes
Transcept: (transbuild.8.fmz)
trans_tbody	trans_tbody.rad	N	style_5 is "white" defined in master_new.mat
trans_arch	trans_arch_tri.rad	Y
trans_leadflats	trans_leadflats.rad	Y	If not triangulated, the result is not correct. Extra: bottom_view is done.
Arch: (transbuild.8.fmz)
arch_fins	arch_fins_tri_front.rad	Y
arch_glass	arch_glass_tri_front.rad	Y
arch_grillwork	arch_grillwork_tri_front.rad	Y
arch_medalion_back	arch_medalion_back_tri_front.rad	Y
arch_medalion	arch_medalion_tri_front.rad	Y
archface_blue	archface_blue_tri_front.rad	Y
archface_white	archface_white_tri_front.rad	Y
Galleries: (galleries.fmz)
floor_underfloor	floor_underfloor.rad	N	Different color for top surface and bottom surface. Top surface is currently defined as white, needs to be re-defined.
joist_rail_grill	joist_rail_grill.rad	N
longjoist	longjoist.rad	N
stairs_rail	stairs_rail.rad	N
transjoist_strut	transjoist_strut.rad	N
Roof: (roofSetup.5.fmz)
roofW2	roof_w.rad	N	construction3 is "white" defined in master_new.mat)
canvasE	canvasE.rad	N
roofElow_mpGuttersE_endcapsE6E7	roofElow_mpGuttersE_endcapsE6E7.rad	N	construction3 is "white" defined in master_new.mat
roofElow	roofElow.rad	N
trimandflag: (trimandflag.fmz)
trim	trim	Y
flag	flag	N

Notes for non-symbols

For Galleries and Roof sections, they are not made of symbols from the symbol library; their parts are selected so that the different types of objects from Crystal Palace (include geometry and material) are all covered. The names of objects are all illustrative, showing which layers are included.

Galleries

floor_underfloor:	includes floor and underfloor.
	The reason of separating into two geometries is due to the fact that there are two different colors for the top and bottom sides of floors, respectively. Note that the top floor is defined as "white"; and it needs to be redefined. It is currently redefined as "floor" in master_new.mat.
joist_rail_grill:	includes joist, rail and grill layers.
longjoist:	includes longjoist layer.
stairs_rail:	includes the stairs with rail.
transjoist_strut:	includes transjoist and strut layers.

Roof

Different roof and endcaps layers are made from the same geometry and material, only the sizes and locations are different. Thus, the selected "roofElow_mpGuttersE_endcapsE6E7.rad" covers the following layers:

roofElow

mGutters³

pGutters

endcapsE6

endcapsE7

Canvas

The canvas in the symbol library has holes in the middle, and it is the correct one.

The canvas in the Form•Z model roofSetup.5.fmz has no holes in the middle. When rendering under the previous software, the initial intention is to avoid the big computational burden due to the large number of holes, and add the holes later using image mapping method. Thus, we need to substitute the canvas by the ones in the symbol library to render.

Trimandflag

There are only six layers to be exported from this Form•Z file; namely, flagsW, flagsC, flagsE, walledgeW, walledgeC, walledgeE; other layer groups (west, east, center) are for the purpose of designing, i.e. finding alignment.

File name conventions for non-symbols

Directory:	view_nonsymbol/ FRONT/ RIGHT/ BACK/ TOP/
Radiance input file:	master_{nonsymbolname}(_tri)_viewlabel.rif
Octree file:	build_{nonsymbolname}(_tri)_viewlabel.oct
Image file:	pics/build_{nonsymbolname}(_tri)_viewlabel_vw#.pic
Smaller image file to fit screen:	pics/smallpics/build_{nonsymbolname}(_tri)_viewlabel_vw#_small.pic
Progress Report:	Report/out_{nonsymbolname}(_tri)__viewlabel.txt
(Optional standard output: Report/out_{nonsymbolname}(_tri)_viewlabel.txt)

Note that (_tri) is added if the triangulation was done on the geometry.

Group II: Other parts of the Crystal Palace that cannot be exported from Form•Z models

In the current Form•Z model for Crystal Palace, canvas of the roof, floor and trees are not available for direct exporting. We will discuss them in the following sections.

Canvas

Each piece of canvas has holes in the middle so that the rain could drop into the underneath gutter. However, the holes add very large amount of geometry due to the size of the roof; it would be impossible to export the canvas geometry from the Form•Z model. Thus, the middle holes were eliminated in the canvas layer in the original Form•Z model RoofSetup5.fmz.

The canvas designed in the symbol library is the correct version. The canvas symbol can be replicated according to the locations outlined in the canvas layer in the RoofSetup5.fmz.

In the actual canvas, each 288" long canvas piece is placed one after another above each section of roof, with the exceptions that the left and the right ends of a canvas piece are cut short by 48" in length respectively to meet the corresponding end cap of the roof. As a result, four pieces of canvas with different lengths are created.

canvas_tri_front.rad:	288" long, it can be directly exported from Form•Z library.
canvas_ld_leftend.rad:	240" long, it is obtained by cutting off the 48" portion of the left side of geometry in canvas_tri_front.fmz, and then exported from Form•Z.
canvas_ld_middle.rad:	192" long, it is obtained by cutting off the 48" portion of both left and right sides of geometry in canvas_tri_front.fmz, and then exported from Form•Z.
canvas_ld_rightend.rad:	240" long, it is obtained by cutting off the 48" portion of the right side of geometry in canvas_tri_front.fmz, and then exported from Form•Z.

The canvas sections listed below were created by transformations of the above pre-defined Radiance geometry files for canvas symbols. They are dynamically generated when creating the octree using calls to 'xform' within files to reduce the number of scene files and to dramatically reduce the file sizes.

(l: stands for left; m stands for middle; r: stands for right.)

canvas_E1_l

canvas_E1_m

canvas_E1_r

canvas_E2_center_l

canvas_E2_center_r

canvas_E3_center_l

canvas_E3_center_r

canvas_E4_center_l

canvas_E4_center_r

canvas_E5_l

canvas_E5_m

canvas_E5_r

canvas_W2_center_l

canvas_W2_center_r

canvas_W3_center_l

canvas_W3_center_r

canvas_W4_center_l

canvas_W4_center_r

canvas_W6_l

canvas_W6_m

canvas_W6_r

canvas_W7_l

canvas_W7_m

canvas_W7_r

canvas_W9E9_center

Floor

The floor of Crystal Palace was made of wooden strips. Radiance provides a color data function, called colorpict, which can be used to map a picture onto a surface. It enables rendered or scanned pictures to be mapped to objects within the scene. Thus, we decide to create some pictures with wood grain strips, and map each picture to a polygon. Four different pictures are created and mapped onto four polygons separately; and they are tiled one by one to create more random pattern appearance.

The image-mapped floors of Crystal Palace and their corresponding Radiance geometry description files are listed below.

First floor:	design_center_1floor.rad design_east_1floor.rad design_west_1floor.rad
Second floor:	design_galleriesC_2floor_all.rad design_galleriesE_2floor.rad design_galleriesW_2floor.rad
Landing floor in gallery:	design_galleriesC_landingfloor.rad design_galleriesE_landingfloor.rad design_galleriesW_landingfloor.rad

Instance

When designing floor of the Crystal Palace, scene description files contain many surface primitives derived from Radiance "instance". An instance is defined in terms of a Radiance octree (.oct file), which contains any number of surfaces confined to a region of space. Multiple occurrences of the same octree in a given scene will use only as much memory as that required for a single instance, plus some small amount of additional memory to store the associated transformations for each instance's location. Thus, this mechanism is widely used in designing the floor due to the repetitive nature of the floor patterns.

As mentioned earlier, a special implementation of color data, called colorpict, can be used to map Radiance picture files to material surfaces. The primitive colorpict uses a two dimensional image stored in Radiance picture format to produce a colored picture. The dimensions of the picture is normalized so that the smaller dimension is always one unit in length and the other dimension being the ratio between the larger and the smaller. The colorpict type normally uses a predefined function called picture.cal. The function file always maps the new picture pattern in the xy plane with its origin at (0,0,0). Assuming that the z-axis is up, it is as though the picture were placed on the floor facing upward. Thus usually the picture must be rotated, transformed and scaled. Moreover, the picture remains invisible until it is placed on a canvas. Once the canvas and the picture have been merged together, the artwork can be located in a file and placed anywhere in the scene by using 'xform'.

The following is a complete example demonstrating how to create an instance, how to reference it, and finally how to include it in the Radiance input file. Pay special attention on declarations of the relative file paths.

File #1:

lib/floor/tile1.pic

# It is the Radiance picture file to be mapped on a piece of floor.

File #2:

lib/floor/one_x288_y_288_tile1.rad

# This file is to show how to map a Radiance picture file to a defined 
geometry, # which is 288x288 square in this case.

void plastic titanium_white_canvas
0
0
5 .9 .9 .9 0 0

void colorpict image_data_1
15 clip_r clip_g clip_b lib/floor/tile1.pic picture.cal pic_u pic_v  -rz 90 -t 1 0 0 -s 288
0
0

image_data_1 alias art_location_1 titanium_white_canvas

art_location_1 polygon art_floor_1
0
0
12 288  0       0
   288  288     0
   0    288     0
   0    0       0

File #3:

create_floor_oct

# This file is to show how to create an instance defined by Radiance octree 
# (.oct file).

oconv lib/floor/one_x288_y288_tile1.rad >lib/floor/one_x288_y288_tile1.oct

File #4:

lib/floor/one_x288_y288_tile1.ins

# This file contains the actual Radiance instance.

void instance art_work_tile1
1 lib/floor/one_x288_y288_tile1.oct 
0
0

File #5:

lib/floor/design_center_1floor_tiles.rad

# This file is to put the instance in the desired location inside of the scene.

!xform -t 9216 288 0 -a 3 -t 1152 0 0 -a 18 -t 0 288 0 lib/floor/one_x288_y288_tile1.ins

File #6:

master_CP_center_front_2880.rif

# This file is to show how to include the instance inside of the Radiance input 
# .rif file.

scene= lib/floor/design_center_1floor_tiles.rad

Trees

There are two trees in the central section of Crystal Palace.

1. One tree geometry:

   To get the Radiance geometry description file, export Elm1.fmz and save as .obj file without triangulation, and convert the .obj file to .rad file by using the following:

   obj2rad elm1.obj >elm1.rad

   elm1.rad: Radiance data file of tree geometry exported from Form•Z.

2. Material definition:

   master_tree.mat: Defines the color and material properties of different parts of a tree. In Radiance, a color property is defined by the following numbers: red, green, blue, specularity, and roughness.

   To find the numbers for red, green and blue:

   Open Elm1.dxf (Form•Z dxf file), click on Options menu ---> Surface Styles, double click on the desired color to get the Surface Style Parameters window, click on RenderZone ---> Color ---> Options.

   For each color, write down the numbers for red, green and blue, and divide each by 256, respectively; the results are used for the definition of the corresponding color in master_tree.mat.

3. Final scene description:

   design_trees.rad: It is the final scene description file included in the Radiance input .rif file. It enlarges two trees into the correct sizes and places them in the designated places of Crystal Palace.

Crystal Palace Complete Model

The complete source files of Crystal Palace can be found in ~/CP_completefiles/.

Obj_files/

It contains the object files exporting from Form•Z, and it does not contain any geometry files for canvas, floor and trees, which would be generated by many transformations of some pre-defined Radiance data files by using 'xform'.

Rad_files/

It contains all the Radiance files to render the images of Crystal Palace. There is a sample executable program to demonstrate how to run the program.

Rad_files/lib/

The following table shows the Radiance scene description files of the complete Crystal Palace, and their corresponding parts (layers) of Form•Z models if available.

Scene source			Scene description
(EISetup5.fmz)
	West Zone:	layer 1-7	west_1_7_tri.rad
	West Zone:	layer 8-12	west_8_12.rad
	Central Zone:	layer 1-7	center_1_7_tri.rad
	Central Zone:	layer 8-13	center_8_13.rad
	East Zone:	layer 1-7	east_1_7_tri.rad
	East Zone:	layer 8-12	east_8_12.rad
	Whole parts:	landing_cols	CP_landing_cols.rad
	Whole parts:	base	CP_base.rad
	Whole parts:	frontsteps	CP_steps.rad
	Whole parts:	3 named layers	CP_xbracesSmall_xbraceCeiling_intwalls.rad
	Whole parts:	int doors	CP_intdoors_tri.rad
(galleries.fmz)
	All except 2floor+landing floor		CP_galleries_no2floor_nolandingfloor.rad
(roofSetup.5.fmz)
	All except canvas layer		CP_roof_nocanvas.rad
(transbuild.8.fmz)
	TBody		trans_tbody.rad
	Arch		trans_arch_tri.rad
	LeadFlats		trans_leadflats_tri.rad
(trimandflag.fmz)
	walledgeW, walledgeC, walledgeE		CP_walledge_tri.rad
	flagsW, flagsC, flagsE		CP_flags.rad
(elm1.dxf)
	All layers		elm1.rad
(Others: The Form•Z files are not available for the following geometries.)
	canvas		design_canvas.rad
	trees		design_trees.rad
	floor:	1floor of Central Zone	design_center_1floor.rad
		1floor of East Zone	design_east_1floor.rad
		1floor of West Zone	design_west_1floor.rad
		2floor of Gallery Central	design_galleriesC_2floor_all.rad
		2floor of Gallery East	design_galleriesE_2floor.rad
		2floor of Gallery West	design_galleriesW_2floor.rad
		landing floor of GalleryC	design_galleriesE_landingfloor.rad
		landing floor of GalleryE	design_galleriesE_landingfloor.rad
		landing floor of GalleryW	design_galleriesW_landingfloor.rad

Note: We are rendering the Crystal Palace images with quite different view parameters; in other words, there is no significant overlap between different views. Thus, it does not make sense to save the cached indirect irradiance values to an ambient file to be reused for later renderings. As a result, we just need one Radiance input .rif file to include multiple view description files to render images with different views.

Images

This holds viewable image files of the CP objects. It's not yet clear what format the files will be -- probably .jpg and maybe .pic. We could also put .obj files in here. There will likely be four views of each object (front, back, left, right). The views can be <xptr>s that are grouped with <linkGrp>.

.obj Files

We could also put the .obj files in their own separate section. This would keep things a bit neater (since .obj files are text files, but represent images), but it would add yet another set of ids to keep track of (besides the notes and the images).

Notes

1 The "decomposition" is done only when '_tri' is at the end of the file name. [back]

2 Optional. [back]

3 The mGutters layers were cut in order to be the same length with other parts. Also, the canvas layer and roof layer (made of glass) are rendered separately. [back]

Change log

date: Thur, 17 June 03
done by: Sarah Wells, tech writer
fixed links to images

Copyright 2003 IATH at the University of Virginia. All rights reserved.