Arbeitspapiere
Working Papers Nr. 2, Oktober 2010
Technische Einführung in FREAC
Reinhard Koenig, Torsten Thurow, Jörg
Braunes, Christian Tonn, Dirk Donath,
Sven Schneider
ISSN 2191-2416
Informatik in der Architektur | InfAR
Bauhaus-Universität Weimar, Professur Informatik in der Architektur, Belvederer Allee 1, 99421 Weimar Fon: +49/3643/584201, [email protected], http://infar.architektur.uni-weimar.de
Reinhard Koenig, Torsten Thurow, Jörg Braunes, Christian Tonn,
Dirk Donath, Sven Schneider
Technische Einführung in FREAC
Weimar 2010
Arbeitspapiere Informatik in der Architektur, Bauhaus Universität Weimar, Nr. 2
ISSN 2191-2416
Bauhaus-Universität Weimar, Professur Informatik in der Architektur
Belvederer Allee 1, 99421 Weimar
http://infar.architektur.uni-weimar.de Titelbild: Jugendstil-Wendeltreppe im Hauptgebäude © Bauhaus-Universität Weimar
Redaktionelle Anmerkung:
Prof. Dr. Dirk Donath leitet die Professur Informatik in der Architektur an der Bauhaus-Universität
Weimar. Dr. Reinhard König ist Vertretungsprofessor der Professur Informatik in der Architektur an
der Bauhaus-Universität Weimar. Dr. Torsten Thurow, Dipl.-Ing. Jörg Braunes, Dipl.-Ing. Christian,
Tonn und Dipl.-Ing. Sven Schneider sind wissenschaftliche Mitarbeiter an der Professur Informatik in
der Architektur an der Bauhaus-Universität Weimar.
Der vorliegende Text ist auf Englisch erschienen:
Koenig, R., Thurow, T., Braunes, J., Tonn, C., Donath, D., & Schneider, S. (2010). FREAC: A Techni-
cal Introduction to a Framework for Enhancing Research in Architectural Design and Communication.
Education and research in Computer Aided Architectural Design in Europe (eCAADe).
Arbeitspapiere Nr. 2 Bauhaus-Universität Weimar | Informatik in der Architektur
1
Technische Einführung in FREAC:
A Framework for Enhancing Research in
Architectural Design and Communication
Reinhard Koenig1, Torsten Thurow
2, Jörg Braunes
3, Christian, Tonn
4, Dirk Donath
5, Sven Schneider
6
Abstract
Im vorliegenden Beitrag wird ein Framework für ein verteiltes dynamisches Produktmodell
(FREAC) vorgestellt, welches der experimentellen Softwareentwicklung dient. Bei der Ent-
wicklung von FREAC wurde versucht, folgende Eigenschaften umzusetzen, die bei her-
kömmlichen Systemen weitgehend fehlen: Erstens eine hohe Flexibilität, also eine mög-
lichst hohe Anpassbarkeit für unterschiedliche Fachdisziplinen; Zweitens die Möglichkeit,
verschiedene Tools nahtlos miteinander zu verknüpfen; Drittens die verteilte Modellbear-
beitung in Echtzeit; Viertens das Abspeichern des gesamten Modell-Bearbeitungsprozesses;
Fünftens eine dynamische Erweiterbarkeit sowohl für Softwareentwickler, als auch für die
Nutzer der Tools. Die Bezeichnung FREAC umfasst sowohl das Framework zur Entwicklung
und Pflege eines Produktmodells (FREAC-Development) als auch die entwickelten Tools
selbst (FREAC-Tools).
Keywords: Softwareentwicklung; Experimentalplattform; Produktmodell; digitales Gebäu-
demodell.
Arbeitspapiere Nr. 2 Bauhaus-Universität Weimar | Informatik in der Architektur
2
1. Introduction
Forschung im Bereich von Computer Aided Architectural Design (CAAD) besteht neben der
Untersuchung, Bewertung und Einordnung bestehender digitaler Systeme in der Regel da-
rin, neue Konzepte und Ideen für zukünftige Softwareentwicklungen auszuarbeiten. Diese
Konzepte werden im Idealfall mittels Prototypen umgesetzt und evaluiert. Eine Möglich-
keit, solche Prototypen zu realisieren besteht darin, kommerzielle Systeme als Basis zu nut-
zen und Erweiterungen für diese zu programmieren. Jedoch sind diese kommerziellen Sys-
teme (trotz ihres großen Funktionsumfangs) häufig zu starr und unflexibel, um den oft sehr
speziellen Anforderungen neuer Konzepte (z.B. interaktive und generative Entwurfssyste-
me, Open-Design Methoden, digitale Bauaufnahme) gerecht zu werden. Eine andere Mög-
lichkeit für die Realisierung von Prototypen besteht in der Programmierung eigenständiger
Tools "from the scratch". Neben dem sehr großen Programmieraufwand besteht hier jedoch
das Problem der mangelhaften Kompatibilität mit anderen Programmen (Tools). Deshalb
bleiben diese Werkzeuge oft auf spezielle Aspekte beschränkt und sind aufgrund ihres ge-
ringen Funktionsumfangs nur begrenzt evaluierbar.
Die beschriebene Situation macht deutlich, dass für die experimentelle Softwareentwick-
lung im Bereich der CAAD-Forschung ein Framework zur Verknüpfung verschiedener Soft-
waretools fehlt. Im vorliegenden Beitrag wird ein Framework für ein verteiltes dynamisches
Produktmodell (FREAC) vorgestellt, welches die oben dargestellten Anforderungen erfüllt
und in wesentlichen Teilen zur Verfügung steht. Die Bezeichnung FREAC umfasst sowohl
das Framework zur Entwicklung und Pflege eines Produktmodells (FREAC-Development) als
auch die entwickelten Tools selbst (FREAC-Tools). Entwickelt wurde FREAC als Forschungs-
Experimentierplattform, für die bis heute bereits zahlreiche Tools entstanden sind.
2. Konzept eines dynamischen Produktmodells
Aktuelle CAAD-Systeme verwenden Bauwerks-Informations-Modelle (BIM) zur internen
Abbildung ihrer Daten. Diese bieten in der Regel eine feste Strukturierung in Raum- und
Bauteilobjekte sowie deren geometrische Ausprägung an. Eine Nutzer und Projekt orien-
tierte Anpassung hinsichtlich Strukturierung und geometrischer Ausprägung ist derzeit nicht
möglich. Dies ist aber bei der Umsetzung neuer Softwarekonzepte und Gebäudetypologien
unabdingbar.
Kern des FREAC-Development bildet daher ein zur Laufzeit dynamisch veränderbares und
erweiterbares Produktmodell. Einzelne Aspekte des Produktmodells lassen sich durch eine
Arbeitspapiere Nr. 2 Bauhaus-Universität Weimar | Informatik in der Architektur
3
Menge von Klassen und Objekten abbilden, welche wiederum aus Attributen und Metho-
den bestehen (Prinzip der Objektorientierten Programmierung). Ein dynamisches Modell
erfordert, dass bestimmte Strukturen modifiziert bzw. erweitert werden müssen. Diese
Modifikationen umfassen dabei u.a. das Hinzufügen und Ändern von Klassen, Attributen
und Methoden.
Zur Umsetzung eines solchen dynamischen Produktmodells existieren verschiedene Ansät-
ze, wobei unterschiedliche Anforderungen an Flexibilität und Performance an das Modell
zu berücksichtigen sind:
• Flexibilität des Gesamtsystems, d.h. die Anpassungen von Attributen und Methoden
sollen zur Laufzeit ermöglicht werden.
• Teilweise hohe Anforderungen an die Geschwindigkeit, z.B. bei der Geometriedar-
stellung, oder bei der Ausführung aufwendiger numerischer Operationen
• Effiziente Speichernutzung, insbesondere bei der geometrischen Abbildung größerer
Bauwerke oder bei Details
• Nötiges Fachwissen des Nutzers bei der Anpassung von Strukturen
Aus diesen Anforderungen ergeben sich Spannungen hinsichtlich Flexibilität auf der einen
Seite und Performance, d.h. Geschwindigkeit und effektive Speichernutzung, auf der ande-
ren Seite. Um den Anforderungen größtmöglich gerecht zu werden, wird ein heterogener
Systemansatz vorgeschlagen, der Anpassungen auf verschiedenen Ebenen der Programmie-
rung bzw. Nutzeranpassung vorsieht. Für den vorgeschlagenen Ansatz werden daher drei
unterschiedliche Personengruppen vorgesehen:
• Programmierer
• Administrator
• Nutzer
Die Gruppe der Programmierer erstellt hauptsächlich Teilmodelle, wie z.B. zur Geometrie-
abbildung, Beschreibung der Raum- und Bauteilstruktur, Statik etc. Die Teilmodelle werden
in der Regel mit Hochsprachen wie C++ erstellt wodurch eine hohe Performance und effizi-
ente Speichernutzung gewährleistet wird. Eine Dynamik der Teilmodelle ist nur begrenzt
möglich und wird zur Compilezeit bestimmt. Die Menge der Teilmodelle wird als Fachscha-
le bezeichnet (Abb. 1).
Administratoren passen das Produktmodell seinen jeweiligen Aufgaben an. Anpassungen
erfolgen zunächst durch Hinzuladen neuer Teilmodelle, welche anschließend modifiziert
und erweitert werden können. Schnittstellen stelleneine Verbindung zwischen den fest
Arbeitspapiere Nr. 2 Bauhaus-Universität Weimar | Informatik in der Architektur
4
programmierten Teilmodellen und den darauf aufbauenden nutzerseitigen Erweiterungen
von Attributen und Methoden durch bspw. Skripte dar. Die Fachschale zusammen mit den
administrativen Anpassungen bzw. Erweiterungen stellen die Basisschemata dar, welche
dem Nutzer zur Verfügung gestellt werden. Auf Applikationsebene füllen diese das Modell
mit den jeweiligen Daten. Veränderungen am Produktmodell sind auf Basisschemata-Ebene
nicht möglich.
Abb. 1: Aufbau des verteilten Produktmodells als Schalenmodell.
Die bisher entwickelten Teilmodelle nutzen das verteilte Produktmodell als BIM. Grund-
sätzlich ist der FREAC-Kern allerdings auch für andere Bereiche (z.B. Produktdesign oder
Städtebau) adaptierbar und kann daher als verteiltes Produktmodell verstanden werden.
Die Nutzer des dargestellten Modells arbeiten in der Regel am gleichen Ort, sondern sind
auf einzelne Büros oder Institutionen verteilt. Daher ist der Einsatz eines verteilten Pro-
duktmodells notwendig (Hauschild & Hübler 2003), welches den Zugriff auf das Modell
„online“ ermöglicht. Idealerweise sollte dieser unmittelbar auf den zentral gehaltenen Da-
tenbestand erfolgen. Da dies nicht in jedem Fall möglich ist, werden „Offline“- Synchroni-
sationstechniken notwendig, welche das Splitten und spätere Zusammenfügen von Daten-
beständen ermöglichen. FREAC nutzt dabei Techniken wie Transaktionen und Versionie-
rungen mit Online-Synchronisation, welche die Speicherung der Historie von Modellen
sowie ihre quasi-parallele Bearbeitung erlauben. Ein FREAC-Modell wird auf einem lokalen
Computer mittels Anwendungen für spezielle Aufgaben, den Clients, bearbeitet. Alle Cli-
ents gleichen ihre Modelldaten mit denen auf einem zentralen Server ab. Anhand des Cli-
entkonzepts wird eine reibungslose Vernetzung verschiedener Projekte ermöglicht, die,
basierend auf einem gemeinsamen Modell, unabhängig voneinander entwickelt werden
können. Durch die nahezu unbeschränkte Erweiterbarkeit auf Entwickler- sowie Nutzer-
ebene stellt FREAC einen Ansatz vor, wie sich die Entwicklung von individuellen Software-
Arbeitspapiere Nr. 2 Bauhaus-Universität Weimar | Informatik in der Architektur
5
Insellösungen hin zu einem zusammenhängenden Kontinent digitaler Systeme verwirkli-
chen lässt.
3. Technische Grundlagen von FREAC
3.1. Modellsynchronisation
Bei dem FREAC zugrundeliegenden Ansatz erfolgt die Synchronisation von Veränderungen
an einem Modell vorrangig online über kurze Transaktionen. Das heißt, dass nach jedem
abgeschlossenen Veränderungsschritt, der am lokalen Modell anhand eines Clients durch-
geführt wurde, einmalig die Modelländerungen an den Server und von dort wieder an alle
Clients übertragen werden müssen. Das Vorgehen erlaubt eine quasiparallele Bearbeitung
auf Grundlage einer sequentiellen Änderung des Modells ohne Merging-Mechanismen,
beschränkt aber die Anzahl der quasiparallel arbeitenden Clients und stellt entsprechende
Anforderung an die Kürze der Transaktionen. Weiter muss eine permanente Netzverbin-
dung zwischen Clients und Server bestehen. Die zugrundeliegende persistente Datenhal-
tung unterstützt jedoch auch lokale Versionsverzweigungen, auf deren Grundlage Offline-
Synchronisationen mit Merging-Ansatz aufbauen können.
Die Datenhaltung der FREAC-Modelle erfolgt parallel in Server und Clients. Dieser Ansatz
erlaubt unter anderem eine Reduzierung der Netzlast, da nur Modelländerungen übertra-
gen werden müssen. In der Regel sind die meisten Objektaufrufe lesender Art, so dass im
Vergleich zu entfernten Methodenaufrufen meist nur auf die lokale Modellkopie zugegrif-
fen werden muss.
Eine entscheidende Frage beim Entwurf einer Modellverwaltung ist die Größe der zu ver-
waltenden Modelle. Die Verwendung konventioneller Datenbanken erlaubt die Bearbei-
tung sehr großer Modelle, da hier der Arbeitsspeicher nicht die Modellgröße beschränkt.
Dafür ist die Zugriffsgeschwindigkeit auf Datenbankinhalte relativ langsam im Vergleich zu
Modellen, welche vollständig im Arbeitsspeicher gehalten werden. Der vorgestellte FREAC-
Ansatz geht hier einen Kompromiss ein, indem er beide Konzepte kombiniert. Diese Kom-
bination führt zu einer Größenbeschränkung der Modelle, ermöglicht dafür aber eine höhe-
re Zugriffsgeschwindigkeit im Vergleich zu Datenbanklösungen, da Objektinhalte im Ar-
beitsspeicher gehalten werden können. Des Weiteren werden Objekte erst dann in den
Arbeitsspeicher geladen, wenn der erste Zugriff auf ihren Inhalt erfolgt. Die Objekte kön-
nen auch wieder aus dem Arbeitsspeicher ausgelagert werden, solange auf ihren Inhalt
nicht zugegriffen wird.
Arbeitspapiere Nr. 2 Bauhaus-Universität Weimar | Informatik in der Architektur
6
3.2. Dynamik der Modellstrukturen
Im Bezug zur FREAC-Modellstruktur bedeutet Dynamik, dass bei einer bestehenden Daten-
struktur jederzeit Objekte hinzugefügt, die Eigenschaften der Objekte erweitert, sowie neue
Methoden zur Bearbeitung von Objekten erstellt werden können. Die Dynamik betrifft also
sowohl Modellstruktur wie auch die darauf aufbauenden Algorithmen, wobei wir uns bei
beiden vor allem auf die Erweiterbarkeit konzentrieren. Ein in dieser Art dynamisches Pro-
duktmodell ist, wie bereits erwähnt, deshalb so wichtig, da bei komplexen Artefakten nicht
alle Elemente, deren Eigenschaften und Interaktionsmöglichkeiten vorherbestimmt werden
können. Dies trifft nicht zuletzt auf die Abbildung von Bauwerken zu In der Regel bringt
jeder Planungs- und Entwurfsprozess Sonderfälle mit sich.
FREAC wurde auf Grundlage von Microsofts Software-Plattform .NET erstellt. FREAC-
Module mit hohen Anforderungen an Performance oder Speicherbedarf sind allerdings in
unmanaged code implementiert. .NET bietet verschiedene Eigenschaften, welche sich sehr
gut zur Realisierung der beschriebenen Dynamik eignen. Zum einen gibt der Reflection-
Mechanismus Auskunft über vorhandene Klassen und Datenstrukturen. Zum anderen kön-
nen neue Assemblys (DLLs) zur Laufzeit hinzugefügt werden. Auf letztgenannter Möglich-
keit basiert die Erstellung neuer Teilmodelle in FREAC.
Diese Grundfunktionalitäten von .NET werden von FREAC ergänzt um erstens die Möglich-
keit der Erweiterung von Objekten und Attributen zur Laufzeit um neue Attribute und um
zweitens das Monitoring von Objekten und Attributen zur Laufzeit. Mit Monitoring ist im
vorliegenden Kontext gemeint, das jedes Objekt und Attribut - auch zur Laufzeit hinzuge-
fügte - in der Lage ist, andere Objekte - welche dieses beobachten - über Veränderungen
zu informieren. Monitoring ist ein grundlegender Mechanismus zur Realisierung der dyna-
mischen Erweiterbarkeit eines Modells. Ein weiterer ist das Hinzufügen von Teilmodellen
zur Laufzeit durch neue Assemblys in Form von DLLs.
Die Dynamik der FREAC-Modellstruktur soll in Zukunft nicht nur für Programmierer, son-
dern auch für Administratoren und Nutzer verfügbar sein. Auch hier bietet gerade .NET
Vorteile, da im Rahmen dieser Software-Plattform verschiedene Programmiersprachen ver-
fügbar sind. Da besonders bei Endnutzern keine Programmierkenntnisse vorausgesetzt
werden können, bieten sich für die Ebene der Nutzer Ansätze der grafischen Programmie-
rung oder des Scripting an.
Arbeitspapiere Nr. 2 Bauhaus-Universität Weimar | Informatik in der Architektur
7
4. Anwendungsbeispiele
Im folgenden Abschnitt wird die Funktionsweise der FREAC-Modellstruktur anhand von
ausgewählten Softwareprototypen (FREAC-Tools) beispielhaft demonstriert. Die vorgestell-
ten Prototypen stellen zum Teil Testapplikationen zur Verifizierung bestimmter Funktionali-
täten dar, sowie fortgeschrittene Anwendungen, die im Zuge verschiedener Forschungstä-
tigkeiten entstanden sind. Im Folgenden werden die Applikationen kurz beschrieben und
anschließend deren Einbindung in FREAC-Development dargestellt.
4.1. FREAC-Tools
Ein FREAC-Tool ist „Colored Architecture“ (Tonn et al., 2006). Dieses widmet sich beson-
ders dem Defizit des digitalen Farb- und Materialentwurfes, welcher vom Beginn einer Pla-
nung bis hin zur Ausführung unterstützt werden soll. „Colored Architecture“ adaptiert be-
währte Vorgehensweisen, Darstellungen und Werkzeuge der Planungspraxis wie Varianten,
Farbstudien, Farbharmonien und Farbkontraste, um die Gestaltung von Materialoberflä-
chen zu unterstützen. Für die Bewertung und Beurteilung dieser Farb- und Materialkonzep-
tionen wurde eine Live-Radiosity-Berechnung entwickelt. Bei dieser lassen sich die Parame-
ter Sonnenstand, Bewölkung des Himmels sowie die Farben der Oberflächen interaktiv ein-
stellen, während man sofort die aktualisierte, realitätsnahe Radiosity-Visualisierung beurtei-
len kann. Mit Hilfe dieser Software lassen sich Wechselwirkungen wie z.B. Farbreflexionen
der Materialien untereinander in Echtzeit darstellen und bewerten (Abb. 2).
Abb. 2: Live Radiosity-Visualisierung in „Colored Architecture“.
Ein weiteres Tool zur einfachen Modellierung von 3D-Geometrien ist der „SketchClient“
(Abb. 3, links). Es verfügt über einfache Polygonmodelling und -editing Funktionen. Dabei
wird jede Änderung am Modell als Version abgespeichert und im Versionsgraphen darge-
stellt (Abb. 3, rechts). Ein schneller Wechsel zwischen verschiedenen Entwurfsvarianten
sowie zu vorangegangenen Arbeitsständen ist jederzeit möglich. In jedem Knoten des Ver-
Arbeitspapiere Nr. 2 Bauhaus-Universität Weimar | Informatik in der Architektur
8
sionsgraphen wird protokolliert, welcher Nutzer zu welchem Zeitpunkt eine Änderung
durchgeführt hat, und wie viele Objekte verändert wurden. Dieses Versionierungssystem
ist dabei nicht auf den einzelnen Client beschränkt, sondern wird durch die FREAC-
Modellstruktur zentral bereitgestellt.
Abb. 3: Modellierwerkzeug „SketchClient“ und sein Versionsgraph-Dialog.
Bei dem dritten hier angeführten Beispiel handelt es sich nicht um einen eigenständigen
Client, sondern um ein ergänzendes Teilmodell, welches der Abbildung der Raum- und
Bauteilstruktur eines Gebäudes dient. Dieses Teilmodell befindet sich derzeit in der Ent-
wicklung und orientiert sich in seinem Aufbau zu großen Teilen an den IFC. Innerhalb eines
Clients wird die Gebäudestruktur in Form eines Treeview geordnet dargestellt. Diese Struk-
tur basiert auf der Organisation in: Projekt → Grundstück → Gebäude → Geschoss → Raum
oder Bauteilkategorien. Die einzelnen abstrakten Elemente des Raum- und Bauteilmodells
werden mit der zugehörigen 3D-Geometrie verknüpft.
4.2. Zusammenarbeit der Teilmodelle
Je nach Anwendungsgebiet verwenden die einzelnen FREAC-Tools unterschiedliche Teil-
modelle, welche spezifische Aufgaben erfüllen. „ColoredArchitecture“ beispielsweise ver-
wendet zur Darstellung der 3D-Geometrie das „GeometryModel“. Die Funktionalitäten zur
Farb- und Materialwahl sowie der Live-Radiosity-Berechnung sind im „ColorModel“ im-
plementiert. Der „SketchClient“ wiederum greift lediglich auf das „GeometryModel“ zu. Zur
semantischen Abbildung eines Gebäudes wird wiederum das „BuildingElementModel“ in
Verbindung mit dem „GeometryModel“ verwendet. Alle Teilmodelle und das Zusammen-
spiel der Clients werden vom „SyncServer“ verwaltet, wobei zwischen den Clients und dem
Server lediglich Änderungen an den Modellen übertragen werden (Abb. 4). Die Clients „se-
hen“ immer nur die Modelle, bzw. die in den Modellen gespeicherten Objekte, die sie für
ihren Anwendungsfall benötigen. Änderungen an Modellinhalten werden aber - im Gegen-
satz zu einem Repositorium - in Echtzeit an alle Clients weitergegeben.
Arbeitspapiere Nr. 2 Bauhaus-Universität Weimar | Informatik in der Architektur
9
Abb. 4: Teilmodelle (unten) und Interaktion zwischen Clients und dem SyncServer.
Wie im technischen Teil dieses Artikels bereits erläutert, erlaubt die dynamische Modell-
struktur des FREAC-Development jederzeit das Ergänzen und Anpassen von Teilmodellen
ohne die Notwendigkeit der Recompilierung bereits bestehender Teilmodelle. Damit kön-
nen die FREAC-Tools jederzeit um neue Softwareprototypen für neue Anwendungsfälle
ergänzt werden. Neu entwickelte Clients können dabei sowohl bestehende, wie auch neue
Teilmodelle nutzen.
5. Ausblick
Ziel der Entwicklung von FREAC ist es, eine flexible Plattform für verschiedene CAAD-
Forschungsprojekte zu etablieren. In einer Reihe von Forschungsprojekten wurde und wer-
den vielfältige Clients entwickelt: Zur computerbasierten Bauaufnahme, für verschiedene
Planungsaspekte wie Farbplanung oder die Ermittlung der optimalen Ausnutzung von
Grundstücken, zur Generierung von Architekturlayouts sowie zur Koordination und Kom-
munikation in offenen kollaborativen Entwurfsprozessen. Die in diesen Projekten entstan-
denen Clients sind über das FREAC-Modellkonzept nahtlos miteinander verbunden. Sie
demonstrieren die Potentiale des vorgestellten Ansatzes für den Austausch zwischen ver-
schiedenen Fachdisziplinen im Planungsprozess – der Verbindung der Insellösungen zu ei-
nem Modell-Kontinent.
Wir beabsichtigen, FREAC ab Anfang 2011 für Forschungsprojekte unentgeltlich zur Verfü-
gung zu stellen.
Arbeitspapiere Nr. 2 Bauhaus-Universität Weimar | Informatik in der Architektur
10
References
Hauschild, T. & Hübler, R. (2003): Techniken der Verwaltung dynamischer digitaler Bau-
werksmodelle für Revitalisierungsvorhaben. Proceedings of IKM 16: Internationales
Kolloquium über Anwendungen der Informatik und Mathematik in Architektur und
Bauwesen (http://e-pub.uni-weimar.de/volltexte/2005/317/)
Tonn, C., & Donath D. (2006): Color, Material and Light in the Design Process: A Software
Concept. (RivardH., MelhemH., MirescoE., Ed.). Proceedings of ICCCBE: International
Conference on Computing and Decision Making in Civil and Building Engineering.
1467-1476