Würfelsimulator

PDA-Programmieren • "Würfelsimulator" • SS10 • Simon Brennecke • Ivo Torp • Klaus Manneck 

Würfelsimulator 

PDA-Programmierung 

Ausarbeitung 

von 

Ivo Torp 

Klaus Manneck 

Simon Brennecke 

im 

SS2010 

Seite 1 / 37


Inhaltsverzeichnis 

Übersicht............................................................3 

Hintergrund........................................................3 

Problemstellung.................................................4 

Ist-Analyse.........................................................4 

Zielsetzung.........................................................4 

Technologien......................................................5 

Vorüberlegungen................................................5 

Dice-Framework...........................................5 

3d-Engine......................................................5 

Physik............................................................6 

Bewegung.................................................6 

Kollisionserkennung.................................7 

Kollisionsbehandlung...............................7 

Umsetzung.........................................................8 

Analyse der Zielplattform PDA....................8 

Testgerät...................................................8 

Hardware..................................................8 

Software....................................................8 

Software-Architektur.....................................9 

Aufbau......................................................9 

Datenstrukturen......................................10 

Programmablauf.....................................10 

Verfahren.....................................................11 

Generierung der Würfelkoordinaten.......11 

Dice8 .................................................11 

Dice20................................................11 

Dice12................................................11 

Sonderfall Dice10..............................12 

Generierung der Drahtgittermodelle.......13 

Generierung der Texturen.......................14 

Funktionsweise des Composition-Caches 

................................................................15 

Funktionsweise der Physik-Engine........16 

Programmablauf................................19 

Bewegung..........................................20 

Kollisionserkennung..........................21 

Kollisionsbehandlung........................24 

Funktionsweise der 3d-Engine...............27 

Initialisierung.....................................27 

Vertexbuffer.......................................29 

Rendern..............................................30 

Schnittstellen....................................................31 

Modulbeschreibungen.................................31 

GUI.........................................................31 

libDice....................................................31 

libPhysics................................................31 

libDXRender..........................................31 

Klassendiagramme......................................32 

libDice....................................................32 

libPhysics................................................33 

libDXRender..........................................34 

Screenshots......................................................35 

Echte Würfel? - Eine Statistik..........................36 

Zukunft.............................................................37 

Referenzen.......................................................37 

Seite 2 / 37


Übersicht 

Projektname: Würfelsimulator 

Fach: 

PDA-Programmierung 

Professor: 

Herr Prof. Dr. Zimmermann 

Programmiersprache: C# 

Zielplattform: PDA und PC 

Code-/Spitzname: Dice! 

Hintergrund 

Hintergrund ist das "Pen&Paper-Rollenspiel", für das viele verschiedene Arten von Würfel benötigt 

werden. Viele Menschen kennen nur den 6-seitigen Würfel. Im Umfeld des Pen&Paper-Rollenspiels 

existieren aber verschiedenste Arten von Würfeln. Ein verbreitetes Regelwerk 

"Dungeons&Dragons" setzt zum Beispiel auf 4-, 6-, 8-, 10-, 12- und 20-seitige Würfel. Zum 

Mitspielen benötigt jeder Spieler einige, oder nicht selten auch viele dieser Würfel. 

Bildquelle: Wikipedia ( http://de.wikipedia.org/wiki/Spielwürfel ) 

Seite 3 / 37

Problemstellung 


Nun kann man diese Würfel natürlich käuflich erwerben, was Geld und Zeit kostet. Hier ergibt sich 

aber schon das erste Problem: Der 6-seitige Würfel ist verbreitet und praktisch in jedem 

Spielwarengeschäft erhältlich. Ein 20-, oder 4-seitiger Würfel wiederum ist praktisch nicht 

erhältlich. Spezialisierte Online-Shops bieten diese Würfel zu gehobenen Preisen an. 

Ein zweites Problem ist, das man nicht selten vergisst die Würfel einzupacken und mitzubringen. 

Ist-Analyse 

Letzteres kommt leider nicht selten vor. Aus diesem Grund existieren bereits viele 

"Würfelgeneratoren". Diese simulieren aber keine Würfel, sondern zeigen lediglich auf Knopfdruck 

eine neue Zufallszahl, skaliert auf die Größe des Würfels, an. Dies ist zwar funktional und in der 

Regel ausreichend, aber vernichtend für den Spielspaß am Rollenspiel. Man möchte ja sehen wie 

die Würfel fallen. 

Zielsetzung 

Aus diesen Gründen haben wir uns entschieden einen "Würfelsimulator" zu entwickeln. Dieser soll 

physikalisch korrekt und in 3d den Wurf eines Satzes von Würfeln simulieren, die Ergebnisse 

anzeigen und evt. beschränkte Auswertungen durchführen. 

Die Physik-Engine muss mindestens in der Lage sein, eine begrenzte Menge an Objekten 

realitätsnah zu bewegen, kollidieren und zur Ruhe kommen zu lassen. Dazu muss sie verschiedene 

physikalische Gesetze und Faktoren beachten: Gesetze der Mechanik und Kreisbewegung, 

Impulsübertragung und Stöße, Energieerhaltungssatz, Reibung, etc. 

Im Bestfall ist die Physik-Engine ein eigenständiges Modul, dass unabhängig von der restlichen 

Anwendung beliebige Objekte entgegennehmen und behandeln kann. Sie sollte möglichst alle 

bekannten physikalischen Faktoren mit einbeziehen und auch auf dem PDA ein flüssiges Ergebnis 

liefern. Da die Dice Anwendung nur Würfel simuliert (genau genommen gleichförmige, konvexe, 

starre Polyeder mit gleichverteilter Masse und ohne bewegliche Teile), wäre eine Erweiterung auf 

beliebige Objekte (z.B. verformbare, selbst bewegende oder aus Komponenten aufgebaute 

Gegenstände) zwar wünschenswert, um die Engine auch in anderen Projekten einsetzen zu können, 

aber im Rahmen dieses Projekts nicht unbedingt nötig. 

Seite 4 / 37

Technologien 


Zum Einsatz kamen folgende Technologien: 

• Microsoft Managed DirectX 

• Microsoft .net Compact Framework 3.5 

• Microsoft Visual Studio 2008 

• Subversion Codeverwaltung 

• Remote-Desktop 

• Virtuelle Maschinen 

Vorüberlegungen 

Dice-Framework 

Das Projekt wurde von Anfang an groß angelegt. Selbst nachdem aus Zeitgründen schon große 

Abstriche an der Kern-Funktionalität gemacht wurden, blieben etliche teilweise sehr 

unterschiedliche Funktionen übrig. Auch war von Anfang an klar, das die fehlenden Funktionen 

irgendwann einmal nachgetragen werden. Es wurde schnell klar, das ein eigenes Framework 

notwendig sein wird um alle Funktionen unter ein Dach zu bekommen und einfach zugänglich zu 

machen. 

3d-Engine 

Probleme gab es mit der 3D Leistung des Pocket Devices. Wie sich nach langer Recherche 

herausgestellt hat, war auf dem Gerät nur ein Software-Renderer-Treiber installiert. Dieser hat alle 

3D Berechnungen selbst über die CPU berechnet, anstatt die vorhandene Hardware-Beschleunigung 

zu verwenden. Da kein offizieller Treiber für diese Windows Mobile Version existiert (6.0), musste 

das Betriebssystem des PDA auf Windows Mobile 6.1 aktualisiert werden – um dann den einzigen 

(inoffiziellen) Direct3D Treiber installieren zu können. 

Seite 5 / 37

Physik 


Die Physik-Engine war der erste Teil des Dice Projekts, der bereits rudimentär existierte, als das 

Projekt begonnen wurde. Die ursprüngliche Idee war es, eine eigene physikalische Grundlage für 

weitergehende Projekte zu schaffen, wie z.B. die Programmierung eines Computerspiels mit 

realistischen Bewegungen. Die Entwicklung einer Starrkörpersimulation, um Würfel fallen zu 

lassen, war der erste Schritt zu dieser Idee. 

Begonnen wurde die Entwicklung in einem C# Testprogramm, das nur eine sehr grundlegende 

Darstellung der simulierten Objekte ermöglichte, nämlich ein parallel projiziertes 

Drahtgittermodell. Das Programm war dafür gedacht, eine Umgebung zu bieten, in der die 

Implementierung der Physik möglichst simpel und unabhängig von anderen Anwendungen 

erarbeitet werden konnte. Als die Physik-Engine mit dem restlichen Dice-Projekt verbunden werden 

sollte, wurde der Code noch einmal komplett neu geschrieben, um eine einheitliche Struktur 

umzusetzen, die Programmiersprache C# jedoch beibehalten, da auch die restlichen Teile des 

Projekts darin geschrieben wurden. 

Die Engine hat im Wesentlichen drei Aufgaben zu bewältigen: die realitätsgetreue Bewegung von 

Objekten, die Erkennung von Kollisionen zwischen diesen Objekten und die physikalisch korrekte 

Reaktion auf die gefundenen Kollisionen. 

Bewegung 

Die erste Aufgabe ist zugleich auch die einfachste. Die Bewegung befolgt einfache Gesetze der 

Mechanik, wie sie in allen gängigen Formelsammlungen zu finden sind. Da eine Bewegung im 

dreidimensionalen Raum stattfindet, sind alle beteiligten Größen vektoriell zu sehen. Die nötigen 

Grundgrößen zur Berechnung der Translation sind Beschleunigung (z.B. durch Gravitation), deren 

erste Ableitung Geschwindigkeit und als zweite Ableitung die zurückgelegte Strecke. Äquivalent 

dazu finden sich zur Berechnung der Rotation die Winkelbeschleunigung, Winkelgeschwindigkeit 

(Vektoren, deren Richtung die Achse der Drehung angibt, während die Länge die 

Drehgeschwindigkeit festlegt), sowie die Orientierung, die im Gegensatz zu den anderen 

v= v 0 

a⋅t 

s= s 0 

v⋅t 1 2 a⋅t 2 

Vektorgrößen als Matrix angegeben wird, da sie als 

Transformation auf die Koordinaten des Objekts 

angewendet wird. Die Strecke wäre im Prinzip auch 

als Transformationsmatrix darzustellen, doch da eine 

= 0 

⋅t 

= 0 

⋅t 1 2 ⋅t 2 

reine Translationsmatrix nur in einer einzigen Spalte tatsächlich Werte enthält, kann sie zu einem 

Vektor vereinfacht werden. 

Seite 6 / 37

Kollisionserkennung 


Die zweite Aufgabe erforderte einige Recherche und Überlegung. Das Testprogramm besaß nur eine 

sehr rudimentäre Kollisionserkennung, die noch keine Kollisionen zwischen verschiedenen, sich 

bewegenden Objekten registrieren konnte. Überprüft wurde lediglich, ob sich eine der Koordinaten 

der Eckpunkte eines Objekts über oder unter einem bestimmten Schwellwert (den Ausmaßen des 

Bildschirms bzw. Fensters) befand. Diese Art der Kollisionserkennung war jedoch alles andere als 

ausreichend. Um eine Kollision zwischen zwei konvexen Objekten festzustellen, müsste prinzipiell 

jeder Punkt eines Objekts gegen jede begrenzende Fläche (bzw. Ebene) des anderen Objekts geprüft 

werden. Falls sich ein Punkt von jeder Ebene aus gesehen auf der Innenseite befindet, liegt er 

zweifelsfrei innerhalb des Objekts. Diese Art der Kollisionsbestimmung erfordert jedoch gerade bei 

vielen, vieleckigen oder vielflächigen Objekten einen großen Aufwand, der sich exponentiell 

erhöht. Um dieses Problem zu vermeiden wurden verschiedene gängige Verfahren in Augenschein 

genommen, z.B. das sogenannte Voronoi-Clipping. Keines dieser Verfahren hat sich jedoch als 

brauchbar erwiesen, da entweder der Aufwand unverhältnismäßig hoch für den PDA, die 

Ergebnisse zu ungenau bzw. zu fehleranfällig waren oder das Verfahren nicht alle Daten liefern 

konnte, die die Physik für ihre Berechnungen benötigt. Daher wurde letztendlich ein eigenes 

Verfahren entwickelt, das für relativ gleichmäßige, konvexe Polyeder eine möglichst genaue 

Annäherung bei möglichst geringem Aufwand bieten soll (s. Umsetzung). 

Kollisionsbehandlung 

Die dritte Aufgabe wurde bereits im Testprogramm grundsätzlich gelöst. Zur Behandlung der 

Kollisionen wird der Impulserhaltungssatz herangezogen. Durch Umformen der Gleichung und 

Einsetzen der bereits bekannten Werte (Geschwindigkeit, Rotation, Kollisionspunkt), sowie 

Hinzunehmen von weiteren Parametern (Masse, Trägheitsmoment, Elastizität), kann ein gerichteter 

Impuls errechnet werden, der auf die kollidierenden Objekte angewandt wird, um sie wieder 

auseinander zu bewegen. Der Bias-Faktor (von engl. bias – Verzerrung), eine in der Natur nicht 

vorkommende Größe, wurde ebenfalls hinzugefügt, um Ungenauigkeiten auszugleichen, die 

aufgrund der beschränkten Rechenleistung zwangsläufig bei der Kollisionserkennung auftreten. Die 

meisten Bestandteile dieser Formeln wurden dem „Physics“ Artikel von Chris Hecker im Game 

Developer Magazine von März 1997 sowie dem Rigid Body Physics Tutorial auf www.xbdev.net 

entnommen. 

r= v A 

A 

× P A 

− v B 

B 

× P B 

 

 

j=n⋅ 

1 m A 

1 m B 

 

−1e⋅r⋅n 

 

P 2 

A 

×n 

I A 

 

P B 

×n 

I B 

2 

 

v A 

= v A 

j 

P 

; 

m A 

= A 

A 

×j 

A I A 

v B 

= v B 

− j 

P 

; 

m B 

= B 

− B 

×j 

B 

I B 

Seite 7 / 37


Umsetzung 

Analyse der Zielplattform PDA 

Testgerät 

Hersteller: 

HTC 

Modell: 

Kaiser TyTN II 

Prozessor: 

QUALCOMM(R) 7200 @ 400MHz 

Arbeitsspeicher: 

128 MiB 

Flash-Speicher: 

256 MiB 

Auflösung: 

240x320 Pixel 

3d-Beschleunigung: vorhanden 

Hardware 

Dia PDA-Hardware unterliegt im wesentlichen zwei Bedingungen: Sie muss klein sein und wenig 

Energie verbrauchen. 

Daraus resultieren verschiedene Einschränkungen. Einige hiervon sind: 

• Eingeschränkte Bildschirmgröße 

• Verhältnismäßig geringe Rechenleistung 

• Langsame Massenspeicher 

• Wenig Arbeitsspeicher 

• Eingeschränkte Eingabegeräte 

Software 

Aus den Einschränkungen der Hardware resultieren entsprechende Einschränkungen der Software. 

Das notwendigerweise zu verwendende .net Compact Framework 3.5 besitzt gerade im Multimedia- 

Bereich stark reduzierte Funktionalität im Verhältnis zur PC-Version: 

• Reduzierte Funktionalität der Bitmap-Klasse 

◦ Keine Möglichkeit zum direkten Zugriff auf den Pixel-Puffer 

◦ Dadurch auf GetPixel/SetPixel limitiert 

• Reduzierte Funktionalität der Graphics-Klasse 

◦ Gedreht Schrift zeichnen ist nicht möglich 

• Unpräzise Timer 

Seite 8 / 37

Software-Architektur 


Aufbau 

Das Projekt wurde in vier Softwaremodule unterteilt: 

• Benutzeroberfläche 

• Dice-Framework 

• Physik-Engine 

• 3d-Engine 

Die 3d-Engine und die Physik-Engine sind dabei vollkommen unabhängig von dem Rest. Man 

könnte Sie also jederzeit für andere Projekte weiterverwenden. Die beiden Module greifen nur über 

Schnittstellen auf den gemeinsamen Datenspeicher im Dice-Framework zu: 

Physik 

Engine 

Direct3D 

Renderer 

Dice 

Framework 

Das Dice-Framework verwaltet diese Daten und stellt selbst die abstrakte Funktionalität "Würfel zu 

werfen" über Schnittstellen bereit. Dazu konfiguriert es die Physik- und 3d-Engine und steuert diese 

entsprechend an. Die Benutzeroberfläche nutzt die Schnittstellen des Dice-Frameworks um die 

Benutzereingaben auszuführen. Die Benutzeroberfläche ist der einzige Teil der Software, der sich 

wesentlich über die Plattformgrenzen hinweg verändert hat. Die PC-Fassung musste mit Platz nicht 

sparen und war daher für einen kleinen PDA-Bildschirm ungeeignet. Die PDA-Version wurde 

komplett neu gestaltet um den neuen Bedingungen gerecht zu werden. 

Seite 9 / 37

Datenstrukturen 


Das Dice-Framework kennt folgende Datenstrukturen, die die verschiedene Elemente der 

Würfelumgebung beschreiben: 

• Material - Beschreibt das Material aus dem ein Objekte besteht 

• Oberfläche - Beschreibt eine Oberfläche eines Objekts 

• Objekt - Beschreibt ein generisches Objekt 

• Würfel - Beschreibt einen Würfel, spezialisiertes Objekt 

• Wand - Beschreibt eine Wand der Welt, spezialisiertes Objekt 

• Welt - Beschreibt die Welt selbst 

Jede Datenstrukturen beschreibt das entsprechende Element sowohl physikalisch (Masse, 

Trägheit, ...), als auch optisch (Textur) und liefert somit die Grunddaten für Physik- und 3d-Engine. 

Programmablauf 

Zunächst erstellt die Benutzeroberfläche eine neue Instanz der Welt. Daraufhin erzeugt das Dice- 

Framework bereits ein Grundgerüst mit Boden, Wänden und Skybox. Dann werden von der 

Benutzeroberfläche weitere Objekte in die Welt hinzugefügt. Dabei spielt es eigentlich keine Rolle 

was die Objekte darstellen. Das Framework behandelt alle außer Wände und Würfel gleich. Wände, 

da diese die absolute äußere Limitierung der Welt angeben, und Würfel da diese für das Ergebnis 

relevant sind. Nachdem dann die Welt konfiguriert ist können die Würfel geworfen werden. Hierzu 

ruft die Benutzeroberfläche die entsprechende Funktion im Framework auf. Diese Funktion startet 

dann die Physik- und 3d-Engine und führt den Würfelvorgang Schritt- für Schritt aus. 

Seite 10 / 37

Verfahren 


Generierung der Würfelkoordinaten 

Die Koordinaten eines bestimmten Würfels zu finden ist nicht immer einfach. Bei einem Dice6 sind 

die Koordinaten noch einfach zu finden, doch wie findet man Koordinaten für einen Dice8 , oder 

einen Dice12 – bei dem jede Seite 5 Ecken hat? Zunächst muss man wissen, dass bei Spielwürfeln 

jede Seite gleich groß und gleich geformt ist, und alle Eckpunkte denselben Abstand zum 

Mittelpunkt (Schwerpunkt) des Würfels haben müssen. Dies wird im Folgenden anhand einfacher 

Darstellungen gezeigt: 

Dice8 

Zunächst wird ein Dice6 zur Hilfe genommen. Alle Eckpunkte des 

Dice8 liegen genau auf den Mittelpunkten der Flächen des Dice6. 

Dice20 

Es wird auf jeder Achse eine Fläche mit dem Seitenverhältnis 

1 zu 

(goldener Schnitt) erstellt. 

Dann lassen sich die gefundenen Punkte wie in der Abbildung gezeigt zu 

den Flächen verbinden. 

Dice12 

Hier werden die selben Hilfsflächen wie beim Dice20 verwendet – und 

zusätzlich ein Dice6 im Inneren. Hier werden immer 5 Punkte zu einer 

Fläche verbunden. 

Seite 11 / 37

Sonderfall Dice10 


Bisher wurde die Meshgenerierung für alle Würfel außer den Dice10 erklärt. Diese waren bisher 

regelmäßige Polyeder – das heißt sie besitzen gleichseitige und gleichmäßige Würfelflächen. 

Dies trifft beim Dice10 nicht zu. Die Flächen des Dice10 sind sogenannte Drachenvierecke, die 

natürlich nicht gleichseitig sind. 

Da bekannt ist, dass alle Punkte denselben Radius haben (auf der 

Einheitskugel liegen), lassen sich die Koordinaten näherungsweise 

ermitteln. 

Zunächst werden die Spitzen oben und unten gesetzt, und auf genau 

mittlerer Höhe (siehe Seitenansicht) zwei Fünfecke – wie in der Draufsicht 

zu sehen, genau versetzt, platziert. 

Um die genaue Verschiebung der Fünfecke nach oben und unten zu finden, 

müssen diese langsam nach oben bzw. unten auf der Einheitskugel verschoben werden. Bei jeder 

Verschiebung wird dabei per Kreuzprodukt geprüft, ob die 4 entsprechenden Punkte einer „Fläche“ 

tatsächlich auf einer Ebene liegen. Sobald dies (mit einer gewissen Toleranz) der Fall ist, wurde die 

korrekte Verschiebung gefunden. Die ermittelten Koordinaten wurden direkt in den Würfelsimulator 

übernommen. 

Seitenansicht 

Draufsicht 

Seite 12 / 37


Generierung der Drahtgittermodelle 

Die 3D-Modelle der Würfel (Meshes) werden zur Laufzeit generiert. Dies geschieht im Konstruktor 

der jeweiligen Dice-Klasse (z.B. Dice6 ). Dabei wird zunächst eine Liste der Eckpunkte erstellt. 

Vector3f[] vectors = new Vector3f[8]; 

vectors[0] = new Vector3f(-0.5f, -0.5f, -0.5f); 

vectors[1] = new Vector3f(+0.5f, -0.5f, -0.5f); 

vectors[2] = new Vector3f(+0.5f, +0.5f, -0.5f); 

vectors[3] = new Vector3f(-0.5f, +0.5f, -0.5f); 

vectors[4] = new Vector3f(-0.5f, -0.5f, +0.5f); 

vectors[5] = new Vector3f(+0.5f, -0.5f, +0.5f); 

vectors[6] = new Vector3f(+0.5f, +0.5f, +0.5f); 

vectors[7] = new Vector3f(-0.5f, +0.5f, +0.5f); 

for (int i = 0; i < vectors.Length; i++) 

vectors[i].Normalize(); 

Des Weiteren muss definiert werden, welche der Punkte zu einer Würfelseite gehören. Es wird pro 

Würfelart im Code festgelegt, wie viele Punkte eine Fläche bilden. Zu jedem Punkt einer jeden 

Fläche werden zusätzlich Texturkoordinaten hinzugefügt. Da (wie später noch erläutert) auf jeder 

Würfelseite eine eigene Textur mit jeweils einer Zahl verwendet wird, sind die Texturkoordinaten 

für jede Seite gleich. 

Für einen Dice6 sieht der Code, der die Eckpunkte, Flächen und Texturkoordinaten zusammenfasst, 

so aus: 

int[] vi = { 2, 3, 0, 1, 3, 2, 6, 7, 6, 2, 1, 5, 7, 4, 0, 3, 1, 0, 4, 5, 7, 6, 5, 4 }; 

float[] tv = { 1.0f, 0.0f, 0.0f, 1.0f }; 

float[] tu = { 1.0f, 1.0f, 0.0f, 0.0f }; 

int i=0; 

for (int i = 0; i < 6; i++){ 

Vertex3f[] vertices = new Vertex3f[4]; 

for (int v = 0; v < vertices.Length; v++) 

vertices[v] = new Vertex3f(vectors[vi[n++]], tv[v % 4], tu[v % 4]); 

// … generate Surface with vertices … 

} 

Analog dazu wird es für die anderen Würfel gehandhabt. Dabei muss eine Fläche nicht zwingend 

aus 4 Ecken zusammengesetzt werden – so haben der Dice8 und der Dice20 nur 3-eckige Flächen, 

und der Dice12 hat sogar 5-eckige. 

Seite 13 / 37

Generierung der Texturen 


Bisher wurde nur die Geometrie erstellt. Zwar wurden Texturkoordinaten gesetzt, doch fehlen nun 

noch die Texturen selbst. 

Für jede Würfelseite wird eine eigene Textur verwendet, welche beim Laden eines Würfels erstellt 

und auch in einem Cache abgelegt wird, damit diese nicht mehrfach generiert werden muss. 

Texturen werden aus mehreren Parametern zusammengesetzt: 

Die Grundfarbe, die Zahl, die Umrandungsform, und einer Oberflächenstruktur (aus einer PNG- 

Datei). 

1. Zunächst wird eine Bitmap im Speicher mit der Grundfarbe gefüllt. 

4 

4 

2. Die Zahl wird per Graphics Objekt mittig auf das Bitmap platziert. 

3. Der Rahmen wird (je nach Würfel) dazu gezeichnet. Dieser Beispielrahmen ist 

für einen Dice10 geeignet. 

4. Zum Schluß wird per Alphablending die Strukturtextur mit der bisherigen Textur 

„vermischt“. 

Bei Würfeln wie dem Dice10, Dice12 und Dice20 müssen einige Besonderheiten 

beachtet werden. 

So gibt es (als Spielwürfel) Dice10-Würfel, die anstelle von „1“ mit „0“ in der Zählung beginnen, 

und wahlweise in Einer- oder Zehnerschritten beschriftet sind. 

Des Weiteren müssen bei jedem dieser Würfel an den Ziffern 6 und 9 eine Markierung angebracht 

werden, damit diese unterschieden werden können. Dies wurde im Würfelsimulator mit Hilfe eines 

Punktes rechts unten an der Ziffer erreicht. 

Seite 14 / 37


Funktionsweise des Composition-Caches 

Natürlich kann das ganze Framework nicht ohne ein paar Hilfs-Funktionen und Hilfs-Klassen 

leben. Eine wichtige davon ist der "CompositionCache". Um seine Aufgabe verstehen zu können, 

ist es zunächst einmal wichtig zu verstehen, wie Würfel überhaupt erstellt werden. 

Der Konstruktor unseres Referenzwürfels (d6) sieht folgendermaßen aus: 

public Dice6(World World, Material Material, float Scale, FontFamily 

FontFamily, Color ForeColor); 

Der Konstruktor benötigt also Informationen wie: 

• Die Welt in dem der Würfel erzeugt werden soll 

• Das Material aus dem er bestehen soll 

• Seine Skalierung 

• Die Schriftart der Zahlen 

• Die Schriftfarbe der Zahlen 

Erkennbar wird, dass der Würfel erst zur Laufzeit aus kleinen Bauteilen zusammengesetzt wird. 

Dies kostet Rechenleistung, die auf einem PDA nur in beschränkter Menge zur Verfügung steht. 

Wenn man nun bedenkt das man oft mit vielen gleichen Würfeln würfelt, würde es doch Sinn 

machen, das Grundgerüst des Würfels zwischenzuspeichern, um danach schneller Kopien eines 

Würfels erzeugen zu können. 

Genau das übernimmt der "CompositionCache". Er speichert Rechenintensive Vorgänge wie die 

Texturgenerierung (GetPixel, SetPixel) zwischen und stellt Sie Würfeln, die die selbe Textur 

benötigen zur Verfügung. 

Warum Texturgenerierung zur Laufzeit? 

• Verschiedene Materialien (Metall, Stein, Plastik, Holz, etc....) 

• Verschiedene Farben für das selbe Material 

• Zahlen oder Punkte auf den Seiten der Würfel 

• Verschiedene Farben und Schriftarten für die Beschriftung der Würfel 

Seite 15 / 37


Funktionsweise der Physik-Engine 

Die Physik-Engine ist als eigenständige Bibliothek in der libPhysics implementiert. Die einzigen 

Abhängigkeiten ergeben sich von DirectX durch die Nutzung der Vector3 und Matrix Klassen. Die 

Kommunikation mit den anderen Programmteilen erfolgt über drei Interfaces, die die grundsätzliche 

Objektstruktur darstellen. 

IObject stellt einen einzelnen, abgeschlossenen Starrkörper dar. Es enthält alle Werte, die für die 

Physik wichtig sind: 

• Position, Velocity und TransAcceleration für die geradlinige Bewegung 

• Orientation, Rotation und RotAccaleration für die Drehbewegung 

• Mass und Inertia zur Berechnung von Kräften und Impulsen 

• Corners und Faces, die den geometrischen Aufbau des Objekts beschreiben 

• OrientedCorners und Radius, Hilfsvariablen für den schnellen Zugriff auf geometrische 

Eigenschaften des Objekts 

• Resting, das gesetzt wird, sobald ein Objekt sich nicht mehr (relevant) bewegt 

ISurface beschreibt eine Seitenfläche eines Objekts und enthält folgende Daten: 

• das Object, zu dem die Fläche gehört, und das Material, aus dem sie besteht 

• Corners und Normal, die die räumliche Lage der Fläche relativ zu ihrem Objekt beschreiben 

• OrientedCorners und OrientedNormal, Hilfsvariablen für den schnellen Zugriff auf die 

räumliche Lage 

IMaterial enthält alle Oberflächeneigenschaften, die für die Kollisionsbehandlung benötigt werden: 

• Restitution für die Elastizität bei Stößen 

• StaticFriction und KineticFriction, die (approximierten) Reibungskoeffizienten 

Seite 16 / 37


Die tatsächliche Funktionalität der Physik wird vom Environment zur Verfügung gestellt. Diese 

Klasse enthält globale Parameter, die die Umgebung beschreiben, in der die Simulation abläuft: 

• Objects, Walls und Collisions, Listen von Objekten, die simuliert werden, Ebenen, die als 

räumliche Begrenzung der Simulation fungieren, bzw. festgestellten Kollisionen, die intern 

bis zur Behandlung gespeichert werden. 

• Gravity als allgemeine Beschleunigung, die auf alle Objekte angewendet wird. Über diese 

Beschleunigung kann auch ein stetiger Wind oder ähnliches dargestellt werden. 

• Damping zum Abbremsen von Objekten, aufgeteilt in transDamping (Translation) und 

rotDamping (Rotation). Diese Variable kann zur Simulation von Medien genutzt werden, die 

dichter als Vakuum sind (z.B. Luft). 

• Tolerance, MaxIntervals und MinEnergy zur Bestimmung von Schwellwerten für die 

Kollisionserkennung. Standardwerte: Toleranz 0.1 m, maximale Intervalle 5, minimale 

Energie 0. 

• Bias Faktor, der global für alle Kollisionen gilt 

• Resting, um abzufragen, ob das gesamte System unterhalb der minimalen Energieschwelle 

liegt 

Die von außen ansprechbaren Methoden dienen einerseits zum Aufbauen (AddObject, AddWall) 

bzw. Aufräumen (ClearObjects, ClearWalls) der zu simulierenden Umgebung, sowie zum 

Durchführen der Simulation selbst (Simulate). Die privaten Methoden werden später ausführlich 

erklärt (s. Programmablauf). 

Da die Interfaces keine eigenen Methoden implementieren, wurde dem Environment die Hilfsklasse 

Oriented hinzugefügt, die statische Methoden zur Beschleunigung und Vereinfachung der 

Objektbehandlung enthält: 

• Corners(Object und Surface) sowie Normal(Surface) zur effizienten Bestimmung der 

gedrehten Koordinaten. Die Koordinaten werden nur berechnet, wenn sie tatsächlich 

benötigt werden, und dann für das restliche Intervall zwischengespeichert. Reset(Object und 

Surface) setzt sie wieder zurück. 

• FaceIndexTowards und FaceTowards zur Richtungsbestimmung von Flächen. Dies wird 

einerseits für die optimierte Kollisionserkennung benötigt und andererseits auch zum 

Ablesen der Würfelergebnisse verwendet. 

• Distance zur Distanzberechnung zwischen Punkt und Ebene 

• Energy zur Bestimmung der Bewegungsenergie Körpers 

Seite 17 / 37


Zur Erkennung und Behandlung von Kollisionen wird in der libPhysics die Collision Klasse 

verwendet. Hierbei handelt es sich um eine abstrakte Klasse, die ein gemeinsames Grundgerüst für 

mehrere verschieden implementierte Kollisionstypen, die BodyCollision und die WallCollision, 

bietet. Jede Collision-Instanz stellt eine (mögliche) Kollision zweier Objekte miteinander oder eines 

Objekts mit einer Wand dar. 

Soll eine Kollision geprüft werden, wird zunächst eine Instanz mit den zu prüfenden Objekten 

erzeugt und dann die Methode Detect() aufgerufen, die jede abgeleitete Kollisionsklasse 

eigenständig implementiert. Diese führt die nötigen Berechnungen aus, um die Kollision danach mit 

einem Handle() Aufruf aufzulösen. Die genaue Funktionsweise dieser Methoden wird später 

erläutert (s. Programmablauf). 

Um den aktuellen Status einer Kollision zu beschreiben, wird das Enum State verwendet. 

UNDEFINED ist eine Kollision, wenn noch keinerlei Prüfung oder Rechnung stattgefunden hat. 

CLEAR bedeutet, dass die Objekte zu weit voneinander entfernt sind, um sich zu berühren. Mit 

COLLIDING wurde eine Berührung innerhalb der Toleranzgrenzen des Environment festgestellt, 

wohingegen PENETRATING eine Durchdringung bedeutet, die über diese Toleranzgrenze 

hinausgeht. SEPARATING ist eine Kollision dann, wenn die Objekte bereits kollidiert sind und sich 

nun wieder voneinander entfernen. 

Intern muss jede Kollision ihren aktuellen Status (currentState), die kollidierenden Objekte, die 

Umgebung (environment), in der die Kollision stattfindet, sowie alle bereits gefundenen 

Kollisionspunkte (cpoints) speichern. Die Punkte werden jeweils in einem CollisionPoint Struct 

gehalten, da sie mehrere Werte aufnehmen müssen: 

• Position, ihre absoluten Koordinaten 

• Normal, die Richtung, in die der Kollisionsimpuls an dieser Stelle übertragen wird, 

abhängig von der Ausrichtung der Flächen, die einander berühren 

• Distance, die Eindringtiefe der Objekte ineinander an dieser Stelle. Dieser Wert ist wichtig, 

um zu beurteilen, welchen Status eine Kollision besitzt und ob bereits Toleranzgrenzen 

überschritten wurden. 

Seite 18 / 37

Programmablauf 


Der Einstiegspunkt in die Physik, nachdem das Environment erzeugt und die Objekte hinzugefügt 

wurden, ist die Simulate() Methode. Diese wird von außen mit dem zu berechnenden Zeitintervall 

(dTime) aufgerufen und stößt den Prozess der Intervallhalbierung an. 

public void Simulate(float dTime) 

{ 

CalculateAllAccelerations(); 

Interval(dTime, 1); 

} 

private void Interval(float dTime, int Level) 

{ 

MoveAll(dTime); 

switch (DetectAllCollisions()) 

{ 

case Collision.State.COLLIDING: 

HandleAllCollisions(); 

break; 

case Collision.State.PENETRATING: 

if (Level > maxIntervals) 

{ 

HandleAllCollisions(); 

} 

else 

{ 

Interval(-Math.Abs(dTime) / 2f, Level + 1); 

Interval(+Math.Abs(dTime) / 2f, Level + 1); 

} 

break; 

} 

} 

Die Intervallhalbierung dient dem Zweck, sich einer stattfindenden Kollision so genau wie möglich 

anzunähern, da auf einem Computersystem (insbesondere auf einem PDA) keine unbegrenzten 

Ressourcen und damit auch keine unbegrenzte Genauigkeit verfügbar sind. 

Der grobe Ablauf ist relativ simpel. Bevor das Intervall begonnen wird, werden zunächst für alle 

Objekte die aktuell wirkenden Beschleunigungen ausgerechnet. Dies ist erforderlich, da sich 

manche Kräfte, wie z.B. Reibung und Dämpfung, über die Zeit bzw. mit der Geschwindigkeit 

verändern können. Innerhalb eines Intervalls werden diese Kräfte als konstant angenommen, um 

einen unnötig hohen Rechenaufwand zu vermeiden. 

Als nächstes werden die Objekte mit den so berechneten Geschwindigkeiten um die angegebene 

Zeitspanne bewegt. Danach läuft die Kollisionserkennung durch, die uns sagen kann, ob sich zu 

diesem Zeitpunkt Objekte berühren oder überschneiden. Falls nicht, ist die Simulation ereignislos 

verlaufen und die Methode wird verlassen. Falls eine Durchdringung festgestellt wurde, greift 

allerdings die Halbierung: die Simulation wird rekursiv um die halbe Zeit zurückgedreht und noch 

einmal auf Kollisionen überprüft, usw. bis ein Kollisionspunkt innerhalb der Toleranzgrenzen 

gefunden wurde oder die maximale Anzahl an Iterationen überschritten wird. Sobald dies der Fall 

ist, werden alle aktuell bestehenden Kollisionen behandelt und aufgelöst, so dass alle halbierten 

Intervalle auf Basis der nun veränderten Objektbewegung weiter gerechnet werden können. Dieser 

Prozess wird fortgesetzt, bis die Behandlung am Ende des festgelegten Zeitintervalls angelangt 

Folgende Grafik stellt die Intervallschritte zur Findung einer Kollision anschaulich dar: 

Seite 19 / 37


Durchdringung 

Durchdringung 

Keine Kollision 

Kollision 

Bewegung 

Um die Objekte zu bewegen, muss zuerst einmal deren Beschleunigung bestimmt werden, wie oben 

bereits erwähnt. Die wirkenden Kräfte, die von der libPhysics berücksichtigt werden, sind die 

geschwindigkeitsabhängige Dämpfung (die auf jede Bewegung wirkt) und Gravitation (die nur 

Translation betrifft). 

private void CalculateAllAccelerations() 

{ 

foreach (IObject body in objects) 

CalculateAcceleration(body); 

} 

private void CalculateAcceleration(IObject Object) 

{ 

if (!Object.Resting) 

{ 

Object.TransAcceleration = new Vector3(); 

Object.TransAcceleration += gravity; 

Object.TransAcceleration -= transDamping * Object.Velocity; 

} 

} 

Object.RotAccaleration = new Vector3(); 

Object.RotAccaleration -= rotDamping * Object.Rotation; 

Nachdem die Beschleunigungen für dieses Intervall feststehen, können alle Objekte entsprechend 

bewegt werden. Hierbei ist zu beachten, dass durch die Annahme einer konstanten Beschleunigung 

innerhalb eines Intervalls eine Rechnung in beide zeitlichen Richtungen möglich ist. Dies ist für die 

oben genannte Intervallhalbierung von besonderer Wichtigkeit. 

private void MoveAll(float dTime) 

{ 

foreach (IObject body in objects) 

{ 

Translate(body, dTime); 

Rotate(body, dTime); 

} 

} 

private void Translate(IObject Object, float dTime) 

{ 


{ 

Object.Position += dTime * Object.Velocity + 0.5f * dTime * dTime * 

Object.TransAcceleration; 

Object.Velocity += dTime * Object.TransAcceleration; 

} 

} 

private void Rotate(IObject Object, float dTime) 

{ 


{ 

Matrix Orientation = Object.Orientation; 

Orientation.Multiply(Matrix.RotationAxis(Object.RotAccaleration, 0.5f * dTime * 

Seite 20 / 37


dTime * Object.RotAccaleration.Length())); 

Orientation.Multiply(Matrix.RotationAxis(Object.Rotation, dTime * 

Object.Rotation.Length())); 

Object.Orientation = Orientation; 

Object.Rotation += dTime * Object.RotAccaleration; 

Oriented.Reset(Object); 

} 

} 

Kollisionserkennung 

Die Kollisionserkennung wird nach jedem Intervallschritt einmal angestoßen. Zunächst werden alle 

im letzten Schritt gefundenen Kollisionen verworfen und danach für jede Objekt-Objekt bzw. 

Objekt-Wand Kombination, die nicht stillsteht, eine Kollisionsinstanz erzeugt und per Detect() auf 

ihren Status geprüft. Alle gefundenen Kollisionen werden zur Behandlung in die Liste 

aufgenommen, wobei der „tiefste“ Status zur Steuerung an die Intervallhalbierung zurückgegeben 

wird. 

private Collision.State DetectAllCollisions() 

{ 

Collision.State currentState = Collision.State.UNDEFINED; 

collisions.Clear(); 

for (int i = 0; i < objects.Length; i++) 

{ 

foreach (ISurface wall in walls) 

{ 

if (!objects[i].Resting) 

{ 

Collision col = new WallCollision(objects[i], wall, this); 

col.Detect(); 

Collision.State stat = col.CheckState; 

if (stat > Collision.State.SEPERATING) 

collisions.Add(col); 

if (stat > currentState) 

currentState = stat; 

} 

} 

for (int j = i + 1; j < objects.Length; j++) 

{ 

if (!objects[i].Resting || !objects[j].Resting) 

{ 

Collision col = new BodyCollision(objects[i], objects[j], this); 

col.Detect(); 

Collision.State stat = col.CheckState; 

if (stat > Collision.State.SEPERATING) 

collisions.Add(col); 

if (stat > currentState) 

currentState = stat; 

} 

} 

} 

return currentState; 

} 

Die Implementierung der Detect() Methode unterscheidet sich in den verschiedenen 

Kollisionsarten. Beispielhaft soll hier nun der Ablauf für die BodyCollision (Objekt-Objekt- 

Kollision) gezeigt werden. Der Code der WallCollision (Objekt-Wand-Kollision) ist prinzipiell nur 

eine Untermenge davon, bei der eines der Objekte als eine einzelne, statische Fläche angenommen 

werden kann. 

Zu Beginn der Methode wird eine Initialisierung der benötigten Variablen 

vorgenommen. Die Kollisionsnormale wird zunächst als Vektor zwischen 

den Mittelpunkten der beiden Objekte approximiert, um mithilfe der Radien 

der beiden Objekte zu testen, ob sie sich überhaupt nah genug für eine 

Seite 21 / 37


Kollision beieinander befinden. Falls nicht, kann die Kollisionserkennung an dieser Stelle schon 

wieder verlassen werden. 

float radius, distance, depth = environment.Tolerance; 

Vector3 point, normal = bodyA.Position – bodyB.Position; 

if (normal.LengthSq() > Math.Pow(bodyA.Radius + bodyB.Radius, 2) + 

environment.Tolerance) 

{ currentState = State.CLEAR; return; } 

Als nächster Schritt wird anhand dieses Mittelpunktvektors bestimmt, 

welche Flächen der beiden Objekte einander zugewandt sind. Da es sich in 

unserer Simulation einheitlich um konvexe Polyeder mit in etwa 

gleichmäßiger räumlicher Ausdehnung handelt, können wir davon ausgehen, 

dass nur diese beiden Flächen einander berühren können. 

faceA = Oriented.FaceTowards(bodyA, normal); 

faceB = Oriented.FaceTowards(bodyB, -normal); 

Die FaceTowards() Methode wird von der statischen Hilfsklasse Oriented 

zur Verfügung gestellt. Die Winkelbestimmung erfolgt über den Vergleich der Skalarprodukte mit 

der Normale jeder Fläche. 

public static class Oriented 

{ 

... 

public static ISurface FaceTowards(IObject Object, Vector3 Normal) 

{ 

return Object.Faces[FaceIndexTowards(Object, Normal)]; 

} 

public static int FaceIndexTowards(IObject Object, Vector3 Normal) 

{ 

float last = 0f, least = 0f; 

int index = -1; 

for (int i = 0; i < Object.Faces.Length; i++) 

{ 

last = Vector3.Dot(Oriented.Normal(Object.Faces[i]), Normal); 

if (last < least) 

{ 

least = last; 

index = i; 

} 

} 

} 

public static float Distance(ISurface Surface, Vector3 Vector) 

{ 

return Vector3.Dot(Vector - (Corners(Surface)[0] + Surface.Object.Position), 

Normal(Surface)); 

} 

... 

} 

Sobald die zugewandten Flächen feststehen, wird für jeden der Eckpunkte 

überprüft, ob er die Fläche des anderen Objektes durchdringt. Die 

Koordinaten jedes Eckpunktes sind relativ zu ihrem Objekt 

angegeben, daher wird zunächst die absolute Position bestimmt. 

Die Distanzermittlung behandelt die Fläche allerdings als Ebene 

von unbegrenzter Ausdehnung, daher muss, selbst wenn 

Seite 22 / 37


eine Durchdringung festgestellt wird, der Eckpunkt danach noch einmal mit der Bounding Sphere 

des anderen Objekts verglichen werden, um sicherzustellen, dass er nicht hinter der Ebene aber 

außerhalb des Objektes liegt. Die Normale der Fläche, mit der die Durchdringung geprüft wurde, 

sowie die ermittelte Distanz werden zur späteren Behandlung im Kollisionspunkt gespeichert. Die 

weiteste Eindringtiefe wird außerdem zum Bestimmen des Kollisionsstatus anhand der 

Toleranzgrenzen des Environment herangezogen. 

cpoints.Clear(); 

normal = Oriented.Normal(faceB); 

radius = (float)Math.Pow(bodyB.Radius, 2) + environment.Tolerance; 

foreach (Vector3 corner in Oriented.Corners(faceA)) 

{ 

point = corner + bodyA.Position; 

distance = Oriented.Distance(faceB, point); 

if (distance < environment.Tolerance && (point - 

bodyB.Position).LengthSq() < radius) 

{ 

cpoints.Add(new CollisionPoint(point, normal, distance)); 

if (distance < depth) depth = distance; 

} 

} 

normal = -Oriented.Normal(faceA); 

radius = (float)Math.Pow(bodyA.Radius, 2) + environment.Tolerance; 

foreach (Vector3 corner in Oriented.Corners(faceB)) 

{ 

point = corner + bodyB.Position; 

distance = Oriented.Distance(faceA, point); 

if (distance < environment.Tolerance && (point - 

bodyA.Position).LengthSq() < radius) 

{ 

cpoints.Add(new CollisionPoint(point, normal, distance)); 

if (distance < depth) depth = distance; 

} 

} 

if (depth < -environment.Tolerance) 

currentState = State.PENETRATING; 

else if (depth < environment.Tolerance) 

currentState = State.COLLIDING; 

else 

currentState = State.CLEAR; 

Diese Überprüfung wird in der BodyCollision für jedes Objekt einmal 

ausgeführt. In der WallCollision findet die Überprüfung nur einmal statt, 

da nur ein Objekt mit einer Fläche verglichen werden muss, außerdem 

fällt der Abgleich mit der Bounding Sphere weg, da die Wand tatsächlich 

eine unbegrenzte Ebene ist. Sobald alle Kollisionspunkte gefunden 

wurden und der Gesamtstatus der Kollision festgestellt ist, kann die 

Kollisionserkennung abgeschlossen werden. 

Kollisionsbehandlung 

Nachdem eine Kollision festgestellt wurde, kann sie behandelt und aufgelöst werden. Auch die 

Handle() Methode ist genau wie Detect() eine abstrakte Methode, die von jeder Kollisionsklasse 

selbstständig implementiert ist. Dem obigen Beispiel folgend wird hier die Behandlung einer 

BodyCollision gezeigt, da die WallCollision nur eine Vereinfachung darstellt, bei der eines der 

Objekte (die Wand) als unbeweglich und von unendlicher Masse behandelt 

wird. 

Vor der Kollisionsbehandlung muss geprüft werden, ob überhaupt eine 

Seite 23 / 37


Berührung stattfindet bzw. erkannt wurde. Falls nicht, wird die Kollisionsbehandlung an dieser 

Stelle abgebrochen. Andernfalls findet die Deklaration von temporären Variablen statt, die später 

verwendet werden, und die Behandlung wird fortgesetzt. 

if (currentState < State.COLLIDING) return; 

Vector3 pointA, pointB, normal, relativeVelocity; 

float normalVelocity; 

Die folgenden Abschnitte werden nacheinander für jeden Kollisionspunkt durchlaufen, falls mehr 

als einer gefunden wurde. 

Zunächst wird die relative Geschwindigkeit der beiden Objekte am 

Kollisionspunkt bestimmt. Dazu werden erst die Vektoren vom 

Objektmittelpunkt zum Kollisionspunkt festgelegt, um die 

Rotationsgeschwindigkeit an dieser Stelle errechnen zu können. Die 

Translationsgeschwindigkeit ist an allen Stellen gleich, daher kann sie 

direkt addiert werden. 

pointA = cpoint.Position - bodyA.Position; 

pointB = cpoint.Position - bodyB.Position; 

normal = cpoint.Normal; 

relativeVelocity = (bodyA.Velocity + 

Vector3.Cross(bodyA.Rotation, pointA)) 

- (bodyB.Velocity + Vector3.Cross(bodyB.Rotation, 

pointB)); 

Seite 24 / 37


Die relative Geschwindigkeit wird dann per Skalarprodukt auf die Kollisionsnormale aufgetragen. 

Falls sich die beiden Objekte in Richtung der Normalen nicht aufeinander zubewegen (z.B. weil 

sich der Kollisionspunkt am Rand befindet und die Objekte sich nur streifen) braucht keine weitere 

Rechnung zu erfolgen und die Behandlung kann mit dem nächsten Punkt fortgesetzt werden. 

normal); 

normalVelocity = Vector3.Dot(relativeVelocity, 

if (normalVelocity > 0f) continue; 

Stoßen die Objekte zusammen, wird als nächstes unter Hinzunahme der 

Massen und Trägheitsmomente der beiden Objekte sowie der 

Oberflächeneigenschaften der kollidierenden Flächen der Impuls 

errechnet, der zwischen den Objekten übertragen wird. Wichtig hierbei 

sind einerseits die Elastizität und andererseits der Bias-Faktor. 

Elastizität gibt an, wie viel Energie bei einem Stoß erhalten bleibt. Eine 

Elastizität von 1 wäre ein komplett elastischer Stoß, bei dem keine 

Energie verloren geht, wohingegen 0 einen komplett plastischen Stoß 

darstellt, bei dem die Objekte ineinander stecken bleiben. Werte über 1 

oder unter 0 kommen in der Natur nicht vor, wären aber denkbar, wenn Objekte bei einem 

Zusammenstoß Energie gewinnen oder beschleunigt ineinander einsinken. Der Bias-Faktor ist eine 

Größe, die in der Natur nicht existiert, die aber zum Ausgleich von Ungenauigkeiten hinzugezogen 

wird, um die Simulation stabil zu halten. Da eine Kollision immer nur innerhalb bestimmter 

Toleranzgrenzen festgestellt werden kann, ist der Bias-Faktor dafür zuständig, die Objekte stärker 

auseinander zu befördern, je tiefer sie ineinander eindringen (ein Zustand, der bei realen Körpern 

eigentlich nicht vorkommen kann). 

Vector3 impulse = normal * ( 

-((1 + faceA.Material.Restitution * faceB.Material.Restitution) * 

normalVelocity 

+ cpoint.Distance * environment.Bias) 

/ ((1f / bodyA.Mass + 1f / bodyB.Mass) 

+ Vector3.LengthSq(Vector3.Cross(pointA, normal)) / bodyA.Inertia 

+ Vector3.LengthSq(Vector3.Cross(pointB, 

normal)) / bodyB.Inertia)); 

Wenn der Impuls feststeht, muss er nur noch auf beide Objekte angewandt 

werden. Zur Bestimmung der Rotationsbewegung spielt neben dem 

Trägheitsmoment wieder die Lage des Kollisionspunktes relativ zum 

Objekt eine Rolle, zur Translation kann der Impuls (nach Verrechung mit 

der Objektmasse) direkt addiert werden. Zu beachten ist, dass der Impuls 

auf das zweite Objekt negativ angewendet wird, da dieses auch zur 

Bestimmung der Relativgeschwindigkeit mit negativem Vorzeichen 

herangezogen wurde. 

Seite 25 / 37


bodyA.Velocity += impulse * (1f / bodyA.Mass); 

bodyA.Rotation += Vector3.Cross(pointA, impulse) * (1f / bodyA.Inertia); 

bodyB.Velocity -= impulse * (1f / bodyB.Mass); 

bodyB.Rotation -= Vector3.Cross(pointB, impulse) * 

(1f / bodyB.Inertia); 

Sobald diese Schleife für alle Kollisionspunkte durchlaufen wurde, kann 

der Status der Kollision auf SEPARATING gesetzt werden. Danach erfolgt 

zum Abschluss der Kollisionsbehandlung nur noch eine Überprüfung auf 

die Energie der Objekte. Da bei jedem Stoß Energie verloren gehen kann, 

wird nach jeder Kollision überprüft, welche der Objekte die Schwelle des 

Environment unterschreiten, und werden in den Ruhezustand versetzt, um 

Rechenleistung zu sparen und dem Framework anzuzeigen, dass diese 

Würfel nun abgelesen werden können. 

true; 

true; 

if (bodyA.Resting || bodyB.Resting) 

{ 

if (Oriented.Energy(bodyA) < environment.MinEnergy) bodyA.Resting = 

} 

else bodyA.Resting = false; 

if (Oriented.Energy(bodyB) < environment.MinEnergy) bodyB.Resting = 

else bodyB.Resting = false; 

Um zu verhindern, dass zwei Objekte in der Luft zusammenstoßen und dann hängen bleiben, weil 

ihre Energie zu niedrig ist, wird der Ruhezustand nur aktiviert, wenn das Objekt mit einer 

unbeweglichen Wand (s. WallCollision) oder einem anderen ruhenden Objekt kollidiert. 

Andererseits können auf diese Weise auch bereits ruhende Objekte von anderen angestoßen und aus 

ihrem Ruhezustand heraus befördert werden. Der Code zur Berechnung der Energie wird auch hier 

von der Hilfsklasse Oriented zur Verfügung gestellt und folgt einer einfachen physikalischen 

Formel für kinetische Energie. 

public static class Oriented 

{ 

... 

public static float Energy(IObject Object) 

{ 

return 0.5f * Object.Mass * Object.Velocity.LengthSq() 

+ 0.5f * Object.Inertia * Object.Rotation.LengthSq(); 

} 

... 

} 

Seite 26 / 37

Funktionsweise der 3d-Engine 


Das Direct3D Renderer Modul besteht aus nur einer Klasse. Es besitzt einige Interfaces zur 

Kommunikation mit anderen Programmteilen – in diesem Fall mit dem Dice Framework. Auch hier 

sind Objekte (Würfel) noch in Surfaces aufgeteilt. 

Der grundsätzliche Aufbau eines Direct3D Renderes ist immer sehr ähnlich. 

Es beginnt mit der Initialisierung, wo Auflösung, Farbtiefe und einige 3D Parameter gesetzt 

werden. Dann werden einer oder mehrere sogenannte VertexBuffers generiert. Und dann gehört 

natürlich noch eine „Render“-Funktion dazu. Diese Teile des Renderers werden im Folgenden 

genauer beschrieben. 

Initialisierung 

PresentParameters presentParams = new PresentParameters(); //Datenstruktur für DirectX 

DisplayMode dispMode = Manager.Adapters.Default.CurrentDisplayMode; //Aktueller 

Displaymodus 

presentParams.AutoDepthStencilFormat = DepthFormat.D16; // Bit-Größe des Z-Buffers 

presentParams.EnableAutoDepthStencil = true; 

// Z-Buffer aktivieren 

presentParams.BackBufferCount = 1; 

//


device.RenderState.ZBufferEnable = true; 

device.RenderState.CullMode = Cull.CounterClockwise; 

device.Lights[0].Type = LightType.Point; 

device.Lights[0].Diffuse = Color.White; 

device.Lights[0].AmbientColor = new ColorValue(0, 1, 0); 

device.Lights[0].Position = new Vector3(0.49f, 0.49f, 0.49f); 

device.Lights[0].Attenuation0 = 0; 

device.Lights[0].Attenuation1 = 0.75f; 

device.Lights[0].Attenuation2 = 0; 

device.Lights[0].Range = 100; 

device.Lights[0].Specular = Color.White; 

device.Lights[0].Update(); 

device.Lights[0].Enabled = true; 

device.RenderState.Ambient = Color.FromArgb(0x20, 0x20, 0x20); 

device.RenderState.Lighting = true; 

Backface Culling ist ein Verfahren, um jene Polygone, die gerade nicht sichtbar sind (weil sie auf 

der Rückseite des Würfels sind) nicht mit zu rendern. Ob ein Polygon ausgeblendet wird, wird 

durch die Reihenfolge der Eckpunkte angegeben. Hier speziell werden Polygone ausgelassen, 

dessen Punkte (nach der Transformation in Bildschirmkoordinaten) gegen den Uhrzeigersinn 

verteilt sind. 

Für die Beleuchtung wird eine Lichtquelle definiert. Diese enthält Typ, Farbe, Position und 

Reichweite. Es wird nach dem Aktivieren des Lichts und der Beleuchtung (Lighting) von DirectX 

automatisch angewendet. Dieses einfache Beleuchtungsmodell kann keine Schatten werfen, sondern 

nur die Helligkeit von Polygonen ändern, je nach dem, wie genau die Normale des Polygons zur 

Lichtquelle ausgerichtet ist. 

Nun muss nur noch eine „Kamera“ gesetzt werden. Diese besteht aus ein paar Matrizen, welche, 

multipliziert mit den eigentlich zu rendernden Daten multipliziert werden, um entsprechend die 

Position und Drehung einer Kamera zu imitieren. Auch hier macht DirectX die meiste Arbeit : 

device.Transform.View = 

Matrix.LookAtRH( 

new Vector3(-0.5f, 0.0f, +0.5f), 

new Vector3(0.0f, 0.0f, 0.0f), 

new Vector3(0.0f, 0.0f, 1.0f)); 

device.Transform.Projection = 

Matrix.PerspectiveFovRH( 

(float)Math.PI / 2.0f, 

(float)targetForm.ClientSize.Width/(float)targetForm.ClientSize.Height, 

0.1f, 40.0f ); 

Seite 28 / 37

Vertexbuffer 


Dies sind schreibgeschützte Arrays, welche 3D-Geometrie und Texturkoordinaten enthalten. Sie 

werden nach der Erzeugung direkt in den Grafikspeicher geladen und können dadurch schneller 

abgerufen werden beim Rendern. Unter Windows Mobile mit dem Compact .NET Framework ist 

dies die einzige Möglichkeit, überhaupt etwas zu rendern. 

vb = new VertexBuffer( 

typeof(CustomVertex.PositionNormalTextured), 

numvertices, device, Usage.WriteOnly, 

CustomVertex.PositionNormalTextured.Format, Pool.Managed); 

Der Vertexbuffer muß zum Füllen mit Daten einmal gesperrt werden (Lock), kann dann wie ein 

Array beschrieben werden, und natürlich muß er wieder freigegeben werden (Unlock). 

CustomVertex.PositionNormalTextured[] v = 

(CustomVertex.PositionNormalTextured[])vb.Lock(0, 0); 

... 

v[c] = objs[j].Surfaces[i].Points[k]; 

... 

vb.Unlock(); 

Seite 29 / 37


Rendern 

1 public void Render() 

2 { 

3 device.Clear(ClearFlags.Target | ClearFlags.ZBuffer, Color.Blue, 1.0f, 0); 

4 device.BeginScene(); 

5 

6 if (vb != null) 

7 { 

8 device.VertexFormat = CustomVertex.PositionNormalTextured.Format; 

9 device.SetStreamSource(0, vb, 0); 

10 

11 foreach (DrawingInfoObject dio in drInfo) 

12 { 

13 Matrix m; 

14 m = dio.o.Orientation; 

15 m.Multiply(Matrix.Translation(dio.o.Position)); 

16 

17 device.Transform.World = m; 

18 

19 foreach (DrawingInfoSurface dis in dio.Surfaces) 

20 { 

21 device.SetTexture(0, dis.tex); 

22 device.DrawPrimitives(PrimitiveType.TriangleFan, dis.start, dis.length 

- 2); 

23 } 

24 } 

25 } 

26 device.EndScene(); 

27 device.Present(); 

28 } 

Dies ist der vollständige Code, der die Würfel in 3D rendert. 

In Zeile 3 wird der BackBuffer auf eine blaue Hintergrundfarbe geleert – ebenso wird der Z-Buffer 

geleert. 

Zeile 4 leitet den Bereich ein, in dem alle Renderbefehle stattfinden müssen. Für die meisten 

Programme ist es effizienter, wenn alle Polygone in nur einem “Renderbereich” zwischen 

device.BeginScene() und device.EndScene() liegen. 

In Zeile 8 wird das Vertexformat eingestellt. In diesem Fall Vertices mit Positionsangabe, eine 

Normalen und Texturkoordinaten. 

Zeile 9 wählt den Vertexbuffer als Datenquelle aus. 

In den Zeilen 13 bis 17 findet pro Würfel die genaue Positionierung und Drehung statt. 

In Zeile 21 wird pro einzelne Fläche eines Würfels die entsprechende Textur aktiviert. 

Zeile 22 ist schließlich der (einzig vorhandene) Befehl, der Polygone zum Rendern an die 

Grafikhardware “schickt”. 

Der Renderbereich wird in Zeile 26 verlassen, und der wichtigste Befehl in Zeile 27 führt den 

Kopiervorgang vom BackBuffer auf den Bildschirm aus. 

Seite 30 / 37

Schnittstellen 


Modulbeschreibungen 

GUI 

Die GUI (Graphical User Interface) ist die Schittstelle zum Benutzer. Sie wird benötigt, da weder 

das Framework noch die Physik- oder 3d-Engine Benutzerschnittsllen anbieten. Die GUI stellt in 

der aktuellen Fassung nur einen sehr geringen Teil der Funktionalität des Dice-Frameworks dem 

Benutzer zur Verfügung. Dies ist allerdings kein direktes Versagen der GUI, sondern eine 

Notwendigkeit. Die Funktionalität des Frameworks übersteigt die Anforderungen auf dem PDA, 

daher wurde eine Auswahl getroffen. 

libDice 

Die Kern-Bibliothek. Sie verwaltet die Texturen, Materialien, Objekte, Würfel und die Welt selbst 

und stellt diese Daten dann der Physik- und 3d-Engine zur Verfügung. Sie nimmt die Befehle der 

GUI entgegen und führt diese entsprechend aus. 

libPhysics 

Die Physik-Engine. Sie führt sämtliche Bewgungen in der Welt aus, ermittelt alle Kollisionen und 

Behandelt diese. 

libDXRender 

Der DirectX-basierte 3d-Renderer. Enthält die 3d-Engine und sorgt für die optische Darstellung des 

Würfelvorgangs. 

Seite 31 / 37

Klassendiagramme 


libDice 

Seite 32 / 37


libPhysics 

Seite 33 / 37


libDXRender 

Seite 34 / 37


Screenshots 

Seite 35 / 37


Echte Würfel? - Eine Statistik 

Eine Frage, die sich nun aufstellt ist : Werden alle Zahlen auf den Würfeln etwa gleich oft 

gewürfelt? Zu diesem Zweck wurde das Programm leicht geändert, um schnell viele Würfe zu 

absolvieren, und die gewürfelten Ergebnisse in einer Datei herauszuschreiben. Bei 600 Wurf mit 

jeder Würfelart wurden folgende Zahlen gewürfelt: 

140 

120 

100 

80 

60 

40 

20 

0 

D6 

0 1 2 3 4 5 6 

D6 

100 

90 

80 

70 

60 

50 

40 

30 

20 

10 

0 

D8 

0 1 2 3 4 5 6 7 8 

D8 

80 

D10 

70 

D12 

70 

60 

50 

40 

30 

20 

10 

D10 

60 

50 

40 

30 

20 

10 

D12 

0 

0 1 2 3 4 5 6 7 8 9 

0 

0 1 2 3 4 5 6 7 8 9 10 11 12 

45 

40 

35 

30 

25 

20 

15 

10 

5 

0 

D20 

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 

D20 

Seite 36 / 37


Zukunft 

"Dice!" war ursprünglich viel größer und umfassender konzipiert. Aus Zeitgründen wurde aber von 

vornherein nur ein Teil der Funktionen angestrebt. Diese Funktionen werden in Zukunft wohl nach 

und nach hinzugefügt. Da uns in der Zukunft aber wahrscheinlich kein PDA mehr mit ausreichend 

Rechenleistung zur Verfügung stehen wird, wird die Weiterentwicklung von "Dice!" wohl auf dem 

PC stattfinden müssen. Das Projekt wird wahrscheinlich auch später ein Teil einer größer 

angelegten privaten Projektarbeit im Bereich Pen&Paper-Rollenspiele. Das Teilprojekt "libPhysics" 

wird wahrscheinlich noch massiv ausgebaut und nach C++ portiert, um dann Teil unserer 

gemeinsamen Diplomarbeit zu werden. 

Referenzen 

• Wikipedia 

• „Physics“ Artikel von Chris Hecker im Game Developer Magazine von März 1997 

• Rigid Body Physics Tutorial auf www.xbdev.net 

• Das große Tafelwerk - Formelsammlung 

• Treiber für PDA von www.htcclassaction.org 

• Geräteinformationen von www.xda-developers.com 

• Windows Mobile 6.1 von www.htc.com 

• Microsoft Developer Network (MSDN) 

Seite 37 / 37

Würfelsimulator

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?