Inhalt dieser Diplomarbeit ist die Integration eines bestehenden CAD-Kerns in die Software eines VirtualReality-Systems. Hierbei soll der Zugriff auf die gesamte Funktionalität des Kerns verfügbar sein, um neben der Betrachtung bestehender Konstruktionen auch deren Änderung oder Erstellung in einer VR-Umgebung zu ermöglichen.
Hierfür werden zuerst bestehende Systeme und Integrationsansätze sowie die zur Verfügung stehende Hard- und Software im CAD- und VR-Bereich betrachtet. Dies liefert die wesentlichen Kriterien für die nachfolgende Auswahl des verwendeten Kerns und der Konzeption des Integrationsmodells.
Die Integration des Kerns erfolgt über ein nachrichtenbasiertes Modell, bei dem die Funktionalität des Gesamtsystems in funktionell unterschiedliche Module gegliedert wird. Zusammen mit der Ansteuerung im Textformat erlaubt die flexible Struktur die Anpassung an vielfältige Einsatzgebiete, ohne daß hierfür Änderungen an den Kernmodulen erforderlich sind.
Den Abschluß bildet die praktische Umsetzung des vorgestellten Konzepts und deren Verwendung in einer prototypischen Anwendung für Desktop- als auch für VR-Umgebungen zusammen mit einer Beschreibung der implementierten Funktionalität und der dabei gewonnenen Erkenntnisse.
Dieses Dokument ist auch in einer PDF-Version verfügbar.
Die Funktionalität derzeitiger Virtual Reality (VR) Applikationen im industriellen Einsatzbereich digitaler Prototypen (DMU) beschränkt sich häufig auf das passive Betrachten und Analysieren dreidimensionaler Objekte. Wird der Einsatzbereich von VR jedoch um die Möglichkeit zur Modifikation oder sogar Generierung von Geometrien durch direkten Zugriff auf CAD-Funktionalitäten erweitert, könnte die VR-Technologie in der Produktentwicklung zukünftig noch effizienter eingesetzt werden.
Ziel der Arbeit ist die Konzeption und prototypische Implementierung eines Integrationsmodells zwischen dem VR-System und dem CAD-Kern. Hierbei dient das VR-System als Benutzungsschnittstelle zur Interaktion beim Modellieren und zur Visualisierung der vom CAD-Kern generierten Geometrien. Der CAD-Kern generiert die vom Benutzer modellierten parametrischen Geometrien und die zur Visualisierung erforderlichen Polygonnetze. Dem Integrationsmodell liegt dabei eine eindeutige Trennung zwischen VR-System und CAD-Anwendungskern zu Grunde, um eine spätere Weiterverwendbarkeit des Integrationsmodells in anderen Umgebungen, beispielsweise einer Desktop-Anwendung, zu vereinfachen.
Die Diplomarbeit gliedert sich in folgende Teile: Zuerst werden potentielle Einsatzgebiete einer integrierten VR-CAD-Anwendung aufgezeigt, gefolgt von einer Übersicht über bestehende Ansätze und derzeit verfügbare Hard- und Software. Anschließend werden mit Parasolid und OpenCascade zwei CAD-Kerne verglichen, welche für die praktische Implementierung in die nähere Auswahl kamen. Es folgt eine Aufzählung der wichtigsten Kriterien für das Integrationsmodell, dessen theoretischer Aufbau und die bei der praktischen Implementierung erfolgte Vorgehen. Abschließend werden im Fazit die dabei neu gewonnenen Erkenntnisse genannt und ein Ausblick auf weitere Möglichkeiten und Forschungsschwerpunkte gegeben.
Die Integration eines CAD-Systems in eine VR-Umgebung eröffnet Möglichkeiten, die von bestehenden desktopbasierten Lösungen nur unzureichend unterstützt werden und zu höherer Ergonomie und flüssigeren Arbeitsabläufen führen können:
Im VR-Umfeld eingesetzte Eingabegeräte und Interaktionstechniken erlauben eine direktere Steuerung und Navigation im Umgang mit dreidimensionalen Objekten als es mit den gängigen für zweidimensionale Anwendungsgebiete konzipierten Eingabegeräten wie Stift und Maus möglich ist. Dies erlaubt in Verbindung mit dem zunehmenden Einsatz räumlicher Darstellungen in der Benutzeroberfläche von CAD-Systemen eine natürlichere und effizientere Interaktion während des Konstruierens.
Mit der stereoskopischen Darstellung eines VR-Systems ist es möglich, dem Anwender eine realistischere dreidimensionale Darstellung zur Beurteilung der Konstruktion zu bieten. Für einfache lineare, zylindrische oder kugelförmige Strukturen ergibt sich dadurch zwar nur ein geringer Vorteil, aber bei komplexeren Freiformkurven und -Flächen ergeben sich deutliche Vorteile zur Beurteilung des Aussehens der erzeugten Objekte [VRDFFS].
Besonders interessant wird dies dadurch, daß in CAD-Systemen zunehmend Funktionen Einzug halten, die weniger einer klassisch am Reißbrett konstruierten Vorgehensweise sondern mehr der eines intuitiv arbeitenden Modellierers entsprechen, etwa bei der Erstellung von Flächen und Kurven aus einer Menge von Punkten oder anhand vorgegebener physikalischer Parameter. Damit wird der Einsatz eines CAD-Systems als Designwerkzeug zunehmend interessanter, was einer besseren Verzahnung zwischen Konzeption und Konstruktion förderlich ist.
Ein entsprechender Arbeitsplatz dürfte in der Regel als halbimmersives System ausgelegt sein, das sich von der Bedienung weitgehend an bestehenden Desktoparbeitsplätzen ausrichtet und somit einen nahtlosen Übergang von einem herkömmlichen CAD-Arbeitsplatz darstellt. Die gängigen Eingabegeräte im CAD-Bereich (Tastatur, Maus, Spacemouse, Tablett) können parallel oder alternativ weiterverwendet werden, für die stereoskopische Ausgabe kann anstelle spezieller Bildschirme oder Projektionslösungen auch ein herkömmlicher Bildschirm in Kombination mit Shutterbrillen verwendet werden.
Die Visualisierung fertiger Konstruktionen in einem VR-System wird schon heute mit Erfolg eingesetzt und ermöglicht es, auch Betrachtern mit geringer ausgeprägtem räumlichen Vorstellungsvermögen einen umfassenden Eindruck von den dargestellten Objekten zu gewinnen. Diese sind allerdings statisch und können nur durch erneuten Export samt ggf. nötiger Nachbearbeitung aus dem CAD-System geändert werden. Mit der Integration des CAD-Kerns in das VR-Systems entfällt dieser Schritt [CDPVE].
Mit einer geeigneten Anbindung wird es möglich, sowohl zur Evaluierung als auch zur Konstruktion dieselbe Benutzungsschnittstelle zu verwenden. Umständliche und unergonomische Wechsel zwischen der Benutzeroberfläche des 3D-VR-System und der 2D-Oberfläche eines CAD-Systems können somit entfallen. Es ist auch denkbar, einige einfache Funktionen zur Objektmanipulation einzubinden, mit denen auch Betrachter ohne nähere CAD-Kenntnisse schnell ihre Vorstellungen direkt in die Konstruktion einbringen können. Dies läßt eine effektivere Gestaltung der Kommunikation zwischen Designern und Konstrukteuren zu [VRAD] [CCSVR].
Je nach Art und Größe der dargestellten Objekte kann ein entsprechender Arbeitsplatz sowohl als halbimmersives als auch als vollimmersives System aufgebaut sein. Letzteres bietet sich vor allem bei Konstruktionen von Verkehrsmitteln, Gebäudeteilen und anderen Objekten an, bei denen der Mensch sich zu einem großen Teil in deren Inneren aufhält. Hier ist zu beachten, daß die Eingabegeräte sich deutlich von denen eines herkömmlichen CAD-Arbeitsplatzes unterscheiden und mit wesentlich weniger Eingabemöglichkeiten als diese auskommen müssen. Ein halbimmersives System kann hingegen einem herkömmlichen CAD-Arbeitsplatz entsprechend konzipiert werden.
Beliebt ist der Einsatz eines VR-Systems zur Visualisierung von Simulationsergebnissen, was insbesondere durch deren Eignung zur verständlicheren Darstellung großer Datenmengen begründet ist. Ebenso wie bei der Visualisierung des konstruierten Objekts bietet sich bei Integration eines CAD-Systems an, nicht nur die Auswirkungen an einem statisch exportierten Objekt zu betrachten, sondern dieses interaktiv verändern und die resultierenden Auswirkungen auf die Simulationsergebnisse direkt betrachten zu können. Es entfällt somit auch hier der umständliche Wechsel zwischen den jeweiligen Benutzungsschnittstellen. Die Gestaltung eines geeigneten Arbeitsplatzes hängt hier stark von den jeweils simulierten Vorgängen ab. Mit zunehmend umfangreicheren darzustellenden Datenmengen sind vollimmersive Systeme im Vorteil, da diese eine möglichst einfache und direkte Änderung der Betrachterposition im virtuellen Raum erlauben.
Die Trennung des Anwendungskerns von der Benutzeroberfläche entsprechend des Model-View-Controller oder Presentation-Abstraction-Control-Musters ist bewährte und gängige Praxis in der Anwendungsentwicklung und findet sich auch in bestehenden CAD-Umgebungen wieder. Während hier der Schwerpunkt der Entwicklung meist in der Kernfunktionalität, dem Datenaustausch und möglichst effizient handhabbaren Eingabemöglichkeiten liegt, erfolgt die Anbindung der graphischen Bildschirmausgabe sowie der unterstützten Eingabemöglichkeiten auf Basis bewährter Standard-APIs oder durch herstellerspezifische Plugins mit begrenzter Flexibilität. Gerade hier liegt dafür die Stärke von VR-Systemsoftware, die neben leistungsfähigen, gut skalierenden Funktionen zur Kapselung aktueller Grafik-APIs für monoskopische und stereoskopische Darstellungen auch eine weite Unterstützung verschiedenster Eingabegeräte von mechanisch betätigten Geräte über Bewegungserkennung und -Verfolgung bis hin zu Spracheingabe reichen. Vorhandene Algorithmen, insbesondere Shaderprogramme, lassen sich leichter in bestehende VR-Systeme integrieren als in die weitgehend vordefinierten 3D-Renderingfunktionen bestehender CAD-Systeme, was einer realistischeren Darstellung der konstruierten Objekte entgegenkommt. Die modular aufgebaute Struktur vieler VR-Systeme bietet zudem die Möglichkeit, bei einheitlichen Schnittstellen zu den restlichen Systemkomponenten eine hohe Flexibilität bei der Konzeption der Benutzungsschnittstelle zu bieten, was einer schnellen anwenderspezifischen Anpassung des Gesamtsystems sehr entgegenkommt [OTR][LTVR].
Aus dem Aufbau und der Fähigkeiten schon vorhandener Systeme lassen sich nützliche Hinweise für die Anforderungen an das zu entwerfende Integrationsmodell gewinnen. Ebenso wurden zwei einfache Objekte in Catia V5 als auch in SolidWorks konstruiert, anhand denen die Vorgehensweise als auch die benötigte Funktionalität für die prototypische Umsetzung in einer VR-Umgebung abgeschätzt werden kann.
Mit dem Detailed Virtual Design System (DVDS) entstand 2000 an der University of Wisconsin ein CAD-Kernwrapper, mit dem ein umfangreiches Konstruktionssystem realisiert wurde [DVDS]. Hierbei wird ein Server mit CAD-Kern mit VR-Systemen als Clients gekoppelt, wobei auch eine optionale Client-Client-Kommunikation mitsamt Rechteverwaltung zur Kommunikation zwischen den Anwendern eingeplant wurde. Für die Konstruktion wird ein 2D-Skizzierer mit automatischer Erkennung möglicher Zwangsbedingungen verwendet, die entstehenden Skizzen können danach in 3D extrudiert, geschnitten und weiterverarbeitet werden. Als Eingabemöglichkeiten stehen neben gängigen 3D-Eingabegeräten Sprach- und Gestenerkennung zur Kommandoauswahl bereit [MSUI]. Eine Vorschau in Echtzeit ist möglich, erfolgt aber aus Performancegründen auf Basis der tesselierten Daten im VR-System und beschränkt sich somit auf die jeweils vordefinierten Anwendungsfälle wie Extrusionen und Rotationskörper.
Am Fraunhofer IGD wurde mit ARCADE/VT [ARCVT] eine Konstruktionsumgebung geschaffen, bei der auf einer tischartigen Fläche virtuelle Objekte konstruiert werden können. Hierbei wurde der Schwerpunkt auf eine möglichst natürliche, intuitive Eingabe gelegt, bei der für zweidimensionale Skizzen zusätzlich auf eine Kombination eines frei beweglichen virtuellen Tabletts samt dazugehöriger physikalischer Platte als räumlich bewegliches Eingabegerät gesetzt wird. Von besonderem Interesse sind zudem die Möglichkeiten zur Eingabe von Freiformflächen, insbesondere die "Subtractive sweeping" genannte Kombination aus Extrusion und Boolschem Schnitt mit echtzeitfähiger bildraumbasierter Vorschau.
Die bisher einzig bekannte direkte Kopplung eines CAD-Kerns mit einer VR-Umgebung auf dem Markt wird als Erweiterung von Catia V5 in Zusamenarbeit mit SGI angeboten [CATVR]. Diese setzt auf der herstellertypischen modularen CAA-Schnittstelle auf, so daß die vorhandenen Komponenten sowie die schon bestehenden Visualisierungsfähigkeiten wie Culling, LOD, Szenegraph und Tesselierung für die VR-Anbindung verwendet werden können. Aufgabe der zusätzlichen VR-spezifischen Komponenten ist neben der Einbindung geeigneter Eingabegeräte die Verteilung der graphischen Daten an mehrere Ausgabekanäle für stereoskopische Darstellung, CAVE-Anwendungen oder Mehrbenutzeranwendungen. Als Haupteinsatzgebiet der VR-Anbindung wird die Evaluierung bestehender Konstruktionen propagiert, bei der durch den direkten Zugriff auf die gesamte Datenstruktur alle relevanten Informationen ausgelesen werden können und Hinweise für die weitere Konstruktion hinzugefügt werden können.
Alle anderen bekannten kommerziellen Anwendungen setzen dagegen auf den Export der Daten aus dem CAD-System in einem für das jeweilige VR-System geeignete Format. Hierfür werden entweder Standardformate für den CAD-Datenaustausch wie IGES und STEP verwendet oder bereits von Haus aus im VR-System unterstützte, aus dem Grafikbereich bekannte Formate wie VRML nebst den von gängigen 3D-Modellierern wie 3D-Studio oder Maya verwendeten Dateitypen eingesetzt. Problematisch ist hier neben dem Verlust von Strukturinformationen, welche derzeit selbst von STEP nur unvollständig unterstützt werden, die oft unbefriedigende Qualität der Daten, so daß neben dem Export eine zusätzliche Aufbereitung der Daten vor ihrer Verwendung benötigt wird. Hier läßt sich zwar mit externen Programmen die Konsistenz der Oberflächennormalen sicherstellen und Probleme in der Tesselierung wie Lücken und T-Intersections an Kanten ebenso wie eine zu hohe Polygonzahl halb- oder vollautomatisch korrigieren, für Texturdaten und Metainformationen sind aber oftmals zusätzliche Eingriffe des Benutzers nötig [CVRWSA]. Ein Reimport veränderter Daten in die CAD-Umgebung ist prinzipiell möglich, aber aufgrund des Datenverlustes beim vorherigen Export, insbesondere das Fehlen parametrischer Geometrie und der Konstruktionshistorie, nur sehr eingeschränkt sinnvoll.
Mit Lightning wurde am IAO ein flexibel einsetzbares datenflußorientiertes VR-System entwickelt [LTVR]. Dieses besteht aus einzelnen Modulen, Lightning-Objekte genannt, die über einen Tcl-Interpreter dynamisch geladen, instantiiert und vernetzt werden können. Die beiden wichtigsten Modultypen sind die Sensorobjekte, welche die Daten von Eingabegeräten einlesen, sowie die Visualisierungsobjekte, welche je nach Typ vordefinierte geometrische Objekte, bestehende Knoten im Szenegraph oder extern zu ladende Objekte in den Szenegraph einhängen und manipulieren können. Weitere Objekte führen mathematische Operationen wie Koordinatentransformationen, boolsche Algebra und Vektoroperationen aus. Als Szenegraph und für das Rendering wird OpenGL/Performer eingesetzt, dessen Funktionalität weitgehend von den vorhandenen Objekten gekapselt wird. So werden auch Objektpicking und die Initialisierung der Renderkanäle über entsprechende Objekte verfügbar gemacht. Positionierungsangaben als auch Transformationen werden stets durch ein Vektorpaar aus Position und Orientierung angegeben, wobei die Orientierung in den drei eulerschen Winkeln Head, Pitch und Roll erfolgt. Zusätzlich kann jedes Visualisierungsobjekt entlang seiner drei Hauptachsen separat skaliert werden. Weitere Objekte lassen sich entweder in C++ durch Ableiten bestehender Objekte realisieren oder zur Laufzeit als Tcl-Skripte erzeugen.
Als Beispiel für eine mit Lightning mögliche Anwendungsoberfläche kann HyMod dienen, ein sowohl auf Flächen- als auch auf Voxeldarstellung basierender Modellierer. Dieser enthält zwar keine CAD-spezifische Datenstruktur, dafür aber gute Beispiele wie die direkte Interaktion mit den modellierten 3D-Objekten aussehen kann. Von besonderem Interesse ist hierbei die Modifikation von vordefinierten Grundkörpern wie z.B. Kugeln oder Würfeln in Echtzeit.
Auf der Basis von OpenCascade entwickelte Prototypen lieferten nützliche Erkenntnisse über die Leistungsfähigkeit des verwendeten CAD-Kerns sowie über praktikable Wege bei der Konzeption des Integrationsmodells. So zeigte die Arbeit von S. Reinhold [LTBREP], daß OpenCascade grundsätzlich dafür geeignet ist, einfachere Körper echtzeitfähig zu tesselieren, während die prototypische Anwendung von F. Haselberger eine gute Ausgangsbasis zum Testen von Lightning sowie des Kerns mit komplexeren Objekten bot und einen gemischten Ansatz aus schnellem echtzeitfähigem Sketching einfacher Objekte im Wrapper und der Verwendung des CAD-Kerns für komplexere Geometrien demonstrierte.
Eine Analyse verschiedener VR-tauglicher Ein- und Ausgabegeräte findet sich in [IVRK], im folgenden werden die wichtigsten Punkte tabellarisch zusammengefaßt:
Gerät | Freiheitsgrade | Mapping | Haupteinsatzzweck | Vorteile | Nachteile |
---|---|---|---|---|---|
Tastatur, Dashboard | typisch 80-105 Tasten | n/a | Eingabe von beliebigen Bezeichnern, Kommentaren und exakten Zahlenwerten | Hohe Vertrautheit beim Benutzer, stets exakte Eingabewerte | Gerät benötigt Auflagefläche |
Maus/Trackball | 2 Achsen (+ Mausräder), wenige Tasten | relativ | schnelle Selektion | Hohe Vertrautheit beim Benutzer, hohe Genauigkeit möglich | Gerät benötigt meist Auflagefläche, echte 3D-Eingabe nur über unintuitiven Moduswechsel möglich |
Spacemouse | 3 Translation, 3 Rotation sowie mindestens 6 Tasten | relativ | Navigation in 3D, Positionieren von Objekten | relativ hohe Verbreitung im CAD- und 3D-Modellierbereich, gut geeignet zur gleichzeitigen Verwendung in Kombination mit weiteren Eingabegeräten | Mapping der Freiheitsgrade nicht eindeutig |
Grafiktablett | 2, wenige Tasten | üblicherweise absolut | Eingabe und Nachzeichnen von 2D-Punkten und -Kurven | intuitive Bedienung | Gerät erfordert Auflagefläche, Ergebnisse stark von der Gewöhnung des Benutzers abhängig |
Touchscreen | 2 Achsen | absolut | Selektion | hohe Intuitivität | Verwendung für stereoskopische Darstellung schwierig |
Joystick | meist 2-4 Achsen, 1-20 Tasten, Point-of-View | relativ | Navigation in simulierten Umgebungen | intuitive Bedienung der Achsen | geringe Genauigkeit |
Tracker | bis zu 6 | absolut | Eingabe der Betrachterposition relativ zum Ausgabegerät | hohe Intuitivität, Hände bleiben frei | kaum für andere Zwecke nutzbar |
3D-Zeigegeräte | bis zu 6 Achsen, wenige Tasten | absolut | Selektion, Manipulation in 3D | kompakte Form, intuitive Verwendung möglich | fehlende Auflagefläche erschwert längeren Einsatz |
Datenhandschuh | entsprechend Anzahl der Fingerkrümmungs- und Berührungssensoren | absolut | Kommandoeingabe | tragbares Gerät mit geringer Ermüdung des Benutzers | geringe Genauigkeit, Bedienung meist weniger intuitiv als erwartet |
Spracheingabe | n/a | n/a | Kommando- und Texteingabe | Hände und unmittelbare Umgebung des Benutzers bleiben frei | stark schwankende Erkennungsqualität der Eingabe, kaum zur Eingabe kontinuierlicher Werte geeignet |
Gestenerkennung | n/a | n/a | Kommandoeingabe | Verwendung intuitiver Gesten möglich | Eingabequalität schwankend und stark von den gewählten Gesten abhängig, taktile Rückkopplung fehlt |
Um dem Begriff der virtuellen Realität möglichst nahezukommen sollten soviele Sinne des Benutzers wie möglich berücksichtigt werden. Eingabegeräte mit Kraftrückkopplung erlauben dem Benutzer dabei, durch gemachte Materialien und Oberflächenstrukturen unmittelbar während der Eingabe zu erleben und entsprechend zu reagieren. Positionierbare Umgebungsgeräusche, Sprachausgabe und Systemklänge eigenen sich für die Beschreibung der virtuellen Umgebung als auch zur Information über eintretende Ereignisse und Statusmeldungen, unabhängig von Ort und Existenz der visuellen Repräsentation des zugehörigen Verursachers. Für die Ausgabe in einem graphischen Konstruktionssystem sind sie allerdings nur von untergeordneter Rolle und eignen sich mehr für die Unterstützung als einen echten Ersatz graphisch ausgegebener Informationen. Interessant sind hierbei die deutlichen Unterschiede zwischen den graphischen Ausgabegeräten je nach Technologie und Aufbau:
Technologie | Vorteile | Nachteile |
---|---|---|
2D-Standardbildschirm (Kathodenstrahlröhre, LCD, DFP) | hohe Auflösung und Ergonomie, Röhrentechnologie mit Shutterbrille auch zur 3D-Ausgabe nutzbar, portable Geräte vorhanden | für immersive Systeme weniger geeignet |
autostereoskopisches Display | hohe Auflösung und Ergonomie | Ergebnisse stark von Betrachterposition und Tracking abhängig |
Polarisationsbrille mit Projektionsschirm | wenig störende Hardware, auch für zwei oder drei Benutzer möglich | mäßige Kanaltrennung |
Farbfilterbrille | wenig störende Hardware | Farbverfälschung, mäßige Kanaltrennung |
Head-Mounted Display | optimale Kanaltrennung | geringe Auflösung, störende Abschirmung von der Umgebung, mitunter hohes Gewicht führt zu schneller Ermüdung der Nutzer |
Aufbau | Vorteile | Nachteile |
---|---|---|
Senkrechte Fläche | Auch für allgemeine Arbeitsplätzen nutzbar | geringe Immersion erfordert wenig intuitive Navigation des Betrachters in der 3D-Welt |
Pult oder Tisch | Optimale Kombination aus Ergonomie und Immersion | Integration herkömmlicher Eingabegeräte schwierig |
CAVE | höchster Immersionsgrad durch weites Gesichtsfeld | Aufwendige Installation, hoher Platzbedarf, schwierige Integration in bestehende Arbeitsumgebungen |
Darüber hinaus gibt es einige grundsätzliche Einschränkungen bei der 3D-Visualisierung. So stört jedes physikalische Objekt zwischen Bildfläche und Betrachter den dreidimensionalen Eindruck, was eine intuitive Bedienung (außer bei Head-Mounted Displays und BOOM) erschwert. Für einen Teil der Bevölkerung ist eine VR-Umgebung zudem nicht in vollem Umfang nutzbar, etwa durch eine eingeschränkte stereoskopische Sicht oder Anfälligkeit für Bewegungsübelkeit.
Beim Entwurf des VR-Interaktionsmodells sind physiologische Einschränkungen zu beachten, vor allem die anisotrope Wahrnehmung: Es stellt sich heraus, daß eine präzise Navigation in einer 3D-Umgebung in der Horizontalen am leichtesten fällt während sie in der Tiefe mit einer großen Unsicherheit behaftet ist [STVRBC]. Bei Verwendung eines Selektionsstrahls für indirekte Interaktion ähnlich eines Laserpointers kommt noch die Asymmetrie zwischen Position und Orientierung des Selektionsstrahls hinzu: Während Positionsänderungen sich unabhängig von der Entfernung des selektierten Objekts die Position des Auftreffpunkts stets mit demselben Maßstab ändern wirken sich Orientierungsänderungen mit zunehmendem Abstand stärker aus. Dies kann für eine schnelle (Selektion durch Orientierungsänderung) als auch genaue (Selektion durch Positionsänderung) Interaktion von Vorteil sein, bei ungeeigneter Auslegung können jedoch Schwankungen in der Meßgenauigkeit oder schon das Zittern der Hand des Benutzers eine Interaktion nachhaltig stören [IVRK].
Der optimale Aufbau des Interaktionsmodells ist auch heute noch weitgehend ungelöst: Die konsequente Übertragung der Interaktion mit realen Gegenständen auf möglichst authentische Weise auf virtuelle Objekte, besticht durch die intuitive Verwendung und ist für Augmented Reality-Anwendungen meist der einzig sinnvolle Weg. Aufgrund der in der Praxis auftretenden Probleme, sei es durch technische Schwierigkeiten, die Erwartungen des Benutzers oder die Komplexität der Anwendung bedingt, kann es jedoch sinnvoll sein, ähnlich wie von 2D-Benutzeroberflächen gewohnt, Eingabetechniken mit höherem Abstraktionsgrad einzusetzen.
Das erste Testobjekt besteht aus einem Ring mit senkrecht zueinander stehenden Oberflächen. Auf einem Teilbereich des Ringes befinden sich mehrere Bohrungen mit identischem Abstand voneinander, die zudem von beiden Seitenflächen des Ringsegments denselben Abstand haben. Innerer und äußerer Ringradius sollen dabei ebenso wie der Bohrungsradius flexibel einstellbar sein. Zudem sollen die Außenkanten nachträglich verrundet werden. Mit diesem Beispiel sollten vor allem die Konstruktionsfunktionen für Features und Muster sowie der Einsatz einfacher Bedingungen untersucht werden.
Als Fundament der Konstruktion dienen zwei konzentrische Kreise, ein dritter Kreis beschreibt alle Punkte, die von den anderen beiden Kreisen denselben Abstand haben. Da eine derartige Bedingung bzw. Konstruktionsfunktion in beiden Systemen nicht direkt verfügbar ist, wurde anders vorgegangen: Der dritte Kreis wurde ebenfalls konzentrisch mit den anderen angelegt, sein Radius ist zunächst beliebig. Über zwei Bemaßungen wurde anschließend der Abstand der Abstand der drei Kreise voneinander festgelegt. Eine der Bemaßungen kann vom Benutzer frei verändert werden, die zweite berechnet sich abhängig aus ihr, entweder als AbstandInnen = AbstandAußen oder als Ringdicke = 2*AbstandAußen. Sowohl in Catia als auch SolidWorks werden all diese Arbeiten im 2D-Sizzenmodus erledigt, die Berechnungsfunktion wird dabei über einen separaten Dialog mit Tastatur und Maus eingeben. Über eine Extrusion wird anschließend der Grundkörper im 3D-Modus erstellt.
Die erste Bohrung wird als Feature auf dem Ringkörper erstellt. Hier verwenden beide Systeme einen Dialog zur Festlegung der umfangreichen Attribute zur Erstellung der Bohrung. Catia erstellt deutlich sichtbar automatisch eine separate Skizze für die Bohrung, die allerdings nur den Ausgangspunkt der Bohrung enthält. In SolidWorks wird das innere Wesen dagegen vollkommen vor dem Anwender verborgen, eine Vorschau während der Eingabe bieten beide Systeme. Schwieriger ist dagegen jedoch die mittige Platzierung der Bohrung: Während SolidWorks ohne Schwierigkeiten die Bohrung anhand einer in der 2D-Skizze des Rings platzierten Achse erlaubt ist dies in Catia aufgrund der strikten Trennung zwischen einzelnen Skizzen als auch dem 3D-Modus nicht möglich. Ein Ausweg besteht darin, in der Skizzierebene des Rings den Radius des mittleren Kreises über eine Bemaßung zu ermitteln und den Wert dieser Bemaßung für den Abstand des Bohrungsmittelpunkts von der Mittelachse des Ringes als Bedingung einzusetzen. Als skizzenübergreifende Achse wird hierbei die Achse des Koordinatensystems verwendet.
Die Angabe des Bohrungsmusters erfolgt in beiden Systemen über einen Dialog, der dem Dialog zur Bohrungsdefinition weigehend ähnlich gestaltet ist. Dies gilt auch für die Dialoge zur Kantenverrundung, wobei die Kanten direkt am Objekt durch Selektieren angegeben werden. Bei umfangreichen Änderungen am Ausgangskörper, z.B. dem Ersetzen von Kanten in der Skizze, kann es hierbei passieren daß die zu verrundende Kante neu angegeben werden muß.
Als zweites Testobjekt wurde ein Tisch konstruiert, dessen benachbarte Tischbeine paarweise parallel zur nächstliegenden Tischkante ausgerichtet sind. Die Tischbeine sind rotationssymmetrisch um eine senkrecht zur Tischplatte stehende Rotationsachse, obere und unterer Hälfte sind symmetrisch zueinander aufgebaut. Länge und Breite der Tischplatte bleiben ebenso wie der Abstand der Tischbeine von den Kanten der Tischplatte frei einstellbar. Dieses Beispiel untersucht vor allem die Erstellung von hierarchischen Konstruktionen mit vielen einfachen Abhängigkeiten zwischen den verschiedenen Ebenen.
Die Konstruktion der Tischplatte ist unkritisch. Nützlich ist hierbei, daß in SolidWorks im Skizzenmodus angelegte Hilfsgeraden und Bemaßungen auch in anderen Modi verfügbar bleiben. Auf diese Weise ist auch das Erstellen einer senkrecht zur Skizzierebene gelegenen Hilfsachse möglich.
Das Tischbein entsteht aus geraden Kanten und angehängten Kreissegmenten. Dieser Kantenzug schließt bündig mit der Spiegel- und Rotationsachse des Tischbeins ab. Anschließend entsteht durch Rotation und Spiegelung im 3D-Modus das fertige Objekt. In SolidWorks wurde hier wieder zusätzlich die Rotationsachse mit als 3D-Hilfsgeometrie beibehalten. Sowohl die Tischplatte als auch das Tischbein wurden anschließend als separate Bauteile gespeichert.
Der Zusammenbau des fertigen Tisches als Assembly erfolgt in einem speziell dafür vorgesehenen Modus. Der Zusammenbau in SolidWorks ist vergleichsweise geradlinig: Die in der Skizze der Tischplatte angelegten Hilfsgeraden und -Achsen sind auch hier verfügbar und werden durch parallele Achsen auf der Tischplatte ergänzt. Anschließend werden die ebenfalls noch verfügbaren Rotationsachsen der Tischbeine anhand Schnittpunkte der Hilfsgeraden positioniert und die Tischbeine über eine separate Bedingung bündig an die Tischplatte angesetzt.
Schwierig wird es jedoch in Catia, da hier weder Hilfsgeraden oder -Punkte aus den Skizzen übernommen werden noch im Assembliermodus diese neu angelegt werden können. Als Abhilfe wird auf die Koordinatensystemebenen der Tischplattebeine zurückgegriffen: Indem diese per Bedingung als paarweise kongruent und parallel zu den Koordinatensystemebenen der Tischplatte definiert werden läßt sich derselbe Effekt erzielen wie mit Hilfsachsen. Anschließend stellt auch hier eine Kontaktbedingung den bündigen Zusammenschluß der Tischbeine mit der Tischplatte her.
Als interessante Elemente in der Benutzeroberfläche erweisen sich der Skizzierer in Catia, welcher die Eingabe kompletter aus Geraden und Kreissegmenten bestehender Kantenzüge ohne einen einzigen Rückgriff auf Menüs erlaubt und dabei noch eine Vielzahl an gesetzten Bedingungen automatisch erkennen kann. Vergleichsweise banal, aber ebenso praktisch ist das Dreibein in Catia, das nicht nur wie das SolidWorks-Gegenstück zur Anzeige der Koordinatensystemausrichtung dient sondern darüber hinaus auch noch zur Navigation in allen als auch in Teilen der Freiheitsgrade eingesetzt werden kann.
Anhand der vorliegenden Betrachtungen ergeben sich folgende Kriterien an die Integration:
Von den am Institut näher betrachteten Kernen (siehe [LTBREP]) kamen letztendlich Parasolid [PS] als auch OpenCascade [OCC] in die engere Wahl. Diese wurden neben dem allgemeinen Funktionsumfang insbesondere auf ihre Eignung für eine möglichst geradlinige Integration in das zu erstellende Gesamtsystem untersucht. Die wesentlichen Punkte sind im folgenden:
Bei Parasolid handelt es sich um einen monolithischen mehrprozessorfähigen Kernel, welcher den BlackBox-Ansatz mit Zugriff über eine klar definierte und leistungsfähige API konsequent umsetzt. Da der Kern für Speicherverwaltung, Grafikausgabe (GO) und persistente Datenspeicherung auf vom Anwender bereitzustellende Callback-Funktionen aufsetzt lassen sich auf elegante Weise Ein- und Ausgabe auf die verschiedensten Medien umleiten. Eine umfangreiche und gut strukturierte Dokumentation der verwendeten Konzepte und verfügbaren Funktionen liegt bei.
OpenCascade ist dagegen als umfangreiche Sammlung von C++-Klassen entworfen, so daß sich der Umfang des Kernels in einem weiten Bereich an die Bedürfnisse der Anwendung anpassen läßt, ebenso können die benötigten Daten auf vielfältige Weise von der Anwendung verwaltet werden. Mit OCAF wird zudem ein umfangreiches Framework mit Datenstrukturen, Interaktion und Datenspeicherung mitgeliefert, das vor allem auf Desktopanwendungen zugeschnitten ist. Der gesamte Quelltext ist frei verfügbar, was aber angesichts der weniger übersichtlichen und unvollständigen Dokumentation auch eher erforderlich ist. Für das nötige Verständnis der internen Struktur und die Verwendung der wichtigen Modellierfunktionen genügt die vorhandene Dokumentation allerdings durchaus.
Beide Kerne verwenden eine BRep-Struktur mit den dazugehörigen topologischen Objekten wie Vertex, Kante, Kantenzug, Fläche, Flächenzug, Massivkörper und allgemeine Verbundobjekte. Zudem besteht Zugriff auf die für die Definition der Kanten und Flächen verwendete Trägergeometrie, deren Parametrisierung und eventuell vorhandene Unterobjekte von Kantenzügen, Flächenzügen und Verbundkörpern.
Der Zugriff auf die topologischen und geometrischen Objekte erfolgt in Parasolid einheitlich über sogenannte Tags, die das jeweilige Objekt während der gesamten Systemlaufzeit referenzieren. Die Unterobjekte eines Objekts werden jeweils über einen zugehörigen Identifier verfügbar gemacht, der anders als ein Tag auch persistent abgespeichert werden kann. Es gibt allerdings keine feste Regel, nach der die Identifier erzeugt werden. Zudem können in einem Objekt auch geometrische Objekte ohne direkten Bezug zu einem topologischen Objekt abgelegt werden, was für Hilfsgeometrie vorteilhaft ist.
In OpenCascade werden topologische Objekte, die sogenannten Shapes, direkt durch Instanziierung der zugehörigen Klasse im Quelltext verwendet. Da diese intern ihre Daten über Referenzzähler verwalten können sie auch beliebig kopiert und referenziert werden. Der Zugriff auf topologische Unterobjekte erfolgt über einen sogenanntes Explorer-Objekt, welcher ähnlich einem C++-STL-Iterator alle Unterobjekte eines gewünschten Typs aufzählt. Über spezielle Funktionen kann die einem Shape zugrundeliegende Geometrie vom Typ Geom_Geometry extrahiert werden. Diese enthalten neben der zugrundeliegenden Basisgeometrie vom Typ gp_... Informationen zur Parametrisierung. Jedem Shape ist darüber hinaus noch eine Transformation (Translation, Rotation, Skalierung, Spiegelung) zugeordnet. Zusätzlich sind neben Klassen für 3D-Geometrie auch solche für 2D-Geometrie verfügbar.
Parasolid verfügt über umfangreiche Funktionen für mehrstufiges paralleles Rollback, welches auch ein selektives Redo ermöglicht. Diese können aber aufgrund des fehlenden direkten Zugriffes auf gespeicherte Objekte nicht ohne Weiteres für den Neuaufbau entsprechend einem Strukturbaum genutzt werden.
In OCAF ist ein Framework zur Erstellung von Bäumen und gerichteten Graphen enthalten, das für den Aufbau eines Strukturbaumes eingesetzt werden kann. Mangels detaillierter Dokumentation und dem Fehlen geeigneter Beispielprogramme läßt sich die Verwendbarkeit dieses Frameworks allerdings nur schlecht bewerten.
Beide Kerne verfügen sowohl über vergleichbare Funktionen zum direkten Erzeugen von Festkörper-Primitiven (Kugel, Quader, Zylinder,...) und grundlegender topologischer Objekte (Vertex, Kanten, ...) als auch der inkrementellen Bearbeitung wie Extrusionen und Boolesche Operationen. Ebenso sind Funktionen zur Ermittlung von lokalen Eigenschaften wie Tangenten, Krümmung und Normalen sowie von globalen Eigenschaften wie Schwerpunkt und Masse in beiden Kernen vorhanden (Anmerkung: Falls nach der Länge einer Kurve gesucht wird, so kann diese auch als Gewicht dieser Kurve berechnet werden).
Anders als OpenCascade bietet Parasolid zusätzlich Funktionen für musterartig wiederholte Boolesche Operationen. Ebenso kann Parasolid auch Festkörper zu neuen Festkörpern extrudieren. Beide Funktionen lassen sich allerdings in OpenCascade relativ leicht unter Verwendung schon vorhandener Funktionen nachbilden. Interessant sind allerdings die Funktionen zur Erstellung von Körpern, wie sie mit Press- und Spritzgußverfahren hergestellt werden können: Während OpenCascade hier nur grundlegende Funktionen zur Erstellung von Körpern mit Auszugschrägen bietet, kann Parasolid ähnlich eines Wizards fertig geprägte Oberflächen oder spritzgußfähige Körper in nur einem Schritt aus bestehenden Objekten errechnen. Das Verrunden und Anschrägen von Kanten wird dagegen von beiden Kernen ähnlich gehandhabt und wird über die umständliche Angabe der zu bearbeitenden einzelnen Kanten gelöst. Für Schnittpunktberechnungen ist jeweils direkt auf die zugrundeliegende Geometrie zurückzugreifen.
Beide Kerne können triangulierte Objekte und die dazugehörigen Kantenzüge in tabellarischer Form ausgeben. Alternativ ist auch die Ausgabe über das dafür vorgesehene Parasolid-GO-Interface bzw. die OpenCascade-Visualisierungsfunktionen möglich. Die Wiederverwendung bestehender Triangulationen ist in beiden Kernen bei Änderungen (Parasolid) bzw. feinerer Triangulierung eingeschränkt möglich. Parasolid kann optional auch Körper mit mehreren Flächen lückenlos triangulieren, allerdings entfällt dann die Wiederverwendbarkeit der Triangulation. Oberflächennormalen und Geometrieparameter können zusammen mit der Triangulierung ausgegeben werden, spezielle Funktionen zur Erzeugung von Texturkoordinaten liegen dagegen bei beiden Kernen nicht vor.
Linienzeichnungen für Silhouetten, Isolinien und verdeckte Linien werden in OpenCascade über entsprechend berechnete Shapes realisiert, die anschließend wie normale Shapes weiterverarbeitet werden. Parasolid gibt sie stattdessen direkt in tabellarischer Form bzw. via GO aus.
Mit STEP und IGES unterstützen beide Kerne den Im- und Export von Modellen in und aus anderen CAD-Systemen. Für Parasolid wird zusätzlich die Anbindung von Catia, VDA-FS sowie Pro/Engineer (nur Import) angeboten, bei OpenCascade steht zusätzlich triangulierter Export im STL und VRML-Format bereit. Weitere OpenCascade-Datenaustauschfunktionen sind als gebührenpflichtige Module erhältlich.
Der zusätzliche Austausch von Strukturinformationen wäre zwar mit den standardisierten Funktionen in OCAF möglich, allerdings wird die konkrete Verwendung der einzelnen Felder im Graphen dem Anwender überlassen. Somit bietet keiner der beiden Kerne die Möglichkeit, den Strukturbaum und weitere Attribute auf standardisierte Weise zu übertragen.
Wie man sieht bieten beide Kerne die nötige Funktionalität für die Verwendung in dem zu entwerfenden System. Auf eine Verwendung von OCAF wurde verzichtet, da aufgrund mangelnder Dokumentation sich der benötigte Aufwand nicht realistisch abschätzen ließ. Ebenso wurde aufgrund mangelnder Flexibilität von einem Einsatz der Rollback- und Sessionmanagementfunktionen in Parasolid abgesehen. Die in den Kernen enthaltenen Selektionsmechanismen wurden nicht weiter berücksichtigt, stattdessen soll die Selektion aufgrund der interaktiven Anforderungen allein der Implementierung im VR-System vorbehalten bleiben.
Aufgrund der wesentlich einheitlicheren API-Struktur von Parasolid im Vergleich zu OpenCascade wurde untersucht, ob sich der Parasolid-Kern über standardisierte, eventuell sogar halbautomatisch über Makros erzeugte Wrapperfunktionen in das Gesamtsystem einbinden läßt. Dies erwies sich allerdings als nicht praktikabel, da viele Funktionen jeweils spezielle Flags oder gar die Übergabe von Strukturen mit den benötigten Informationen verwenden, deren Initialisierung nur schlecht vereinheitlichbar ist. Ebenfalls störend ist, daß einige Funktionen wie z.B. Boolesche Operationen die eingegebenen Objekte modifizieren oder löschen, weshalb gegebenenfalls zusätzliche Aufwand zur Kompensation dieses Verhaltens anfällt. Damit schrumpft der Vorteil der klareren Parasolid-API gegenüber den uneinheitlichen Objekttypen (Shape, Geom_Geometry, gp...) mitsamt den dadurch erforderlichen Konversionen beim Umgang mit OpenCascade-Funktionen deutlich.
Letztendlich ausschlaggebend war die Tatsache, daß mit OpenCascade schon erste Erfahrungen über Leistungsfähigkeit und Problemstellen vorhanden waren und zudem funktionierender Tesselierungsquelltext für den Import in den Lightning-Szenegraphen bereit stand. Daß die Entscheidung nur knapp ausfiel deutet auf die erhöhte Wichtigkeit eines möglichst kernunabhängigen Integrationsmodells hin, so daß bei Bedarf auch ein anderer Kern integriert werden kann. Dies gilt insbesondere bei einer zukünftige Verwendung eines standardisierten Formats auch für strukturelle Daten, wie es z.B. für PTC Granite angekündigt wird [PTCGR], oder der zusätzlichen Integration eines separaten 2D-Modellierkerns.
Die realisierte CAD-Integration besteht aus zwei logischen Teilen: Den ersten bildet das eigentliche CAD-System, welches die gesamten Konstruktionsdaten verwaltet und die dazugehörige Geometrie berechnet. Dazu gehören auch die Schnittstellen zum Im- und Export der Daten in verschiedenen Formaten, die Verwaltung von Zwangsbedingungen und weitergehende Strukturfunktionen wie eine Konstruktionshistorie mit Undo und Redo-Funktionalität.
Der zweite Teil besteht aus der Benutzungsschnittstelle, für die hier das VR-System eingesetzt wird. Dieses bietet dem Anwender den Zugriff auf die Funktionen des CAD-Systems und erlaubt es, die im CAD-System erzeugte Konstruktion als auch die ihr zugrundeliegenden Daten anzuzeigen. Zu den Aufgaben der Benutzungsschnittstelle gehört auch die Auswahl der in Abhängigkeit vom Anwendungszustand verfügbaren Benutzerfunktionen als auch der der aktuell anzuzeigenden Daten. Im Gegensatz zum CAD-System enthält das VR-System keine dauerhaft zu speichernden Daten, so daß die Art und Auswahl der in ihm verwendeten Daten dem jeweiligen Anwendungszweck entsprechend frei gewählt werden kann. Insbesondere gilt dies auch für die Anzahl und Laufzeit der Benutzungsschnittstellen während einer Sitzung im CAD-System. Eventuell fehlende Daten müssen dazu jederzeit aus dem CAD-System angefordert werden können. Für exakte Berechnungen mit konstruierten Objekten soll stets auf das CAD-System zurückgegriffen werden, da im VR-System in der Regel weder die exakte Geometrie noch die zu berücksichtigenden Toleranzgrenzen vorliegen.
Während mit Lightning schon ein fertiges flexibles VR-System bereit steht, welches nur noch um passende Objekte zur Anbindung des CAD-Systems zu erweitern ist, existierte auf der CAD-Seite leider kein vergleichbar geeignetes System. Somit mußte eine geeignete Umgebung zur Einbettung eines existierenden CAD-Kerns von Grund auf neu konzipiert werden. Neben einer konsequenten Gliederung der verschiedenen Systemteile antsprechend ihrer Funktion wurde hierbei speziell darauf geachtet, daß flexible, fehlertolerante und zugleich einfach handhabbare Schnittstellen sowohl innerhalb der Systemteile als auch nach außen hin vorhanden sind. Auf diese Weise wird die Erstellung von experimentellen und prototypischen Anwendungen als auch eine schnelle bedarfsgerechte Erweiterbarkeit des Systems um neue Funktionen unterstützt.
Die verschiedenen Funktionsgruppen sind in sogenannten Modulen gekapselt. Ein Modul speichert und verwaltet intern die ihm zugehörigen Daten und stellt zugleich anderen Modulen passende Funktionen zu deren Bearbeitung bereit. Dazu verwenden alle Module nach außen hin dieselbe Schnittstelle, welche auf dem Versand und Empfang von systeminternen Nachrichten basiert. Auf diese Weise lassen sich auch leicht Module auf separate Prozesse oder in einem Netzwerk auf mehrere Rechner verteilen, da nur die Funktion zum Austausch der Nachrichten passend erweitert werden muß. Jegliche Kommunikation läuft dabei grundsätzlich über ein speziell dafür vorgesehenes Nachrichtenmodul ab.
Die in den Nachrichten verschickten Daten liegen stets als Klartext vor. Dies hat den Vorteil, daß sie direkt in Skriptsprachen erzeugt und verarbeitet werden können. Ebenso können viele Bibliotheken und Programme - inklusive der Unix-Shell - von Haus aus mit Klartextdaten umgehen und somit leicht in das CAD-System eingebunden werden. Auch für den Anwender bieten sich Vorteile, da sich somit das CAD-System direkt in seinem nativen Format ansteuern und sein Verhalten beobachten läßt.
Es werden vier wichtige Arten von Nachrichten unterschieden:
Im Gegensatz zu anderen gängigen nachrichtenbasierten Systemen ist es hier durchaus möglich, daß ein Modul während der Bearbeitung einer Nachricht eine andere Nachricht abarbeiten muß. Dieser Fall kann immer dann auftreten, wenn zur Abarbeitung einer Nachricht der Rückgabewert eines neuen Kommandos erforderlich ist: Die Abarbeitung dieses Kommandos kann zum Aufruf weiterer Funktionen innerhalb des wartenden Moduls führen, wobei deren Rückgabewert zuerst ermittelt werden muß.
Jede Nachricht hat einen Sender und einen Empfänger, die jeweils das entsprechende Modul identifizieren. Für den Empfänger kann alternativ auch ein spezieller Broadcast-Wert angegeben werden: Dieser dient dazu, Update- und Statusnachrichten an alle im Nachrichtenmodul registrierten Empfängermodule weiterzuleiten. Für Kommandonachrichten ist er der Standardwert und bedeutet, daß der tatsächliche Empfänger der Nachricht anhand der im Kommandomodul hinterlegten Daten zu bestimmen ist. Registernachrichten werden ohnehin stets an das Kommandomodul weitergeleitet.
Um Statusnachrichten den entsprechende Kommandos zuordnen zu können besitzt jede Nachricht ein Feld für eine Nachrichtenid. Dabei wird vorrausgesetzt, daß das Paar aus Kommandosender und Nachrichtenid mit dem Paar aus Statusempfänger und Nachrichtenid identisch ist. Selbiges wird auch für Updatenachrichten empfohlen, in allen anderen Fällen kann die Nachrichtenid getrost auf Null gesetzt werden. Normalen Kommandos sollte jeweils exakt eine resultierende Statusnachricht zugeordnet sein, für spezielle Anwendungsfälle wurde jedoch auf ein Erzwingen dieses Verhaltens verzichtet: Da nicht in jedem Fall - etwa in einem verteilten System - garantiert ist, daß der Empfänger einer Kommandonachricht existiert oder der Empfänger das Kommando eventuell gar nicht verarbeiten kann, wäre die Erzwingung einer solchen Nachricht ohnehin nur mit unverhältnismäßig großen zusätzlichem Aufwand möglich.
Die ausschließlich nachrichtenbasierte Kommunikation mit gepaarten Kommando- und Statusnachrichten sowie vorgegebener Signatur hat zudem einen praktischen Nebeneffekt: Auf diese Weise wird der Anwender bei der Erstellung neuer Kommandos stärker als bei der Definition neuer Funktionen dazu angehalten, sich rechtzeitig passende Parameter und Rückgabewerte zu überlegen.
Die in den Nachrichten ausgetauschten Daten entsprechen in einer an EBNF angelehnter Notation folgender Syntax:
Jedes Datum kann als Paar bestehend aus einem ersten Wert als Kopf sowie der restlichen (ggf. leeren) Zeichenkette als Schwanz gesehen werden, welche wieder als Paar gesehen werden kann. Zur schrittweisen Auswertung stehen hierfür die Funktionen getHead, getTail, isGrouped und Ungroup zur Verfügung. Die Gesamtzahl der Werte als auch die Tiefe der Gruppierungen ist hierbei beliebig und nur durch die Fähigkeiten der Implementierung begrenzt.
Bei der Auswahl der Parametersignaturen ist darauf zu achten, daß im Allgemeinen die Typen Angle und Metric nicht eindeutig unterscheidbar sind, ebenso kann jeder Typ auch als String interpretiert werden, weshalb spezielle Strings auch zu anderen Datentypen passen können. Potentielle Konflikte sind deshalb entweder intern aufzulösen oder durch andere Wahl des Kommandonamens und seiner Signatur zu vermeiden. Sinnvoll ist es, in der Signatur für Strings zum Schutz von Leerzeichen grundsätzlich Gruppierungsklammern vorzuschreiben. Auf diese Weise besteht auch keine Verwechslungsgefahr mit ungruppierten Ausdrücken anderen Typs mehr.
Um zukünftige Erweiterungen auch auf Skriptebene zu ermöglichen findet eine Syntaxprüfung erst innerhalb der verarbeitenden Module statt, für Kommandonachrichten ohne Empfängerangabe findet sie somit im Kommandomodul statt. Zur Überprüfung, ob ein Kommando erfolgreich war sollte derKopf der entsprechenden Statusnachricht stets mit dem Wert für Statusok verglichen werden.
Das Fundament des CAD-Systems bilden das Nachrichten- und das Kommandomodul, welche die grundlegende Funktionalität des Systems erst ermöglichen, sowie das Id-, Topologie- und Geometriemodul, welche zusammen die essentiellen Konstruktionsmittel bereitstellen:
Das Nachrichtenmodul ist dafür zuständig, für alle eintreffenden Nachrichten die entsprechenden Empfänger zu bestimmen und die Nachricht an diese weiterzuleiten. Registernachrichten und Kommandonachrichten ohne Angabe des Empfängermoduls werden an das Kommandomodul weitergeschickt. Desweiteren verteilt es alle als "Broadcast" markierten Nachrichten an alle darauf reagierenden Empfänger. Die Bereitstellung dieser beiden Hauptfunktionen ermöglicht es zusammen mit dem Kommandomodul, Nachrichten ohne Kenntnis des internen Aufbaus zu versenden und die Bedeutung der Nachrichten von den sie tatsächlich verarbeitenden Modulen zu trennen.
Intern speichert das Nachrichtenmodul, welches Modul das Kommandomodul ist sowie eine Liste aller Empfänger von Broadcast-Nachrichten. Das aktuelle Kommandomodul wird mit dem Kommando RegisterCommandModule zur Laufzeit bestimmt. Entsprechend können sich mit dem Befehl RegisterBroadcastReceiver Module zur Laufzeit als Empfänger von Broadcast-Nachrichten eintragen.
Das Nachrichtenmodul ist auch der geeignete Ansatzpunkt, wenn man das CAD-System in ein verteiltes System umwandeln möchte: Es genügt, benötigte Erweiterungen zur Kommunikation allein in ihm unterzubringen, während die restlichen Module unverändert übernommen werden können. Ebenso bietet es sich an, um Funktionen zum Mitverfolgen der systeminternen Kommunikation unterzubringen.
Kommandos zum Versand von Nachrichten sind allerdings nicht zwingend erforderlich: Jedes CAD-Systemmodul enthält schon von Haus aus die gesamte Funktionalität zum Erzeugen und Versenden von Nachrichten, da es andernfalls gar nicht mit dem Rest des Systems kommunizieren könnte.
Während das Nachrichtenmodul den Nachrichtenversand von den Modulen abstrahiert ist es die Aufgabe des Kommandomoduls, die verschiedenen Kommandos von den sie verarbeitenden Modulen zu trennen. Dazu enthält es intern eine Liste aller bekannten Kommandos, ihrer Parametersignaturen und den Modulen, die das jeweilige Kommando mit bestimmter Signatur anbieten. Trägt nun ein beliebiges Modul sein Kommando mittels einer Register-Nachricht in diese Liste ein, so kann dieses Kommando ab sofort systemweit ohne Kenntnis des verarbeitenden Moduls verwendet werden.
Dazu prüft das Kommandomodul für alle eintreffenden Nachrichten, die nicht speziell an das Kommandomodul geschickt werden, ob das entsprechende Kommando in der Liste vorliegt. Werden passende Einträge gefunden, so werden die Parameter dieses Kommandos mit der gespeicherten Signatur verglichen. Wird eine mit den Parametern übereinstimmende Signatur gefunden, so wird das Kommando an das Modul weitergeleitet, daß dieses Paar aus Kommando und Signatur registriert hat. In allen anderen Fällen wird eine Fehlerstatusmeldung an den Absender des Kommandos zurückgeschickt.
Für Gruppen innerhalb von Parametern werden alle enthaltenen Komponenten mit dem in der Signatur angegebenen Typ verglichen. Einzelne Parameter werden wie eine Gruppe mit nur einer Komponente behandelt, Gruppen innerhalb von Gruppen werden nicht rekursiv aufgelöst, sondern als gewöhnlicher String betrachtet.
Kommandos können überladen werden, indem man identische Kommandonamen mit unterschiedliche Signaturen registriert. Zum Überschreiben von Kommandos kann mittels RenameCommand der Name des existierenden Kommandos mit gegebener Signatur in der Kommandoliste geändert werden: Wird nun der neue Name aufgerufen, so ersetzt ihn das Kommandomodul durch den alten Namen, damit er wie gehabt von dem ihn verarbeitenden Modul behandelt werden kann. Der alte Name ist somit wieder zur neuen Belegung mit identischer Signatur verfügbar. Auf diese Weise lassen sich durch Überladen und Überschreiben registrierte Kommandos zur Laufzeit dynamisch ändern und erweitern. Ein dynamisches Hinzufügen und Entfernen von beliebigen kommandoanbietenden Modulen wird dadurch ebenfalls möglich.
Zur Erzeugung eindeutiger Bezeichner dient das ID-Modul. Zwischen zwei Aufrufen von ResetId liefert CreateId stets einen neuen, eindeutigen Bezeichner. Entsprechend sollten nur solche IDs verwendet werden, die mit diesem Modul erzeugt worden sind. Werden existierende IDs von außerhalb in das System importiert, so sind diese passend in neue IDs umzubenennen. Entsprechend ist auch nicht davon auszugehen, daß eine ID bei persistenter Speicherung unverändert bleibt.
Weitergehende Annahmen zu IDs sind nicht zulässig, insbesondere gibt es keine fest vorgeschriebene Regel, wie Ids erzeugt werden oder eine Möglichkeit herauszufinden, welche IDs in Verwendung sind oder nicht. Dies ist auch nicht erwünscht, da die in den verschiedenen Modulen gespeicherten Daten und Funktionen ohnehin in sich abgeschlossen sein sollen.
Der typische Verwendungszweck einer ID ist sein Einsatz als Bezeichner für ein im Topologiemodul gespeichertes topologisches Objekt. Es spricht allerdings nichts gegen eine anderweitige Verwendung, da Kollisionen durch deren Eindeutigkeit ausgeschlossen werden. Auch der umgekehrte Fall, der Versuch mittels einer ID auf ein inexistentes Objekt zuzugreifen bleibt ohne schwerwiegende Folgen, da dieser Fall ohnehin bei der Arbeit mit topologischen Objekten berücksichtigt werden muß.
Im Topologiemodul wird die logische Struktur der aktuellen Konstruktion gespeichert. Sie umfaßt alle Daten, die zur vollständigen Erzeugung der Konstruktion notwendig sind. Jedes Konstruktionselement wird hier als topologisches Objekt bezeichnet und durch folgende Attribute komplett beschrieben:
Sämtliche Geometrie wird als am Ursprung befindlich und entsprechend der Hauptachsen ausgerichtet betrachtet. Diese wird dann mittels der angegebenen Position und Orientierung im lokalen Koordinatensystem im Raum positioniert. Auf diese Weise kann das topologische Objekt bewegt werden, ohne daß die Geometrie neu berechnet werden muß. Allerdings bedeutet das nicht, daß am Ursprung tatsächlich Geometrie vorhanden ist: Dies ist der Fall, wenn die erzeugte Geometrie von Objekten abhängt, die selbst nicht am Ursprung positioniert sind. Aus Gründen der Übersichtlichkeit wird man deshalb üblicherweise nur direkt erzeugbare Geometrie frei positionieren, während man von anderen Objekten abhängige Geometrie in ihrer Ausgangslage belässt. Für Kopien von Objekten kann eine Ausnahme von dieser Regel aber durchaus zweckmäßig sein, da man hier Änderungen an der Geometrie der kopierten Objekte meist direkt am Ausgangsobjekt selbst durchführen möchte.
Die Darstellung als Paar aus einem Positionsvektor und dem Tripel der eulerschen Winkel bietet neben ihrer intuitiv verständlichen Bedeutung den Vorteil, daß neben Lightning auch viele andere Systeme und APIs entsprechende Parameter verwenden (z.B. glRotate in OpenGL). Zudem entsprechen sie genau den 6 physikalischen Freiheitsgraden von Festkörpern (Rigid Motion). Auf eine naheliegende Berücksichtigung einer isotropen Skalierung oder von Spiegelungen wurde verzichtet: Diese sind zwar ebenfalls geometrieerhaltend, d.h. längenverhältnis- und winkeltreu, besitzen aber keine physikalische Entsprechung für die Bewegung von Festkörpern. In einem CAD-System können sie zudem zum Über- und Unterschreiten von Toleranzgrenzen führen, so daß sich der Typ oder die Gültigkeit eines Modells unbeabsichtigt ändern können. Skalierungen und Spiegelungen bleiben deshalb speziellen Operationen im Kern vorbehalten.
Das Koordinatensystem verhält sich zu dem positionierten Objekt genauso wie das Position-Orientierungs-Paar zum unpositionierten Objekt. Durch Angabe eines zusätzlichen Bezeichners lassen sich identische Koordinatensysteme in mehreren topologischen Objekten identifizieren, so daß sie bei Bedarf gemeinsam geändert werden können. Auf eine optionale Verwendung gekrümmter Koordinatensysteme, etwa anhand der Parametrisierung der Oberfläche anderer Objekte, wird zugunsten einer einfachen und effizienten Umsetzung im VR-System vorerst verzichtet.
Bei gesetztem 2D-Flag fungiert das Koordinatensystem als frei im Raum positionierbare Referenzebene, ähnlich dem 2D-Skizziermodus in vielen CAD-Systemen. Anders als diese ist sie jedoch nicht auf die Erstellung zweidimensionaler Objekte beschränkt, ebenso sorgt die ausschließliche Beschränkung des 2D-Flags auf die Positionierungsdaten dafür, daß sämtliche 2D-positionierten Objekte vollkommen gleichwertig mit normal positionierten Objekten verwendbar sind. Dies erleichtert insbesondere die Verwendung von Hilfsachsen enorm, ebenso wird eine störende Trennung zwischen 2D- und 3D-Modus in der GUI vermieden.
Durch Angabe des Erzeugungskommandos als auch des abgeleiteten Objekts wird die Datenstruktur implizit zu einem bidirektionalen, nicht notwendigerweise zusammenhängenden gerichteten Graphen. Da es jeweils maximal ein abgeleitetes Objekt gibt ist jeder Teilgraph sogar ein echter Baum. Dies unterscheidet sich von Ansätzen in anderen CAD-Systemen, bei denen die voneinander abhängenden Objekte einen gerichteten Graph mit mehreren Elternknoten bilden können. Für den Fall, daß mehrere Objekte auf demselben abgeleiteten Objekt aufbauen, wird hier somit eine explizite Kopie der verwendeten Objekte erzeugt. Die Kohärenz der Kopien wird anschließend mittels Zwangsbedingungen sicher gestellt. Auf diese Weise vereinfachen sich die Algorithmen zur Bearbeitung topologischer Abhängigkeiten enorm, was angesichts der Verwendung als interaktives Evaluationswerkzeug gegenüber dem mitunter höheren Gesamtrechen- und Speicherungsaufwand bei den üblicherweise wenigen gemeinsam genutzten Objekten von höherer Bedeutung ist.
ID, erzeugendes Kommando und Typ werden bei Erstellung des topologischen Objektes festgelegt und können nicht mehr nachträglich verändert werden. Eine Änderung dieser Daten wäre auch nicht wünschenswert, da dadurch bestehende Beziehungen zerstört oder erzeugte Geometrien ungültig werden könnten. Sofern nicht explizit angegeben werden die ID und der Typ automatisch ermittelt. Die automatische Typermittlung ist insbesondere für interaktive Aktionen nützlich, allerdings unter Umständen weniger genau als eine explizite Angabe, da sie anhand der erzeugten dazugehörigen Geometrie des Objekts geschieht.
Bei Änderungen an den Daten eines topologischen Objekts werden automatisch entsprechende Update-Nachrichten erzeugt. Damit darauf reagierende Module nicht die gesamten Daten aktualisieren müssen werden die Änderungen an den Feldern eines Objektes bei der Updatenachricht mit angegeben.
Zum Aufbau der Geometrie dienen die Kommandos BuildTopologyObjectGeometry und UpdateTopologyObjectGeometry. Ersteres erzeugt die Geometrie eines topologischen Objekts und all seiner untergeordneten Objekte, was vor allem zum erstmaligen Berechnen der Geometrie eines Objekts benötigt wird. Letzteres baut die Geometrie eines topologischen Objekts samt all seiner übergeordneten Objekte neu auf, was nach Änderungen an einem topologischen Objekt benötigt wird.
Neben Funktionen zum Setzen und Auslesen der verschiedenen Attribute gibt es auch noch Funktionen zum Ermitteln aller existierenden Objekte sowie zum Export eines gesamten topologischen Objekts. Zusammen mit der Funktion zum Anlegen eines topologischen Objekts läßt sich somit die gesamte Topologie abfragen, exportieren und importieren.
Das Geometriemodul enthält den eigentlichen CAD-Kern und berechnet und verwaltet sämtliche Geometrie, die im System vorhanden ist. Durch Neuimplementierung des Geometriemoduls kann somit auch der gesamte CAD-Kern ausgetauscht werden, ohne daß der Rest des Systems programmtechnisch beeinflußt wird. Es gibt zwei Arten von Geometrie: Die erste Art besitzt eine gültige ID als Namen und wird als einem topologischen Objekt derselben ID zugeordnet betrachtet, während alle anderen Namen davon unabhängige Geometrie kennzeichnen. Neu erzeugte Geometrie erhält stets einen vom Geometriemodul automatisch bestimmten Namen, der bei Bedarf mit dem entsprechenden Kommando in den engültigen Namen umbenannt werden muß. Diese Unterscheidung ist für das Geometriemodul jedoch transparent und ist vorwiegend für die Erstellung von Makrobefehlen und der Benutzungsschnittstellen relevant.
Die im Modul gespeicherte Geometrie dient nur dazu, mehrstufige Konstruktionsschritte zu erlauben und Neuberechnungen weitgehend zu vermeiden. Sie dient nicht dazu, Geometrie dauerhaft zu speichern. Eine dauerhafte Speicherung ist auch nicht erwünscht, da die gesamte Information ohnehin schon in den topologischen Objekten vorhanden ist. Daß mit LoadOccBRep(File) und SaveOccBRep(File) dennoch Kommandos zum Im- und Export von Geometrie in einem nativen Format bereitsteht ist kein Widerspruch: Diese sind vor allem für Testzwecke, zum Erstellen von Makros zur einfachen Erzeugung komplexer geometrischer Primitive oder eine kompakte Implementierung von Assemblies vorgesehen.
Auch enthält das Geometriemodul keinerlei explizite Informationen über Abhängigkeiten zwischen den gespeicherten Geometrien. Für die korrekte Bereitstellung verwendeter Geometrien zur Erzeugung neuer Geometrie ist allein das kommandosendende Modul bzw. dessen Benutzer zuständig. Passende Hilfestellung wird dabei vom Geometriemodul geleistet, indem Funktionen zur Existenz und zur Bestimmung des Typs von geometrischen Objekten vorhanden sind. Ob gültige Geometrie aus vorhandenen Daten erzeugt werden kann läßt sich durch einfaches Ausprobieren des erzeugenden Kommandos und Überprüfen des Status ermitteln, spezielle Testkommandos werden somit nicht benötigt.
Die einem topologischen Objekt zugehörige Geometrie wird stets als untransformiert betrachtet. Wird sie für die Konstruktion neuer Geometrie benötigt, so muß sie gegebenenfalls erst passend transformiert werden. Für die Bereitstellung der Positionsdaten vor dem eigentlichen Erzeugungsschritt ist in diesem Falle das Topologiemodul zuständig.
Bei der Konzeption der im Modul angebotenen Konstruktionsbefehle sind die speziellen Gegebenheiten in einem VR-System zu berücksichtigen. So sind Parameter ohne direkte geometrische Entsprechung wie Flags oder numerische Gewichte zu vermeiden, da deren Eingabe die Aufspaltung in mehrere Befehle oder die Verwendung von Menüs und Dialogen erfordert, was einer möglichst intuitiven und immersionsfähigen Bedienung einer VR-Anwendung widerspricht. Stattdessen wird ein geometriebasierter Ansatz verfolgt: Abstände und Richtungen werden durch zusätzliche Hilfsunkte und -Achsen im Raum angegeben, so daß eine interaktive Änderung der Parameter durch einfaches Umpositionieren der Hilfskörper möglich ist. Auf dieselbe Weise läßt sich auch die Selektion von Teilflächen und Teilkurven eines Objekts realisieren: Das selektierte Teilobjekt ist dasjenige, welches von dem Hilfspunkt den geringsten Abstand hat. Dieses Vorgehen hat zudem den Vorteil, daß damit erzeugte Objekte wie verrundete Körper auch bei starken Änderungen am Ausgangskörper, etwa der Austausch eines Kreises durch ein Polygon als Basiskörper einer Extrusion, wieder neu erzeugt werden können. Dies ist bei indexbasierten Verfahren, wie sie in vielen gängigen Systemen üblich sind, nicht der Fall. Falls die durch den Hilfspunkt erzeugten Parameter außerhalb des gültigen Bereiches liegen oder nicht die gewünschten Ergebnisse liefern, genügt ein einfaches Neupositionieren zum Wiederherstellen der Konstruktion. Da die Hilfsobjekte wie normale Objekte erzeugt und mit Zwangsbedingungen versehen werden können lassen sich somit bei durchdachten Konstruktionen hochgradig flexible und dennoch stabile Objekte erstellen.
Die Tesselierung von Geometrien wird in gesonderten Modulen untergebracht. Dies hat zwei Gründe: Einerseits wird die Tesselierung nur für die Visualisierung und ggf. externe Zusatzmodule benötigt und ist somit für die eigentliche Erzeugung der Geometrie ohne weitere Bedeutung. Andererseits hängt die Implementierung des Tesselierungsmoduls stark von den Anforderungen des darauf aufsetzenden Visualisierungs- oder Simulationssystems ab, während die darunterliegende Geometrie selbst unverändert bleibt. Im Geometriemodul sind folglich nur passende Funktionen zum Geometrieexport unterzubringen. Dies geschieht entweder über die übliche Nachrichtenschnittstelle via SaveOccBRep im nativen Exportformat des CAD-Kerns, oder über spezielle Methoden, welche die Geometriedaten binär zur Verfügung stellen. Letzteres erfordert allerdings zusätzlich einen direkten Zugriff des Tesselierungsobjekts auf das CAD-Objekt, was aus Geschwindigkeitsgründen eine lohnenswerte Einschränkung ist und bei Verwendung der Module innerhalb ein und desselben Betriebssystemprozesses ohnehin gegeben ist.
Für ein praktisch anwendbares CAD-System sind noch weitere Module nötig. Diese stellen Hilfsmittel bereit, mit denen der Anwender leichter Konstruktionen erzeugen und auslesen kann.
Ein Datenspeicherungsmodul stellt Kommandos bereit, mit denen sich Daten als Kommando- bzw. Statusparameter aus dem gesamten System exportieren und importieren lassen. Fertig implementiert ist ein Modul zum Dateizugriff mit den Kommandos StorageRead und StorageWrite zum Lesen und Schreiben kompletter Dateien. Auf vergleichbare Weise sind auch Module zum Zugriff auf Datensätze via Datenbank- oder Netzwerkschnittstellen denkbar.
Speziell für Experimentierzwecke gedacht sind Module, die Kommandonachrichten zeilenweise von der Standardeingabe einlesen oder ankommende Nachrichten auf der Standardausgabe ausgeben. Mithilfe von Pipe- und Umleitungen lassen sich diese mit anderen kommandozeilenbasierten Programmen (z.B. grep oder less) bearbeiten.
Die Zerlegung der im Geometriemodul vorhandenen Geometrien im nativen Format des CAD-Kerns in einfacher handhabbare Primitive zur externen Weiterverarbeitung geschieht entweder über den Datenexport des CAD-Kerns oder in einem Tesselierungsmodul unter Verwendung entsprechender Kernfunktionen. Tesselierungsmodule sind somit je nach eingesetztem CAD-Kern eng an das Geometriemodul gekoppelt. Ebenso wie dieses kann es die tesselierten Daten entweder über die übliche Nachrichtenschnittstelle oder über anwendungsspezifische Zugriffsweisen austauschen.
Standardmäßig wird die Geometrie als am Ursprung befindlich betrachtet und entsprechend tesseliert, so daß die Positionierung des tesselierten Objekts innerhalb des VR-Systems diesem selbst überlassen bleibt. Dies hat den Vorteil, daß die Positionierungsdaten innerhalb des VR-Systems stets mit den Positionierungsdaten des topologischen Objekts identisch sind, umständliche und fehleranfällige Differenzbestimmungen innerhalb des VR-Systems sind somit nicht nötig. Falls dennoch im VR-System fertig positionierte Daten erforderlich sind läßt sich dies bewerkstelligen, indem entweder die Geometriedaten über die entsprechenden Kommandos des Geometriemoduls entsprechend transformiert werden oder indem die Berücksichtigung der Objektpositionierung in der Tesselierungsfunktion freigeschaltet wird.
Ein Geometrieobjekt wird tesseliert, sobald das entsprechende Kommando mit passendem Geometrienamen als Parameter an das Tesselierungsmodul geschickt wird. Alternativ läßt sich auch eine automatische Tesselierung erstellen, indem sich das Tesselierungsmodul als Empfänger für Broadcastnachrichten registriert und die ankommenden Updatenachrichten auswertet. Diese Vorgehensweise eignet sich allerdings nur für Beobachtungszwecke, da dann nur noch die Geometrien aktiver topologischer Objekte angezeigt werden können.
Zur Übertragung der Geometriedaten in das VR-System gibt es mehrere Wege. Der aus Sicht des Cad-Systems einfachste Weg ist die Verwendung des nativen Datenformats oder eines ohnehin vorhandenen CAD-Exportformats, wie es in der Arbeit von [LTBREP] realisiert wurde. Die Tesselierung wird dann direkt im VR-System erledigt. Von Vorteil ist diese Vorgehensweise vor allem bei niedriger Bandbreite und hoher Latenzzeit der VR-Anbindung, da die exakten CAD-Modelldaten in der Regel deutlich kleiner sind als die Daten des tesselierten Modells und zudem das VR-System zur Erzeugung einer feineren Tesselierung nicht erneut auf das CAD-System zugreifen muß. Unschön an diesem Ansatz ist allerdings, daß dadurch im VR-System benötigte Tesselierungsfunktionalität eher in das CAD-System gehört und im Falle eines nativen Datenformats sogar von der Wahl des verwendeten CAD-Kerns abhängt. Wird diese Art der Anbindung gewählt, so degeneriert das Tesselierungsmodul zu einem reinen Datenübertragungsmodul oder kann sogar ganz entfallen.
Ohne große Eingriffe in bestehende VR-Systeme kommt dagegen die Übertragung der Polygondaten in einem von diesem unterstützten Format aus. Am einfachsten ist die Verwendung eines Dateiformates wie VRML oder .obj, das oftmals ohnehin schon im Funktionsumfang von vielen CAD-Kernen und VR-Systemen enthalten ist. Schneller, aber zusätzlichen Programmieraufwand erfordend, ist die Übertragung in einem binären Format, bevorzugt dem nativen Format des VR-Systems.
Liegen sowohl das VR-System als auch das CAD-System in demselben Adressraum, so kann dem Tesselierungsmodul direkt Zugriff auf den Szenegraphen bereitgestellt werden. Die tesselierten Daten lassen sich danach direkt in entsprechende Knoten des Szenegraphen schreiben, so daß der zusätzliche Datenübertragungsschritt zwischen CAD- und VR-System entfällt.
Durch die Einbindung eines Skriptinterpreters läßt sich der Funktionsumfang des Systems schnell und bequem ausbauen. Insbesondere ist es zur Erweiterung von vorhandenen Kommandos des Geometrie- und Topologiemoduls um weitere Parameter oder zur Erstellung komplexer Makro-Kommandos aus einfacheren Kommandos mehrerer Module vorgesehen. Je nach Art und Einbindung des verwendeten Skriptinterpreters steht somit innerhalb des CAD-Systems eine vollständige Programmiersprache bereit.
Das hier exemplarisch verwendete Skriptmodul verwendet einen Tcl-Interpreter, dessen Sprachumfang vom Modul her nur noch die Funktionen zum Versenden von Nachrichten mit und ohne Warten auf eine Statusantwort hnzugefügt werden müssen. Als Komfortfunktion werden dem Interpreter zusätzlich noch die wichtigste Funktionen zum Parsen der Nachrichten wie getHead, isGrouped, etc. bereitgestellt um sich deren erneute Implementierung in Tcl zu ersparen und dabei potentiell entstehende Inkonsistenzen zu vermeiden.
Nach außen hin bietet das Modul nur das Kommando TclExecute an, mit dem direkt Tcl-Code an den Interpreter geschickt und dort ausgeführt wird. Der Rückgabewert dieses Codes wird als Statusnachricht an den Absender zurückgeschickt. Jedes andere an dieses Modul geschickte Kommando wird direkt als Tcl-Code betrachtet und als solches ausgeführt. Dabei sorgt das Modul dafür, daß Leerzeichen in gruppierten Parametern Tcl-gerecht umformatiert werden.
Das Modul verwendet während der gesamten Systemlaufzeit dieselbe Instanz des Interpreters. Einmal angelegte Prozeduren, Variablen und Parameter im globalen Namensraum des Interpreters bleiben somit auch nach Ausführung eines Tcl-Kommandos erhalten. Auf diese Weise wird kein spezielles Kommando im Modul benötigt um Skripte zu laden, denn dies kann Tcl mit dem source-Befehl schon von Haus aus. Alternativ kann Skriptcode auch von einem anderen Modul geladen werden und per TclExecute dem Interpreter dauerhaft verfügbar gemacht werden.
Dieser Funktionsumfang reicht zum Anlegen neuer systemweiter Kommandos aus: Sowohl der Code der neuen Kommandos in Form von Tcl-Prozeduren als auch der Code zum Abschicken der Register-Nachrichten dieser Kommandos werden auf eine der schon beschriebenen Arten im Interpreter ausgeführt. Danach werden alle entsprechenden Kommandos vom Kommandomodul an das entsprechende Skriptmodul weitergeleitet. Dieses schickt es, da es selber die entsprechenden Kommandos nicht kennt, an den Interpreter weiter.
Bei der Erweiterung von Kommandos mit demselben Namen sei nochmal auf potentielle Kollisionen mit ähnlichen Signaturen hingewiesen. Diese können durch Umbenennung aller betreffenden Kommandos im Kommandomodul vermieden werden. Um Inkompatibilitäten zu entgehen sollte das neue Kommando bei Aufruf mit der Signatur des alten Kommandos gleichen Namens dasselbe Verhalten aufweisen wie das alte Kommando. Dies geschieht am sichersten durch Aufruf des alten Kommandos unter seinem neuen Namen.
In vielen Konstruktionen mit veränderlichen Teilobjekten werden Freiheitsgrade von Teilobjekten zur Erzielung des gewünschten Ergebnisses zusätzlich eingeschränkt. Ein einmal erstelltes Modell läßt sich jedoch auch ohne diese Zwangsbedingungen wieder aufbauen, erst bei erneuten Änderungen an Teilobjekten werden sie wieder benötigt. Aus diesem Grund wurde ihre Verwaltung in ein separates Modul verlagert, was einer übersichtlicheren Systemstruktur zugute kommt.
Aus Sicht des Gesamtsystems verhält sich ein Zwangsbedingungsmodul wie ein Benutzer, welcher über Kommandos Informationen über topologische und geometrische Objekte einholt und diese gegebenenfalls seinen Vorstellungen entsprechend anpaßt. Entsprechend registriert sich ein Zwangsbedingungsmodul typischerweise als Empfänger von Updatenachrichten, so daß es Änderungen an Objekten mit gesetzten Zwangsbedingungen überwachen kann. Zusätzlich kann die Überprüfung der Zwangsbedingungen auch mittels eines CheckConstraints-Kommandos von Hand veranlaßt werden, was sinnvoll ist um auch bei temporären Änderungen die Gültigkeit überprüfen zu können.
Bei den Zwangsbedingungen lassen sich grob zwei Arten unterscheiden: Die erste Sorte setzt die Attribute eines topologischen Objekts direkt als konstante Werte oder in direkter Abhängigkeit von entsprechenden Attributen anderer topologischen Objekte. Beispiele hierzu sind identische Position und Orientierung zweier Objekte oder die Positionierung auf bestimmten Achsen und in bestimmten Winkeln innerhalb des lokalen Koordinatensystems. Für ihre Gewährleistung genügt der Zugriff auf die Daten im Topologiemodul. Im Gegensatz dazu stehen Bedingungen, welche die benötigten Attributwerte auf geometrischem Weg unter Zuhilfenahme des Geometriemoduls berechnen müssen. Beispiele hierzu wäre die Positionierung eines Punkts als Schnittpunkt zweier Kurven oder als Punkt, dessen Position auf die Oberfläche eines anderen Objekts beschränkt ist.
Bei zwei über Zwangsbedingungen gekoppelten Objekten läßt sich zudem zwischen symmetrischen und asymmetrischen Bedingungen unterscheiden: Symmetrische Bedingungen wie Parallelität oder identische Positionen besitzen unabhängig davon, welches der beiden Objekte verändert wurde, eine eindeutige Lösung für das jeweils andere Objekt. Entsprechend sollte die Zwangsbedingung stets an dem unveränderten Objekt wiederhergestellt werden, um eine möglichst intuitive Konstruktion zu ermöglichen. Bei asymmetrischen Bedingungen, etwa als Punkt auf einer Kurve, ist in der Regel nur für eines der beiden betroffenen Objekte eine Anpassung gewünscht, in diesem Falle wäre dies die dem Punkt am nächsten liegende Stelle auf der Kurve. Folglich wird unabhängig davon, welches Objekt verändert wurde stets dasselbe Objekt korrigiert. Beide Fälle sollten von einem Zwangsbedingungsmodul entsprechend behandelt werden können.
Die entworfene Systemarchitektur besitzt nur minimale Anforderungen an Aufbau und Funktionalität des VR-Systems. Deshalb werden im Folgenden anstelle eines konkreten VR-Konzepts die wichtigsten Punkte genannt, die beim Entwurf zu beachten sind sowie einige empfehlenswerte Vorgehensweisen aufgezeigt.
In jedem Fall zwingend benötigt wird eine Schnittstelle, anhand derer sich Kommandonachrichten an das CAD-System senden lassen und die bei Bedarf auch die Statuswerte zurückliefen kann. Ebenso muß eine Schnittstelle bereitstehen, anhand der sich erzeugte Modelle entweder im CAD-Format oder fertig tesseliert einlesen und graphisch darstellen lassen. Darüber hinaus sollte das VR-System jederzeit Updatenachrichten empfangen und auswerten können, da andernfalls die Verwendung von Zwangsbedingungen oder die Erstellung von Mehrbenutzersystemen nur unter großen Schwierigkeiten möglich ist.
In Bezug auf die vom CAD-System gelieferten Daten gilt das Gebot der Datensparsamkeit: Informationen über Attribute und Zwangsbedingungen sollten nur bei Bedarf angefragt werden und nicht permanent gespeichert oder gar zum Aufbau einer Datenstruktur verwendet werden, die mit der im CAD-System identisch ist. Auf diese Weise wird das Problem der Einhaltung konsistenter Daten innerhalb der verschiedenen Systemteile, insbesondere in Umgebungen mit vielen Nutzern und Oberflächen, auf einen überschaubaren Bereich begrenzt. Ein weiterer positiver Effekt eines sparsamen Umgangs mit CAD-relevanten Daten besteht darin, daß Änderungen innerhalb des CAD-Systems sich weitaus weniger auf den Aufbau des VR-Systems auswirken als es bei umfangreicher paralleler Datenhaltung der Fall wäre. Ausgenommen von diesem Gebot sind Daten, die für echtzeitfähige Anwendungen zwingend erforderlich sind. Dies sind im wesentlichen tesselierte Objekte samt ihrer Positionierungsdaten und Bezeichner sowie Daten, an denen gerade Änderungen vorgenommen werden.
Beim Import eines geometrischen Objekts in das VR-System ist es hilfreich, Flächen und Kanten separat als Unterknoten eines gemeinsamen, das Objekt repräsentierenden Knotens zu speichern. Auf diese Weise lassen sich Kanten und Flächen separate Eigenschaften wie Farbe und Textur zuweisen oder leicht zwischen einer Flächen-, Kanten- oder gleichzeitigen Darstellung wechseln. Mitunter kann es auch von Vorteil sein, zusätzliche Unterknoten für Selektionshilfsmittel bereitzustellen oder einzelne Teilobjekte wiederum als Unterknoten der Flächen und Kanten abzulegen. Falls der Szenegraph für die Selektion verwendet werden kann ist es sinnvoll, die Knoten so zu bezeichnen, daß sich aus der Bezeichnung des Knotens direkt auf die Bezeichnung des entsprechenden geometrischen Objekts im Geometrie- oder dessen ID im Topologiemodul schließen läßt.
Die Knoten im Szenegraph entsprechend des Strukturbaums im CAD-System aufzubauen ist wenig empfehlenswert. Neben der Empfehlung, Strukturinformationen nicht dauerhaft im VR-System zu speichern spricht auch dagegen, daß dadurch ein zweckmäßigerer Einsatz des Szenegraphen verhindert wird: So ist der Strukturbaum nur unzureichend für die Aussortierung nicht sichbarer Teile geeignet, da z.B. die Achse eines Rotationsobjekt einen weitaus größeren Winkel im Raum abdecken kann als das damit erzeugte Rotationsobjekt, welches im Szenengraph als Elternknoten verwendet werden würde. Eine optimierte Sichbarkeitsberechnung sollte somit besser den dafür vorgesehenen Algorithmen des Szenegraphen vorbehalten bleiben.
Falls die Sichtbarkeitsberechnung für den Aufbau des Szenegraphen wenig relevant ist läßt sich dieser auch geschickt für interaktive Zwecke nutzen. So lassen sich Objekte mit identischen Eigenschaften oder selektierte Gruppen unterhalb eines gemeinsamen Knotens zusammenfassen, worauf diese dann im VR-System bequem als ein einheitliches Objekt ansprechbar sind.
Aus Sicht des Benutzers wäre es ideal, wenn jegliche Änderung an einem Teilobjekt sich unmittelbar als Vorschau auf die Darstellung des Gesamtobjekts auswirkt. Dies mag für einzelne Punkte, Kanten und Kantenzüge noch in Echtzeit durch das CAD-System möglich sein, komplexere Konstruktionen benötigen für den gesamten Neuaufbau und die Tesselierung jedoch schnell weitaus mehr Zeit als die für Echtzeit geforderten Zehntel- oder Zwanzigstelsekunden. Der Nachbau der entsprechenden Operationen im VR-System erlaubt dagegen zumindest für den aktuellen Konstruktionsschritt eine echtzeitfähige Vorschau, bietet aber die Gefahr, daß die Vorschau nicht mit dem tatsächlich berechneten Ergebnis des CAD-Systems übereinstimmt. Es gilt also, einen Kompromiß zu finden, der für die praktische Arbeit zumindest ein Gefühl der Echtzeitinteraktion vermittelt.
Unkritisch und vom Konzept des CAD-System auch explizit vorgesehen ist die Bewegung eines konstruierten Objekts als Festkörper mit 6 Freiheitsgraden. Ebenfalls denkbar wären Spiegelungen, Skalierungen und Scherungen im VR-System vorzusehen. Diese sind allerdings aus genannten Gründen nicht als Attribut vorgesehen, so daß die entsprechenden Änderungen im Strukturbaum entweder über ein entsprechendes Makrokommando im CAD-System oder durch das VR-System selbst erfolgen müßte.
Einfache geometrische Primitive wie Punkte, Kreise, Kugeln, Zylinder, Quader oder Kegel lassen sich leicht in einem VR-System modellieren und modifizieren, etwa indem sie als vordefinierte Daten geladen werden und passend skaliert werden. Ein identischer Körper läßt sich danach leicht über entsprechende Kommandos im CAD-System nachbilden. Etwas schwieriger sind gerade Kanten, Kantenzüge oder Tori, die sich nicht vordefiniert abspeichern lassen. Aufgrund ihrer einfachen Parametrisierung lassen sie sich jedoch leicht auf eine mit dem CAD-System identische Weise nachprogrammieren.
Bei komplizierteren Objekten wie Freiformkurven, Verrundungen oder beliebigen Flächen mit Löchern wird dieser Ansatz jedoch schnell unpraktikabel, insbesondere wenn die exakten Parameter innerhalb des CAD-Systems nicht näher bekannt sind. Als mögliche Lösung bietet es sich an, nur das unmittelbar von dem modifizierten Objekt abhängende Objekt neu aufzubauen und den Neuaufbau der gesamten Konstruktion vorerst durch Setzen des Flags für temporäre Änderungen zu verhindern. Bei zusätzlich reduzierter Genauigkeit der Tesselierung bzw. alleiniger Tesselierung der Kanten läßt sich somit eine zumindest teilweise echtzeitfähige Vorschau auf einfache und unproblematische Weise realisieren.
Ein anderer, vorwiegend für Extrusionen und Rotationen geeigneter Ansatz besteht darin, sich mit Hilfe des CAD-Systems einige exemplarische Positionen für den verwendeten Ausgangskörper berechnen zu lassen und im VR-System an den entsprechenden Stellen Kopien des Ausgangskörpers als Vorschau zu positionieren. Hierbei weicht die Vorschau optisch schon deutlich vom Endergebnis ab, sie vermittelt aber immer noch eine aussagekräftige Vorstellung des Ergebnisses.
Planare Referenzebenen sind ein wichtiges Hilfsmittel bei der Konstruktion. Für deren Realisierung ist die XY-Ebene des lokalen Koordinatensystems eines topologischen Objekts vorgesehen, Objekte mit derselben Referenzebene verwenden folglich dasselbe Koordinatensystem. Für eine Darstellung dieser Ebene ist das VR-System verantwortlich. Die Darstellung eines zweidimensionalen Musters oder Gitters auf der Ebene ermöglicht dabei dem Betrachter, Neigung und Entfernung der Ebene abzuschätzen. Bei vorhandenem Rasterfang sollte dieses Muster zudem die Granularität des Rasters wiedergeben.
Für häufig benötigte Elemente der graphischen Oberfläche empfiehlt sich eine Platzierung im Sichtfeld des Betrachters in mittlerer Tiefe sowie eine Bedienung, die sich an der Arbeit mit den Konstruktion selbst orientiert. Kontextmenüs und Objektinformationen werden dabei direkt neben dem dazugehörigen Objekt positioniert. In Verbindung mit einer passenden graphischen Gestaltung wird somit ein nahtloser Übergang zwischen der direkten Arbeit an der Konstruktion und der Bedienung der Menüelemente erzielt. Ein vergleichbares Konzept wird auch in [ISAAC] vorgestellt.
Da die Anbindung der Eingabegeräte allein dem VR-System überlassen bleibt empfiehlt sich hier analog zu der klar definierten Schnittstelle zwischen VR- und CAD-System die Trennung zwischen einem die Eingabegeräte abstrahierenden Teil und der eigentlichen Benutzeroberfläche in der VR-Anwendung. In dieser Schnittstelle lassen sich neben der Übergabe der Betrachter-, Hand- bzw. Cursorposition eine Möglichkeit zur Texteingabe und Felder zur direkten Ansteuerung der wichtigsten Interaktionsfunktionen (z.B. Selektieren und Abbrechen) unterbringen. Zur Anpassung des Gesamtsystems an die jeweils vorhandene Hardware ist dann im Wesentlichen nur noch die Anpassung des die Eingabegeräte abstrahierenden und entsprechend kompakten Teils erforderlich.
Für die praktische Umsetzung wurden die benötigten Module als Klassen in C++ implementiert. Für die Wahl dieser Sprache sprechen die hohe Vertrautheit bei allen Beteiligten sowie die einfache Integration des ebenfalls in C++ geschriebenen CAD-Kerns. Ebenso wurde für Listen und assoziative Arrays die Standard Template Library eingesetzt. Für das Skriptmodul wird Tcl verwendet, da diese Sprache bei Lightning-Anwendern ohnehin schon bekannt ist und sich der dazugehörige Interpreter hervorragend in eigene Programme einbinden sowie um benutzerspezifische Anweisungen erweitern läßt. Um mit den Import- und Exportfunktionen kompatibel zu bleiben werden Längeneinheiten ohne Maßeinheit der DIN-Norm entsprechend als in Millimetern angegeben betrachtet, entsprechend gelten Winkelangaben ohne Maßeinheit als in Bogenmaß angegeben.
Für die Nachrichten wurde eine eigene Klasse erstellt, deren Instanzen für jede Nachricht nicht kopiert, sondern nur referenziert werden. Auf diese Weise läßt sich bei sehr umfangreichen enthaltenen Daten ein langwieriges Kopieren der Daten weitgehend vermeiden. Ebenso werden Typ, Inhalt, Sender und Empfänger der Nachricht einmalig bei der Erzeugung der Nachricht angegeben werden und bleiben danach unverändert. Dies verhindert, daß gleichzeitig von mehreren Modulen verwendeten Nachrichten eine Änderung der in ihr enthaltenen Daten zu unvorhergesehenen Effekten führt.
Für die in den Nachrichten verwendeten Daten werden Funktionen wie getHead, getTail, isGroup, addGroup, usw. bereitgestellt, mit denen eine einfache und konsistente Analyse der Daten möglich ist. Da dieselben Daten auch im VR-System verwendet werden wurden die wichtigsten Funktionen dem VR-System sowohl als Lightning-Objekt als auch in Form zusätzlicher Tcl-Befehle bereitgestellt. Neben den schon reservierten Sonderzeichen Leerzeichen, (, ) und ' (nur bei der Angabe von Signaturen) kommt durch die Implementierung der Zeichenkette mittels der C++-String-Klasse die binäre 0 als Sonderzeichen hinzu. Für dieses muß aufgrund seiner Verwendung als Zeichenkettenendemarkierung eine explizite, benutzerspezifische Kodierung (z.B. ähnlich eines Escape-Codes) zur Übertragung eingesetzt werden.
Alle innerhalb des CAD-Systems vorkommenden Module werden von der abstrakten Basisklasse CadSystemModule abgeleitet. Diese definiert die Methode ReceiveMessage zum Empfang und Zwischenspeichern der von einem Modul empfangenen Nachrichten. Da die vorliegende Realisierung in einer Singletasking-Umgebung erfolgt wird die Abarbeitung der Nachrichten über den rekursiven Aufruf der nachrichtenempfangenden Methode durch die nachrichtenempfangende Methode realisiert. Sofern innerhalb eines Moduls eine Nachricht aktiv verarbeitet wird, werden ankommende Nachrichten zwischengespeichert und die Rekursion abgebrochen. Auf diese Weise wird eine übermäßige Verzögerung aktuell verarbeiteter Nachrichten verhindert und ein potentieller Stapelspeicherüberlauf vermieden. Ausgenommen von der Zwischenspeicherung sind Kommandonachrichten sowie Statusnachrichten, auf die das Modul wartet, da andernfalls ein synchroner Empfang von erwarteten Statusnachrichten nicht möglich wäre.
Jedes von der Basisklasse abgeleite Modul muß seine eigene Methode ProcessMessage implementieren, mittels der die empfangenen Nachrichten von der geerbten ReceiveMessage-Methode zur Verarbeitung übergeben werden. Im Gegenzug stehen ihm dafür die vererbten Funktionen zum Nachrichtenversand mit (synchron) und ohne Warten (asynchron) auf den Rückgabewert bereit.
Die von den Modulen in C++ implementierten Kommandonamen werden ebenso wie die gängisten Statusmeldungen als Stringkonstanten in jeweils einer einzigen Datei gesammelt. Dies garantiert, daß auch bei Änderungen an den Namen die Module für dasselbe Kommando stets denselben Namen verwenden, erlaubt die Erkennung von Tippfehlern während des Kompiliervorgangs und stellt darüber hinaus eine aktuelle Übersicht über die aktuell in C++ verwendeten Kommandonamen bereit.
Die Implementierung des Nachrichtenmoduls ist vergleichsweise einfach, läßt sich aber für die Verwendung in einem verteilten System beliebig um Funktionen zum Nachrichtenversand zwischen verschiedenen Prozessen oder Rechnern ausbauen. Zu beachten ist vor allem, daß dieses Modul als einziges Nachrichten direkt an andere Module schickt und somit zum Nachrichtenversand die ReceiveMessage-Methode des in der Nachricht angegebenen Empfängermoduls anstelle der ReceiveMessage-Methode des Nachrichtenmoduls aufruft. Wird in einer Nachricht statt einem Empfängermodul der Wert BROADCAST_MESSAGE angegeben, so wird die ReceiveMessage-Methode aller in einem entsprechenden Set vermerkten Updatenachrichtenempfänger der Reihe nach aufgerufen.
Ebenfalls zu berücksichtigen ist, daß das Nachrichtenmodul ebenso wie das Kommandomodul stets unterscheiden muß, ob ankommende Nachrichten für die Verarbeitung im Modul selbst oder zur Weiterleitung an fremde Module bestimmt sind.
Der wichtigste Bestandteil des Kommandomoduls ist eine Multimap mit den registrierten Kommandonamen als Schlüssel sowie der Signatur, dem verarbeitenden Modul und dem originalen Kommandonamen in den dazugehörigen Werten. Während des Vergleichs einer eingehenden Kommandozeile werden die einzelnen Parameter für jedes registrierte Schlüssel-Signatur-Paar nacheinander verglichen. Die erste passende Signatur bestimmt daraufhin das verarbeitende Modul bzw. die Validität einer zu testenden Kommandozeile.
Kern des Topologiemoduls ist eine Map mit den IDs der verwalteten topologischen Objekte als Schlüssel und der kompletten Beschreibung der topologischen Objekte als dazugehörige Daten. Der korrekte Neuaufbau der zugehörigen topologischen Objekte durch passende Verwendung der geometrieverarbeitenden Kommandos wird ebenfalls hier mittels der internen Hilfsfunktion BuildGeometry realisiert: Zuerst werden die zur Erzeugung eines geometrischen Objekts benötigten Ausgangsobjekte entsprechend ihrer Attribute in lokalen Koordinaten positioniert. Falls sich ein Ausgangsobjekt und das zu erstellende Objekt in verschiedenen Koordinatensystemen befinden wird zusätzlich noch das Ausgangsobjekt aus den lokalen Koordinaten in seinem Koordinatensystem in die lokalen Koordinaten des zu erstellenden Objekts transformiert.
Das Topologiemodul registriert sich selbst als Empfänger von Updatenachrichten. Auf diese Weise kann es die Geometrie der topologischen Objekte bei Änderungen an Attributen neu aufbauen, ohne daß dazu jede die Attribute verändernde Funktion separat mit zusätzlichem Programmcode instrumentiert werde muß.
Die wichtigste Funktion des Topologiemoduls ist das AddTopologyObject-Kommando. Dieses legt nicht nur die Datenstruktur des neuen Objekts passend an, sondern kopiert auch bei mehrfacher Verwendung existierender Objekte komplette Unterbäume des Strukturbaums durch rekursiven Aufruf und setzt dabei, falls verfügbar, Zwangsbedingungen welche die Positionierungsdaten identisch halten. Sofern in den Parametern der Typ des topologischen Objekts nicht angegeben wurde versucht das Topologiemodul zuerst, diesen anhand des erzeugenden Kommandos zu erkennen. Ist dieses unbekannt, so wird durch testweise Erzeugung und Abfrage des Typs des entstandenen Objekts über die Kommandos des Geometriemoduls zu ermitteln.
Eine weitere wichtige Funktion sind das BuildTopologyObjectGeometry-Kommando zum Aufbau der Geometrie eines topologischen Objekts mitsamt der Geometrie all der Objekte, unter deren Verwendung es konstruiert worden ist. Bereits existierende Geometrie wird dabei nicht neu erzeugt. Für den Neuaufbau der Geometrie eines Objekts mitsamt aller unter seiner Zuhilfenahme konstruierten Objekte wird stattdessen das UpdateTopologyObjectGeometry-Kommando verwendet. Dieses überschreibt auch bereits bestehende Geometrie durch die neu erzeugten Versionen.
Hierbei ist zu beachten, daß es prinzipiell möglich ist, zyklische Abhängigkeiten unter Verwendung der AddTopologyObject-Funktion zu konstruieren, so daß ein (Neu-)Aufbau in eine Endlosschleife geraten würde. Auf ein Abfangen dieses Falles wurde allerdings verzichtet: Normal konstruierte Objekte sind entweder geometrische Primitive oder basieren stets auf anderen bereits erfolgreich konstruierten Objekten. Für die Erstellung zyklischer Abhängigkeiten ist dagegen zumindest vorübergehend die Verwendung eines noch nicht existierenden Objekts nötig, was bei konsequenter Verwendung existenter Geometrie in der Benutzeroberfläche nicht auf versehentliche Weise geschehen kann. Es ist allerdings denkbar, daß Kommandos zum Ersetzen bestehender topologischer Objekte durch ein anderes derartige Abhängigkeiten unbeabsichtigt erstellen können, so daß diese entsprechende Vorkehrungen gegen zyklische Abhängigkeiten treffen sollten. Die andere naheliegende Möglichkeit, die Verwendung nicht existierender topologischer Objekte für die Konstruktion neuer Objekte generell zu verbieten wäre dagegen geschützt, hat aber den großen Nachteil, daß dadurch Makrobefehle wie sie zum Laden kompletter topologischer Datenstrukturen verwendet werden um ein vielfaches aufwendiger gestaltet werden müßten. Es ist auch denkbar, in zyklischen Konstruktionen vorkommende Objekte nur endlich oft neu aufzubauen. Da derartige Konstruktionen aber weder für die Praxis bedeutend sind noch sich allgemein angeben läßt nach welcher Zahl an Iterationen das Objekt fertig erstellt ist wurde auch davon abgesehen.
Für das Topologiemodul wurde wie auch für das Geometriemodul die Zuordnung der eintreffenden Kommandonamen zu den entsprechenden Funktionen aufgrund der hohen Zahl an exportierten Kommandos anstelle einer Kette aus if-Bedinungen eine Map eingesetzt, welche für jeden Kommandnamen einen Zeiger auf die aufzurufende Funktion enthält. Dies ist zudem geschickter als es ein entsprechender C++-switch-Ausdruck für den String-Datentyp gewesen wäre, da sich die einzelnen Kommandos durch die Hilfsfunktion RegisterCommand gleichzeitig mit ihrer Registrierung im Kommandomodul auch in die Map eintragen lassen.
Im Geometriemodul werden die einzelnen OpenCascade-Modellierfunktionen in Form exportierbarer Kommandos gekapselt. Die erzeugten Geometrieobjekte werden dabei in einer Map gespeichert und durch einen zugehörigen Namen gekennzeichnet. Für die automatische Vergabe der Namen im Geometriemodul wird eine einfache Aufzählung natürlicher Zahlen benutzt. Für verwandte Module steht neben der Nachrichtenfunktionen auch eine Methode zum direkten Zugriff auf die enthaltenen Geometrieobjekte bereit.
Die Struktur der meisten kommandoimplementierenden Funktionen ist dreigeteilt in das Auslesen der Parameter, dem eigentlichen Modellierungsschritt und der anschließenden Speicherung des erzeugten Objekts in der Map. Davon ausgenommen sind komplexere Funktionen mit Parametern variablen Typs oder Gruppen von Parametern wie CreateFilleted, bei denen ein Auslesen der Parameter während der Modellierung zu einer einfacheren Implementierung genutzt werden konnte.
Bei der Verwendung ist zu beachten, daß OpenCascade die Topologietypen AXIS, HALFAXIS und PLANE nicht kennt und diese stattdessen als EDGE bzw. FACE betrachtet. Aus diesem Grund wird für die Kommandosignaturen im Geometriemodul stets EDGE oder FACE anstelle von AXIS, HALFAXIS und PLANE verwendet. Falls es sich bei den angegebenen Parametern um keine Gerade oder Ebene handelt wird dies entweder durch geometrische Analyse innerhalb der Funktion abgefangen oder stattdessen, soweit sinnvoll, versucht eine passende Ebene oder Gerade aus den angegebenen Parametern abzuleiten.
Bei der Implementierung erwiesen sich die primitiven geometrischen Objekte der gp_...-Klassen als relativ bequeme Hilfsmittel für die Erzeugung nur temporär benötigter Objekte. Störend war dagegen, daß einige Funktionen nicht für Objekte der TopoDS-Klassen verfügbar waren und gerade die Konversion einer TopoDS_Face oder TopoDS_Edge in die entsprechenden Geom_Geometry-Objekte vergleichsweise umständlich ist, zumal viele Operationen nur für bestimmte abgeleitete Geom-Klassen verfügbar sind. Zudem läuft die Untersuchung eines zusammengesetzten Shapes meist darauf hinaus, die entsprechenden Teilflächen- und Kanten mittels des dafür gedachten TopAbs_Explorers einzeln untersuchen zu müssen. Wichtige Hilfsmittel für die Konversion allgemeiner Shapes und Geom-Objekte in den entsprechenden genauen Typ der abgeleiteten Klasse (TopoDS_Vertex, Geom_Plane,...) sind die Methoden ShapeType() für ein Shape sowie GeomAdaptor_Curve.GetType() für Geom_Geometry-Objekte. Derzeit wird allerdings nur die Methode ShapeType() in der Dokumentation erwähnt, die entsprechende Methode für Geom_Geometry-Objekte findet sich dagegen nur durch mühsames Durchsuchen der Klassendefinitionen, etwa anhand der beigelegten automatisch generierten, aber unkommentierten Zusammenfassung. Die Konversion von Geom_Geometry-Objekten in zugehörige gp_...-Objekte ist dagegen unkritisch: Da für diese keine Elternklasse verwendet wird müssen die Methoden der Geom_Geometry-Objekte stets den genauen Typ des Objekts zurückliefern.
Der Schnittpunkt von Kurven ist nur für 2D-Kurven berechenbar. Entsprechend müssen 3D-Kurven zur Schnittpunktbestimmung erst auf entsprechende 2D-Kurven parametererhaltend projiziert werden. Aus dem ermittelten Schnittpunktparameter kann anschließend der dazugehörige Punkt auf der 3D-Kurve reproduziert werden. Sowohl für Flächen als auch für Kurven lassen sich Tangente und Normale an einem Punkt berechnen, die Richtung einer Oberflächentangente hängt dabei von der Parametrisierung der Fläche ab.
Bei der Verwendung von OpenCascade gab es einige Schwierigkeiten zu umgehen. Diese sind im wesentlichen:
Das implementierte Tesselierungsmodul greift direkt auf die Daten des Geometriemoduls als auch auf den Szenegraphen zu. Somit muß bei Initialisierung des Tesselierungsmoduls die Zeiger zum Zugriff auf Szenegraph und Geometriemodul mit übergeben werden.
Intern besteht das Modul aus zwei Teilen: Der direkt im Quelltext des Moduls tesseliert Objekte unabhängig von dem vorhandenen Szenegraphen in einer hierarchischen Darstellung. Dabei wird für jedes Objekt ein Knoten mit dem Namen des Objekts angelegt. Dieser enthält die Unterobjekte Knotennamen_Faces, Knotnenamen_Edges, Knotennamen_Vertices und Knotennamen_Pick. Für jede Kante und jede Fläche in einem Objekt werden zudem im entsprechenden Unterknoten eigene Knoten eingefügt, die dem Namen des Unterknoten gefolgt von einer durchlaufenden Zählung entsprechen. Enthält ein Objekt keinerlei Flächen, anhand derer es selektiert werden könnte so werden durch Verschieben der Kanten in alle drei Hauptachsen Flächen erzeugt, die im Unterknoten Knotennamen_Pick abgelegt werden. Entsprechend wird für allein aus Punkten bestehenden Objekte eine umgebende Fläche in Form einer Doppelpyramide (vergleichbar einer sehr grob tesselierten Kugel) erzeugt.
Der zweite Teil des Tesselierungsmoduls besteht aus den Funktionen, mittels der die während der Tesselierung erzeugten Knoten mitsamt ihren Daten im Szenegraphen abgelegt werden. Diese sind in einer separaten Quelltextdatei abgelegt, so daß für die Anpassung des Tesselierungsmoduls an andere Szenegraphen nur diese Datei angepaßt werden muß. Hierfür ist kein näheres Verständnis vom internen Aufbau des Tesselierungsmoduls mehr erforderlich.
Die Quelltexte für die Tesselierung und die Übergabe im Szenegraphen konnten weitgehend von bestehenden Vorarbeiten übernomen werden und mußten nur noch den geänderten Anforderungen entsprechend erweitert und angepaßt werden. Für die Darstellung relevante Parameter wie Farbe und Reflexionsgrad werden nicht mit in den Knotendaten abgelegt, da hierfür allein das VR-System zuständig sein soll.
Bei der Verwendung des Tesselierungsmoduls ist zu beachten, daß der verwendete Tesselierungscode noch nicht dafür geeignet ist, uendlich ausgedehnte Objekte zu tesselieren. Somit muß die Darstellung unendlicher Achsen und Flächen im VR-Syste durch eine geeignete Repräsentation ersetzt werden, welche ohne Daten aus der Tesselierung auskommt.
Bei seiner Instantiierung erzeugt das Skriptmodul eine Instanz des verwendeten Tcl-Interpreters, welche über die gesamte Lebenszeit des Moduls erhalten bleibt und sämtliche in ihm global angelegten Funktionen und Variablen auch zwischen mehreren Aufrufen des TclExecute-Kommandos beibehält. Zum Zeitpunkt der Initialisierung werden dem Sprachumfang des Interpreters auch die Befehle SendMessage, SendMessageGetStatus, grouped, ungroup, group, getHead, getTail und isId hinzugefügt, welche auf den entsprechenden C++Funktionen des Systems aufbauen.
Prinzipiell wäre es bei Vorliegen eines gemeinsamen Adressraums möglich, die Tcl-Interpreterinstanz des Lightning-Systems mitzuverwenden, da diese leicht über eine globale Variable ausgelesen werden kann. Allerdings bietet dies keinen funktionalen Vorteil, da alle eventuell zu teilenden Daten und anzulegende Funktionen auch über die Nachrichten ausgetauscht werden können. Stattdessen wurde die freie Zugänglichkeit des Tcl-Interpreters zur Erstellung eines unabhängigen Lightning-Objekts genutzt, welches aus dem Skriptmodul bekannte Befehlserweiterungen auch im Lightning-Interpreter verfügbar macht. Damit existiert eine praktische Möglichkeit, Skripte zur Kommandoerstellung und -verarbeitung gleichzeitig für das Skriptmodul als auch in Lightning zu verwenden.
Während sich die Implementierung des bei der Konzeption beschriebenen Verhaltens erfreulich geradlinig umsetzen läßt kann es während der Kompilierung zu Problemen kommen: Sowohl Lightning als auch eine Standard-OpenCascade-Installation verwenden einen Tcl-Interpreter in ihren Pfaden, zusätzlich zu eventuell anderweitig auf dem System installierten Interpretern. Kommt es bei der Kompilierung zu Problemen, so sollte darauf geachtet werden, daß sich nur die Pfade eines Interpreters in den Parametern von Compiler und Linker befinden.
Für die Verwaltung der Zwangsbedingungen wird eine hierarchische Struktur verwendet: Jedes topologische Objekt, für das mindestens eine Bedingung gesetzt ist, besitzt einen Eintrag in einer Map mit der ID des Objekts als Schlüssel. Die dazugehörigen Daten sind eine zweite Map, in der für jeden mit diesem Objekt verwendeten Bedingungstyp ein Eintrag existiert mit dem Typ als Schlüssel. Dessen Daten bilden wiederum ein Set, welches die Menge aller Daten der Bedingungen dieses Typs für dieses Objekt enthält. Die Verwendung der Bedingungen ist unabhängig von den existierenden topologischen Objekten: Existiert ein in einer Bedingung enthaltenes Objekt nicht, so wird die gesamte Bedingung einfach ignoriert. Das Setzen einer Bedingung führt nicht automatisch zu deren Überprüfung, dies tritt erst ein, wenn diese über das CheckConstraints-Kommando oder durch eine Updatenachricht veranlaßt wird.
An einschränkbaren Freiheitsgraden werden derzeit die drei Komponenten der Position und der Orientierung sowie das Koordinatensystem eines Objekts unterstützt. Jeder Freiheitsgrad kann nur einmal beschränkt werden, existieren mehrere Bedingungen für denselben Freiheitsgrad, so wird nur die erste aufgefundene Bedingung berücksichtigt. Auf diese Weise werden Probleme durch eine Überzahl an gesetzten Bedingungen vermieden. Eine Erkennung unerfüllbarer Bedingungen existiert darüber hinaus aufgrund des wesentlich höheren Implementierungsaufwands noch nicht.
Symmetrische Bedingungen werden dadurch realisiert, daß vor der Überprüfung der Bedingungen des geänderten Objekts zuerst die gesetzten Bedingungen des unveränderten Objekts geprüft werden. Somit wird dieses zuerst korrigiert und folgt damit den Änderungen des ursprünglich veränderten Objekts. Bedingungen mit konstanten Werten werden vor allen anderen Bedingungen geprüft, um in möglichst wenigen Schritten ein endgültiges mit allen Bedingungen übereinstimmendes Ergebnis zu finden.
Die Bedingungen ATINTERSECTION, ONCURVE und CURVEPARAM basieren auf den Kommandos GetNearestIntersection, GetNearestProjection und GetParametricValue des Geometriemoduls. Dementsprechend besitzen sie die gleichen Parameter, Fähigkeiten und Beschränkungen wie diese. Alle anderen Bedingungen basieren dagegen allein dem stringbasierten Vergleich der Attributwerte der entsprechenden topologischen Objekte.
Die Einbindung in das Lightning-VR-System erfolgt durch ein Modul, das aus Sicht des CAD-Systems als ganz normales Modul zum Versand und Empfang von Nachrichten in Erscheinung tritt, aus Sicht von Lightning aber zugleich wie ein Lightning-Objekt mit Eingangs- und Ausgangsfeldern zu verwenden ist.
Die tatsächliche Realisierung könnte auf vielfältige Weise, auch in Form getrennter Module für Nachrichtenversand, -Empfang und tesselierte Geometrie erfolgen. Hier wurde eine leicht verständliche Variante gewählt, die das gesamte CAD-System als Summe all seiner Module in Form interner Objekte instantiiert und nach außen hin die benötigten Lightning-Felder für den Nachrichtenversand bereitstellt. Der einzige Nachteil dieser Lösung besteht darin, daß zur Verwendung des Szenegraphen ein von ltVisObj abgeleitetes Objekt verwendet werden sollte, da nur damit eine mit anderen Objekten konsistente Verwendung des Szenegraphen möglich ist. Für den asynchronen Empfang ankommender Nachrichten eignet sich jedoch ein ltSensor-Objekt besser, da dieses auch ohne Änderungen an den Eingabefeldern die Werte an den Ausgabefeldern aktualisieren kann. Zur Behebung dieses Problems wurde deshalb dem Interface-Objekt ein Datenfeld hinzugefügt, dessen einzige Aufgabe darin besteht, die Ausgabe neuer Daten anzustoßen. Dieses kann dann mit dem Ausgang eines geeigneten Sensor-Objekts, etwa dem Systemzeitgeber, verbunden werden.
Bei der Auslegung der Nachrichtenübergabe ist zudem zu beachten, daß durch den asynchronen Versand sowohl das VR-System als auch das CAD-System mehrere Nachrichten auf einmal versenden kann. Für den Versand in das CAD-System hinein ist dies unkritisch, da ohnehin jedes Modul über eine eigene Warteschlange für empfangene Nachrichten verfügt. Für den Empfang von Nachrichten im Lightning-Objekt muß diese dagegen zusätzlich hinzugefügt werden. Dies geschieht in Form zweier Queues separat für empfangene Status- und Updatenachrichten. Für jeden Nachrichtentyp existieren somit drei Felder zum Auslesen der Nachrichten in Lightning: Ein Lesefeld, das die aktuelle Schreibposition in der Queue angibt und mit jeder empfangenen Nachricht inkrementiert wird. Das zweite Feld gibt die Leseposition in der Queue an, dieses wird von der Lightning-Anwendung zum Auslesen der Nachrichten entsprechend inkrementiert. Die gerade auszulesenden Daten werden in einem Textfeld ausgegeben, das die Daten entsprechend der Leseposition in der Queue bereitstellt. Einmal ausgelesene Daten werden anschließend aus der Queue entfernt.
Die verbleibenden Module sind sehr einfach strukturiert und eignen sich gut als Beispiele zum Aufbau eigener Module. Zur Datenspeicherung dient ein Modul, daß die Standard-C++-Funktionen zum Lesen und Schreiben von Dateien als Kommando kapselt. Das Kommandozeilenausgabemodul kann eingesetzt werden, um Updatenachrichten zu verfolgen oder um an es gesendete Nachrichten auf der Standardausgabe auszugeben. Umgekehrt dient das Kommandozeileneingabemodul zum Einlesen von Kommandonachrichten, entweder einmalig beim Start der Anwendung oder dauerhaft. Im letztem Fall empfiehlt es sich, vor dem Aufruf der ReadInput-Methode das Vorhandensein einer Eingabe auf der Kommandozeile zu prüfen oder die ReadInput-Methode von einem separaten Thread aus aufzurufen, da ansonsten auf die vollständige Eingabe gewartet werden muß.
Für die Erzeugung der IDs wird wie für die automatisch erzeugten Namen ein einfacher Zähler verwendet. Mit dem verwendeten Integer-Datentyp lassen sich somit 232-1 verschiedene IDs erzeugen, was für die praktische Anwendung genügen sollte. Die Zählvariable wurde als static deklariert, so daß selbst bei mehrfacher Instantiierung des ID-Moduls eindeutige IDs generiert werden. Dazu müssen jedoch alle beteiligten ID-Module im gleichen Adressraum liegen.
Aus Sicht des Benutzers besteht die Bespielanwendung im Wesentlichen aus einer Kommandozeile, aus Icons bestehenden Menüs und den konstruierten Objekten, zwischen denen der Anwender frei navigieren kann. Mittels eines einem Laserpointer ähnlichen Cursors lassen sich die Objekte verschieben oder die Kommandozeile durch Anklicken der Icons und der konstruierten Objekte füllen. Ebenso kann die Kommandozeile über die Tastatur verwendet werden. Ist die Kommandozeile komplett, wird sie durch Betätigung einer entsprechenden Taste ausgeführt.
Je nach aktuell verwendetem Menü wird der Inhalt der Kommandozeile entweder direkt an das CAD-System geschickt oder zuvor durch Ergänzung von Parametern in ein geeignetes Kommando umgewandelt. Letzteres erleichtert die Erzeugung der Objekte und das Setzen von Zwangsbedingungen im Vergleich zur direkten Eingabe des CAD-Kommandos.
Die einzelnen Menüs sind jeweils als separates Lightning-Skriptobjekt mit identischen Ein- und Ausgabefeldern realisiert. Diese Menüobjekte erhalten direkt die eingelesenen Daten über die Lightning-Routes, bei einem Wechsel werden diese Routen entsprechend umgesetzt. Für die Ausgabe der Menüs an das CAD-Interface oder je nach Menü andere Lightning-Objekte werden die Feldwerte allerdings mit dem ltsetA-Befehl gesetzt, da das Routing nur ein Ausgabefeld pro Eingabefeld erlaubt.
Die Aktualisierung der Konstruktionsdaten erfolgt rein passiv durch ein Skriptobjekt, daß bei ankommenden Updatenachrichten für die einzelnen Konstruktionsbestandteile die Lightning-Objekte für dessen graphische Repräsentation anlegt, dessen Daten aktualisiert oder dieses wieder löscht. Für jedes konstruierte Element wird je ein Objekt für die gesamte Grafik, je ein Objekt zum Zugriff auf dessen Oberfläche, Kanten und Selektionshülle sowie ein Transformationsobjekt für die Translation und Rotation angelegt. Diese werden über das Lightning-Routing mit dem Transformationsobjekt des entsprechenden Koordinatensystems verbunden. Für Achsen, Halbachsen und Ebenen werden Lightning-Objekte verwendet, die schon über die entsprechende Geometrie verfügen, bei allen anderen Topologietypen werden die Geometriedaten und die Lightning-Objekte zu deren Zugriff separat erzeugt und erst im Nachhinein verknüpft.
Da innerhalb des CAD-Systems noch kein Modul die Verwaltung der Koordinatensysteme übernimmt wird diese innerhalb des VR-Systems umgesetzt. Ebenso wie für konstruierte Objekte werden hier Lightning-Objekte für dessen graphische Repräsentation und die Transformation des Koordinatensystemursprungs relativ zum globalen Koordinatensystem eingesetzt. Zusätzlich besitzt jedes Koordinatensystem ein Lightning-Skriptobjekt, welches bei Änderungen der Koordinatensystemposition die Attribute der zugehörigen topologischen Objekte entsprechend aktualisiert. Das jeweils zur Konstruktion verwendete Koordinatensystem wird durch einfache Selektion seiner graphischen Repräsentation ausgewählt.
Das Verschieben der konstruierten Objekte und Koordinatensysteme erfolgt im Drag-and-Drop-Stil. Hierzu wird die Position des Cursors in das lokale Koordinatensystem des zu verschiebenden Objekts transformiert und über das Lightning-Routing während der Dauer der Verschiebung mit den Eingangsfeldern des Transformationsobjekts des zu verschiebenden Objekts verknüpft. Ein versehentliches Verschieben des globalen Koordinatensystems wird dabei durch dauerhafte Deaktivierung des entsprechenden Transformationsobjekts verhindert.
Die prototypische Anwendung wurde mit identischer graphischer Oberfläche sowohl als Desktopanwendung realisiert als auch auf die am institutseigene VR-Workstation PIcasso portiert. Hierfür waren keinerlei Änderungen am CAD-Teil der Anwendung nötig, auch konnte der VR-spezifische Teil mit Ausnahme einer zu verändernden Tiefenposition für die Menüelemente praktisch unverändert übernommen werden. Der für die Portierung nötige Zeitaufwand entfiel somit weitgehend auf die Anpassung der VR-Konfiguration an die veränderte Hardware sowie den Austausch des Skripts zur Einbindung der Desktop-Ein- und Ausgabegeräte durch ein an die Trackinghardware angepaßtes Pendant.
Ein erster Eindruck über die Leistungsfähigkeit des modularen Integrationskonzepts zeigte sich schon bei den Tests der zuerst implementierten Module. So konnte die Funktionsfähigkeit des Systems schon vor Fertigstellung des Geometrie- oder Tesselierungsmoduls mit Hilfe der Kommandozeilenmodule getestet werden, ohne daß dafür zusätzliche Änderungen an den Modulquelltexten oder eine bereits funktionierende Lightning-Testanwendung erforderlich waren. Ebenso fügten sich die zu einem späteren Zeitpunkt erstellten Skript- und Zwangsbedingungsmodule wie geplant nahtlos in die bereits bestehende Umgebung ein. Zugleich zeigte die Einbindung des Zwangsbedingungsmoduls, daß das Updatenachrichtenkonzept für Umgebungen mit mehreren Benutzern grundsätzlich funktionsfähig ist. Nach der Konzeption anfallende Wünsche an die Funktionalität, etwa eine Positionierung von neuen Koordinatensystemen tangential zur Oberfläche bereits bestehender Objekte oder vereinfachte Konstruktionsbefehle wie die direkte Erzeugung eines Polygonzugs aus Punkten und Kurven zugleich ließen sich weitgehend auf Basis der bereits bestehenden Funktionalität integrieren.
Obwohl die in der prototypischen Anwendung realisierte Benutzeroberfläche vergleichsweise rudimentär gehalten ist und alle Konstruktionsfunktionen auf dieselbe Weise dem Benutzer zur Verfügung gestellt werden, lassen sich bereits erste Erkenntnisse über die Konstruktion in einer VR-Umgebung ermitteln. So gelang es mit dem Prototypen, die in bestehenden CAD-Systemen erstellten Testobjekte nachzubauen und auf entsprechende Weise in den Abmessungen verändern zu können. Auch ist es durchaus praktikabel, neben der Konstruktion von Objekten auch die Eingabe vieler Zwangsbedingungen direkt mit einem Zeigegerät ohne Rückgriff auf die Tastatur oder spezielle Eingabehilfen wie Dialoge oder Menüs einzugeben.
Für die Erstellung einer flächigen Konstruktion bietet sich gegenüber einem vergleichbaren 2D-CAD-System kein wesentlicher Vorteil. Bei der Konstruktion im dreidimensionalen Raum ergibt sich jedoch durch die Verfügbarkeit aller sechs Freiheitsgrade im Zeigegerät ein deutlicher einfacherer Umgang, da öfters auf umständliche Wechsel der Objekt- bzw. Betrachterposition verzichtet werden und das Mapping der Freiheitsgrade des Eingabegeräts auf die zugehörigen Bewegungen stets dasselbe bleiben kann. Zusätzlich wird die Erkennung der aktuellen Zeigerposition durch die stereoskopische Darstellung unterstützt, was beim Umgang mit nicht allzuweit vom Betrachter entfernten Objekten einer schnelleren Interaktion förderlich ist. Insbesondere die Betrachtung eines gerade konstruierten Objekts von allen Seiten erfolgt dabei durch Verwendung der VR-Umgebung auf sehr natürliche und somit außerordentlich effiziente Weise.
Es zeigt sich aber auch, daß die Gestaltung der Benutzeroberfläche und das Verhalten der Eingabegeräte in einer VR-Umgebung noch weitaus mehr als bei herkömmlichen CAD-Systemen für eine effektive Interaktion entscheidend ist. Insbesondere der Zugriff auf feststehende Elemente der graphischen Oberfläche verzögert die Eingabe durch zusätzliche Berücksichtigung der dritten Dimension bei der Auswahl enorm und sollte dementsprechend weitgehend durch besser geeignete Interaktionstechniken ersetzt werden. Ebenso erhöht sich der Aufwand zur Anpassung der Eingabegeräte, da die Erwartungen an Mapping, Ausgangslage und Empfindlichkeit der einzelnen Freiheitsgrade sich zwischen verschiedenen Benutzern deutlich unterscheiden können.
Mit dem bisher implementierten und verwendeten Funktionsumfang bestätigt sich die Einschätzung, daß OpenCascade grundsätzlich für die Erstellung einer CAD-Anwendung geeignet ist. Nach einem vergleichsweise hohen Einarbeitungsaufwand lassen sich die einzelnen Methoden und Klassen überwiegend gut handhaben und in die eigenen Konzepte eingliedern. Dagegen sind Boolesche Operationen und das Verrunden von Kanten vergleichsweise langsam, was unter anderem daran liegt, daß einige Operationen einfachere geometrische Objekte wie Kreise und Geradensegmente zwecks Erhalt der Parametrisierung dauerhaft in Splinekurven umwandeln. Die Zahl der gefundenen Problemstellen deutet zudem auf einen niedrigeren Reifegrad im Vergleich mit anderen Kernen hin, was aber aus Zeitgründen nicht weiter überprüft werden konnte.
Mit dem konzipierten und realisierten Integrationsmodell steht ein flexibel einsetzbares System zur Einbindung eines CAD-Kerns in eine VR-Umgebung bereit. Dieses kann über die Lightning-Schnittstelle als auch auf Kommandozeilenbasis angesprochen werden und läßt sich leicht um weitere Schnittstellen erweitern und ist für den Einsatz auf verteilten Systemen und mit mehreren Benutzern gleichzeitig vorbereitet. Ebenso erlaubt die modulare nachrichtenbasierte Struktur eine Erweiterung und Anpassung des Implementierung sowohl temporär zur Laufzeit als auch dauerhaft durch Hinzufügen oder Änderungen von Modulen bei gleichzeitiger Vermeidung von Inkompatibilitäten mit darauf aufsetzenden Anwendungen. Damit eignet es sich besonders zur Erstellung von prototypischen Programmen zur Erprobung von Interaktionszwecken und die Verwendung in Kombination mit anderen bestehenden Systemen.
Die Ausführung geometrischer Operationen erfolgt ebenso wie der Datenaustausch in Standardformaten durch den eingesetzten OpenCascade-Kern. Da für den Austausch von Zwangsbedingungen und der Konstruktionshistorie keine entsprechenden Formate verfügbar waren ist zudem die persistente Speicherung im nativen Format des Integrationsmodells möglich. Der Austausch tesselierter Daten kann über entsprechende Formate wie VRML oder durch direkten Zugriff im Szenegraphen des VR-Systems erfolgen.
Bei der Konzeption der einzelnen Konstruktionsbefehle wurde darauf geachtet, nur mit den Freiheitsgraden für Position und Orientierung sowie bereits bestehenden Objekten als Parametern auszukommen und auf zusätzliche Bezeichner und numerische Angaben weitgehend zu verzichten. Auf diese Weise lassen sich gängige VR-Eingabegeräte in unterschiedlicher Kombination direkt einsetzen.
Die Implementierung der Beispielanwendung sowohl für Desktop- als auch VR-Arbeitsplätze zeigt zusammen mit den darin erstellten Testkonstruktionen daß der Einsatz eines VR-Systems für CAD-Anwendungen auch in der Konstruktion praktikabel ist und Einschränkungen herkömmlicher CAD-Systeme vermeiden kann. Ebenso weist sie auf die Wichtigkeit von für dreidimensionale Anwendungen optimierte Interaktionstechniken hin, somit sollte hierauf bei der weiteren Entwicklung ein wesentlicher Schwerpunkt liegen. Dies schließt auch die Fähigkeit zur Konstruktion mit Vorschau in Echtzeit unter Verwendung speziell dafür vorgesehener Algorithmen innerhalb des VR-Systems mit ein. Zusätzlich liegt zur Aufrechterhaltung der Framerate bei umfangreichere Konstruktionen der Einsatz von LOD-Techniken nahe.
Entsprechend liegt ein Ausbau der bestehenden Funktionalität nahe. Die Verwaltung von Koordinatensystemen und bereits konstruierten Bauteilen als Komponenten ließe sich nach dem Vorbild der Topologiemoduls realisieren. Ebenso ist eine Erweiterung um Module sinnvoll, mit denen auch über Netzwerke ein Zugriff auf die Funktionen des CAD-Systems möglich ist. Für ein Mehrbenutzersystem kann dieses zugleich um eine Zugriffsrechteverwaltung erweitert werden.
Interessant wäre auch der Austausch des verwendeten CAD-Kerns und die sich daraus ergebenden Konsequenzen. Dies ist vor allem für Kerne interessant, deren Funktionsumfang über den von OpenCascade hinausgeht.
Der folgende Absschnitt beschreibt die verfügbaren Kommandos und ihre Parameter. Optionale Parameter sind in eckigen Klammern angegeben, Gruppen entsprechend ihrer Syntax in runden Klammern.
Mit diesem Kommando trägt sich ein Modul als Empfänger von Updatenachrichten beim Nachrichtenmodul ein. Der Empfang von Updatenachrichten erfolgt sofort nach Ausführug des Kommandos.
Dieser Befehl ist nur zur internen Verwendung vorgesehen. Mit ihm wird dem Nachrichtenmodul mitgeteilt, an welches Modul Registernachrichten sowie Kommandonachrichten ohne Empfängerangabe gesendet werden sollen.
Tested, ob das als Parameter angegebene Kommando mitsamt seinen Parametern einer im System registrierten Kommandosignatur entspricht.
Gibt eine Liste aller im System registrierten Kommandos zurück.
Gibt alle bekannten Signaturen des im Kommandonamen angegebenen Kommandos zurück.
Dient als Hilfsmittel, um eine Registernachricht für das im Kommandonamen angegebene Kommando mit der angegebenen Signatur zu versenden. Nützlich, falls nur eine Schnittstelle zum Versand von Kommandonachrichten bereit steht.
Entfernt für das Kommandonamen genannte Kommando die angegebene Signatur aus der Liste bekannter Kommandosignaturen. Falls dies die letzte Signatur für dieses Kommando war, wird das Kommando mit entfernt.
Benennt das unter dem Ausgangsnamen mit der gegebenen Signatur eingetragene Kommando in den neuen Namen um. Diese Umbenennung betrifft nur die Verwendung unter der angegebenen Signatur.
Erzeugt eine neue ID
Setzt den für die Erzeugung von IDs verwendeten Ausgangswert neu. Die Eindeutigkeit einer ID ist nur zwischen zwei Aufrufen dieser Funktion gegeben.
Erzeugt ein neues topologisches Objekt vom angegebenen Typ mit der angegebenen ID. Das angegebene Erzeugungskommando dient dabei zur Erzeugung der zu diesem Objekt gehörenden Geometrie. Zusätzlich kann eine Liste zu setzender Attribute in der Form ((Attributname1 Attributwert1) (Attributname2 Attributwert2) ... (AttributnameN AttributwertN)) angegeben werden. Bei der Erzeugung des Objekts werden entsprechende Updatenachrichten verschickt.
Gültige Typwerte sind die topologischen Typen POINT, AXIS, HALFAXIS, EDGE, PLANE, FACE, SHELL, SOLID und COMPOUND. Wird kein Typ angegeben, so wird versucht, diesen anhand der dazugehörigen Geometrie zu bestimmen. Ebenso wird bei fehlender ID automatisch eine passende ID erzeugt.
Bei Ausführung dieses Kommandos werden für die im Erzeugungskommando als Parameter verwendete topologische Objekte automatisch die Attribute für das abgeleitete Objekt gesetzt. Da jedes Objekt nur ein abgeleitetes Objekt haben kann werden bei Bedarf zusätzliche Kopien erzeugt und mit einer EQUAL-Bedingung verknüpft.
Löscht das unter der gegebenen ID abgespeicherte Objekt und entfernt es aus den Attributen der Objekte, von dem es abgeleitet wurde. Sofern das Objekt nicht für temporäre Änderungen markiert war wird eine Updatenachricht der Form ID REMOVED verschickt.
Liefert eine Liste aller Attribute in der Form ((Attributname1 Attributwert1) (Attributname2 Attributwert2) ... (AttributnameN AttributwertN)) zurück.
Liefert für das Objekt mit angegebener ID den Wert des angegebenen Attributs zurück.
Liefert für das Objekt mit angegebener ID die Positionierungsdaten in der Form POSITION ORIENTIERUNG KOORDINATENSYSTEM 2D-FLAG zurück. Hierbei ist bei gesetztem GEOMETRY_2D-Flag der Wert von 2D-Flag gleich 1, ansonsten gleich 0.
Liefert den topologischen Typ des Objekts mit angegebener ID zurück.
Setzt für das Objekt mit angegebener ID das angegebenen Attributs auf den angegebenen Wert. Sofern das Objekt nicht für temporäre Änderungen markiert war oder soeben markiert wurde, werden Updatenachrichten der Form ID Attributname Attributwert verschickt.
Aktiviert für das Objekt mit angegebener ID die angegebenen Flags. Gültige Flag-Werte sind INACTIVE, CONSTRUCTION_GEOMETRY, TEMPORARY und GEOMETRY_2D. Bei Bedarf werden Updatenachrichten in derselben Form wie bei SetTopologyAttribute verschickt.
Deaktiviert die angegebenen Flags. Die Syntax und das Verhalten ist ansonsten identisch mit dem Kommando SetTopologyObjectFlags.
Liefert für das Objekt mit angegebener ID das davon abgeleitete Objekt. Das Ergebnis ist identisch mit dem Aufruf von GetTopologyObjectAttribute ID DerivedObject
Liefert für das Objekt mit angegebener ID eine Liste aller topologischen Objekte zurück, die in dem Erzeugungskommando des Objekts vorkommen.
Erzeugt die dem topologischen Objekt mit angegebener ID zugehörige Geometrie unter Verwendung des angegebenen Erzeugungskommandos, sofern sie nicht schon existiert. Bei Bedarf werden die zur Erzeugung der Geometrie dieses Objekts benötigte Geometrien rekursiv erzeugt. Sofern das dazugehörige topologische Objekt nicht für temporäre Änderungen markiert war, werden Updatenachrichten der Form ID GEOMETRY verschickt.
Erzeugt die dem topologischen Objekt mit angegebener ID sowie für alle direkt oder indirekt davon abgeleiteten Objekte die zugehörige Geometrie neu. Dabei werden wie bei BuildTopologyObjectGeometry entsprechende Updatenachrichten erzeugt.
Liefert für das Objekt mit angegebener ID die gesamte Beschreibung in der Form (ID Typ (Erzeugungskommando) (Attribute)), wobei die Attribute in derselben Form ausgegeben werden wie sie von AddTopologyObject benötigt wird.
Liefert eine Liste der IDs aller im Topologiemodul gespeicherten topologischen Objekte zurück.
Prüft, ob im Geometriemodul ein geometrisches Objekt unter dem angegebenem Name vorliegt.
Liefert den topologischen Typ des geometrischen Objekts angegebenen Namens zurück. Dieser kann unter Umständen vom im topologischen Objekt angegebenen Typ abweichen, etwa weil der CAD-Kern Typen wie AXIS und HALFAXIS mit EDGE und PLANE mit FACE zusammenfasst, oder weil ein degenerierter Fall vorliegt, bei dem z.B. eine Extrusion aus einer FACE statt einem SOLID wiederum ein FACE erzeugt. Dieser Fall kann besonders bei Änderung an einer Konstruktion vorübergehend auftreten.
Benennt das geometrische Objekt namens Ausgangsname in den neuen Namen um
Löscht das geometrische Objekt angegebenen Namens
Setzt die Position und Orientierung des angegebenen geometrische Objekts mittels PositionGeometry und ReorientateGeometry auf die angegebenen Werte und transformiert diese anschließend mittels RepositionGeometry und ReorientateGeometry in das angegebene Koordinatensystem, sofern dieses nicht als leerer Parameter angegeben wurde. Ist der Parameter 2D-Flag ungleich 0, so werden die Z-Komponente der Position sowie die Pitch- und Rollkomponenten der Orientierung intern auf 0 gesetzt.
Betrachtet die Koordinaten des angegebenen Objekts als global und transformiert sie mittels InverseRepositionGeometry und InverseReorientateGeometry so, daß sie den lokalen Koordinaten im angegebenen Koordinatensystem entsprechen.
Transformiert die globalen Koordinaten x y z in das angegebene Koordinatensystem und gibt diese als lokale Koordinaten zurück. Dies ist identisch mit den Koordinaten eines an der Stelle x y z erzeugten Punkts, der mittels CoordSystemLocalizeGeometry entsprechend transformiert wurde.
Setzt die Position des angegebenen Objects auf die Werte x, y und z.
Setzt die Orientierung des angegebenen Objects auf die Werte head, pitch und roll.
Verschiebt die dem angegebenen Objekt zugehörige Position inkrementell um x, y und z. Dies entspricht einer Multiplikation der alten Positionsangaben in Matrixdarstellung mit der Matrixdarstellung der angegebenen Translation.
Dreht das angegebene Objekt unter Berücksichtigung der vorhandenen Position und Orientierung inkrementell um head, pitch und roll. Dies entspricht einer Multiplikation der alten Positionsangaben in Matrixdarstellung mit den Matrixdarstellungen der angegebenen Rotationen.
Verschiebt die dem angegebenen Objekt zugehörige Position inkrementell um -x, -y und -z. Dies entspricht einer Multiplikation der alten Positionsangaben in Matrixdarstellung mit der Inversen der Matrixdarstellung der angegebenen Translation.
Dreht das angegebene Objekt unter Berücksichtigung der vorhandenen Position und Orientierung. Dies entspricht einer Multiplikation der alten Positionsangaben in Matrixdarstellung mit der Inversen der Matrixdarstellungen der angegebenen Rotationen. Vorsicht: Diese Operation lässt sich, anders als InverseRepositionGeometry, nicht auf eine Rotation um die mit -1 multiplizierten Winkel zurückführen.
Berechnet den Abstand der beiden angegebenen Punkte.
Berechnet den Winkel zwischen den beiden Objekten. Der erste Parameter muß eine Kurve sein, deren Startpunkt als Referenzpunkt für den Winkel verwendet werden kann. An diesem wird der erste Richtungsvektor bestimmt. Ist der zweite Parameter ein Punkt, so wird der Differenzvektor zwischen diesem Punkt und dem Startpunkt der Kurve als zweite Richtung verwendet. Ist der zweite Parameter eine Kurve, so wird stattdessen die Tangente an dem Punkt auf der Kurve, der dem Startpunkt der ersten Kurve am nächsten liegt als zweite Richtung verwendet. Das Ergebnis der Berechnung ist der Winkel dieser beiden Richtungen und wird im Bogenmaß als Wert zwischen 0 und Pi zurückgegeben.
Berechet den Winkel zwischen dem zweiten und dem dritten Objekt. Das erste Objekt gibt den Referenzpunkt für die Messung an, wird hier eine Kurve angegeben so wird deren Startpunkt als Referenzpunkt verwendet. Die Richtungsvektoren, an denen der Winkel ermittelt wird, bestimmt sich für Punkte als Differenzvektor zwischen Referenzpunkt und zweitem bzw. drittem Objekt, für Kurven aus der Tangente der dem Referenzpunkt nächstliegenden Punkte auf den entsprechenden Kurven. Das Ergebnis der Berechnung ist der Winkel dieser beiden Richtungen und wird im Bogenmaß mit einem Betrag zwischen 0 und Pi zurückgegeben. Der Winkel kann negativ sein, wenn für das erste Objekt eine Kurve angegeben wird, deren Richtungsvektor am Referenzpunkt die Orientierung des berechneten Winkels festlegt.
Berechnet für Punkte, Kurven und Flächen gegebenen Namens die Position eines Punktes, der sich an den parametrischen Koordinaten U und V auf dem Objekt befindet. Der Standardwert für U und V ist 0, die Parameter sind auf die Werte 0 und 1 normalisiert. Bei Flächen, deren Begrenzung sich nicht allein durch die Intervallgrenzen angeben läßt kann der berechnete Punkt auch außerhalb der Fläche bzw. in einem Loch innerhalb der Fläche befinden, da die Berechnung stets auf der Trägerfläche des angegebenen Objekts erfolgt.
Gibt die Koordinaten des Punkts auf der Oberfläche des angegebenen Objekts zurück, der von dem angegebenen Punkt den geringsten Abstand hat.
Gibt die Koordinaten des Punkts auf der Oberfläche des angegebenen Objekts zurück, der von einem Punkt an den Koordinaten x y z den geringsten Abstand hat.
Berechnet die Schnittpunkte der beiden angegebenen Objekte und gibt die Koordinaten desjenigen Punkts zurück, der von dem angegebenen Punkt den geringsten Abstand hat.
Berechnet die Schnittpunkte der beiden angegebenen Objekte und gibt die Koordinaten desjenigen Punkts zurück, der von einem Punkt an den Koordinaten geringsten Abstand hat.
Berechnet die Normale an dem Punkt auf dem angegebenen Objekt, der von dem angegebenen Punkt den geringsten Abstand hat.
Berechnet die Normale an dem Punkt auf dem angegebenen Objekt, der von einem Punkt an den Koordinaten x y z den geringsten Abstand hat.
Berechnet die Tangente an dem Punkt auf dem angegebenen Objekt, der von dem angegebenen Punkt den geringsten Abstand hat.
Berechnet die Tangente an dem Punkt auf dem angegebenen Objekt, der von einem Punkt an den Koordinaten x y z den geringsten Abstand hat.
Erzeugt eine vollständige Kopie des Objekts angegebenen Namens.
Erzeugt eine Kopie des Objekts angegebenen Namens. Anders als bei CopyGeometry können diese je nach verwendeten CAD-Kern intern Datenstrukturen teilen, so daß z.B. die Tesselierungsdaten bei Tesselierung der Kopie automatisch an das Original angehängt werden und umgekehrt. Dies spart Rechenaufwand und Speicherplatz, verhindert allerdings, daß zusätzliche Kopien ohne diese angehängten Daten verfügbar bleiben.
Verschiebt die Geometrie des angegebenen Objekts entsprechend des durch x, y und z angegebenen Vektors. Anders als RepositionGeometry, das nur die Positionsdaten temporär ändert ist diese Operation nicht reversibel.
Dreht die Geometrie des angegebenen Objekts entsprechend der Winkel head pitch und roll. Anders als ReorientateGeometry, das nur die Positionsdaten temporär ändert ist diese Operation nicht reversibel.
Erzeugt einen Punkt mit den Koordinaten (0 0 0).
Erzeugt einen Punkt mit den Koordinaten (x y z). Dieses Kommando ist vorwiegend für die Erstellung von Makros vorgesehen.
Erzeugt einen Punkt an den von GetParametricValue mit denselben Parametern zurückgegebenen Koordinaten. Dieses Kommando ist vorwiegend für die Erstellung von Makros vorgesehen.
Erzeugt einen Punkt an den von GetNearestProjection mit denselben Parametern zurückgegebenen Koordinaten. Dieses Kommando ist vorwiegend für die Erstellung von Makros vorgesehen.
Erzeugt einen Punkt an den von GetNearestIntersection mit denselben Parametern zurückgegebenen Koordinaten. Dieses Kommando ist vorwiegend für die Erstellung von Makros vorgesehen.
Erzeugt eine Gerade durch die beiden Punkte. Wird kein Punkt angegeben, so wird eine in x-Richtung zeigende Gerade durch den Ursprung erzeugt.
Erzeugt eine Halbgerade durch die beiden Punkte. Wird kein Punkt angegeben, so wird eine am Ursprung beginnende, in positive x-Richtung zeigende Halbgerade erzeugt.
Erzeugt eine Ebene. Werden keine Parameter angegeben, so ist die Lage der Ebene mit der x-y-Ebene identisch. Andernfalls wird versucht, anhand der angegebenen Objekte drei Punkte zur Konstruktion einer passenden Ebene zu finden. Geraden und Geradensegmente liefern zwei Punkte, gekrümmte Kurven und Flächen drei Punkte. Punkte, die sich als Linearkombination bestehender Punkte darstellen lassen werden nicht mitgezählt.
Erzeugt eine Kante als nichtperiodische Spline-Kurve anhand der angegebenen Stützpunkte. Hierbei besitzen alle Stützpunkte dasselbe Gewicht und sind mit Ausnahme der Endpunkte mit Grad 3 vom Grad 1.
Erzeugt eine gerade Kante zwischen den beiden Punkten.
Erzeugt eine Kante als Kreis mit Mittelpunkt Punkt1 durch den Punkt2 in der x-y-Ebene. Sind drei Parameter angegeben, wird ein durch alle drei Punkte gehender Kreis erzeugt.
Erzeugt eine Kante als Kreissegment auf dem Kreis durch die Punkte Punkt1, Punkt2 und Punkt3. Sind Punkt2 und Punkt4 identisch, so wird das durch Punkt2 gehende Kreissegment zurückgegeben, andernfalls wird das Segment außerhalb von Punkt1, Punkt2 und Punkt3 erstellt.
Erzeugt eine Kante, die derjenigen Kante innerhalb des angegebenen Objekts entspricht, welche von dem angegebenen Punkt den geringsten Abstand hat.
Erzeugt eine Kante, die derjenigen Kante innerhalb des angegebenen Objekts entspricht, welche von einem an den angegebenen Koordinaten befindlichen Punkt den geringsten Abstand hat.
Erzeugt einen Kantenzug aus den als Parameter angegebenen Kanten, Kantenzügen und Punkten. Aufeinanderfolgende Punkte werden dabei zuerst in einen Kantenzug konvertiert. Aufeinanderfolgende Kanten und Kantenzüge müssen dabei stets einen zusammenhängenden Kantenzug bilden. Es lassen sich offene und geschlossene Kantenzüge konstruieren.
Erzeugt eine durch den Rand begrenzte planare Fläche mit optionalen Löchern. Sowohl der Rand als auch die Löcher müssen in ein und derselben Ebene liegen.
Erzeugt eine Fläche, die derjenigen Fläche innerhalb des angegebenen Objekts entspricht, welche von dem angegebenen Punkt den geringsten Abstand hat.
Erzeugt eine Fläche, die derjenigen Fläche innerhalb des angegebenen Objekts entspricht, welche von einem an den angegebenen Koordinaten befindlichen Punkt den geringsten Abstand hat.
Erzeugt einen quaderförmigen Massivkörper mit gegebener Breite, Höhe und Tiefe. Dieser ist an den Koordinatenachsen ausgerichtet, die Hauptdiagonale beginnt im Ursprung und endet im Punkt mit den Koordinaten Breite, Tiefe, Höhe.
Erzeugt eine massive Kugel mit gegebenen Radius und Mittelpunkt. Standardwert für den Mittelpunkt ist der Ursprung.
Erzeugt ein Objekt, das durch Verschieben des Ausgangsobjekts entlang des angegebenen Pfades entsteht. Der Typ des erzeugten Objekts hängt sowohl vom Typ des Pfades als auch vom Typ des Ausgangsobjekts ab. Falls möglich sind für den Pfad gerade Kanten zu bevorzugen, da für diese ein optimierter Algorithmus verwendet wird. Als Ausgangsobjekt werden außer Massivkörpern alle Arten von Objekten unterstützt.
Erzeugt ein Objekt, das durch Rotieren des Ausgangsobjekt um den angegebenen Winkel um die angegebene Rotationsachse entsteht. Der Typ des erzeugten Objekts hängt dabei vom Typ des Ausgangsobjekts ab. Als Ausgangsobjekt werden außer Massivkörpern alle Arten von Objekten unterstützt, der Standardwert für den Winkel entspricht einer vollen Umdrehung.
Erzeugt ein Objekt, das der Schnittmenge, Vereinigung oder Subtraktion von Objekt1 mit Objekt2 entspricht. Die hierfür entsprechenden Operationstypen lauten COMMON, FUSE und CUT.
Erzeugt ein Objekt, das der Vereinigung des Ausgangsobjekts mit seinem Spiegelbild entspricht. Als Spiegelobjekt kommen Punkte, Kanten oder Flächen in Frage, dabei wird stets eine Spiegelung an einem entsprechenden Punkt, Geraden oder Ebene erzeugt.
Erzeugt ein Objekt durch Verschieben der Bestandteile des Ausgangsobjekt um den angegebenen Abstand in Richtung der Objektnormalen. Ist als Kantentyp ARC gesetzt, so werden Lücken zwischen Kanten und Flächen durch eine bogenförmige Kante oder Fläche ergänzt, andernfalls werden sie durch entsprechende Verlängerung der benachbarten Kanten und Flächen geschlossen.
Erzeugt ein neues Objekt durch Verrunden von Kanten in Form von Kreisbögen mit angegebenem Radius. Werden keine Marker angegeben, so werden alle Kanten verrundet. Andernfalls besteht die Liste der Marker aus einer Reihenfolge von Suchkriterium und nachfolgenden Punkten. Das Suchkriterium kann ALL, FACE, WIRE oder EDGE lauten und gibt an, welche Kanten hinzugefügt werden: ALL fügt alle Kanten des den Punkten am nächsten liegenden Objekts hinzugefügt werden sollen, FACE fügt alle Kanten hinzu, welche die am nächsten liegende Fläche begrenzen, WIRE sucht nach den Kanten des am nächsten liegenden Kantenzugs und EDGE fügt nur die am nächsten liegende Kante hinzu. Es sind beliebige Kombinationen von Suchkriterien und nachfolgenden Punkten möglich, allerdings ist dabei zu beachten, daß nicht jede Kombination von Parametern eine gültige Verrundung erlaubt. Die Hauptursache hierfür sind zu großen Verrundungsradien als auch eine ungeeignete Wahl der Kanten, etwa wenn zwei Kanten ein und dieselben Fläche begrenzen, aber nur eine von beiden verrundet werden soll.
Erzeugt ein Objekt anhand einer vorliegenden Datei angegebenen Namens. Unterstützte Dateiformate sind STEP und IGES.
Speichert das angegeben Objekt in einer Datei namens Dateiname im angegebenen Dateiformat. Dabei werden als Einheiten im IGES-Format stets Millimeter verwendet. Die verfügbaren Optionen für die Formate STEP, IGES, STL und VRML sind:
Erzeugt ein Objekt anhand der im nativen OpenCascade-BRep-Format angegebenen BRep-Daten.
Erzeugt ein Objekt anhand einer im nativen OpenCascade-BRep-Format vorliegenden Datei angegebenen Namens.
Gibt die Daten des angegeben Objekts im nativen OpenCascade-BRep-Format zurück.
Schreibt die Daten des angegeben Objekts im nativen OpenCascade-BRep-Format in eine Datei angegebenen Namens.
Gibt die interne Darstellung des Objekts ins ASCII-Format konvertiert zurück. Dieses Kommando ist nur für Test- und Debuggingzwecke vorgesehen.
Fügt für das topologische Objekt mit der angegebenen ID eine Bedingung mit den entsprechenden Parametern in die Liste zu überwachenden Bedingungen hinzu. Anschließend wird eine Updatenachricht der Form ADDCONSTRAINT ID Bedingung (Parameter) verschickt. Typ und genaue Anzahl der Parameter richtet sich nach der gewählten Bedingung:
Entfernt die angegebene Bedingung aus der Liste zu überwachender Zwangsbedingungen und verschickt danach eine Updatenachricht der Form REMOVECONSTRAINT ID Bedingung (Parameter). Die Parameter müssen in exakt derselben Form wie beim AddConstraint-Kommando angegeben werden.
Überprüft alle Bedingungen, an denen das topologische Objekt mit der angegebenen ID beteiligt ist.
Liefert eine Liste mit den Daten der angegebenen Bedingung für das Objekt mit gegebener ID zurück. Die Daten sind in derselben Form wie sie als Parameter für das RemoveConstraint-Kommando benötigt werden.
Liefert eine Liste aller das Objekt mit gegebener ID betreffenden Bedingungen zurück.
Liefert eine Liste der IDs aller topologischen Objekte zurück.
Speichert die angegebenen Daten in einer Datei mit angegebenem Namen.
Gibt die in einer Datei mit angegebenem Namen gespeicherten Daten zurück.
Tesseliert geometrische Objekte mit der modulweit eingestellten Genauigkeit. Für einen einzelnen Punkt, eine einzelne Kante oder einen einzelnen Kantenzug wird zudem eine Hülle mit der modulweit eingestellten Größe erzeugt. Das tesselierte Objekt wird unter dem Namen des Objekts im Szenegraphen angelegt, eventuell vorhandene Knoten gleichen Namens werden dabei überschrieben.
Entfernt einen Knoten mit dem angegebenen Namen aus dem Szenegraphen.
Setzt die modulweit eingestellte Größe für die Hülle einzelner Kanten und Punkte auf den angegebenen Wert.
Setzt die modulweit eingestellte Tesselierungsgenauigkeit auf den angegebenen Wert.
Führt das als Parameter angegebene Skript im Interpreter des Skriptmoduls aus und gibt bei erfolgreicher Verarbeitung den berechneten Rückgabewert zurück. Andernfalls wird die Fehlermeldung des Interpreters zurückgegeben. Dieses Kommando ist vorwiegend zum Anlegen und Einlesen skriptbasierter Kommandos gedacht, eignet sich aber ebenso für kurze Berechnungen.
In dem beiliegenden Makroskript CadSystemMacros.tcl sind einige nützliche Erweiterungen beispielhaft implementiert:
Gibt einen String zurück, in dem alle vorkommenden IDs durch neue IDs ersetzt werden. Mehrfach vorkommende IDs werden dabei durch identische Werte ersetzt.
Speichert die Liste mit den Daten aller topologischen Objekte sowie die Liste mit den Daten aller gesetzten Zwangsbedingungen als Liste in einer Datei ab. Diese Datei enthält sämtliche Informationen, die für den Wiederaufbau der gesamten Konstruktion benötigt werden. Zur besseren Lesbarkeit werden als Trenner zwischen den einzelnen Objektdaten Zeilenumbrüche statt der üblichen Leerzeichen gesetzt.
Inverse Operation zum Kommando SaveAll, lädt eine komplette Konstruktion aus der angegebenen Datei.
Erweiterung des GetDistance-Kommandos um den Abstand zwischen einem Punkt und einem beliebigen geometrischen Objekt zu messen.
Erzeugt eine Kugel mit gegebenen Mittelpunkt und dem Abstand der beiden gegebenen Punkte als Radius.
Erweiterung des CreateFace-Kommandos, mit der neben Kantenzügen zusätzlich auch geschlossene Kanten als Parameter unterstützt werden.
Kurzformen des Boolean-Kommandos mit entsprechend gesetztem Operationstyp.
Erweiterung des CreateOffseted-Kommandos, mit der der Abstand des angegebenen Punktes vom Objekt als Abstandsparameter verwendet werden kann.
Erweiterung des CreateFilleted-Kommandos, mit der der Abstand des angegebenen Punktes von der ihm nächstliegenden Kante auf dem Objekt als Radius für die Verrundung verwendet werden kann.
Ersetzung des SGTesselate-Kommandos, welche bei nicht vorhandener Geometrie im Geometriemodul versucht, diese automatisch anhand der im Topologiemodul angegebenen Daten zu erzeugen. Erst wenn dies nicht möglich ist schlägt die Ausführung des Kommandos fehl.
Kurzformen des LoadImport-Kommandos mit entsprechend gesetztem Dateiformat als Parameter.
Kurzformen des SaveExport-Kommandos mit entsprechend gesetztem Dateiformat als Parameter.
Für den Lochring wurden der Innen- und Außenkreis durch einen gemeinsamen Mittelpunkt und je einen radiusbestimmenden Punkt auf dem Kreis erzeugt. Die Bohrung wurde der Einfachheit halber ebenfalls gleich in der zu extrudierenden Fläche untergebracht. Für deren identischen Abstand zu den Kreisen wurde zuerst eine Achse durch den Mittelpunkt gelegt, deren Schnittpunkte wiederum werden für die Definition eines Geradenstücks verwendet. Der Mittelpunkt der Bohrung wird anschließend durch eine Bedingung CURVEPARAM mit Parameter 0.5 auf diesem Geradenstück festgelegt. Anschließend wurden die Kreisfläche der Bohrung als auch die Fläche des Rings aus den bestehenden Kanten erzeugt.
Da im bisherigen Funktionsumfang keine Funktion zur Mustererzeugung vorliegt wurde diese kurzerhand als Skriptmodul-Makro realisiert. Die Parameter des Makros sind neben dem Mittelpunkt des Bohrungskreismusters und der anzuwendenden Funktion zwei Punkte bzw. Geraden, welche den Winkel zwischen benachbarten Bohrungen und den Winkel, der mit dem Muster zu füllen ist, angeben. Der erzeugte Verbundkörper wird anschließend vom Ring per Booleschem Schnitt abgezogen.
Alle bisher genannten Konstruktionselemente liegen in der XY-Ebene, was durch Setzen des entsprechenden Flags gesichert wird. Die Kante zur Definition einer senkrechten Extrusion der erzeugten Lochfläche zum fertigen Körper wird durch einen schon vorhandenen Punkt sowie einem Punkt mit denselben XY-Koordinaten (garantiert durch entsprechende Bedingungen) festgelegt.
Zwei zusätzliche Punkte definieren die Außenkanten als zu verrundende Kanten, wobei durch gesetzte Bedingungen einer der Punkte in der XY-Ebene und der zweite auf der Oberfläche des zu verrundenden Objekts zu liegen kommen. Letzterer wurde zugleich zur Definition des Verrundungsradius verwendet.
Das Ergebnis ist eine Konstruktion, bei der sich alle wesentlichen Parameter durch einfaches Verschieben von insgesamt 7 Punkten ändern lassen. Hierbei hat sich herausgestellt, daß es anders als im Bild gezeigt sinnvoller ist, den Punkte zur Bestimmung des Verrundungsradius auf die Seitenfläche des Körpers zu setzen um eine versehentliche Selektion der Bohrungskante zu vermeiden.
Für den Tisch wurde zuerst das Tischbein separat aus vier Geradenstücken und einem Kreisbogen erstellt. Die von ihnen begrenzte Fläche erzeugt anschließend durch Spiegelung und nachfolgender Rotation das fertige Tischbein, das anschließend im BRep-Format als fertiges Bauteil gespeichert wurde. Für die anschließende Weiterverwendung ist es wichtig, daß die obere Kante des Tischbeins bündig mit der X-Achse liegt und die Rotationsachse der Y-Achse entspricht.
Für die Tischplatte, bestehend aus einem parallel zur XY-Ebene liegenden extrudierten Rechteck, wurde keine separates Bauteil abgespeichert, da die Platte nur einmalig verwendet wird. Über zu den Tischplatten parallele und in derselben Ebene wie die Unterseite der Tischplatte liegende Geraden werden vier Schnittpunkte zur Positionierung der Tischbeine definiert. Die Tischbeine selbst werden über das entsprechende LoadBRepFile-Kommando geladen und wie gewöhnliche primitive Geometrietypen verwendet. Über die Bedingungen EQUALPITCH und ATINTERSECTION werden diese anschließend an den zugehörigen Punkten platziert und senkrecht zur Tischplatte stehend ausgerichtet.
Das Ergebnis ist eine Konstruktion, bei der sich die Tischplatte durch Verschieben zweier Punkte und die Position der Beine über das Verschieben der 4 Achsen verändern läßt. Ebenso läßt sich durch Verschieben der 3 Punkte auf dem Kreisbogen das Tischbein in allen freien Parametern anpassen. Aufgrund einer fehlenden Bauteileverwaltung muß das veränderte Tischbein anschließend von Hand abgespeichert und durch erneutes Laden der Gesamtkonstruktion mitgeteilt werden.