Indoor-Rendering Softwaretechnologie II Master of Ceremony: Christian Daum Sidekick: Tanja B. Lange...

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


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:



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



Speichern des Indoor-Szenarios – Components Beispiel (s. Interieur.txt):



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)



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



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



Speichern des Indoor-Szenarios – Definition der Sektoren III:

Beispiel Definition Sektoren


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!


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


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)


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


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.


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!


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


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

Indoor-Rendering Softwaretechnologie II Master of Ceremony: Christian Daum Sidekick: Tanja B. Lange...

Documents

Transcript of Indoor-Rendering Softwaretechnologie II Master of Ceremony: Christian Daum Sidekick: Tanja B. Lange...