Analytische und Polygonale Shapes

Transkript

1 Analytische und Polygonale Shapes Eldar Sultanow Hasso-Plattner-Institut an der Universität Potsdam Zusammenfassung. Analytische und Polygonale Shapes sind geometrische Objekte. Analytische Shapes sind definiert durch mathematische Funktionen wie beispielsweise algebraische Flächen. Polygonale Shapes stellen lediglich eine Sammlung von Dreiecksflächen oder Vierecksflächen dar. Analytische Shapes lassen sich auf polygonale Shapes abbilden. Den polygonalen Shapes liegt eine mathematische Funktion zu Grunde nämlich jene, die das entsprechende analytische Shape definiert. Bekannte Vertreter analytischer Shapes sind Kugel, Zylinder, Kegel und Torus. Viele Renderingsysteme können analytische Shapes nicht direkt verarbeiten und es ist eine Umwandlung der analytischen Shapes in polygonale Strukturen erforderlich. VRS ist ein Echtzeit- Renderingsystem, das nach einem bestimmten Konzept und unter Verwendung verschiedener Algorithmen analytische Shapes für Renderingsysteme wie OpenGL oder POVRay so aufbereitet, dass sie durch diese dargestellt werden können. Keywords: analytische Shapes, Kugel, Torus, algebraische Fläche, Polygon, polygonale Shapes, VRS. 1 Einführung Das Virtual Rendering System (VRS) ist eine 3D Grafik Library. In VRS sind zur Zeit fünf Renderingsysteme integriert, die häufig in computergrafischen Systemen verwendet werden. Sowohl aus Sicht der Entwickler als auch die der Anwender sind die Anforderungen an so ein Echtzeit-Renderingsystem sehr hoch. Denn auf der einen Seite wächst mit dem technologischen Fortschritt im Hardware- und Softwarebereich der Anspruch der Konsumenten und auf der anderen Seite ist für den Programmierer ein ordentliches Konzept erforderlich, das den Wartungs- und Entwicklungsaufwand trotz der rapiden Weiterentwicklung von beispielsweise Grafikkarten auf ein Maß reduziert, das wirtschaftlich vertretbar ist. Diese Anforderungen wiederspiegeln sich im Quellcode insbesondere in der Klassenhierachie von VRS. So ist zum Beispiel in VRS die Deklaration analytischer Shapes deutlich von deren Umsetzung getrennt. 2 Analytische Shapes Der Begriff Shape ist aus dem englischen Wortschatz und bedeutet Form, Gestalt, Umriß. Shapes im Sinne der Computergrafik sind geometrische, grafische Objekte. Man unterscheidet dabei Analytische Shapes von den Polygonalen Shapes. 2.1 Definition Analytische Shapes sind mathematisch beschriebene Oberflächen. Sie werden durch ihre analytischen Parameter definiert, wie zum Beispiel eine Kugel durch ihren Mittelpunkt und Radius. Sie lassen sich entweder in expliziter Form definieren, also die Spezifikation einer Variablen durch die anderen wie in z = x+ y, in impliziter Form als Nullstellen einer Funktion zum Beispiel x + y + z 1= 0, oder in Parameterform, also für den d - dimensionalen Fall mit d Funktionen, die von ( d 1) Parametern abhängen, wie am Beispiel einer Kugeloberfläche x( uv, ) = cosucosv yuv (, ) = sinucosv zuv (, ) = sin v [ ] [ ] ( uv, ) 0,2 π π /2, π /2. Jede dieser Darstellungsformen hat ihre Vor- und Nachteile. Deshalb sind oft für die Bearbeitung eines Problems alle drei Formen erforderlich. Häufig muss dann die eine Form in die andere umgewandelt werden. Zum Beispiel eignet sich die Parameterform für die Berechnung von Vektoren beziehungsweise Punkten im d -dimensionalen Raum. Aber die mathematische Natur des Durchdringungsproblems ist sehr einfach, falls eine Fläche implizit und die andere in Parameterdarstellung gegeben ist. So lassen sich - 1 -

2 die Schnittfiguren alleine durch gegenseitiges Einsetzen der zwei Formen ermitteln. 2.2 Beispiele für Analytische Shapes Es gibt unendlich viele Beispiele für analytische Shapes, da es unendlich viele Möglichkeiten für die Komposition mathematischer Funktionen gibt. Bekannt sind vor allem die Kugel, der Torus, Zylinder, Kreiskegel und Bezierflächen Die Kugel Die Kugel ist ein spezieller Ellipsoid. Für Ellipsoide gilt folgende Gleichung: x y z a b c = Setzt man nun a= b= c= r, so ergibt sich eine Kugel mit dem Radius r. Neben Mittelpunkt und Radius gibt es noch die Möglichkeit, den Vervollständigungswinkel als Parameter zur Beschreibung der Kugel einzuführen. Dieser Winkel gibt an wie weit die Kugelhülle vervollständigt wird beziehungsweise wie gross eine Öffnung in der Kugelhülle ist. Beträgt der Winkel 360 ist die Kugelhülle vollständig also keine Öffnung vorhanden. Beträgt er 180 ergibt sich eine Halbkugel. R+ rcos( ϕ) f ( ϕ) = 0 r sin( ϕ), ϕ [ 0, 2π ]. Der Mittelpunkt dieses Kreises liegt demzufolge auf der x Achse und sein Abstand zum Ursprung ist R : Ο M = R, R r. Dieser Kreis werde um die z Achse gedreht, wodurch ein Ring mit kreisförmigen Querschnitt (Torus) entsteht. Der Torus ist gegeben durch die Funktion ( R+ rcos ϕ)cos( ϑ) g( ϕ, ϑ) = ( R+ rcos ϕ)sin( ϑ), ϕ, ϑ [ 0,2π]. r sin( ϕ) Abbildung 2. Torus Abbildung 1. Kugel dargestellt durch 762 Punkte und 800 Polygone Im Anhang finden sich Darstellungen der Kugel durch VRS, wobei ein Vervollständigungswinkel von 270 und 360 gewählt wurde (Abbildung 21). Neben den beiden Radien R, r und dem Mittelpunkt gibt es wie bei der Kugel einen Vervollständigungswinkel als weiteren Parameter. Er gibt an, wie weit in unserem Fall der in E xz befindliche Kreis, den wir am Anfang des Abschnitts beschrieben haben, um die z Achse gedreht wird. Im Anhang finden sich auch Darstellungen vom Torus durch VRS, wobei wie im Beispiel der Kugel ein Vervollständigungswinkel von 270 und 360 gewählt wurde (Abbildung 22) Der Torus In der x z Ebene Exz : y = 0 wird ein Kreis mit dem Radius r und dem Mittelpunkt M = ( R,0,0) durch folgende Vektorfunktion beschrieben:

3 Abbildung 3. Torus, dessen Vervollständigungswinkel kleiner als 360 ist Bézierdarstellung von parametrisierten Kurven und Flächen Seit 1958 finden Freiformflächen Anwendung im CAD-Bereich insbesondere im Automobil- Karosseriebau. Pierre Bézier (Renault) und P. de Casteljau (Citroen) entwickelten etwa zeitgleich jeweils eine Methode, die bei der Entwicklung von Autoformteilen eingesetzt wurde beziehungsweise heute noch eingesetzt wird. Die Bézierdarstellung ist eine parametrische Repräsentation auf der Basis von Bernstein-Polynomen Bézierflächen Bézierflächen sind durch folgende Funktion definiert: n m F ( u, v) P B ( u) B ( v) = B i, j i, n j, m i= 0 j= 0 Dabei sind Bin (, ) die Bernstein-Polynome und können als Formfunktionen aufgefasst werden. In Abbildung 4 ist ein Beispiel zwei miteinander gekoppelter Bézierflächen dargestellt. geschlossenen Polygon gesprochen. Ein einfaches Polygon liegt vor, wenn der Schnitt von jeweils zwei Kanten entweder die leere Menge oder ein Punkt P i ist und jeder Endpunkt einer Kante höchstens zu zwei Kanten des Polygons gehört (Abbildung 5). Ein ebenes geschlossenes und einfaches Polygon zerlegt die Ebene in mehrere Gebiete und zwar in mehrere innere und ein äusseres, das unbegrenzt ist. Abbildung 5. Ein einfaches, geschlossenes Polygon Polygone können konvex oder nicht-konvex (konkav) sein. Ein konvexes Polygon hat die Eigenschaft, dass zwei beliebige, innerhalb des Polygons gelegene Punkte mit einer Geraden verbunden werden können, die vollkommen innerhalb des Polygons verläuft (Abbildung 6). Nicht-konvexe Polygone können in konvexe Teilpolygone zerlegt werden. Viele geometrische Algorithmen, die auf Polygonen operieren, sind für eine effiziente Arbeitsweise auf Konvexität angewiesen. Abbildung 4. Zwei Bezierflächen, 12 und 16 Kontrollpunkte, dargestellt durch 2400 Kanten 3 Polygonale Strukturen 3.1 Polygone Allgemein nennen wir für eine Menge { P0, P1,..., P n} von Punkten im zwei- oder dreidimensionalen Raum die Menge Q= {( P0, P1),( P1, P2),...,( Pn 1, Pn) } ein Polygon [1]. Dabei sind die Paare von Punkten jeweils Kanten des Polygons. Liegen alle Kanten eines Polygons in einer Ebene, wird das Polygon planar genannt. Im Fall von Pn = P0 wird von einem Abbildung 6. Konvexes (links) und nichtkonvexes Polygon (rechts) Weitere Polygone mit besonderen Eigenschaften sind Polygone mit Loch und Polygone mit Selbstschnitt (Abbildung 7). Diese können genauso wie konkave Polygone von vielen Renderingsystemen nicht direkt verarbeitet werden, lassen sich aber immer in einfache Polygone zerlegen. Solche Formen, die für ihre Darstellung von Renderingsystemen gleich interpretiert werden können heißen Geometrische Primitive.

4 Abbildung 7. Polygon mit Loch (links) und Polygon mit Selbstschnitt (rechts) 3.2 OpenGL Primitive OpenGL Primitive sind Geomertische Primitive, welche von OpenGL direkt verarbeitet werden. Eine Übersicht aller OpenGL-Primitive liefert uns die zusammenfassende Darstellung in Abbildung 8. Die einfachste Form sind GL_POINTS. Es werden Punkte an den durch die Ecken spezifizierten Positionen gezeichnet. Bei GL_LINES beschreiben jeweils zwei aufeinanderfolgende Ecken eine Linie. Bei einem GL_LINE_STRIP werden die Punkte entsprechend ihrer Reihenfolge verbunden und bei einer GL_LINE_LOOP wird die Linienfolge dann am Ende geschlossen. Beim GL_POLYGON beschreiben die Ecken eine gefüllte Fläche. Desweiteren gibt es noch GL_QUADS. Jeweils vier aufeinanderfolgende Punkte bilden ein Viereck. Und bei dem GL_QUAD_STRIP bilden die Punkte eine Folge von Vierecken (A,B,C,D)(C,D,E,F)(E,F,G,H).... Das bedeutenste Primitiv sind GL_TRIANGLES. Jeweils drei aufeinanderfolgende Punkte bilden ein Dreieck. Dreiecke sind desshalb von großer Bedeutung, weil sie die einfachste Form unter den Polygon darstellen. Ein Polygon mit geringstmöglicher Anzahl von Ecken und Kanten ist das Dreieck. Ein Dreieck ist immer planar und liegt demzufolge immer in einer Ebene, da Ebenen schon mit drei nicht kollinearen Punkten beschrieben werden können ( Dreipunktegleichung ). Alle Polygone, die keine Dreiecke sind lassen sich in solche zerlegen. Beim GL_TRIANGLE_STRIP bilden die Punkte eine Folge von Dreiecken (1,2,3)(2,3,4)(3,4,5).... Schliesslich bleibt uns nur noch das GL_TRIANGLE_FAN. Die Punkte spannen einen Fächer auf und der erste Punkt bildet das Zentrum (1,2,3)(1,3,4)(1,4,5).... Die zwei zuletzt genannten Primitive sind im Grunde Dreiecksnetzte und werden im Abschnitt genauer beschrieben. 3.3 Polygonmodell Viele Objekte bestehen nur aus ebenen polygonalen Flächen. Auch gekrümmte Flächen lassen sich innerhalb eines annehmbaren Toleranzbereiches durch ein Netz von kleinen ebenen polygonalen Facetten darstellen. Um realistische Bilder von dreidimensionalen Objekten zu erzeugen, wobei versteckte Flächen nicht dargestellt werden und die Flächen in Abhängigkeit verschiedener Lichtquellen schattiert werden, sind Informationen über die Polygone erforderlich. Deshalb werden in den meisten Fällen Polygonmodelle verwendet. Zwei Typen von Informationen werden über das jeweilige Objekt Abbildung 8. OpenGL Geometrische Primitive.

5 gespeichert. Das sind die geometrische Information wie in Form von Punktkoordinaten und die topologische Information, welche beschreibt, wie die geometrischen Entitäten in Beziehung zueinander stehen, zum Beispiel, welche zwei Punkte miteinander verbunden sind. In Abbildung 9 sind diese Informationen am Beispiel des Hexaeders (Würfel) dargestellt. Index X Y Z Tabelle 1: Punktliste vom Hexaeder. Index Zahl d. Punkte Indizes d. Punkte Abbildung 9. Indexierung der Punkte vom Polygonmodell eines Hexaeders Diese Struktur ist grundlegend und das minimal Erforderliche für die polygonale Beschreibung von Objekten. Um das Objekt zu transformieren, genügt lediglich der Zugriff auf die Punktliste, es brauchen nur die Punktkoordinaten transformiert werden. Es verändern sich nicht die Verbindungen zwischen den Punkten bei Skalierung, Rotation oder Translation. Die Skalierung ist aber hier ein Sonderfall, weil sich zwar nicht die Verbindungen zwischen den Punkten des Objektes aber seine Geometrie verändert. Will man das Bild schattieren, wird die Polygonliste benötigt, da die in ihr enthaltenen Informationen es erlauben, jede Fläche einzeln zu zeichnen. Desweiteren wird die Polygonliste für die Berechnung der Flächennormalen verwendet. Das Modell kann man um zusätzliche Informationen erweitern, somit können zum Beispiel Farbeigenschaften oder Texturdaten gespeichert werden. Die geometrische Information wird durch eine Liste aller Punkte dargestellt, in der sowohl die den Punkten eindeutig zugeordneten Indizes als auch die Koordinaten der Punkte festgehalten werden (Tabelle 1). Die topologische Information liegt in Form einer Polygonliste vor, wo die nummerierten Polygone, Anzahl sowie Indizes der zum jeweiligen Polygon gehörenden Punkte erfasst werden (Tabelle 2) Tabelle 2: Polygonliste vom Hexaeder. Die Reihenfolge der Indizes von den Punkten, die zum jeweiligen Polygon gehören ist so gewählt, daß immer zwei aufeinanderfolgende Indizes zu zwei benachbarten Punkten des Polygons gehören und damit eine Kante des Polygons bilden. Bei geschlossenen Polygonen gehören der erste und letzte Index auch zweier benachbarter Punkte im Polygon an und bilden die abschließende Kante analog zu einer geschlossenen Vektorkette. 4 Polygonale Shapes Einige Renderer können verschiedene analytische Beschreibungen direkt verarbeiten, zumeist ist jedoch eine Umsetzung in einfache Grundobjekte wie Dreiecke erforderlich. Insbesondere verarbeiten Echtzeit-Renderingsysteme wie zum Beispiel OpenGL Analytische Shapes nicht direkt. Die Analytischen Shapes müssen auf Polygonale Shapes abgebildet werden, welche für Echtzeit- Renderingsysteme ausgelegt und optimiert sind zur Verarbeitung von polygonalen Strukturen insbesondere von Dreiecksstrukturen. 4.1 Definition Ein polygonales Shape ist eine stückweise-lineare Fläche in 3 Dimensionen, die durch eine Menge von Polygonen, meist Dreiecksflächen definiert ist. Gegenüber analytischen Shapes ist ihre Geometrie nur durch Eckeninformation beschrieben, nicht durch mathematische Funktionen. Sie stellen lediglich eine Ansammlung von Dreicksflächen dar.

6 4.2 Polygonale Netze Ein polygonales Netz wird auch als Mesh bezeichnet und ist ein polygonales Shape mit besonderen Eigenschaften. Eine Menge von geschlossenen, ebenen und einfachen Polygonen nennen wir polygonales Netz, sofern die folgenden Forderungen erfüllt sind: - Je zwei Polygone haben entweder keinen Punkt oder eine Ecke oder eine ganze Kante gemeinsam. Der Schnitt zwischen zwei verschiedenen Polygonen ist entweder leer, ein Eckpunkt eines Polygons oder eine Kante. - Jede Kante eines Polygons gehört zu einem oder höchstens zwei Polygonen. - Die Menge aller Kanten, die nur zu einem Polygon gehören, ist entweder leer oder bildet ein einziges, geschlossenes und einfaches Polygon reguläre, irreguläre Netze Ein Knoten beziehungsweise ein Punkt, welcher Kanten des polygonalen Netzes verbindet heißt regulär, falls die Anzahl der Kanten die er verbindet 4 oder 6 ist. Ein Netz oder ein Teil eines Netzes heisst regulär, wenn es nur reguläre Knoten enthält. Ein Netz heisst semi-regulär, wenn es aus regulären Teilnetzen besteht, die sich in möglicherweise irregulären Knoten treffen [2]. Der Vorteil von regulären Netzen besteht in der Einfachheit einer algorithmischen Indexierung seiner Knoten. Insbesondere für Vierecksnetze wird dazu noch ein Algorithmus vorgestellt Dreiecksnetze Das Dreieck ist aus verschiedenen Gründen die zentrale Form. Erstens ist bei einem Dreieck immer sicher, dass das Polygon planar ist, denn drei Punkte bestimmen eine Ebene und zweitens gibt es für die Speicherung von Dreiecksnetzen sehr effiziente Datenstrukturen. Das Verhältnis zwischen der Anzahl der Ecken und der Anzahl der Dreiecke bei sehr großen Dreiecksnetzen beträgt im Mittel 2. Um die Menge redundanter Informationen für die Definition von Dreiecksnetzen möglichst gering zu halten, gibt es verschiedene Ansätze. Optimal wäre es, für ein gegebenes Dreiecksnetz mit jedem übertragenen neuen Punkt ein neues Dreieck zu definieren. Eine Möglichkeit, dieser Forderung nahe zu kommen, bildet ein Triangle Strip. Beim Triangle Strip sowie beim Triangle Fan definieren n + 2 Eckpunkte n Dreiecke und das Verhältnis zwischen Eckpunkten und damit repräsentierten Dreiecken ist folglich ( n + 2)/2. Für große n kommt dieser Bruch der Optimalforderung eines Verhältnisses von 1 recht nahe. Die Folge (0,1,2,3,4,5) definiert ein Triangle Strip wie in Abbildung 10. Wenn die Nummerierung der Eckpunkte den Durchlaufsinn festlegt, dann alterniert der Durchlaufsinn in diesem Triangle Strip. Das Dreieck (0,1,2) wird gegen den Uhrzeigersinn durchlaufen, das darauf folgende mit dem Uhrzeigersinn und so weiter. Abbildung 10. Triangle Strip (links) und Triangle Fan (rechts) Vierecksnetze Vierecksnetze sind geeignet als Kontrollgitter für Freiformflächen. Sehr häufig stellt man derartige Flächen mithilfe von Vierecksnetzen dar (Abbildung 11). Vierecksnetze lassen sich verwenden für Shapes, die aus mindestens einer Fläche bestehen, deren Projektion in die Ebene ein Viereck ergibt, wie beispielsweise die Mantelfläche vom Zylinder. Abbildung 11. Bézierfläche dargestellt durch ein Vierecksnetz Es ist sehr einfach die Punkte aus dem Polygonmodell von Vierecksnetzen zu indexieren. Ein Quadrat, das in neun identische kleinere Quadrate unterteilt ist stellt ein quadratisches Gitter aus vier Zeilen und vier Spalten dar. Es enthält somit 16 Punkte und 9 Polygone. Wir nummerieren die Punkte jeweils von links nach recht, von oben nach unten durch. Der Punkt in der ersten Zeile und Spalte also der linke obere Eckpunkt trägt die Nummer 0, der rechte obere Eckpunkt hat die Nummer 3, der Punkt in der vierten Zeile und ersten Spalte also der linke untere Eckpunkt trägt die Nummer 12, der letzte Punkt unten recht hat die Nummer 15. Die Polygone des Gitters, die neun Quadrate werden nach dem selben Prinzip nummeriert. Das Quadrat oben links hat die Nummer 0, das oben rechts die Nummer 2, jenes unten links trägt die Nummer 6 und entsprechend hat das letzte Quadrat unten

7 recht die Nummer 8. Abbildung 12 zeigt eine solche Nummerierung am Beispiel des Gitters mit 30 Punkten und 20 Polygonen. Mit dem in Pseudo-Code formulierten Algorithmus werden zuerst die Punkte und anschliessend die Polygone des Gitters berechnet. 5 Realisierung analytischer und polygonaler Shapes in VRS Abbildung 12. Indexierung eines Vierecksnetzes Nun wird ein Algorithmus vorgestellt, der diese Indexierung eines Gitters von m Zeilen und n Spalten durchführt. Das Gitter von m Zeilen und n Spalten ist dann ein Vierecksnetz bestehend aus m n Punkten und ( m 1) ( n 1) Polygonen. Im folgenden Pseudo-Code benennen wir die Anzahl der Zeilen m mit rows und die Anzahl der Spalten n mit columns. procedure initpointsofmesh( rows, columns ) begin for each r { n N 0 n< rows} do for each c { n N 0 n < columns} do i c + r columns Pi ( λxc, λyr, λz f( c, r)) end end end Sollen die x und y Koordinaten aller Punkte P i des Gitters im Intervall [0,1] liegen, wählt man dementsprechend die Faktoren 1 λ x = columns 1 und 1 λ y = rows 1. rows columns ) begin procedure initpolygonsofmesh(, for each r { n N 0 n< rows 1} do c n N 0 n < columns 1 do for each { } end end end i c + r columns P0 Pi i c + r columns + 1 P1 Pi i c + ( r + 1) columns + 1 P2 Pi i c + ( r + 1) columns P3 Pi i c + r ( columns 1) Q ( P, P),( P, P ),( P, P),( P, P) i { } Shapes in VRS VRS implementiert Shapes auf die Art und Weise, wie wir sie bisher beschrieben haben, also gemäß ihrer Bedeutung und analog der Definition von Shapes. Shapes in VRS sind geometrische Objekte im zwei- und dreidimensionalen Raum. Und man unterscheidet polygonale von analytischen Objekten. In VRS gibt es die Klasse PolygonSet, welche von der Klasse Shape erbt. Die Klasse PolygonSet repräsentiert Polygonale Shapes. Genauso gibt es Analytische Shapes, die wie PolygonSet von der Klasse Shape erben. Dazu zählen zum Beispiel die Klasse Sphere und die Klasse Torus. Einen Überblick der Klassen in VRS, welche für die Realisierung von Shapes wichtig sind liefert uns Abbildung 17 im Anhang. Dort wird zum Beispiel ersichtlich, dass die Klasse Mesh eine Erweiterung der Klasse PolygonSet ist, was der Definition von Polygonalen Shapes und Netzen sehr nahe liegt. Im Grunde bildet sich also die Klassenhierarchie von VRS auf die Definition der als Klasse formulierten Strukturen ab. Eine wichtige Eigenschaft von VRS ist, dass Shapes nicht das Verfahren zu ihrer Umsetzung wie zum Beispiel graphisches Rendering definieren. Sie definiern also somit keine Attribute, die ihre Umsetzung gestalten wie beispielsweise Farbe oder Texturen. Shapes in VRS sind frei von Funktionalität, die zu ihrer Umsetzung in einem konkreten Renderingsystem oder Renderingverfahren benötigt wird. Ausserdem erfolgt durch VRS eine strikte Trennung zwischen Deklaration und Berechnung analytischer Shapes. So sind zum Beispiel in der Klasse Sphere hauptsächlich die analytischen Parameter wie Mittelpunkt und Radius implementiert. Demzufolge findet man dort unter anderem die Methoden setcenter(..) und setradius(..). 5.2 Aufbau von VRS Der Kern von VRS besteht im Großen und Ganzen aus einer Sammlung von allgemein einsetzbaren Renderingkomponenten. Dabei unterscheiden wir fünf Hauptkategorien (Abbildung 14): - Shapes (geometrische Objekte) - Attribute (grafische und nichtgrafische Modifikatoren wie Farbe, Textur, Material) - Handler (Auswertungsalgorithmen)

8 - Techniques (Auswertungsstrategien) - Engines (Auswertungsmaschienen) Besonders interessant bei VRS ist, dass es mehrere verschiedene Renderingsysteme integriert durch Implementierung entsprechender Adapter- Subsysteme für jedes Renderingsystem (Abbildung 15). Somit ist es möglich, beispielsweise eine Kugel unter Verwendung von OpenGL, aber auch POVRay darzustellen. Dieses Adapter-Subsystem umfasst alle Painter- und Engine-Klassen, die zur Umsetzung insbesondere zum Zeichnen von Shapes für das konkrete Renderingsystem benötigt werden Handler Handler sind Auswertungsalgorithmen für Shapes. Sie werden in Kategorien eingeteilt. Eine solche Kategorie heißt Service in VRS. Objekte, auf denen ein Handler operieren kann heißen entsprechend Targets. Diese Targets können auch Shapes sein. Handler befassen sich also jeweils mit der Auswertung eines einzelnen Shapes. Sie können wärend der Programmausführung in die Engine installiert beziehungsweise deinstalliert werden. Und die Funktionalität einer Engine ist durch die in ihr installierten Handler festgelegt Engine Die Engine ist eine Auswertungsmaschiene, welche auf Grundlage einer Auswertungsstrategie Renderingkomponenten für Renderingsysteme auswertet. Die Engine verfügt über Handler eines speziellen Service für bestimmte Targets. Sie stellt einen generischen Kontext zur Verwaltung von Attributen, Handlern und Techniques bereit Generischer Kontext Der Generische Kontext verwaltet Handler in einer Handler-Tabelle, in welcher für einen bestimmten Service und ein bestimmtes Target der entsprechende Handler eingetragen ist. Diese Tabelle ist eine Hashtable, in der man über einen Schlüssel nämlich der Service-Id auf Werte zugreift, die wieder in Form einer Hashtable vorliegen. In dieser zweiten Hashtable erhält man dann über die Target-Id Werte, welche jeweils einem Handler-Stack entsprechen (Abbildung 13). Das oberste Element vom Stack ist der momentan aktive Handler des gewünschten Services für das gewünschte Target. Kurz gesagt besteht jede Tabellenzelle aus einem Stack von Handlern, dessen oberstes Element der aktive Handler ist. Die Handler-Tabelle wird dynamisch zur Laufzeit aufgebaut. Durch Installation beziehungsweise Deinstallation von Handlern ändert sich der Zustand des generischen Kontexts. Der Generische Kontext verwaltet aber nicht nur Handler sondern auch Attribute unter Verwendung von Attributstacks. Attribute können ebenfalls zur Laufzeit hinzugefügt und entfernt werden, wodurch sich wieder der Zustand des Generischen Kontexts ändert (Abbildung 16). Abbildung 14. Klassenmodell der Hauptkategorien von Renderingkomponenten.

9 verantwortlich für die Zerlegung der Shapes in eine Sammlung einfacher Shapes wie zum Beispiel Dreiecke. Sie ermöglichen, dass die Renderingsysteme Shapes verarbeiten, für die sie selbst keine eigenen Handler bereitstellen. Simplifier sind unabhängig von den speziellen Renderingsystemen und nicht im jeweiligen Adapter-Subsystemen enthalten. Für alle Analytischen Shapes sind Simplifikations-Handler in der Handler-Tabelle eingetragen. Abbildung 13. Datenstruktur der Handler- Tabelle des Generischen Kontexts 5.3 Aufbereiten der Renderingobjekte Die Renderingobjekte insbesondere die Shapes müssen für verschiedene Renderingsysteme unterschiedlich aufbereitet werden. Die Shapes sind grundsätzlich auf jedes konkrete Renderingsystem abbildbar, sofern die dazu benötigten Handler existieren und in der Engine installiert wurden. Die Handler für Shapes können spezifisch für jede Engine zur Laufzeit durch Installation und Deinstallation konfiguriert werden Handler des Service Simplifikation Die Handler des Service Simplifikation heißen Simplifier. Sie berechnen für das gegebene Shape eine vereinfachte Darstellung auf Basis von weniger komplexen Shapes. Und zwar wandeln die Simplifier Analytische Shapes in eine Polygonale Repräsentationen um. Simplifier sind also Handler des Service Paint Handler des Service Paint werden in VRS auch Painter genannt und sind im Gegensatz zu den Simplifiern stets für das jeweilige spezielle Renderingsystem geschrieben. Shape-Painter sind spezielle Handler, die für das Zeichnen eines Shapes mit Hilfe eines konkreten Renderingsystems verantwortlich sind. Wird zum Beispiel für die OpenGL-Engine versucht, ein Shape vom Typ Sphere zu zeichnen, dann wird zunächst der Simplifikationsservice aufgerufen, um eine polygonale Repräsentation herzuleiten. Und für diese polygonale Repräsentation, das heißt für ein PolygonSet existiert in der OpenGL-Engine ein Painter. Die Sphere kann nun gezeichnet werden Konkreter Ablauf des Aufbereiten von Renderingobjekten am Beispiel der Kugel Den genaueren Ablauf des Aufbereiten von Renderingobjekten in VRS erkennt man an bestimmten Stellen im Sourcecode. Dazu zählen Abbildung 15. Integration der Renderingsysteme in VRS

10 insbesondere die Methode eval(..) der Engine- Klasse und die Methode simplify(..) der jeweiligen Simplifier-Klasse. Der Simplifier einer Kugel entspricht der Klasse SphereSimplifier. Im Anhang finden wir dazu in Abbildung 18 ein Sequenzdiagramm, das den Ablauf des Aufbereitens von Renderingobjekten am konkreten Beispiel der Kugel illustriert. Entsprechen ist in Abbildung 19 der relevanten Ausschnitt vom Sourcecode der Methode eval(..) aus der Engine- Klasse dargestellt. Und in Abbildung 20 finden wir dazu den relevanten Auschnitt vom Sourcecode der in Klasse SphereSimplifier befindlichen Methode simplify(..). Die für das Verständniss des Ablaufs besonders wichtigen Methodenaufrufe sind rot gekennzeichnet. Wie veläuft nun das Aufbereiten der Kugel, dass diese schliesslich gezeichnet werden kann? Die Anfrage der Evaluierung eines Shapes erfolgt durch den Aufruf der Methode eval(..). Dabei wird das zu evaluierende Shape, in unserem Fall die Kugel, der Engine übergeben. In der Methode eval(..) wird wird dann ermittelt, um was für ein Typ es sich bei dem gegebenen Shape handelt. Dies erfolgt durch ein sogenanntes ClassInfo Objekt, welches in unserem Fall eine SPHERE_ID liefert. Anschliessend prüft die Engine, ob für Shapes vom Typ Sphere ein Painter existiert. Dies ist leider nicht der Fall, ein Shape-Painter für Kugeln ist also nicht vorhanden. Demzufolge sucht die Engine einen Simplifier für die Kugel. Ein Simplifier für die Kugel ist auch vorhanden, nämlich der SphereSimplifier. Daraufhin wird bei dem gefundenen Simplifier die Methode simplify(..) aufgerufen und ihm dabei auch die Engine übergeben. Um zu sehen, was nun innerhalb der Methode simplify() des SphereSimplifiers passiert, schauen wir uns die Abbildung 20 im Anhang genauer an. Es wird ein Mesh durch die Methode createmesh(..) erzeugt. Diese Methode ist eine interne Methode zur Generierung von Eckeninformationen, sie erstellt basierend auf einem Algorithmus Punktdaten. Dann wird unsere Kugel durch Matrizenmultiplikation auf die durch den Radius gegebene Größe skaliert und nach der durch den Mittelpunkt festgelegten Position transformiert. Die zwei eben genannten affinen Abbildungen werden anschliessend auf einen Stack gespeichert. Und dann erfolgt wieder der Aufruf der Methode eval(..) bevor letztlich beide Elemente vom Stack entfernt werden. Doch diesmal wird beim Aufruf der Methode eval(..) das erzeugte Mesh übergeben. Wir erkennen also, dass die Methode eval(..) indirekt auf rekursive Weise aufgerufen wird und dabei jeweils unterschiedliche Shapes übergeben VRS-Engine Push/pop install/deinstall eval Attribut Objekt 1 Handler Objekt 1 Shape Objekt Attribute Attribut Objekt 2 Handler Objekt 2 Attributkategorie Attributverwaltung Attribut Objekt 3 Handler Objekt 3 Service Target Attribut Objekt n Handler Objekt n Handler-Tabelle Generischer Kontext Abbildung 16. Aufbau der Engine von VRS

11 werden, nämlich zuerst das Analytische Shape Sphere und dann das Polygonale Netz. Nun schauen wir uns nochmal die Methode eval(..) in der Engine-Klasse an. Es wird zuerst wieder geprüft um was für ein Shape es sich handelt, das ClassInfo Objekt liefert eine MESH_ID. Dann sucht die Engine nach einem Shape-Painter für das Mesh. Da kein Handler vom Service Paint für das Mesh existiert, wird ein Simplifier gesucht. Aber für das Mesh ist auch kein Simplifier vorhanden. In diesem Fall, wenn weder Painter noch Simplifier existieren, wiederholt sich die Suche für die jeweilige Superklasse des zu zeichnenden Shapes. Es wird demzufolge von der Engine geprüft um was für ein Typ es sich handelt, von dem das Shape abgeleitet ist. Aus dem in Abbildung 17 dargestellten Klassendiagramm geht hervor, dass die Klasse Mesh von der Klasse PolygonSet erbt. Dementsprechend liefert das ClassInfo Objekt diesmal eine PolygonSet_ID. Für das PolygonSet findet die Engine schliesslich einen Painter, den PolygonSetPainterGL und beauftragt diesen, die Kugel zu rendern. 6 Schlussfolgerungen Der Leser erkennt wahrscheinlich leicht, dass einem bereits vorhandenen mathematischen Fundament der große Implementierungsaufwand gegenübersteht. Es reicht nicht Algorithmen als solche umsetzten zu können. Vielmehr erfordert ein Echtzeit-Renderingsystem sowie andere computergrafische Systeme ein qualitatives ordentliches Konzept, das es erlaubt trotz der Weiterentwicklung von Grafikkarten, immer den aktuellen Anforderungen bezüglich der Umsetzung geometrischer Objekte gerecht zu werden. Das ist in der Computergrafik besonders wichtig, da sie teilweise hardwarenahe Programmierung einschliesst. VRS ist ein solches Echtzeit- Renderingsystem, es wird sogar in größeren Projekten wie zum Beispiel die Software für Visualisierung geografischer Daten eingesetzt. Literatur [1] Michael Bender, Manfred Brill. Computergrafik. Ein anwendungsorientiertes Lehrbuch. [2] Marc Alexa, Diskrete Geometrische Modellierung. TU Darmstadt. Slides, Anhang Abbildung 17. Diagramm wichtiger Klassen von VRS.

12 Abbildung 18. Ablauf des Aufbereiten von Renderingobjekten am Beispiel der Kugel

13 void Shader::eval(Engine* E, const MonoAttribute*, const Shape* S, unsigned int) { VRS_Assertion(E, "no engine"); VRS_Assertion(S, "no shape"); // process the shape... for(const ClassInfo* info = S->classInfoVRS(); info; info = info->parent()) { const ID& name = info->name(); // if there's a painter, try to paint the shape and exit if(shapepainter* const shapepainter = VRS_Cast(ShapePainter, E->painter(name))) { if(shapepainter->render(e, S)) { return; } } } // look for a simplifier if(shapesimplifier* const shapesimplifier = VRS_Cast(ShapeSimplifier, E->simplifier(name))) { if(shapesimplifier->simplify(e, S)) { return; } } } // no painter and no simplifier found VRS_Warning(false, "does not know how to render " << S->classNameVRS() << " objects"); Abbildung 19. Ausschnitt aus dem Sourcecode der Klasse Shader bool SphereSimplifier::simplify(Engine* E, const Shape* S) { VRS_Assertion(E, "no engine"); const Sphere* sphere = VRS_GuardedCast(const Sphere, S); Tessellation* tes = VRS_GuardedGetMonoAttribute(Tessellation, E); int nx, ny; tes->evaluate(e, S, nx, ny); nx += 3; ny += 3; SphereGenerator* generator = new SphereGenerator(sphere, nx, ny); SO<Mesh> mesh = ShapeSimplifier::createMesh(E, generator); delete generator; Vector c = sphere->getcenter(); double r = sphere->getradius(); Matrix tf(r, 0, 0, c[0], 0, r, 0, c[1], 0, 0, r, c[2], 0, 0, 0, 1 ); E->pushTf(); E->multTf(tf); E->eval(mesh); E->popTf(); } return true; Abbildung 20. Ausschnitt aus der Klasse SphereSimplifier

14 Abbildung 21. Darstellung einer Kugel durch VRS, deren Vervollständigungswinkel 360 beträgt (links) und deren Vervollständigungswinkel kleiner als 360 ist (rechts). Abbildung 22. Darstellung eines Torus durch VRS, dessen Vervollständigungswinkel 360 beträgt (links) und dessen Vervollständigungswinkel kleiner als 360 ist (rechts).