Indoor-Rendering Softwaretechnologie II Master 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: oZahlreiche 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) oAuf dieser Grundlage: Klassifikation von Wänden und Räumen in... >... nicht sichtbar (Sichtbarkeitstest überflüssig) >... potentiell sichtbar (Sichtbarkeitstest notwendig) oLogo: 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? oGrund: 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: Portalsysteme oAlso 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 oComponents: Definition und Verwendung der Bauteil-Geometrien (also Drei- & Vierecke für Wände, Decken & Böden). oDefinition der Portale oDefinition 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-Renderers 4. Überblick Klassen, Strukturen & Funktionen Eben jene sind allesamt in der Datei Indoor.h implementiert: Klasse/MethodeFunktion/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-Renderers 4.Ü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