indoor-rendering softwaretechnologie ii master of ceremony: christian daum sidekick: tanja b. lange...
TRANSCRIPT
Indoor-Rendering
Softwaretechnologie IIMaster of Ceremony: Christian Daum
Sidekick: Tanja B. Lange (wofür, zum Henker, steht eigentlich das „B.“?)
Hohe Anforderungen – Lösung: Portalsysteme
An das Indoor-Rendering sind hohe Anforderungen geknüpft:o Zahlreiche Innenräumen mit hohem Detailreichtum sollen Frame für Frame
fix gerendert werden
Problem: Extremer Rechenaufwand
Lösung: Sichtbarkeitstest auf Basis von Betrachterposition (im „Dungeon“) und Blickrichtung (im Raum)
o Auf dieser Grundlage: Klassifikation von Wänden und Räumen in ...> ... nicht sichtbar (Sichtbarkeitstest überflüssig)> ... potentiell sichtbar (Sichtbarkeitstest notwendig)
o Logo: Zuerst werden Sichtbarkeitstests für potentiell sichtbare Räume durchgeführt, bevor man Tests für „deren“ potentiell sichtbaren Wände anschließt!
Problem: Was tun mit – z.B. – L-förmigen Räumen?o Grund: hier ist es möglich, dass von einem Ende des Raumes Wände (oder gar weitere Räume)
potentiell sichtbar sind – die vom anderen Ende des L-förmigen Raumes nicht sichtbar sind
Lösung: Portalsystemeo Also Unterteilung solcher Räumen in Sektoren (sprich: „künstliche“ neue „Sub-Räume“) o & erneute Klassifizierung der Wände auf Basis von Betrachterposition & Blickrichtung
> Portal: Der jeweilige Übergang zwischen den Sektoren
Funktionsweise eines solchen Portalsystems:1. Sichtbarkeitstest für alle potentiell sichtbaren Portale
(und damit der dahinter liegenden Sektoren)2. Sichtbarkeitstest für alle potentiell sichtbaren Wände dieser Sektoren
Entwicklung eines Indoor-Renderers
1. Dateiformat zum schnellen Aufbau eines Indoor-Szenarios
Speichern der Texturen
Speichern des Indoor-Szenarios
o Components: Definition und Verwendung der Bauteil-Geometrien(also Drei- & Vierecke für Wände, Decken & Böden).
o Definition der Portale
o Definition der Sektoren
2. Speichern der Lichtquellen
3. Globale Variablen
4. Klassen, Strukturen & Funktionen
Überblick & Strukturentwürfe
Entwicklung eines Indoor-Renderers
1. Dateiformat zum schnellen Aufbau eines Indoor-Szenarios.
Alle relevanten Daten des Indoor-Szenarios (Components, Sektoren, Portale) werden in der Datei Interieur.txt gespeichert (s. Folgecharts)
Die Texturen der Components finden sich hingegen in IndoorTextures.txt
Enthält alle Pfade der verwendeten Texturen:
Entwicklung eines Indoor-Renderers
1. Dateiformat zum schnellen Aufbau eines Indoor-Szenarios.
Speichern des Indoor-Szenarios – Components
Ein Indoor-Szenario setzt sich vollständig aus 3- & 4eckigen Bauteilen (sog. Components zur Darstellung von Wänden, Decken & Böden) zusammen
Definition 4eckiger Components (erfolgt wohl immer zuerst):
Logo: durch Definition der Vertices
Zusätzlich jedoch: Angabe der Anzahl der Vertices
Notwendigkeit: für die Berechnung der Lichteinflüsse notwendig, da hierfür die Vertices allein nicht ausreichen
Arbeitsweise: Bei Programmbeginn wird für jedes Bauteil auf Basis dieser Angaben ein Vertexgitter interpoliert (später mehr...)
Definition 3eckiger Components:
Logo: durch Definition der Vertices
Jedoch wird auf eine Interpolation eines Vertexgitters verzichtet
Falls ein solches trotzdem gewünscht sein sollte:
Definition eines 4eckigen Bauteils wie oben – jedoch müssen dann 2 Eckpunkte mit identischen Koordinaten definiert werden
Entwicklung eines Indoor-Renderers
1. Dateiformat zum schnellen Aufbau eines Indoor-Szenarios.
Speichern des Indoor-Szenarios – Components Beispiel (s. Interieur.txt):
Entwicklung eines Indoor-Renderers
1. Dateiformat zum schnellen Aufbau eines Indoor-Szenarios.
Speichern des Indoor-Szenarios – Portale:
Definition der Portale:
Definition der Portal-Vertices
Angabe des zugehörigen „Ziel-Sektors“ (... in den man gelangt, wenn man das Portal durchschreitet)
Entwicklung eines Indoor-Renderers
1. Dateiformat zum schnellen Aufbau eines Indoor-Szenarios.
Speichern des Indoor-Szenarios – Definition der Sektoren I:
Definition der Point-Lights (zwecks Grundausleuchtung des Sektors)
Definition der Sektor-Bauteile (also Anzahl & Nr. der den Sektor definierenden Components); Notwendigkeit:
Kollisionstests mit Wänden
Höhenbestimmung des Betrachters (Entfernung zum Fußboden)
Definition der Sektor-Portale (also Anzahl & Nr. der aus dem Sektor hinausführenden Portale)
Daraufhin Sichtbarkeitstest-Frequenz für jedes dieser Portale: Sequenz beginnt beim jeweiligen Sektor-Portal und checkt, ob dahinter liegende
Räume sichtbar sind oder nicht (bei geöffnetem / nicht geöffnetem Portal etc.)
Sequenz endet, wenn alle Portale abgearbeitet sind und/oder bei negativem Sichtbarkeitstest
Entwicklung eines Indoor-Renderers
1. Dateiformat zum schnellen Aufbau eines Indoor-Szenarios.
Speichern des Indoor-Szenarios – Definition der Sektoren II:
Definition der potentiell sichtbaren Bauteile (also Anzahl, Nummer & Sektorzugehörigkeit)
Auch VSD genannt (Visible Surface Determination = Bestimmung der sichtbaren Oberflächen) Meint das Rendering einer Szene mit möglichst wenig Overdraw (s.u.)
Zuerst Angabe (& Rendering) der nicht-transparenten Bauteile in Front2Back-Order
Danach Angabe (& Rendering) der transparenten Bauteile in Back2Front-Order
Grund: Performancegewinn & bessere Darstellung durch Verringerung des Overdraws beim Rendering
Overdraw-Wert: Definiert die Anzahl an Schreibvorgängen im z-Buffer
Durch Front2Back-Order wird der Overdraw-Wert auf ein Minimum reduziert
Back2Front: Der z-Buffer wird i.d.R. vollständig mit dem größten vorkommenden Tiefenwert initialisiert. Hat ein Polygon einen geringeren Tiefenwert als der z-Buffer, wird der ursprüngliche z-Buffer-Wert überschrieben (Overdraw) = Performance-intensiver Vorgang
Front2Back: Wird der z-Buffer stattdessen mit den jeweils niedrigeren Tiefenwerten initialisiert, entfällt der Overdraw jedesmal dann, wenn das entsprechende Polygon einen höheren Tiefenwert hat, als der z-Buffer (da das Polygon dann ohnehin nicht sichtbar wäre) = weniger Schreibvorgänge
Entwicklung eines Indoor-Renderers
1. Dateiformat zum schnellen Aufbau eines Indoor-Szenarios.
Speichern des Indoor-Szenarios – Definition der Sektoren III:
Beispiel Definition Sektoren
Entwicklung eines Indoor-Renderers
2. Speichern der Lichtquellen
Bis dato wurden die Lichtquellen in der Klasse C3DScenario gespeichert …
Doch damit ist jetzt Schluß – um nicht zu sagen:
Ab sofort wird zum Speichern der Lichtquellen ein globales Array (vom Typ D3DLight9) verwendet!
Grund (na?): Globaler Zugriff auch außerhalb dieser Klasse!
ZÄSUR!
Entwicklung eines Indoor-Renderers
3. Globale Variablen:
Entwicklung eines Indoor-Renderers4. Überblick Klassen, Strukturen & Funktionen Eben jene sind allesamt in der Datei Indoor.h implementiert:
Klasse/Methode Funktion/Zweck
CSektor_Portal_Zuordnung Zuordnung des jeweils zugehörigen Portal-Sektors (mittels der Variablen Sektor-Nr. & Portal-Nr.)
CList_of_Sektor_Portal_Zuordnung Initialisiert ein Array vom Typ CSektor_Portal_Zuordnung (Array wird für Portal-Sichtbarkeits-Testfrequenz verwendet)
CBauteil_Sektor_Zuordnung Benötigt für Sichtbarkeitstest & Rendern potentiell sichtbarer Bauteile (mittels der Variablen Sektor-Nr. & Bauteil-Nr.)
CPortal Speichern von Portal-Eigenschaften (Vertices & Sektor-Nr. d. Portal-Sektoren); Initialisierung einer CQuad-Instanz (zwecks Portaldurchtrittstest – s. CSektor); Portalsichtbarkeitstest (Portalmittelpunkt & -Vertices werden auf potentielle Sichtbarkeit überprüft)
CIndoorTextures Verwaltet die Texturen des Indoor-Secenarios
CBauteil Initialisierung, Verwaltung & Darstellung der Components (1. „Arbeitspferd“ des Indoor-Renderers: Interpolation v. Vertexgittern; Kollisionstests Bauteil <-> Spieler; Rendern der Bauteile)
CSektor Initialisierung & Verwaltung der Sektoren (2. „Arbeitspferd“ des Indoor-Renderers: Initialisierung v. Lichtquellen, Bauteil-, Portal- & Sektor-Listen des Sektors; Kollisions- & Sichtbarkeit- & Portaldurchtrittstests; Sektor-Rendering;
CInterieur Die oberste Instanz des Indoor-Renderers & Schnittstelle zu C3DScenario Initialisierung aller Bauteile, Portale & Sektoren
C3DScenario Oberste Instanz des 3D-Scenarios (Initialisiert & zerstört eine CInterieur Instanz; Rendert die Indoor-Scene)
Init3DScenario() & CleanUp3DScenario()
Initialisierung & Zerstörung des C3DScenario-Objekts
Entwicklung eines Indoor-Renderers
4. Überblick Klassen, Strukturen & Funktionen – C3DScenario:
Passt hier nicht hin, deshalb nur die Highlights der Methode New_Scene():
a) Kollisions- & Höhentest mit Wänden & Böden des aktuellen Spieler-Sektors
Kollisionstest erfolgt u.a. auf Basis von ViewFieldBorder-Matrizen (Matrizen wurden zuvor im C3DScenario-Konstruktor initialisiert)
Kollision (mit Wand/Boden): Frame-Bewegung des Spielers wird rückgängig gemacht
b) Alle Sektoren auf nicht-sichtbar zurücksetzen (vorbereitend auf die nachfolgenden Tests)
c) Portaldurchtrittstests (mit Portalen des Spieler-Sektors)
d) Portalsichtbarkeitstest (für potentiell sichtbare Sektoren)
e) Szenario-Welttransformation (gemäß inverser Spielerbewegung – notwendige Daten: x- & z-Koordinaten des Spielers & Fußbodenhöhe)
f) Interieur-Rendering (realisiert die Darstellung aller sichtbaren Wände;vor dem eigentlichen Rendern wird dabei für jedes potentiell sichtbare Bauteil ein Sichtbarkeitstest durchgeführt)
Entwicklung eines Indoor-Renderers
4. Überblick Klassen, Strukturen & Funktionen – CBauteil:
Interpolation eines Vertexgitters
Notwendigkeit (bereits angesprochen – ERINNERT EUCH!): Zur korrekten Berechnung der Lichteinflüsse auf Components
Berechnung in 2 Schritten (Details s. Folgechart):
1. Berechnung der Vertexpositionen
2. Berechnung der zugehörigen Texturkoordinaten
Nur ein warnendes Zitat vorweg:
Entwicklung eines Indoor-Renderers4. Überblick Klassen, Strukturen & Funktionen – CBauteil:
Interpolation eines Vertexgitters
Entwicklung eines Indoor-Renderers
4. Überblick Klassen, Strukturen & Funktionen – CBauteil:
Ein Bauteil initialisieren (Code zu lang -> deshalb s. dort):
Mittels der Methode Init(FILE *pfile)
Erzeugung des Index- & Vertexbuffers
Interpolation des Vertexgitters
Kollisionstest Spieler <-> Bauteil
Mittels der Methode Test_Collision()
Kollisionstest Spieler <-> Wand (mittels Test_for_point_Collision_Wall() – s. Tag 7)
Höhentest Spieler <-> Fußboden (mittels Test_For_Ray_Intersection_Terrain() – dito)
Idealer Kollisionstest checkt 10 verschiedene Kollisionssituationen ab:
Spieler läuft frontal/rückwärts/ (halb) rechts/(halb) links gegen eine Wand etc.
Bewegungsfreiheit des Spieler nach dem Kollisionstest:
Hängt von Art der Kollision ab: Ist der Spieler gegen die rechte Wand gerauscht – kann er sich auch nicht mehr nach rechts drehen etc.
Entwicklung eines Indoor-Renderers
4. Überblick Klassen, Strukturen & Funktionen – CSektor:
Einen Sektor initialisieren (Code zu lang -> deshalb s. dort):
Mittels der Methode Init_Sektor(FILE *pfile)
Initialisierung aller Lichtquellen des Sektors
Initialisierung einer...
... Bauteil-Liste des Sektors (zwecks Kollisionserkennung)
... Liste potentielle sichtbarer Portale (zwecks Portaldurchtrittstest)
... Liste potentiell sichtbarer Sektoren inkl. der zugehörigen Portale (zwecks Portal-Sichtbarkeits-Testfrequenz)
... Liste potentiell sichtbarer Bauteile inkl. der zugehörigen Sektoren (zwecks Bauteil-Rendering)
Sektor-Funzel an-/ausschalten
Mittels der Methoden Licht_anschalten() & Licht_ausschalten()
Beide Methoden beziehen sich auf potentiell sichtbare Sektoren
Licht_anschalten() erfolgt VOR & Licht_ausschalten() NACH dem Rendern der Bauteile
Jedoch Obacht: Die Lichtquellen-Positionen müssen entsprechend der inversen Spielerbewegung transformiert werden!
Entwicklung eines Indoor-Renderers
4. Überblick Klassen, Strukturen & Funktionen – CSektor:
Portal-Sichtbarkeits-Testfrequenz: Potentiell sichtbare Sektoren auf deren Sichtbarkeit hin checken (Code zu lang -> deshalb s. dort):
Mittels der Methode VisibilityTest_with_potential_visible_Sectors()
Führt für jedes sichtbare Sektor-Portal einen solchen Test durch
Portal-Durchtrittstest
Mittels der Methode Test_Portal_Durchtritt()
Führt für jedes Sektor-Portal einen Durchtrittstest durch
Stützt sich dabei auf die gleichnamige CQuad-Methode
Sektor-Rendering
Mittels der Methode Render()
Führt Sichtbarkeitstest durch
Darstellung aller potentiell sichtbaren Bauteile eines sichtbaren Sektors
Entwicklung eines Indoor-Renderers
4. Überblick Klassen, Strukturen & Funktionen – CInterieur:
Methoden von CInterieur:
Test_Collision_with_SectorComponents()
Veranlasst Kollisionstest Spieler <-> Spieler-Sektor-Bauteile
Turn_Back_List_of_visible_Sectors()
Zurücksetzen aller Sektoren auf invisible
Test_Portal_Durchtritt()
Veranlasst Portaldurchtrittstest für alle Spieler-Sektor-Portale
Sektoren_Visibility_Test()
Veranlasst Sichtbarkeitstest aller potentiell sichtbaren Sektoren
Render_Interieur()
Schaltet Lichtquellen aller sichtbaren Sektoren ein
Veranlasst Sichtbarkeitstest für potentiell sichtbare Bauteile
Schaltet Lichtquellen nach dem Rendern der Bauteile wieder aus