DE102005061590A1

DE102005061590A1 - Verfahren zur Visualisierung komplexer Lichtverteilungssätze technischer Beleuchtungssysteme

Info

Publication number: DE102005061590A1
Application number: DE102005061590A
Authority: DE
Inventors: Jan Berssenbrügge
Original assignee: Spin E V; SPIN EV
Current assignee: Spin E V; SPIN EV
Priority date: 2005-05-27
Filing date: 2005-12-22
Publication date: 2006-11-30

Abstract

Vorgesehen ist ein Verfahren für die Shader-basierte Beleuchtungssimulation technischer Beleuchtungssysteme, welches sich in zwei wesentliche Phasen unterteilt, wobei: DOLLAR A a. in der ersten Phase die Projektion einer LSV-Textur in die virtuelle Szenerie mittels Projective Texture Mapping gemäß den Projektionsparametern erfolgt, welche sich aus den eine asymmetrische Projektion ergebenden Öffnungswinkeln der Lichtquelle ableiten, wobei die Berechnung der Texturkoordinaten für die Abbildung der LSV-Textur auf das Polygonmodell der virtuellen Szenerie in einem Vertex-Shader erfolgt, in dem für jeden Eckpunkt des Polygonmodells die entsprechenden Texturkoordinaten der projizierten LSV-Textur berechnet werden; DOLLAR A b. in der zweiten Phase eine Farbberechnung für jedes Pixel zur Darstellung der Beleuchtung der virtuellen Szenerie durch die simulierten Lichtquellen erfolgt, wobei für die Wiedergabe der Beleuchtung Grautöne für eine Echtfarbdarstellung oder Farbwerte aus dem HSV-Farbmodell für eine Falschfarbdarstellung zum Einsatz kommen.

Description

Die vorliegende Erfindung bezieht sich auf ein Verfahren und eine Einrichtung zur Visualisierung komplexer Lichtverteilungsätze technischer Beleuchtungssysteme, wie durch die unabhängigen Ansprüche beschrieben.

Moderne Fahrzeugscheinwerfersysteme realisieren zahlreiche Lichtverteilungen für den Einsatz in unterschiedlichen Witterungs- und Sichtverhältnissen. Um sicherzustellen, dass der Straßenraum vor dem Fahrzeug in jeder Fahrsituation optimal ausgeleuchtet wird, müssen die Scheinwerfersysteme hohen Anforderungen genügen. Die verschiedenen Lichtverteilungen der Scheinwerfersysteme bilden die Grundlage für eine Evaluierung der Leuchtcharakteristika in den unterschiedlichen Einsatzsituationen.

Moderne Scheinwerfersysteme stellen zunehmend aktive Systeme dar, die sich an verschiedene Fahrsituationen anpassen. Das aktive System steuert die Leuchtrichtung des Scheinwerfers und gleicht den Einfluss der Fahrzeugbewegungen auf die Leuchtrichtung aus, um eine Blendung des Gegenverkehrs zu vermeiden oder im Verbund mit anderen Fahrzeugen den Straßenraum kollektiv auszuleuchten. Andere aktive Systeme, wie das Advanced Frontlighting System (AFS), passen die Leuchtrichtung der vorderen Scheinwerfer je nach Einschlag des Lenkrads der Kurvenfahrt an.

In Zukunft sind auch innovative Scheinwerfersysteme denkbar, die ihre Lichtverteilungen so flexibel ändern, daß sie gezielt situationsspezifische Informationen wie z.B. Richtungspfeile zum Abbiegen oder Angaben zur Geschwindigkeitsbeschränkung auf die Straße projizieren. In Kombination mit Fahrerassistenzsystemen werden auch geschwindigkeitsabhängige dynamische Leuchtweitenregelungen u.v.a. möglich.

Die obigen Beispiele verdeutlichen, dass moderne Fahrzeugscheinwerfersysteme komplexe Produkte darstellen, die vielfältige Produktanforderungen erfüllen müssen, nämlich: Technische und gesetzliche Vorgaben schreiben die Einhaltung bestimmter Lichtwerte und Leuchtreichweiten vor. Funktionale Anforderungen verlangen flexibel ansteuerbare Lichtverteilungen, die z.B. in Scheinwerfern mit Pixel-Light eingesetzt werden. Die Automobilindustrie verlangt nach design- und markenspezifischen, individuellen Leuchtcharakteristika im Nahbereich vor dem Fahrzeug. Klarsichtglas erlaubt den freien Blick in den Scheinwerfer und stellt auf diese Weise zusätzlich hohe Designanforderungen an die optische Gestaltung des Reflektors. Klarsichtglas läßt jedoch keine Bündelung der Lichtstrahlen zu, so dass diese Funktion als zusätzliche technische Anforderung in den Reflektor verlagert wird.

Die Entwicklung innovativer Fahrzeugscheinwerfersysteme ist gekennzeichnet durch markenspezifische Variantenvielfalt, vielfältige Produktanforderungen und hohen Kostendruck seitens der Automobilindustrie. Zur Unterstützung des Produktentwicklungsprozesses werden zunehmend Virtuelle Prototypen der Scheinwerfersysteme eingesetzt. Virtuelle Prototypen ermöglichen schon in frühen Phasen des Produktentwicklungsprozesses eine Überprüfung und Absicherung der Produktanforderungen. Die Simulation der Virtuellen Prototypen führt zu einer Reduzierung der für Tests erforderlichen physischen Prototypen. Das verkürzt den Produktentwicklungsprozeß und reduziert die Entwicklungskosten. Die einzelnen Domänen des Virtuellen Prototypen eines Scheinwerfersystems, wie z.B. die Gestalt, die Leuchtcharakteristika oder die thermischen und dynamischen Eigenschaften, werden mit spezialisierten Simulationswerkzeugen überprüft und auf mögliche Schwachstellen oder Designfehler untersucht. Eine domänenspezifische Simulation ist jedoch nicht immer ausreichend.

Oft werden domänenübergreifende Untersuchungen notwendig, welche die Ergebnisse der einzelnen Simulationen zusammenführen und am Virtuellen Prototypen darstellen. So überprüfen die Unternehmen aus der Automobilzulieferindustrie die Leuchteigenschaften der Scheinwerfer, indem der physische Prototyp im Meßkanal in einem definierten Abstand vor einer Messwand mit bekannten Reflektionsverhalten fixiert wird. Der Prototyp beleuchtet die Meßwand, und die von der Wand reflektierte Lichtmenge wird mittels eines Goniometers gemessen. Ergebnis der Vermessung ist ein Lichtstärkeverteilungsdatensatz, welcher in Abhängigkeit von dem Winkel zwischen Leuchtrichtung und Meßpunkt auf der Wand die reflektierte Lichtmenge angibt. Dieses Vorgehen wird statische Evaluierung genannt, da Position und Orientierung des Scheinwerfers relativ zur Meßwand während der Untersuchung unver ändert bleiben. Der Virtuelle Prototyp des Scheinwerfers wird analog evaluiert, indem der komplette Versuchsaufbau virtuell nachgebildet wird. Dazu wird die Lichtstärkeverteilung des Scheinwerfers mit einem spezialisierten Simulationswerkzeug berechnet, das zeitintensive Raytracingberechnungen zum Scheinwerferprototypen auf Basis der 3D-CAD-Modelldaten durchführt. Ergebnis des Raytracing ist ein Lichtstärkeverteilungsdatensatz, der auf die virtuelle Meßwand projiziert wird, um dann mit den Daten des physischen Prototypen verglichen zu werden. Entscheidend für die Qualität des Virtuellen Prototypen ist im statischen Fall die Genauigkeit, mit der die Leuchtcharakteristika des Scheinwerfers auf der virtuellen Meßwand wiedergegeben werden.

Bei der statischen Evaluierung bleiben jedoch die Einflüsse der Fahrzeugbewegungen unberücksichtigt, die während der Fahrt auf die Leuchtrichtung der Scheinwerfer einwirken und damit wesentlichen Einfluß auf die Ausleuchtung der Straße vor dem Fahrzeug haben. Daher können keine Aussagen über die dynamischen Leuchteigenschaften des Scheinwerfers während der Fahrt getroffen werden. Die Simulation des Einflusses der Fahrzeugbewegungen auf die Leuchtrichtung ist aber eine Grundvoraussetzung für die Eignung des Scheinwerfers in unterschiedlichen Fahrsituationen oder für die Evaluierung der mechatronischen Komponenten zur Lagesteuerung des Scheinwerfers. Somit wird eine dynamische Evaluierung notwendig, welche den Einfluß der Fahrzeugbewegungen auf die Leuchtrichtung der Scheinwerfer berücksichtigt.

Mit der dynamischen Evaluierung der physischen Prototypen ist jedoch ein erhöhter Aufwand verbunden. Anstelle einfacher Untersuchungen an der Projektionswand im Meßkanal werden zeitaufwendige und kostenintensive Nachtfahrten auf einer realen Versuchsstrecke notwendig. Zudem lassen sich einzelne Testfahrten nur bedingt vergleichen, da äußere Einflüsse wie Witterungsbedingungen oder die jeweilige Verkehrssituation nicht kontrollierbar sind, was eine aussagekräftige Auswertung der Testfahrten entscheidend erschwert. Eine dynamische Evaluierung am Virtuellen Prototypen erscheint daher aufgrund der zu erwartenden Zeit- und Kostenersparnis, sowie der im Simulator reproduzierbaren Testbedingungen viel versprechend. Genügte für die statische Evaluierung der virtuellen Scheinwerferprototypen eine qualitativ hochwertige Darstellung der Beleuchtung auf der Meßwand, wird für die dynamische Evaluierung zusätzlich eine hohe Darstellungsgeschwindigkeit notwendig. Die hohe Geschwindigkeit ist erforderlich, da der Einfluß der Fahrzeugbewegungen auf die Leuchtrichtung der Scheinwerfer und damit die Ausleuchtung des Straßenraums vor dem Fahrzeug ohne für den Anwenderl erkennbare Verzögerung und in realistisch empfundener Zeit wiedergegeben werden muß. Dafür müssen die Darstellung der Beleuchtung und die Simulation der Fahrzeugdynamik simultan und ausreichend schnell, also möglichst in Echtzeit, ablaufen.

Die zeitintensiven Raytracing-Berechnungen zur Ermittlung des Lichtstärkeverteilungsdatensatzes offline, d.h. vor der eigentlichen Simulation des virtuellen Scheinwerferprototypen, erfolgen. Online, also während der laufenden Simulation, müssen die Daten der Lichtverteilung ausreichend schnell und genau in der virtuellen Szenerie der simulierten Nachtfahrt dargestellt werden.

Kommerziell verfügbare Nachtfahrsimulatoren zur Evaluierung von Scheinwerferprototypen, bieten generell eine gute Darstellungsqualität des simulierten Scheinwerferlichtes, besitzen jedoch häufig eine zu geringe Darstellungsgeschwindigkeit für eine dynamische Evaluierung. Fahrsimulatoren für die Entwicklung der Fahrzeugdynamik liefern qualitativ hochwertige Ergebnisse für die Simulation der fahrdynamischen Eigenschaften des zu entwickelnden Fahrzeugs, weisen jedoch in der Beleuchtungssimulation deutliche Schwächen auf. Simulatorsysteme, die für Verkehrssicherheits- und Fahrertraining eingesetzt werden, weisen Stärken in den Bereichen Verkehrssimulation und Fahrerinteraktion auf. Eine detailgetreue Beleuchtungssimulation ist bei diesen Systemen jedoch von untergeordneter Bedeutung.

Zusammenfassend ist festzustellen, dass verfügbare Fahrsimulatorsysteme die hohen Anforderungen an die Darstellungsqualität und -geschwindigkeit nur unzureichend erfüllen. Gründe hierfür sind einerseits die unterschiedlichen Zielsetzungen und Verwendungszwecke der Fahrsimulatoren, andererseits die angewandten Lösungskonzepte und eingesetzten Technologien. Im Gegensatz zu den bestehenden Lösungen muß ein System zur Virtual Reality(VR)basierten Simulation der Virtuellen Prototypen von Scheinwerfersystemen die Anforderungen zur Darstellungsqualität und -geschwindigkeit erfüllen, um produktiv für die Evaluierung der Scheinwerferprototypen im Rahmen des Produktentwicklungsprozesses einsetzbar zu sein.

Bisherige Ansätze verwenden aus der Computergraphik einschlägig bekannte Verfahren, wie z.B. Per-Vertex Lighting, welche die Beleuchtungsdaten auf die Eckpunkte der für die Darstellung der virtuellen Szene verwendeten Polygonmodelle abbilden. Diesbezüglich Offenba rungen sind zu finden in Weber, Thomas; Plattfaut, Christian; Kleinkes, Michael; Berssenbrügge, Jan: Virtual Nightdrive. In: Driving Simulation Conference. Paris, France, 11-13 September 2002; Plattfaut, Christian; Kleinkes, Michael; Berssenbrügge, Jan: Nachtfahrsimulation – Scheinwerfer virtuell erleben. In: 1. Paderborner Workshop Augmented & Virtual Reality in der Produktentstehung Bd. 107, Heinz Nixdorf Institut, Universität Paderborn, 11 Juni 2002 (HNI-Verlagsschriftenreihe); Löwenau, J.P.; Strobl, M.H.; Bernasch, J.H.; Reich, F.M.; Rummel, A.H.: Evaluation of Adaptive Light Control in the BMW Driving Simulator.In: Driving Simulation Converence, Sophia Antipolis, France, 2001; Lecocq, P.; Kelada, J.M.; Kemeny, A.: Interactive Headlight Simulation. In: Proceedings of the Driving Simulation Conference, Paris, France, 1999.

Der wesentliche Nachteil all dieser bekannten Verfahren ist, dass sie, um eine qualitativ hochwertige Visualisierung der Scheinwerferbeleuchtung zu erreichen, Polygonmodelle benötigen, welche aus dichten Polygonnetzen bestehen, um die Leuchtwerte in genügend hoher Dichte auf dem Modell abbilden zu können. Das führt jedoch schnell zu sehr komplexen Polygonmodellen, welche nicht mehr schnell genug von gängiger PC-Hardware verarbeitet werden können, um die restriktiven Echtzeitanforderungen einer Nachtfahrsimulation zu erfüllen. Zudem müssen diese Polygonmodell meist sehr aufwendig an die speziellen Beleuchtungsanforderungen angepasst werden. Ergebnis dieser Ansätze ist eine Beleuchtungsvisualisierung, deren visuelle Qualität in hohem Maße von der polygonalen Unterteilung des 3D-Modells der virtuellen Szene abhängt. Eine Steigerung der visuellen Qualität kann bei diesen Ansätzen nur mit entsprechenden Performanzeinbußen bei der Verarbeitung durch die PC-Hardware erkauft werden.

Die Aufgabe der vorliegenden Erfindung ist es daher, ein Verfahren und eine Vorrichtung vorzusehen, die die beschriebenen Probleme umgeht, die einfach umsetzbar ist und sich wirtschaftlich einfach einsetzen lässt.

Diese Aufgabe wird durch die Merkmale der unabhängigen Ansprüche gelöst, wobei zweckmäßige Ausführungsformen durch die Merkmale der Unteransprüche beschrieben sind.

Vorgesehen ist ein Verfahren und eine Vorrichtung, bei denen bekannte Verfahren aus der Computergraphik (z.B. projective texturing und per-pixel lighting) aufgegriffen und mit dem Einsatz der Shader-Technologie moderner PC-Graphiksysteme kombiniert werden. Der Ansatz verwendet speziell aufbereitete hochauflösende Bilder (Texturen) der Lichtverteilungsdatensätze von Lichtquellen im Allgemeinen und Scheinwerfern im spezielleren, um diese durch die virtuellen Lichtquellen/Scheinwerfer wie ein Dia im Diaprojektor in eine virtuelle Szene zu projizieren.

Das Verfahren führt zu sehr hochwertigen Visualisierungen, welche die Beleuchtungsdaten der simulierten Lichtquellen/Scheinwerfersysteme pixel-genau wiedergeben. Dieses wird durch den Einsatz der Shader-Technologie auf Standard PC-Systemen mit ausreichend hoher Performanz möglich, um eine Darstellung quasi in Echtzeit zu erlauben.

Die erreichte qualitativ hochwertige Wiedergabe der Lichtquellen-/Scheinwerferbeleuchtung ist durch die Verwendung des projective texturing vollständig unabhängig von der polygonalen Unterteilung der 3D-Modelle zur Darstellung der virtuellen Szenerie. Die erreichbare visuelle Qualität hängt nur von den verwendeten Texturen zur Projektion der Lichtverteilung und von der verwendeten Auflösung am Bildschirm ab.

Mit diesem Ansatz wird eine high-quality und high-performance Visualisierung moderner Lichtquellen-/Scheinwerfersysteme im Rahmen einer virtuellen Nachtfahrsimulation auf Standard-PC's möglich. Die erreichte Darstellungsqualität übertrifft die der bisherigen Ansätze auch auf viel teureren spezialisierten Großrechnern.

Im spezielleren ist vorgesehen ein Verfahren zur Darstellung komplexer Scheinwerferlichtverteilungen in einer Simulationsumgebung, umfassend die Schritte:

a. Optionales Erzeugen einer konvertierten und verzerrten LSV-Textur soweot diese nicht bereits vorliegen
b. Erzeugen eines projizierten Abbildes der LSV-Textur in einer virtuellen Szenerie
c. Farbberechnung für jedes Pixel zur Darstellung der Beleuchtung der virtuellen Szenerie durch die simulierten Lichtquellen/Scheinwerfer.

Die Shader-basierte Darstellung der komplexen Lichtverteilungen moderner Lichtquellen/Scheinwerfersysteme funktioniert prinzipiell ähnlich wie ein Diaprojektor. Für die Dar stellung eines Bildes auf der Projektionsleinwand wird ein Dia vor die Lampe des Diaprojektors gebracht. Dann wird das Objektiv des Projektors justiert, damit ein scharfes Abbild des Dias auf die Leinwand projiziert wird. In Abhängigkeit von Öffnungswinkel und Zoom des Objektivs wird das Dia in der entsprechenden Größe auf die Leinwand projiziert. Analog zum Diaprojektor verwendet das in dieser Anmeldung vorgesehene Verfahren für die Shaderbasierte Darstellung komplexer Lichtverteilungen das Bild eines aufbereiteten Datensatzes, der die Lichtstärkeverteilung (LSV) des Scheinwerfers enthält.

Grundlegend für das in dieser Anmeldung verwendete Beleuchtungsmodell sind die nachfolgend aufgeführten und nach DIN 5031 definierten lichttechnischen Größen. Sie bilden die Grundlage für ein physikalisches Beleuchtungsmodell.

Lichtstrom: Die Glühlampe in einem Scheinwerfer strahlt gleichmäßig nach allen Seiten den Lichtstrom mit der Einheit Lumen ab. Der Lichtstrom ist die Lichtenergie, welche pro Zeiteinheit von der Glühlampe abgegeben wird.

Lichtstärke: Die Lichtstärke beschreibt die Richtungsabhängigkeit des ausgesandten Lichtstroms. Da der Lichtstrom der Glühlampe am Reflektor reflektiert und an der Scheinwerferabschlußscheibe gebrochen wird, strahlt der Scheinwerfer den Lichtstrom nicht gleichmäßig in den Straßenraum vor dem Fahrzeug ab. Somit ergibt sich in Abhängigkeit von der Abstrahlrichtung die Lichtstärke als Quotient aus dem Lichtstrom und dem durchstrahlten Raumwinkel. Rotationssymmetrische Lichtstärkeverteilungen sind in einer Dimension vermessen und werden durch die Lichtstärkeverteilungskurven definiert. Bei komplexeren Lichtstärkeverteilungen wird die Lichtstärke in Abhängigkeit von den Raumwinkeln und zur Leuchtrichtung des Scheinwerfers erfaßt. Dies führt zu den bereits genannten Lichtstärkeverteilungen (LSV), welche die Leuchtcharakteristika des jeweiligen Scheinwerfers definieren.

Beleuchtungsstärke: Fällt das vom Scheinwerfer abgestrahlte Licht auf eine Fläche, wird diese beleuchtet. Entsprechend ergibt sich die Beleuchtungstärke aus dem Quotienten zwischen Lichtstrom und der beleuchteten Fläche. Während die Lichtstärke die Richtungsabhängigkeit des Lichtstroms beschreibt, gibt die Beleuchtungsstärke die Flächenabhängigkeit des Lichtstroms wieder.

Nach dem photometrischen Entfernungsgesetz nimmt die Beleuchtungsstärke mit wachsender Entfernung zur beleuchteten Fläche ab, da sich der Lichtstrom auf eine immer großer werdende Fläche verteilt.

Leuchtdichte: Das Licht, das von der beleuchteten Fläche abgestrahlt wird, kann vom menschlichen Auge als Helligkeit wahrgenommen werden. Die entsprechende meßbare lichttechnische Größe heißt Leuchtdichte. Sie ergibt sich aus dem Quotienten der Lichtstärke , die aus der leuchtenden oder beleuchteten Fläche unter dem Winkel austritt, und der Projektion der Fläche senkrecht zur Blickrichtung des Betrachters.

Die Leuchtdichte gibt somit die Lichtstärke in Richtung an, welche unter der Projektion der Fläche vom Betrachter als Helligkeit wahrgenommen wird. Unter dem Betrachtungswinkel zwischen der Flächennormalen und der Fläche erscheint die Fläche um den Faktor verkürzt.

Photometrisches Grundgesetz: Das photometrische Grundgesetz definiert den Lichtstrom, der von einer leuchtenden Fläche (Sender) auf eine beleuchtete Fläche (Empfänger) übertragen wird. Der Lichtstrom hängt dabei ab von der Leuchtdichte des Senders, dem Abstrahlwinkel, dem Einstrahlwinkel, der Distanz zwischen den Flächen und den Projektionen der Sender- und Empfängerfläche, durch welche der Lichtstrom von der Senderfläche abstrahlt beziehungsweise auf der Empfängerfläche einstrahlt. ist der Einheitsraumwinkel.

Das Bild der Lichtstärkeverteilung des Scheinwerfers wird in dem Verfahren nach dieser Anmeldung ähnlich wie eine Textur verwendet und daher wie folgt definiert:
Die Lichtstärkeverteilungs-Textur (kurz LSV-Textur) stellt die planare Projektion des Datensatzes der Lichtstärkeverteilung (LSV) eines Scheinwerfers auf eine ebene Fläche dar.

Das Verfahren nach dieser Anmeldung zeichnet sich weiterhin dadurch aus, dass zur Erzeugung der konvertierten und verzerrten LSV-Texturen die in einem Kugelkoordinatensystem vermessenen Leuchtdichtewerte von Scheinwerfern zur Darstellung der Texel der Textur in ein kartesisches Koordinatensystem umgerechnet werden. Die Umrechnung ist notwendig, damit Projektionsfehler vermieden werden. Die Ausgangswerte der LSV-Verteilung können auf verschiedene Weise in Texel-Werte der LSV-Textur konvertiert werden, so daß in Phase 3 des Verfahrens unterschiedlich shader-basierte Beleuchtungsmodelle eingesetzt werden können. Je nach Übersetzung der LSV-Werte in Texel-Werte ergeben sich unterschiedliche LSV-Texturen für den Einsatz in den verschiedenen Beleuchtungsmodellen innerhalb der Shader. Die Aufbereitung des LSV-Datensatzes in eine LSV-Textur erfolgt durch ein separates Konvertierungsprogramm offline, d.h. vor der Nachtfahrsimulation.

Weiterhin kann sich das Verfahren nach Maßgabe der vorliegenden Erfindung, dadurch auszeichnen, dass die Projektion der LSV-Textur in die virtuelle Szenerie mittels Projective Texture Mapping gemäß den Projektionsparametern, welche sich aus den Öffnungswinkeln der Scheinwerfer ableiten, erfolgt, wobei sich bedingt durch die unterschiedlichen Öffnungswinkel der Scheinwerfer eine asymmetrische Projektion ergeben kann.

Die Berechnung der Texturkoordinaten für die Abbildung der LSV-Textur auf das Polygonmodell der virtuellen Szenerie können desweiteren in einem Vertex-Shader erfolgen, wobei für jeden Eckpunkt des Polygonmodells die entsprechenden Texturkoordinaten der projizierten LSV-Textur berechnet werden.

Darüber hinaus können zur Farbberechnung für jedes Pixel für die Wiedergabe der Beleuchtung Grautöne für eine Echtfarbdarstellung oder Farbwerte aus dem HSV-Farbmodell für eine Falschfarbdarstellung verwendet werden. Das Beleuchtungsmodell umfaßt für die Farbberechnung u.a. die einzelnen Lichtanteile gemäß der diffusen, ambienten und spiegelnden Reflexion sowie Faktoren zu deren Gewichtung. Ausgangsbasis für die Farbberechnung bildet die jeweilige Texturfarbe der virtuellen Szenerie. Sie entspricht der Beleuchtung der Szenerie bei Tageslicht, was in einem sehr einfachen Beleuchtungsmodell einem ambienten Lichtanteil von 100% entspricht. Nach Abschluß der Phase 2 steht fest, welches Texel der LSV-Textur an welche Stelle in die virtuelle Szenerie projiziert wird, d.h. welcher Teil des Scheinwerferlichtes wo in die virtuelle Szenerie fällt. Der Wert des Texels aus der LSV-Textur bildet in Phase 3 die Grundlage für die Berechnung der Beleuchtung durch die Scheinwerfer. Die Berechnung kann anhand unterschiedlicher Beleuchtungsmodelle erfolgen, welche dafür die entsprechenden LSV-Texturen aus Phase 1 des Verfahrens verwenden. Für die Darstellung der Beleuchtung der nächtlichen Szene durch die Fahrzeugscheinwerfer wird abschließend die Texturfarbe des Szeneriemodells mit dem auf Basis der LSV-Textur und des verwendeten Beleuchtungsmodells errechneten Lichtanteil modifiziert und als beleuchtete Szenerie darge stellt. Ergebnis der Phase 3 ist eine entsprechend den Scheinwerferleuchtcharakteristika beleuchtete virtuelle Szenerie

Das Verfahren nach Maßgabe der vorliegenden Erfindung kann sich weiterhin auch dadurch auszeichnen, dass zur Bereitstellung der LSV-Textur aus den Lichtverteilungsdaten eines Scheinwerfers eine byte-weise Kodierungen der LSV-Werte in Farbtripel erfolgt, die in den einzelnen Farbkanälen der LSV-Textur gespeichert werden, wobei die LSV-Werte in drei Bytes mit der Wertigkeit 256₀, 256₁ und 256₂ kodiert und direkt als RGB-Tripel in der LSV-Textur gespeichert werden.

Weiterhin können die sich auf dem Segment einer Kugeloberfläche befindenden Ausgangswerte des LSV-Datensatzes durch eine planare Projektion auf die ebene Fläche der LSV-Textur abgebildet werden, zur Projektion in die 3D-Szenen anhand des Projective Texture Mapping.

Das Verfahren kann sich auch dadurch auszeichnen, dass die Größe der LSV-Textur skaliert wird, wobei die Skalierung so gewählt ist, dass im Bereich der unmittelbaren Umgebung der Leuchtrichtung das Abbild eines projizierten LSV-Wertes auf der LSV-Textur der Größe eines Texels entspricht.

Schließlich kann nach dem Verfahren die Berechnung der endgültigen Farbe für die Beleuchtung jedes Pixels innerhalb des Pixel-Shaders erfolgen und die Parameter:

d. Anteil der Beleuchtung hervorgerufen durch die Kfz-Scheinwerfer gemäß dem vorhergehenden Beleuchtungsmodell,
e. Eigenfarbe der Objekte in der virtuellen Szenerie bei Tageslicht, gegeben durch die Texturfarbe der Objekte, und
f. Reflexionsparameter der Objekte entsprechend der Materialeigenschaften

umfassen.

Weitere Eigenschaften und Vorteile der vorliegenden Erfindung ergeben sich aus der folgenden Beschreibung einer bevorzugten Ausführungsform der Erfindung unter Bezugnahme auf die beigefügten Zeichnungen, darin zeigt:
1 das Prinzip der Shader-basierten Projektion einer LSV-Textur in eine virtuelle Szenerie;
2 die prinzipielle Einordnung der Shader-Technologie in die Renderingpipeline;
3 Mögliche Performance-Engpässe in einer programmierbaren Renderingpipeline und Maßnahmen zur deren Vermeidung;
4 das Phasenmodell zur Gliederung des Verfahrens zur Shader-basierten Darstellung komplexer Lichtverteilungen;
5 die Untergliederung der Aufbereitung der Lichtstärkeverteilungsdaten in Subphasen zur Konvertierung und Verzerrung der Ausgangsdate;
6 die planare Projektion der LSV-Daten von dem Kugelsegment aus der Scheinwerfervermessung auf die Ebene der LSV-Textur;
7 die planare Projektion der LSV-Daten auf die LSV-Textur;
8 Resultate zu Phase 1 am Beispiel einer nach dem HSV-Modell farbkodierten Scheinwerferlichtverteilung;
9 die symmetrische und asymmetrische Projektion am Beispiel des rechten Frontscheinwerfers gemäß den unterschiedlichen Öffnungswinkeln;
10 die Projektion der LSV-Textur: Fehlerfreie Projektion der konvertierten LSV-Textur gemäß der Subphasen 1.2 und 1.3 und fehlerbehaftetet Projektion (Verzerrungen) der LSV-Textur bei Auslassen der Subphase 1.2 und 1.3;
11 ein Beleuchtungsmodell für die virtuelle Nachtfahrt;
12 einen Überblick über die einzelnen Subphasen aus Phase 3 zur Berechnung der Komponenten des Beleuchtungsmodells und Darstellung der erzielten Resultate mit dem jeweiligen Effekt auf die Beleuchtung der virtuellen Szenerie;
13 eine Vorgehensweise zur Optimierung der Performance des Shader-basierten Verfahrens;
14 die gleichbleibende Bildqualität bei unterschiedlichen Varianten zum 3D-Modell der Teststrecke;
15 die Positionsabhängige Polygon- und Pixellast;
16 den Einfluß des Zoning auf die Polygonlast; und
17 die Architektur einer Umsetzung des Verfahrens nach den 1-16.
In 1 ist dargestellt, wie eine LSV-Textur vor der virtuellen Lichtquelle positioniert und entsprechend der Projektionsparameter in die 3D-Szene projiziert wird. Dabei wird die Shader-Technologie eingesetzt. Dabei erfolgt die Darstellung einer 3D-Szene am Bildschirm an hand des in 2 links vereinfacht dargestellten Bildgenerierungsprozesses, der alle notwendigen Schritte umfaßt, um das 3D-Polygonmodell einer virtuellen Szene auf dem Ausgabemedium, z.B. einem Bildschirm, darzustellen.
Konventionelle Renderingpipeline: Als erster Schritt des Bildgenerierungsprozesses werden innerhalb der VR-Anwendung einzelne 3D-Objekte der Szene gemäß ihrer Sichtbarkeit durch die CPU selektiert und nur solche 3D-Objekte an die GPU gesendet, die für den Benutzer innerhalb einer VR-Anwendung sichtbar sind. Die CPU sendet einen Strom von 3D-Polygonen der entsprechenden 3D-Objekte an die GPU.
Innerhalb der GPU erfolgt zunächst die Polygonverarbeitung. Im Rahmen der Modelltransformation werden zur Darstellung von Objektbewegungen die 3D-Polygone zuerst anhand von Transformationsmatrizen im 3D-Raum positioniert und ausgerichtet. Es folgt die Berechnung der Beleuchtung der 3D-Polygone anhand von Reflexionsmodellen aus gemäß dem Per-Vertex Lighting.
Im nächsten Schritt werden die 3DPolygone durch eine perspektivische Projektion auf 2D-Polygone abgebildet und damit vom Objektkoordinatensystem in Bildkoordinaten umgerechnet. Die resultierenden 2D-Polygone werden abschließend durch das 2D-Clipping auf die Maße des virtuellen Bildes der 3D-Szene (View Port) begrenzt.
Die Polygonverarbeitung ist damit abgeschlossen.
Im Rahmen der Rasterung werden als Nächstes die 2D-Vektordaten in Fragmente umgewandelt, indem die 2D-Polygone auf ein diskretes Raster – die späteren Pixel am Bildschirm – interpoliert werden. Die Fragmente umfassen neben den Pixeln auch deren jeweilige Informationen für Farbe, Tiefenwert und Texturkoordinaten.
In der Pixelverarbeitung erfolgt abschließend die Konvertierung der Fragmente in die Pixel am Bildschirm. Dazu wird nach einer Tiefenauswertung des Pixels die endgültige Farbe der Pixel auf der Basis der assoziierten Fragmentdaten und zusätzlicher Texturoperationen anhand des Flat- oder Gouraud- Schattierungsmodells.
Entlang des Bildgenerierungsprozesses sinkt der Abstraktionsgrad von komplexen 3D-Objekten über einzelne Polygone bis hin zu einfachen Pixeln (vgl. schematische Darstellung in 2, mitte). Dem sinkenden Abstraktionsgrad entsprechend steigt der Strom der zu verarbeitenden Daten innerhalb des Prozesses sehr stark von einigen tausend 3D-Objekten auf bis zu mehreren Millionen Pixel pro Bild an. Dabei entspricht diese Pixelzahl nicht der eigentlichen Auflösung des Ausgabemediums (z.B. Bildschirm), sondern entspricht den einzelnen, auf Pixel diskretisierten Polygonen der Szene. Dieser Wert liegt je nach Beschaffenheit und räumlicher Tiefe der 3D-Szene um ein Vielfaches über der eigentlichen Bildschirmauflösung.
Damit die für VR-Anwendungen erforderliche Echtzeitfähigkeit erfüllt wird, wurde dieser Bildgenerierungsprozeß standardisiert und in Form der Renderingpipeline vollständig in der Hardware des Graphiksystems implementiert. Die Implementierung in Hardware brachte jedoch eine Beschränkung auf einen festgelegten und eingeschränkten Funktionsumfang der Renderingpipeline mit sich. So erlaubten hardwaretechnische Grenzen nur die Verwendung einer festen Anzahl von Parametern als Eingabe für die Pipeline, wie z.B. die Beschränkung der Anzahl und Auflösung der verwendeten Texturen oder der unterstützten Reflexionsmodelle (meist einfache Modelle) und Schattierungsmodi (meist Flat- und Gouraud-Shading).
Bedingt durch die rasante Entwicklung in der Graphikhardware wurden diese Beschränkungen schnell gelockert, so dass z.B. die 3D-Graphikdaten nach dem SIMD5-Prinzip in mehreren Renderingpipelines parallel verarbeitet wurden oder mehrere Texturen für die Farbdarstellung kombiniert werden konnten (Multitexturing). Der Funktionsumfang der Renderingpipeline blieb jedoch bedingt durch die Standardisierung immer fixiert.
Programmierbare Renderingpipeline (Shader-Technologie): Moderne Graphiksysteme überwinden zunehmend diese Einschränkung auf eine fixierte Funktionalität. Sie ermöglichen eine anwendungsspezifische Anpassung der Renderingpipeline an die jeweiligen Anforderungen. Dies wird möglich durch die Vertex- und Pixel-Prozessoren (vgl. 2 rechts).
Analog zu der Polygonverarbeitung in der konventionellen Renderingpipeline verarbeitet der Vertex-Prozessor jedes 3D-Polygon des Datenstroms, das von der Anwendung an das Graphiksystem geleitet wird. Entsprechend verarbeitet der Pixel-Prozessor weiter unten in der Pipeline sämtliche Fragmente, die durch Konvertierung der 2D-Polygone in der Raster- Einheit entstehen, zu einzelnen Pixeln in der Darstellung der 3D-Szene am Bildschirm.
Die Vertex- und Pixel-Prozessoren ermöglichen die freie Programmierbarkeit der Abschnitte zur Polygon- und Pixelverarbeitung innerhalb der Renderingpipeline. Die zuvor fixierte Funktionalität innerhalb der Polygon- und Pixelverarbeitung wird hier durch benutzerspezifischen Programmcode ersetzt. Der Benutzer kann der C-ähnlichen Hochsprache CG (C for Graphics) die Funktionalität der Renderingpipeline somit speziell an seine Anwendungsanforderungen anpassen.
So kann z.B. innerhalb des Vertex-Prozessors der GPU die konventionelle Modelltransformation derart abgewandelt werden, dass das 3D-Modell die Transformationsmatrizen aus der Simulation eines Mehrkörpersystems übernimmt, ohne dass – wie in der konventionellen Methode – zeitaufwendig der Szenengraph durch die CPU in der jeweiligen Anwendung modifiziert werden muß. Weiter lassen sich aufwendigere Reflexionsmodelle, wie z.B. das Bidirectional-Reflection-Function Modell (BDRF) oder spezielle Projektionsarten mit Linseneffekten wie die Fish-Eye-Projektion integrieren.
Auf gleiche Weise kann der Pixel-Prozessor der GPU für eine komplexere Farbberechnung der Pixel verwendet werden. So kann z.B. das Per-Pixel Lighting in Form der Phong-Schattierung integriert werden, welches das Per-Vertex Lighting der konventionellen Renderingpipeline qualitativ deutlich übertrifft. Die eigentliche Stärke moderner Pixel-Prozessoren liegt in der Kombination vielfältiger Texturen für die Farbberechnung der Pixel.
Texturen liefern beispielsweise die Datengrundlage für Ansätze wie das Bump-Mapping zur Darstellung rauher Oberflächen oder das Gloss-Mapping zur Darstellung spiegelnder Effekte auf ansonsten matten Oberflächen.
Auf diese Weise läßt sich die Standardfunktionalität der konventionellen Renderingpipeline durch benutzerspezifischen Code deutlich erweitern. Wie die pixel-genauen Ansätze ermöglichen Vertex- und Pixel-Shader eine Darstellungsqualität, die nur von der gewählten Pixelauflösung des Bildschirms abhängt. Die Performance ist somit in hohem Maße abhängig von der gewählten Bildschirmauflösung. Dieser Faktor ist jedoch relativ unkritisch, da der Performance-Sprung im Bereich der Vertex- und Pixel-Shader bei den heutigen Graphiksystemen mit jeder neuen Modellgeneration (ca. alle 6-12 Monate) in etwa Faktor 4-8 entspricht. Im Vergleich dazu liegt der Performance-Gewinn im Bereich der Polygonverarbeitung auf modernen Graphiksystemen in etwa bei Faktor 2. Dieses verdeutlicht die Entwicklungsdynamik der Graphiksysteme (engl. graphics processing units, GPUs) im Bereich der Shader-Technologie, aber auch bei der Polygonverarbeitung.
Besonders deutlich wird die Dynamik im Vergleich zur Entwicklung der Prozessoren (engl. central processing units, CPUs), welche ihre Performance nach Moore's Law nur etwa alle 18 Monate verdoppeln. Eine Anwendung dieser neuen Technologie insbesondere innerhalb der echtzeitfähigen Beleuchtungssimualtion erscheint daher besonders attraktiv.
Der Einsatz von benutzerspezifischem Shader-Code bedeutet einerseits einen hohen Nutzen durch die große Flexibilität in der Anwendung der Pipeline. Andererseits müssen aber die Risiken eigenentwickelten Shader-Codes beachtet werden, die in Form von Engpässen innerhalb der Polygon- und Pixelverarbeitung auftreten können. 3 zeigt dazu auf der linken Seite nochmals die programmierbare Renderingpipeline auf Basis der Shader-Technologie. Auf der rechten Seite ist schematisch die Datenmenge in der Renderingpipeline dargestellt, welche – bedingt durch den sinkenden Abstraktionsgrad der zu verarbeitenden Daten – ohnehin entlang der Pipeline kontinuierlich ansteigt.
Innerhalb der Pipeline ergeben sich auf diese Weise zwei mögliche Engpässe, die zu einem Stau führen können: Eine zu hohe Polygonlast (engl. polygon-count) innerhalb des Vertex-Prozessors, die den maximalen Polygondurchsatz der GPU übersteigt und eine zu große Pixellast (engl. pixel-filling), innerhalb des Pixel-Prozessors, die die maximale Pixelfüllrate der GPU übersteigt.
Um einen Verarbeitungsstau innerhalb der Pipeline zu vermeiden (vgl. stark breiter werderne Datenpyramide in der Mitte von 3), gilt es, die Datenmenge in der Pipeline einerseits so früh wie möglich zu reduzieren und andererseits, die Verarbeitung der Daten so effizient wie möglich zu gestalten.
Dafür bieten sich im Wesentlichen die folgenden drei Ansatzpunkte innerhalb des Bildgenerieurngsprozesses an:

– bei der CPU-basierten Verarbeitung innerhalb der Anwendung vor der Renderingpipeline,
– bei der Polygonverarbeitung innerhalb des Vertex-Prozessors der GPU, und entsprechend
– bei der Pixelverarbeitung innerhalb des Pixel-Prozessors der GPU.

Folgende Maßnahmen zur Vermeidung von Verarbeitungsengpässen innerhalb der GPU sind denkbar:

– Einsatz geeigneter komplexitätsreduzierender Verfahren, z.B. LOD, Visibility Culling, etc., um sicherzustellen, daß nur die für die Darstellung absolut notwendigen 3D-Daten an die GPU gesandt werden.
– Optimierung des Programmcodes im Vertex-Shader, um einen möglichst hohen Datendurchsatz innerhalb des Vertex-Shaders sicherzustellen.

Dafür sollte der Programmcode mit einem Minimum an Operationen möglichst effizient die notwendigen Berechnungen durchführen.
Analoges gilt für die Optimierung des Programmcodes im Pixel-Shader.
Die erste Generation von Graphiksystem mit Shader-Technologie verfügte lediglich über sehr einfache Datentypen. Zudem war die Anzahl der möglichen Instruktionen innerhalb der Vertex- und Pixel-Prozessor-Routinen zunächst sehr begrenzt, was die mögliche Rechengenauigkeit und Programmkomplexität stark einschränkte. Durch die rasante Entwicklung im Bereich der Shader-Technologie wurden diese Einschränkungen jedoch schnell aufgehoben, so daß auf Graphiksystemen der aktuellen Generation selbst komplexe Berechnungen durch die Vertex- und Pixel-Prozessoren innerhalb der GPU möglichen werden. Dabei kann die inhärente parallele Architektur moderner Graphikprozessoren, bedingt durch die mehrfache Auslegung der Renderingpipeline innerhalb der GPU, intensiv genutzt werden. Die GPU kann somit als eine Art Streamline-Prozessor eingesetzt werden, der große Datenmengen schneller und effizienter verarbeitet als die CPU und diese zunehmend auch für nicht graphikspezifische Aufgaben ersetzt.
Innerhalb des Vertex-Prozessors werden die Positionen, Normalen und Eckpunkte des Poly gonstroms verarbeitet, der durch die Renderingpipeline fließt. Der Vertex-Prozessor bietet sich daher besonders für den Einsatz in Simulationen von Partikelsystemen Simulation von an, bei denen eine sehr große Anzahl immer gleicher Daten verarbeitet werden muß. Auch für eine echtzeitfähige Kollisionserkennung der Partikel untereinander bietet sich ein GPU-basierter Ansatz an. Weitere Anwendungen finden sich im Bereich der Echtzeit-Darstellung von hochkomplexen Polygonmodellen.
Der Pixel-Prozessor verarbeitet sehr effizient hochauflösende Texturen für die Darstellung der Pixelfarben. Der Pixel-Prozessor bietet sich daher besonders für textur-basierte Verfahren an, z.B. für Bildverarbeitungsanwendungen zur Objekterkennung oder für die Simulation und Darstellung von Erscheinungen aus der Natur (engl. Natural phenomena). In seiner Dissertation über die GPU-basierte Simulation und das Echtzeitrendering von realitätsnahen Wolkendarstellungen für Flugsimulatoranwendungen gibt Harris eine gute Übersicht über GPU-basierte Strömungssimulationen. Harris beschreibt unter anderem die Simulation von kochendem Wasser durch Coupled Map Lattices (CML), einer Art diskretem Gitter, dessen Gitterpunkte verschiedene physikalische Größen (Temperatur, Druck, Geschwindigkeit, etc.) speichert. Zur Nachbildung von Konvektion, Diffusion und weiteren physikalischen Effekten werden in jedem Simulationsschritt die Wechselwirkungen der einzelnen Gitterpunkte untereinander simuliert und die Ergebnisse wieder in das Gitter übertragen.
Das Gitter kann einerseits als diskretes Polygonmodell gespeichert und im Vertex-Prozessor oder konventionell in der CPU verarbeitet werden (analog zu konventionellen FEM-Anwendungen). Effizienter ist jedoch die Speicherung des Gitters als Textur, die sehr schnell und effizient im Pixel-Prozessor verarbeitet werden kann. Der Ansatz von Harris erreicht gegenüber der konventionellen Simulation in der CPU einen Performance-Gewinn um den Faktor zehn.
Auf ähnliche Weise ist auch eine Verlagerung von FEM-Berechnungen in den Pixel-Prozessor der GPU denkbar. Durch die hohe Rechenleistung moderner GPUs sollte die Verlagerung kürzere Simulationszeiten ermöglichen und erspart zudem die aufwendige Übertragung und Verarbeitung des Polygonmodells des FEM-Gitters in der GPU.
Erste Anwendungen der Pixel-Prozessoren finden sich auch im Bereich der globalen Beleuch tungssimulation im Rahmen von Raytracing und Radiosity. Der Pixel-Prozessor läßt sich zudem für eine realitätsnahe visuelle Darstellung der komplexen Materialeigenschaften von Bauteilen in 3D-CAD-Systemen einsetzen.
Durch die zunehmende Flexibilität in der Programmierbarkeit der GPU, lassen sich die Datenstrukturen des Vertex- und Pixel-Prozessors der GPU auch auf nichtgraphikspezifische Anwendungsgebiete übertragen, so dass die GPU zunehmend für atypische Aufgaben zweckentfremdet wird.
Beispielsweise können die RGB-Farbtripel zur Speicherung der räumlichen Komponenten von Größen wie Position, Geschwindigkeit oder Beschleunigung verwendet werden, anstatt die Farbkomponenten für die Grundfarben Rot, Grün und Blau zu speichern. Auf diese Weise kann die GPU anstelle von Farbberechnungen auch numerische Berechnungen zur Simulation der Dynamik von Mehrkörpersystemen oder anderen Simulationsmodellen durchführen.
Zudem bestehen einige Ansätze zur Verlagerung von numerischen Simulationen in die GPU. Letzterer überträgt für eine GPU-basierte Visualisierung einer Strömungssimulation die Lösung von algebraischen Gleichungen als Grundlage für die numerische Simulation von Navier-Stokes-Gleichungen in die GPU. Diese führt aufgrund ihrer hohen Fließkommagenauigkeit die numerischen Berechnungen wesentlich schneller und effizienter durch als eine CPU. Zudem müssen die Ergebnisse der Berechnungen nicht aufwendig in die GPU transferiert werden und können somit direkt für die Visualisierung der Strömungssimulation eingesetzt werden.
Nach Maßgabe der gezeigten Ausführungsform bildet der Vertex-Shader zuerst die 3D-Szene perspektivisch ab (1), berechnet als nächstes die Reflexionswerte für die diffuse und spiegelnde Reflexion gemäß den Materialeigenschaften im Polygonmodell (2), um dann die LSV-Textur in die 3D-Szene zu projizieren (3). Ist die Projektion des LSV-Datensatzes erfolgt, führt der Pixel-Shader eine pixel-genaue Licht und Farbberechnung durch. Grundlage für die Shader-Berechnungen sind die entsprechenden Lichtstärkewerte (4) der projizierten LSV-Textur. Sie gehen neben der Lichtabschwächung (5), den Lichtanteilen aus der Lichtreflexion an den verschiedenen Materialien in der 3D-Szene (6) und den Texturen der 3D-Szene (7) in die Licht- und Farbberechnungen für jedes einzelne Pixel ein und ermöglichen auf diese Weise die hohe Darstellungsqualität des Verfahrens. Bei herkömmlichen Verfahren, wie dem Projective Texture Mapping, liefern die projizierten Texel der Texturen lediglich einen zusätzlichen Farbanteil für die Berechnung der endgültigen Farbe. Im Gegensatz dazu bilden bei dem Ansatz dieser Anmeldung die projizierten Texel die Grundlage für die Berechnungen zur endgültigen Pixelfarbe innerhalb der Shader-Routinen.
Im Gegensatz zum Multitexturing, bei dem die Texel-Farbwerte direkt mit der endgültigen Pixelfarbe kombiniert werden, stellt die LSV-Textur bei diesem Ansatz eine Art Speicher dar, der die Ausgangswerte für die Farbberechnung im Pixel-Shader liefert. Letztlich kann in den Vertex- und Pixel-Shader-Routinen ein vollständiges Beleuchtungsmodell implementiert werden. Je nachdem welche Eingangsdaten die Shader-Routinen über die LSV-Texturen erhalten, ergeben sich so unterschiedliche Modelle zur Beleuchtungssimulation.
Die Möglichkeit, die LSV-Texturen quasi als Datenquelle für aufwendigere Berechnungen zur Beleuchtungsdarstellung innerhalb der Shader-Routinen zu verwenden, macht das in dieser Anmeldung offenbarte Shader-baierte Verfahren im Vergleich zu herkömmlichen Ansätzen auf Basis von Projective Texture Mapping so flexibel. Zudem ermöglicht der Einsatz unterschiedlicher Shader-Routinen den Vergleich verschiedener Berechnungsmodelle für die endgültige Pixel-Farbe und damit letztlich unterschiedlicher Beleuchtungsmodelle für die Simulation des Scheinwerferlichts.
Das Verfahren für die Shader-basierte Beleuchtungssimulation untergliedert sich – wie in 4 dargestellt – in drei Phasen.
Dabei legt Phase 1 fest, welche Beleuchtungsdaten projiziert werden sollen. Phase 2 beschreibt, an welche Stelle in die virtuelle Szenerie die Beleuchtungsdaten projiziert werden. Phase 3 definiert, wie die Beleuchtungsdaten schließlich dargestellt werden. Die einzelnen Phasen werden zunächst überblickartig vorgestellt.
In der Phase 1 werden die Rohdaten einer Scheinwerferlichtverteilung für den Einsatz innerhalb des Verfahrens aufbereitet. Die in dieser Arbeit verwendeten Lichtstärkeverteilungsdatensätze basieren auf gemessenen Lichtverteilungen eines Herstellers von Kfz-Scheinwerfern. Die Lichtverteilungen der Scheinwerfer sind in einen Kugelkoordinatensystem vermessen.
Damit der Ausgangsdatensatz als LSV-Textur projiziert werden kann, müssen die Leuchtdichtewerte aus dem Kugelkoordinatensystem in ein kartesisches Koordinatensystem zur Darstellung der Texel der Textur umgerechnet werden. Die Umrechnung ist notwendig, damit Projektionsfehler vermieden werden. Die Ausgangswerte der LSV-Verteilung können auf verschiedene Weise in Texel-Werte der LSV-Textur konvertiert werden, so daß in Phase 3 des Verfahrens unterschiedliche Shader-basierte Beleuchtungsmodelle eingesetzt werden können. Je nach Übersetzung der LSV-Werte in Texel-Werte ergeben sich unterschiedliche LSV-Texturen für den Einsatz in den verschiedenen Beleuchtungsmodellen innerhalb der Shader. Die Aufbereitung des LSV-Datensatzes in eine LSV-Textur erfolgt durch ein separates Konvertierungsprogramm offline, d.h. vor der Nachtfahrsimulation.
Ergebnis der Phase 1 ist eine konvertierte und verzerrte LSV-Textur, die direkt für die Projektion in Phase 2 eingesetzt werden kann.
In Phase 2 erfolgt die Projektion der LSV-Textur in die virtuelle Szenerie mittels Projective Texture Mapping gemäß den Projektionsparametern, welche sich aus den Öffnungswinkeln der Scheinwerfer ableiten. Bedingt durch die unterschiedlichen Öffnungswinkel der Scheinwerfer ergibt sich eine asymmetrische Projektion. Die Berechnung der Texturkoordinaten für die Abbildung der LSV-Textur auf das Polygonmodell der virtuellen Szenerie erfolgt im Vertex-Shader. Hier werden für jeden Eckpunkt (engl. vertex) des Polygonmodells die entsprechenden Texturkoordinaten der projizierten LSV-Textur berechnet. Bei der Projektion der LSV-Textur erfolgt in dieser Phase jedoch noch keine Kombination der Texturen der 3D-Objekte aus der virtuellen Szenerie mit der LSV-Textur. Die Verrechnung der LSV-Textur mit der Pixel-Farbe zur Darstellung der Beleuchtung erfolgt erst bei der Farbberechnung auf Basis des jeweiligen Beleuchtungsmodells im Pixel-Shader in Phase 3 des Verfahrens. Ergebnis der Phase 2 ist ein projiziertes Abbild der LSV-Textur in der virtuellen Szenerie.
In Phase 3 des Verfahrens erfolgt die eigentliche Farbberechnung für jedes Pixel zur Darstellung der Beleuchtung der virtuellen Szenerie durch die simulierten Scheinwerfer. Dabei werden für die Wiedergabe der Beleuchtung Grautöne für eine Echtfarbdarstellung oder Farbwerte aus dem HSV-Farbmodell für eine Falschfarbdarstellung verwendet. Das Beleuchtungsmodell umfaßt für die Farbberechnung u.a. die einzelnen Lichtanteile gemäß der diffusen, ambienten und spiegelnden Reflexion sowie Faktoren zu deren Gewichtung. Ausgangsbasis für die Farbberechnung bildet die jeweilige Texturfarbe der virtuellen Szenerie. Sie entspricht der Beleuchtung der Szenerie bei Tageslicht, was in einem sehr einfachen Beleuchtungsmodell einem ambienten Lichtanteil von 100% entspricht.
Nach Abschluß der Phase 2 steht fest, welches Texel der LSV-Textur an welche Stelle in die virtuelle Szenerie projiziert wird, d.h. welcher Teil des Scheinwerferlichtes wo in die virtuelle Szenerie fällt.
Der Wert des Texels aus der LSV-Textur bildet in Phase 3 die Grundlage für die Berechnung der Beleuchtung durch die Scheinwerfer. Die Berechnung kann anhand unterschiedlicher Beleuchtungsmodelle erfolgen, welche dafür die entsprechenden LSV-Texturen aus Phase 1 des Verfahrens verwenden. Für die Darstellung der Beleuchtung der nächtlichen Szene durch die Fahrzeugscheinwerfer wird abschließend die Texturfarbe des Szeneriemodells mit dem auf Basis der LSV-Textur und des verwendeten Beleuchtungsmodells errechneten Lichtanteil modifiziert und als beleuchtete Szenerie dargestellt.
Ergebnis der Phase 3 ist eine entsprechend den Scheinwerferleuchtcharakteristika beleuchtete virtuelle Szenerie.
Für die Bereitstellung der LSV-Textur aus den Lichtverteilungsdaten eines Scheinwerfers untergliedert sich Phase 1 des Verfahrens, wie in 5 dargestellt, in drei Subphasen.
Subphase 1.1 – Konvertierung der LSV-Werte: In dieser Phase erfolgt die Konvertierung der original LSV-Werte einer Scheinwerferlichtverteilung in die Texel-Werte der LSV-Textur. Je nach Scheinwerfermodell liegen die LSV-Werte einer Lichtverteilung typischerweise im Bereich 0-100.000 cd (Candela). Damit die Lichtverteilung in einer Textur gespeichert werden kann, müssen die LSV-Werte in entsprechende Farbwerte für die Texel der LSV-Textur umgerechnet werden. Dabei können die LSV-Werte auf unterschiedliche Weise kodiert werden. Die verschiedenen Kodierungen können dann für unterschiedliche Shader-Routinen zur Berechnung der Beleuchtung herangezogen werden.
In Abhängigkeit von dem verwendeten Scheinwerferprototypen kann der Dynamikbereich2 einer Lichtstärkeverteilung bis zu 10⁵ Einheiten umfassen. Dynamikbereiche dieser Größe können allerdings nicht durch jede Kodierung vollständig erfaßt werden. So decken die 256 Graustufen bei Verwendung einer Textur mit 8-Bit Farbauflösung nur einen geringen Teil des Dynamikbereichs der Lichtstärkewerte aus der Scheinwerferlichtverteilung ab, so daß viele LSV-Werte verlorengehen.
Daher muß der Dynamikbereich der LSV-Eingangswerte in Abhängigkeit von der verwendeten Kodierung auf den Wertebereich der LSV-Textur skaliert werden. Die Skalierung führt jedoch zu Ungenauigkeiten bei der Farbdarstellung in Phase 3 des Verfahrens, welche durch die grobere Diskretisierung der Texel-Werte in der LSV-Textur hervorgerufen wird. Selbst bei Verwendung von Texturen mit einer Auflösung von 16-Bit ist der Wertebereich der LSV-Textur nicht ausreichend. So werden die ca. 100.000 Helligkeitsabstufungen des Scheinwerfers in diesem Fall auf 65.536 Farbwerte in der LSV-Textur abgebildet. Abhilfe schaffen nur byte-weise Kodierungen der LSV-Werte in Farbtripel, die in den einzelnen Farbkanälen der LSV-Textur gespeichert werden. Hierbei werden die LSV-Werte in drei Bytes mit der Wertigkeit 256⁰, 256¹ und 256² kodiert und direkt als RGB-Tripel in der LSV-Textur gespeichert. Bei dieser Kodierung ergibt sich ein ausreichend großer Wertebereich von 2²⁴ = 16.777.216 Werten.
Das Zusammensetzen der ursprünglichen LSV-Werte (Dekodierung) beim Auslesen der LSV-Textur im Pixel-Shader in Phase 3 des Verfahrens wird bei dieser Kodierung jedoch aufwendiger.
Die folgende Tabelle zeigt einige Kodierungsbeispiele der Lichtstärkewerte des LSV-Datensatzes in Texel-Farbwerte der LSV-Textur.
Ergebnis der Subphase 1.1 ist eine LSV-Textur, deren Texel-Werte die ursprünglichen LSV-Werte unterschiedlich genau wiedergeben. Die Genauigkeit hängt dabei von der verwendeten Kodierung ab.
Subphase 1.2 – Planare Projektion der LSV-Daten: Die Werte in der Lichtverteilung beruhen auf einer Vermessung des Scheinwerfers mittels eines Goniometers und eines Photometers. Diese Geräte messen die vom Scheinwerfer ausgestrahlte Lichtstärke in Abhängigkeit von dessen Position relativ zur Leuchtrichtung des Scheinwerfers. Ergebnis der Vermessung ist die Lichtstärkeverteilung des Scheinwerfers, die sich auf einem Kugelsegment mit dem Radius r zum Scheinwerfer befindet. Die Größe des Kugelsegments hängt von den horizontalen und vertikalen Öffnungswinkeln und des Scheinwerfers ab, die sich links und rechts bzw. oberhalb und unterhalb der Leuchtrichtung des Scheinwerfers erstrecken (vgl. 6).
Der maximale Vermessungsbereich eines Scheinwerfers liegt zwischen 90° oberhalb, –30° unterhalb, –90° links und 90° rechts von der Scheinwerferleuchtrichtung mit einer Auflösung, d.h. einer Vermessungsschrittweite, von 0,2°. Somit ergeben sich maximal (90° + 90°)/0.2°·(90° + 30°)/0.2° = 540.000 vermessene LSV-Werte. Dieser Winkelbereich erfaßt den gesamten Leuchtbereich des Scheinwerfers, selbst mögliche Reflexionen, welche in den Randbereichen nahe 90° oberhalb der Leuchtrichtung und damit weit außerhalb des Sichtfeldes des Fahrers liegen. Die gesetzlichen Vorgaben für die Sichtbarkeitswinkel von PKW-Scheinwerfern liegen mit max. 80° für die horizontalen und max. 15° für die vertikalen Sichtbarkeitswinkel deutlich unterhalb dieser Vermessungsgrenzen.
Da sich die Ausgangswerte des LSV-Datensatzes durch die Goniometervermessung auf dem Segment einer Kugeloberfläche befinden (s. 6), müssen sie durch eine planare Projektion auf die ebene Fläche der LSV-Textur abgebildet werden, um anhand des Projective Texture Mapping in die 3D-Szene projiziert werden zu können.
Bei der planaren Projektion der LSV-Daten von dem Kugelsegment der Scheinwerfervermessung auf die Ebene der LSV-Textur treten jedoch projektionsbedingte Verzerrungen auf. Die Verzerrurngen sind abhängig von dem Winkel, unter dem die LSV-Werte auf die Texturebene projiziert werden und nehmen mit größeren Winkeln zwischen Leuchtrichtung und aktueller Position auf dem Kugelsegment zu.
Die Ansicht in 7 entspricht schematisch einer Sicht von oben in 6. Sie zeigt einen Querschnitt durch die planare Projektion der LSV-Daten auf die LSV-Textur zur Verdeutlichung des funktionalen Zusammenhangs x = (r + h)·tangα zwischen der projektionsbedingten Verzerrung x (Größe des Abbildes) der LSV-Daten und dem Winkel α. Die Verzerrungen treten in allen 4 Quadranten der LSV-Textur auf, also ober- und unterhalb sowie links und rechts der Leuchtrichtung mit entsprechend steigenden bzw. fallenden Winkeln.
Ergebnis der Subphase 1.2 ist eine LSV-Textur, die im Vergleich zum ursprünglichen LSV-Datensatz verzerrt erscheint. Die Verzerrung durch die Planare Projektion der LSV-Daten auf die Ebene der LSV-Textur ist allerdings notwendig, um Projektionsfehler bei der Projektion der LSV-Textur in die virtuelle Szenerie in Phase 2 des Verfahrens zu vermeiden.
Subphase 1.3 – Skalierung der LSV-Textur: Durch die Planare Projektion ergibt sich eine inhomogene Verteilung der LSV-Werte über die LSV-Textur. Die Dichte der LSV-Werte nimmt – ausgehend von der Leuchtrichtung – mit steigenden Winkelbeträgen für α und β zu den Rändern der LSV-Textur hin ab. Entsprechend werden die projizierten Abbilder der LSV-Werte in den Randbereichen der LSV-Textur größer (vgl. 7, oben rechts). Damit durch die Verzerrung der planar projizierten Lichtverteilung keine Details in der LSV-Textur verlorengehen, wird eine Skalierung der Größe der LSV-Textur notwendig. Die Skalierung wird so gewählt, daß im Bereich der höchsten Dichte der LSV-Werte, also in der unmittelbaren Umgebung der Leuchtrichtung, das Abbild eines projizierten LSV-Wertes auf der LSV-Textur der Größe eines Texels entspricht. In 7 ist diese Skalierung durch Striche unterhalb der Ebene der LSV-Textur dargestellt, welche die Grenzen zwischen den projizierten Abbildern der LSV-Daten in der LSV-Textur anzeigen. Ein Texel entspricht bei dieser Skalierung der Vermessungsschrittweite α_inc des Scheinwerfers. Da nach außen, in Richtung der Randbereiche der LSV-Textur, die Abbildungsgröße der projizierten LSV-Werte zunimmt, deckt ein projizierter LSV-Wert dort mehrere Texel ab. Damit keine Löcher entstehen, müssen diese Bereiche abschließend mit gleichen Texel-Werten aufgefüllt werden (s. 7, oben links).
Bei der Skalierung ergeben sich für die LSV-Werte die entsprechenden Texel-Positionen in der LSV-Textur durch die folgende Gleichung:
Nach dieser Gleichung wird das Abbild eines LSV-Wertes unter dem Projektionswinkel auf die Position x in der LSV-Textur projiziert. Wird dieser Wert durch die minimale Abbildungsgröße x_min eines LSV-Wertes in unmittelbarer Nähe zur Leuchtrichtung des Scheinwerfers geteilt, ergibt sich innerhalb des Texel-Rasters in der LSV-Textur die skalierte Position x_Texel des Abbildes des LSV-Wertes unter dem Projektionswinkel.
Für große Winkel nahe dem Wert 90° ergeben sich aufgrund der Tangensfunktion und der Skalierung, d.h. dem Teilen durch x_min, schnell sehr große Werte für x_Texel und damit große LSV-Texturen. Daher sind für das Verfahren nur Winkel bis maximal 80° sinnvoll. Dieser Effekt verstärkt sich noch, wenn die Scheinwerferlichtverteilung mit noch kleineren Werten, z.B. α_inc = 0,1 °, vermessen wurde. Eine Beschränkung auf den Bereich für Winkel <= 80° ist aber unkritisch, da dieser Wert die gesetzlichen Vorgaben für die maximalen Sichtbarkeitswinkel von Scheinwerfern abdeckt. Die Größe der resultierenden LSV-Texturen für das Verfahren dieser Arbeit ist selbst bei einer Vermessungsschrittweite von 0,1° unkritisch, da die entsprechend großen LSV-Texturen auch in diesem Fall problemlos durch die Graphikhardware verarbeitet werden. Die 8 (Bild 5-6) zeigt die Resultate der einzelnen Subphasen aus Phase 1. In den ersten beiden Subphasen werden die LSV-Werte nach dem HSV-Modell farbkodiert (s. 8 oben) und planar in auf die Ebene der LSV-Textur projiziert. Bedingt durch die Projektion verteilen sich die projizierten LSV-Werte unterschiedlich über die LSV- Textur. Dabei entstehen verstärkt in den Randbereichen der LSV-Textur Lücken zwischen den projizierten LSV-Werten (s. 8 mitte), die in Subphase 1.3 mit Texeln der entsprechenden Wert auf mindestens ein Texel oder entsprechend mehrere Texel abgebildet. Damit ist gewährleistet, daß keine Details des LSV-Datensatzes bei der Konvertierung in die LSV-Textur verloren gehen. Eine derartige Skalierung ist erforderlich, da die Leuchtrichtung der Scheinwerfer, insbesondere bei der Verwendung von AFS, immer in Fahrtrichtung zeigt. Dies ist auch die vornehmliche Blickrichtung des Fahrers während der Nachtfahrt. In diesem Bereich sollte daher eine verminderte Darstellungsqualität durch Skalierungsfehler oder gemittelte Beleuchtungswerte in jedem Fall vermieden werden. Zudem liegt genau in diesem Bereich die für die Wahrnehmung und die Nachtfahrt wichtige Hell-Dunkel-Grenze, welche mit einem sehr hohen Kontrast den scharfen Übergang von der beleuchteten Fahrbahn auf den möglichst unbeleuchteten Bereich oberhalb der Einbauhöhe der Fahrzeugscheinwerfer markiert.
Wird hingegen eine Skalierung gewählt, bei der ein LSV-Wert aus dem Randbereich auf ein Texel skaliert wird, werden zwangsläufig in unmittelbarer Nähe zu der Leuchtrichtung des Scheinwerfers und im Bereich der Hell-Dunkel-Grenze mehrere LSV-Werte auf ein Texel abgebildet. Daher gehen in diesen Bereichen Details der LSV-Daten in der LSV-Textur verloren. Die resultierenden LSV-Texturen sind deutlich kleiner, erfüllen aber nicht die Anforderungen an eine qualitativ möglichst hochwertige und detailgetreue Wiedergabe des LSV-Datensatzes durch die generierte LSV-Textur.
Ergebnis der Subphase 1.3 ist eine LSV-Textur, welche für den Einsatz in Phase 2 des Verfahrens geeignet ist. Die konvertierte LSV-Textur weist die notwendige Detailgenauigkeit für die räumliche Projektion auf, so daß die Detailtreue der ursprünglichen LSV-Datensätze bei der Anwendung dieses Verfahrens erhalten bleiben. Da bei der gewählten Skalierung nur Texel vervielfacht werden, ist die Konvertierung der LSV-Daten in die LSV-Textur verlustfrei.
In Phase 2 des Verfahrens wird die LSV-Textur, die als Ergebnis von Phase 1 für die Projektion bereit steht, in die virtuelle Szenerie projiziert. In diesem Schritt wird festgelegt, welche LSV-Werte an welche Stelle in die virtuelle Szenerie abgebildet werden.
Die gesetzlichen Vorgaben schreiben für einen PKW-Scheinwerfer unterschiedliche Sichtbar keitswinkel vor. Somit ergeben sich für einen Scheinwerfer bis zur vier verschiedene Öffnungswinkel relativ zu seiner Leuchtrichtung. Die vier Winkel öffnen sich ausgehend von der Leuchtrichtung nach oben, unten, links und rechts. Die unterschiedlichen Winkel führen zu einer asymmetrischen Projektion des Scheinwerferlichtes in die virtuelle Szenerie. Entsprechend verschiebt sich aufgrund der unterschiedlichen Öffnungswinkel des Scheinwerfers die Leuchtrichtung aus der Mitte der LSV-Textur. 9 zeigt den Unterschied zwischen einer symmetrischen und asymmetrischen Projektion mit den entsprechenden LSV-Texturen aus Phase 1 des Verfahrens. Die symmetrische Projektion, in 9 links dargestellt, besitzt symmetrische Öffnungswinkel in alle vier Richtungen relativ zur Leuchtrichtung des Scheinwerfers. Phase 1 des Verfahrens führt entsprechend der Öffnungswinkel zu einer symmetrischen LSV-Textur. Die Leuchtrichtung des Scheinwerfers befindet sich genau im Mittelpunkt der Textur.
Unterschiedliche Öffnungswinkel (vgl. 8 rechts) führen zu einer asymmetrischen Projektion und einer LSV-Textur, deren Leuchtrichtung aus dem Texturmittelpunkt verschoben ist. Entsprechend weist die LSV-Textur eine asymmetrische Verschiebung der Leuchtwerte auf. Bei Verwendung der in Phase 1 des Verfahrens entsprechend konvertierten und aufbereiteten LSV-Texturen ist das Ergebnis von Phase 2 eine verzerrungsfreie Projektion des LSV-Datensatzes in die virtuelle Szenerie. Zur Veranschaulichung zeigt 9 das Ergebnis der Subphase 2 des Verfahrens anhand eines projizierten Winkelgitters mit einer Schrittweite von 10°. Werden bei der Aufbereitung der LSV-Textur in Phase 1 des Verfahrens die Subphasen 1.2 und 1.3 ausgelassen, so daß der LSV-Datensatz nicht planar projiziert und skaliert wird, kommt es in Phase 2 zu Projektionsfehlern.
In 10 oben rechts zeigen sich diese Projektionsfehler durch äquidistante Abstände zwischen den Linien des 10°-Rasters. In der Seitenansicht und Aufsicht (mitte und unten rechts) wird das projizierte Gitter mit wachsendem Winkel zur Leuchtrichtung zunehmend verzerrt, so daß die äußeren Winkel kleiner dargestellt werden als die inneren Winkel nahe der Leuchtrichtung.
Die Projektion ist damit nicht winkeltreu. Werden dagegen die LSV-Texturen gemäß Phase 1 des Verfahrens aufbereitet, sind die Linien des 10°-Rasters nicht äquidistant, was einer korrekten planaren Projektion entspricht (s. 10 oben links). Entsprechend sind die Seiten- und Aufsicht (mitte und unten links) winkeltreu, so daß alle Winkel entsprechend ihrer Größe projiziert und die Gitterlinien korrekt abgebildet werden.
Die vorliegende Anmeldung offenbart ein Shader-basierten Verfahren zur Darstellung komplexer Lichtverteilungen. Um die prinzipielle Funktionsweise und das Potential dieses Ansatzes zu demonstrieren, wird innerhalb dieses Verfahrens ein einfaches Beleuchtungsmodell verwendet. Grundsätzlich läßt sich das Verfahren auch auf komplexere Modelle zur Beleuchtungssimulation anwenden. Für eine Anpassung an andere Modelle müssen lediglich die Shader-Routinen modifiziert werden, in denen die Berechnung des Beleuchtungsmodells und der daraus resultierenden Farben erfolgt. Werden für das Beleuchtungsmodell in den Shader-Routinen in Phase 3 andere Eingangswerte für die Lichtverteilung benötigt, muß gegebenenfalls die Aufbereitung der LSV-Texturen in Phase 1 des Verfahrens entsprechend angepaßt werden.
Nach der Aufbereitung der LSV-Textur in Phase 1 und der Projektion der LSV-Textur in Phase 2 erfolgt in Phase 3 des Verfahrens die Berechnung der endgültigen Beleuchtung der virtuellen Szenerie anhand eines entsprechenden Beleuchtungsmodells. Für die Berechnung der Beleuchtung der nächtlichen Szenerie durch die Kfz-Scheinwerfer wird in dieser Arbeit das nachfolgende Beleuchtungsmodell verwendet.
Für die Beleuchtung der virtuellen Szenerie durch die Fahrzeugscheinwerfer ergibt sich die in 11 dargestellte Situation. Aufgrund der diskreten Betrachtungsweise werden in den nachfolgenden Rechenschritten zum Beleuchtungsmodell die differentiellen Darstellungen der Formeln durch diskrete Darstellungen ersetzt.
Die Glühlampe im Scheinwerfer des virtuellen Fahrzeugs erzeugt den Lichtstrom Φ, der gleichmäßig nach allen Seiten abstrahlt (vgl. Marke 1 in 11). Der Lichtstrom der Glühlampe wird am Reflektor des Scheinwerfers reflektiert und an der Abschlußscheibe gebrochen, so daß sich vor dem Scheinwerfer unterschiedliche Lichtstärken I in Abhängigkeit von dem durchstrahlten Raumwinkel Ω und dem Winkel φ_s zur Leuchtrichtung ergeben (vgl. Marke 2 in 11). Dieses führt zu Lichtstärkeverteilungen, welche die Leuchtcharakteristika des Scheinwerfers definieren.
Der Lichtstrom des Scheinwerfers fallt schließlich unter dem Winkel φ_E auf ein Objekt in der virtuellen Szenerie mit der Distanz D zur Lichtquelle und erzeugt auf dessen Oberfläche A_E den Beleuchtungswert E (s. Marke 3 in 11). Der auf die Fläche A_E treffende Lichtstrom wird reflektiert. Die Reflexion hängt dabei von dem materialspezifischen Reflexionskoeffizienten C_R der beleuchteten Fläche A_E ab. Schaut der Beobachter unter dem Blickwinkel φ_EB auf die Fläche A_E, nimmt er die Beleuchtung auf der Fläche als Helligkeit wahr. Die wahrgenommene Helligkeit ist definiert durch die von der beleuchteten Fläche abgestrahlte Leuchtdichte L (vgl. Marke 4 in 11).
Nach dem lambertschen Cosinusgesetz, ist die Lichtstärke I einer diffus abstrahlenden Fläche A_S proportional zu dem Cosinus des Ausstrahlungswinkels φ_s. Diese Größe findet sich in 11 an der Marke 2 und entspricht den Werten aus dem aufbereiteten Lichtstärkeverteilungsdatensatz, der in Form der LSV-Textur mittels dem Projective Texture Mapping in die virtuelle Szenerie projiziert wird. Für den Raumwinkel Ω ergeben sich die entsprechenden Äquivalente in den Vermessungsschrittweiten α_inc und β_inc aus der Aufbereitung der LSV-Textur aus Phase 1 des Verfahrens.
Die Berechnung der Beleuchtung auf der vom Scheinwerfer beleuchteten Fläche (s. Marke 3 in 11) erfolgt auf der Grundlage des photometrischen Grundgesetzes. Diese berechnet den Lichtstrom Φ, der von dem Scheinwerfer auf den beleuchteten Gegenstand in der virtuellen Szenerie übertragen wird. Nach dem photometrischen Grundgesetz überträgt ein Sender, im Kontext dieser Arbeit der Fahrzeugscheinwerfer, einen Lichtstrom auf einen Empfänger, in dieser Arbeit das beleuchtete Objekt in der virtuellen Szenerie. Der übertragene Lichtstrom hängt dabei ab von der Leuchtdichte L des Scheinwerfers, der Fläche A_S des Senders, dem Abstrahlwinkel φ_s von der Senderfläche und dem Eintrittswinkel φ_E des Lichtes auf der Empfängerfläche A_E. Entsprechend dem photometrischen Entfernungsgesetz nimmt der Lichtstrom Φ mit zunehmender Distanz D zur Lichtquelle quadratisch ab.
Diese Gleichung ergibt zusammen mit dem lambertschen Cosinusgesetz für den auf die beleuchtete Fläche AE einfallenden Lichtstrom Φ die folgende Darstellung in Abhängigkeit von der Lichtstärke.
Da der Lichtstrom an der beleuchteten Fläche reflektiert wird, vermindert sich der Lichtstrom in Abhängigkeit von den Materialeigenschaften der Fläche. Der Reflexionsgrad der Fläche wird durch den materialspezifischen Reflexionskoeffizienten C_R beschrieben. Somit gilt für den reflektierten Lichtstrom Φ_R ΦR = Φ·CR
Da der Lichtstrom nicht gemessen bzw. wahrgenommen werden kann, wird die von der beleuchteten Fläche in Form von wahrnehmbarer Helligkeit abgestrahlte Leuchtdichte aus dem Lichtstrom wie folgt berechnet. Nach 11 trifft der Lichtstrom Φ auf die vom Scheinwerfer im Abstand D beleuchtete Fläche A_E nach dem photometrischen Grundgesetz. Die Fläche reflektiert gemäß ihres Reflexionskoeffizienten CR den Lichtstrom Φ_R. Wird die Fläche unter dem Winkel φ_EB betrachtet (vgl. Marke 4 in 11), kann die Leuchtdichte L als Helligkeit wahrgenommen werden. Der Wert für die wahrgenommene Leuchtdichte ergibt sich aus folgenden Berechnungsschritten.
Zuerst wird die Lichtstärke I aus Gleichung 2-4 durch Gleichung 2-2 ersetzt. Dies führt zu dem Lichtstrom Φ_R in der Gleichung. Im nächsten Schritt wird zur Berücksichtigung des Reflexionskoeffizienten CR der Lichtstrom Φ_R durch Gleichung 5-6 ersetzt. Anschließend wird der Ausdruck für den Lichtstrom auf der Empfängerfläche, gegeben durch Gleichung 5-5, eingesetzt. Somit ergibt sich für die vom Beobachter wahrgenommene Leuchtdichte die fol gende Darstellung:
Der Term Ω resultiert aus den Vermessungsschreiten α_inc und β_inc aus der Aufbereitung der LSV-Textur in Phase 1 des Verfahrens. Damit stellt der Term Ω₀/Ω eine Konstante dar, welche in der Farbkalibrierung berücksichtigt wird.
Die Beleuchtung der virtuellen Szenerie durch die simulierten Kfz-Scheinwerfer führt zu einer von dem Beobachter wahrgenommenen Helligkeit auf den Flächen der virtuellen Szenerie. Diese Helligkeit wird definiert durch die Leuchtdichte. Die Leuchtdichte hängt dabei ab von dem Wert I aus der Lichtstärkeverteilung des Scheinwerfers, den Reflexionseigenschaften C_R der beleuchteten Fläche, dem Einfallswinkel φ_E des Scheinwerferlichtes auf die beleuchtete Fläche, dem Winkel φ_EB, unter dem die beleuchtete Fläche vom Beobachter gesehen wird und der Entfernung D der beleuchteten Fläche zum Scheinwerfer.
Die Berechnung der endgültigen Farbe für die Beleuchtung jedes Pixels erfolgt innerhalb des Pixel-Shaders anhand des obigen Beleuchtungsmodells und umfaßt die folgenden Parameter:

– den Anteil der Beleuchtung hervorgerufen durch die Kfz-Scheinwerfer gemäß dem vorhergehenden Beleuchtungsmodell,
– die Eigenfarbe der Objekte in der virtuellen Szenerie bei Tageslicht (gegeben durch die Texturfarbe der Objekte) und
– die Reflexionsparameter der Objekte entsprechend der Materialeigenschaften (Reflexionskoeffizienten für die diffuse, ambiente und spiegelnde Re flexion).

Die obigen Parameter führen zusammen mit der Formel für die Leuchtdichte für die Berechnung der nächtlichen Beleuchtung der virtuellen Szenerie durch die Kfz-Scheinwerfer zu folgender Formel:
Die einzelnen Terme in dieser Gleichung besitzen folgende Bedeutung:

– I ist der Lichtstärkewert aus der projizierten LSV-Textur.
– Ra, Rd und Rs sind die materialspezifischen Reflexionswerte. Für die nächtlichen Lichtverhältnisse wird Ra auf 5% gesetzt. Die Reflexionswerte werden im Vertex-Shader auf der Basis der Normalen des Polygonmodells berechnet und für die Farbberechnung an den Pixel-Shade übergeben.
– DBTextur ist die Texturfarbe der 3D-Objekte aus dem 3D-Modell der virtuellen Szenerie und entspricht der Objektfarbe bei Tageslichtdarstellung.
– 1/D² ist der Lichtabschwächungsfaktor für die pixel-genaue Entfernung zur Lichtquelle.
– Ω₀/Ω stellt eine Konstante dar, die sich aus den Werten für die horizontale und vertikale Vermessungsschrittweite bei Aufbereitung der LSV-Textur ergibt.

Zur Darstellung der Lichtverhältnisse bei Tageslicht wird in der folgenden Gleichung die ambiente Reflexion auf Ra = 100% gesetzt, was ungefähr der globalen Beleuchtung durch das Sonnenlicht entspricht. Anstelle des Beleuchtungsanteils durch die Scheinwerfer wird ein distanzbasierter Verbläuungsfaktor integriert. Dieser Faktor fügt abhängig von der Entfernung des Objektes in der virtuellen Szenerie zum Betrachter einen bläulichen Farbanteil ein, der der diffusen Reflexion des blauen Himmels bei Tageslicht entspricht. Auf diese Weise wirkt die Darstellung der virtuellen Landschaft realer, da entfernte Objekte leicht verbläuen statt ihre Farbe konstant beizubehalten. Somit ergibt sich für die Tageslichtdarstellung die folgende Formel:
Zur Veranschaulichung der Darstellung der Scheinwerferbeleuchtung bei Nacht wird Phase 3 des Verfahrens in fünf Subphasen untergliedert, welche in 12 dargestellt sind. Die einzelnen Subphasen berücksichtigen die verschiedenen Komponenten des obigen Beleuchtungsmodells. Die Darstellungen rechts in 12 veranschaulichen den Effekt der jeweiligen Komponente auf die Beleuchtung der virtuellen Szenerie. Ein Durchlauf durch die einzelnen Subphasen aus Phase 3 führt so sukzessive zu der endgültigen Beleuchtung der virtuellen Szenerie.
Die Sub-Phase 3.1 zeigt zur Verdeutlichung nochmal das Ergebnis aus Phase 2 des Verfahrens – die asymmetrische Projektion und die den Öffnungswinkel entsprechenden Projektionsgrenzen.
In der Sub-Phase 3.2 wird das von der virtuellen Szenerie reflektierte Licht berechnet. Dieses ergibt sich aus den Materialeigenschaften der Objekte in der virtuellen Szenerie. In Abhängigkeit von den Reflexionseigenschaften der verwendeten Materialien reflektieren z.B. eine Seitenbake oder ein Verkehrsschild am Straßenrand deutlich mehr Licht als die raube Fahrbahnoberfläche. Das reflektierte Licht besteht aus einem ambienten, diffusen und spiegelnden Lichtanteil. Die einzelnen Anteile werden jeweils durch einen materialspezifischen Koeffizienten gewichtet und hängen zudem von dem entsprechenden Einfallswinkel des Lichts ab.
Der Einfallswinkel wird in dem hier verwendeten Beleuchtungsmodell jedoch vernachlässigt, da alle Materialien in der virtuellen Szenerie so gewählt wurden, daß sie gleichmäßig das Licht streuen. Dies wurde bewusst so gewählt, damit es auf der durch wenige große Polygone modellierten Straße in der virtuellen Teststrecke nicht zu störenden Effekten durch unterschiedlich hell beleuchtete Straßenabschnitte kommt. Da in dem Modell der virtuellen Ver suchsstrecke Rüthen fast ausschließlich nur stark diffus streuende Materialien verwendet werden, führt diese Vereinfachung zu keiner nennenswerten Beeinträchtigung der Beleuchtungsdarstellung.
Die Reflexionsparameter werden auf der Basis der Flächennormalen des Polygonmodells gemäß den Reflexionsmodellen im Vertex-Shader berechnet und für die endgültige Farbberechnung in Subphase 3.5 des Verfahrens an den Pixel-Shader übergeben.
Ergebnis von Subphase 3.2 ist eine beleuchtete Szenerie, die die Abstrahleigenschaften der einzelnen Materialien wiedergibt. Die Reflektoren der Seitenbaken reflektieren im Vergleich zur übrigen Szenerie sehr viel mehr Licht und erscheinen in der Darstellung entsprechend deutlich hell.
In der Sub-Phase 3.3 erfolgt die Berechnung der Lichtabschwächung. Die Leuchtdichte nimmt mit zunehmender Entfernung D von der Lichtquelle quadratisch ab, da die Fläche, auf welche das Licht trifft, entsprechend quadratisch anwächst. Jedes Pixel auf dem Bildschirm entspricht einem Punkt in der virtuellen Szenerie. Im Pixel-Shader wird in dieser Subphase die Distanz zwischen dem Punkt und der Scheinwerferposition somit pixelgenau berechnet. Entsprechend ergibt sich der Abschwächungsfaktor zu 1/D². In dieser Phase wird der Abschwächungsfaktor entsprechend in der Beleuchtungsberechnung berücksichtigt.
Ergebnis dieser Subphase ist eine mit zunehmender Distanz zum Scheinwerfer deutlich wahrnehmbare Abschwächung der Beleuchtung der virtuellen Szenerie.
Die Sub-Phase 3.4 umfaßt die Berücksichtigung der LSV-Textur. Bis zu diesem Schritt ist die Beleuchtung fast vollständig. Es fehlt noch die eigentliche Lichtverteilung – also die eigentliche Abstrahlcharakteristik des verwendeten Scheinwerfermodells. Ohne Subphase 3.4 entspräche die Beleuchtung der virtuellen Szenerie derjenigen eines homogen in alle Richtungen innerhalb der Öffnungswinkel scheinenden Scheinwerfers. Sämtliche Details der Lichtstärkeverteilung, wie z.B. die Hell-Dunkel-Grenze, fehlen noch. Daher werden in diesem Schritt die Lichtstärkedaten der LSV-Textur in die Beleuchtungsberechnung einbezogen. Die Daten gehen als Faktor in die Beleuchtungsberechnung ein und ergeben auf diese Weise die komplexe Lichtverteilung in der beleuchteten Szenerie.
Ergebnis von Subphase 3.4 ist eine virtuelle Szenerie, die durch den virtuellen Scheinwerfer beleuchtet wird. In der beleuchteten Szenerie sind alle Details der Scheinwerferbeleuchtung dargestellt. Die Darstellung in 12 verdeutlicht den Lichtanteil, welcher vom Scheinwerfer in die virtuelle Szenerie leuchtet.
Zur Darstellung der zahlreichen Details aus der virtuellen Szenerie müssen im letzten Schritt dieser Phase, der Sub-Phase 3.5, die Texturen aus dem 3D-Modell der virtuellen Szenerie in der Darstellung berücksichtigt werden. Hierfür wird der berechnete Beleuchtungswert mit der Texturfarbe des beleuchteten Objektes aus der Modelldatenbank moduliert.
Ergebnis der letzten Subphase ist dann die endgültige Darstellung der vom Scheinwerfer beleuchteten virtuellen Szenerie.
Das oben beschriebene Verfahren stellt die komplexen Leuchtcharakteristika moderner Scheinwerfersysteme in hoher visueller Qualität dar. Die geforderte Echtzeitfähigkeit des Verfahrens wird jedoch nur erreicht, wenn potentielle Engpässe in der Renderingpipeline eliminiert oder zumindest aufgeweitet werden.
In verschiedenen Verarbeitungsstufen können Engpässe innerhalb der Renderingpipeline auftreten, insbesondere bei der Verarbeitung einzelner Polygone am Anfang der Pipeline und beim Rendering der Pixel am Ende der Pipeline. Engpässe am Anfang der Pipeline treten auf, wenn zuviele Polygone verarbeitet werden müssen (engl. Polygon count), was zu einem Polygonstau führt. Analog tritt am Ende der Pipeline beim Rendering der einzelnen Pixel ein Pixel-Stau auf, wenn zuviele Pixel in der Szene dargestellt werden müssen (engl. pixel filling). Engpässe beim Pixel-Filling treten auf, wenn die virtuelle Szenerie große Bereiche auf dem Bildschirm bedeckt, welche mit Pixeln gefüllt werden müssen. Wird zudem noch eine hohe Bildschirmauflösung verwendet, verstärkt sich der Effekt.
Da das Verfahren nach Maßgabe der Erfindung Vertex- und Pixel-Shader-Routinen verwendet, die genau an diesen Stellen in die Rendering-pipeline eingreifen, besteht hier Potential für Optimierungen. Um eine hohe Verarbeitungsgeschwindigkeit des Verfahrens zu erzielen, sollten die verwendeten Vertex- und Pixel-Shader-Routinen möglichst optimal ausgelegt sein, um mit möglichst wenigen und einfachen Berechnungen die Anforderungen hinsichtlich der visuellen Qualität und der geforderten Verarbeitungsgeschwindigkeit zu erfüllen. Da der Vertex-Shader jedes Polygon und der Pixel-Shader entsprechend jedes Pixel der darzustellenden Szenerie verarbeitet, werden die Shader-Routinen für die Darstellung der virtuellen Szene am Bildschirm entsprechend oft ausgeführt. Optimierungen an den Shader-Routinen wirken sich somit unmittelbar auf die Verarbeitungsgeschwindigkeit des Verfahrens aus.
Veränderungen an den Shader-Routinen erfolgen jedoch relativ weit am Ende der Renderingpipeline und greifen somit erst spät in der Verarbeitung des 3D-Modells. Aus diesem Grund wird eine Optimierung der Shader-Routinen an dieser Stelle nicht weiter verfolgt.
Neben der Optimierung der Shader-Routinen – also einzelner Phasen der Renderingpipeline – kann aber auch schon zu Anfang des Verarbeitungprozesses angesetzt und damit deutlich effektiver optimiert werden. Dabei wird nicht die Renderingpipeline selbst optimiert, sondern die Menge der 3D-Daten reduziert, welche als Eingabestrom in die Pipeline einfließen. Um die Menge der eingehenden 3D-Daten zu reduzieren, muß das 3D-Modell entsprechend aufbereitet werden.
Um eine ausreichend hohe Performance des Verfahrens und damit seine Echtzeitfähigkeit sicherzustellen, ergeben sich bei der Aufbereitung des 3D-Modells der virtuellen Szenerie verschiedene Möglichkeiten, Leistungsengpässe innerhalb der Renderingpipeline zu vermeiden. So bieten sich folgende Optionen zur Steigerung der Leistung des Verfahrens an:

– Modelloptimierung, d.h. Vereinfachung des 3D-Modells durch Reduzierung der Polygonanzahl. Dies führt zu einer Minderung der Polygonlast gleich zu Anfang in der Renderingpipeline.
– Zoning, bedeutet Ein-/Ausblenden von Teilen des 3D-Modells und damit zusätzliche Reduzierung der Datenmenge in der Renderingpipeline.
– Culling, entfernt alle Objekte aus der Renderingpipeline ab einer definierten Minimaldistanz zum Betrachter.

Die obigen Optionen sind Verfahren, die im Rahmen von VR-Anwendungen zur Leistungsoptimierung eingesetzt werden, um die Datenmenge innerhalb der Renderingpipeline zu reduzie ren. Die Anwendung dieser Verfahren erscheint im Rahmen dieser Arbeit besonders sinnvoll, da der Einsatz der Vertex- und Pixel-Shader-Routinen zu einer anwendungsspezifischen Anpassung der Renderingpipeline führt. Die Shader-Routinen ersetzen bestimmte Verarbeitungsschritte innerhalb der Standard-Renderingpipeline und führen – je nach Komplexität der Berechnungen innerhalb der Shader – schnell zu einem Mehraufwand beim Durchlaufen der Pipeline. Aus diesem Grund erscheinen Maßnahmen zur Reduzierung der Datenmenge innerhalb der Renderingpipeline im Rahmen des hier vorgestellten Shader-basierten Verfahrens besonders vielversprechend.
Für den Einsatz im Rahmen einer virtuellen Nachtfahrsimulation wird das Verfahren aus auf das 3D-Modell einer Versuchsstrecke angewendet. 13 zeigt eine Vorgehensweise für die Aufbereitung des 3D-Modells und die Anpassung des Verfahrens, um die geforderte Echtzeitfähigkeit des Verfahrens sicherzustellen. Grundlage für die Entwicklung dieser Vorgehensweise ist die folgende Ausgangssituation: Im Fahrsimulator wird ein polygonaler Ansatz auf der Basis von Per-Vertex Lighting verwendet. Um die virtuelle Versuchsstrecke im Rahmen des Fahrsimulators zur Verfügung zu stellen, wird ein komplexes 3D-Modell der Versuchsstrecke erstellt. Das 3D-Modell wird mit engmaschigen Polygonnetzen ausgestattet, damit eine qualitativ hochwertige Wiedergabe der Beleuchtung möglich wird.
V-Phase 1: Zur Verdeutlichung wird in V-Phase 1 der Vorgehensweise der Ansatz des Fahrsimulators für die Beleuchtung des 3D-Modells der virtuellen Versuchsstrecke gewählt, der auf dem Per-Vertex Lighting basiert. Damit das Per-Vertex Lighting Ergebnisse erzielt, die den Anforderungen aus Kapitel 3.1 genügen, wird eine aufwendige Aufbereitung des 3D-Modell der Versuchsstrecke notwendig. Die Aufbereitung ersetzt große Polygone des 3D-Modells durch engmaschige Polygonnetze, welche die Beleuchtung bei diesem Verfahren deutlich besser wiedergeben. Soll das 3D-Modell den Anforderungen an die Scheinwerfersimulation genügen, ergibt sich durch die Aufbereitung im Fall der virtuellen Teststrecke ein 3D-Modell mit ca. 2.1 Mio. Polygonen. Ein derart komplexes 3D-Modell führt aufgrund der hohen Polygonlast unweigerlich zu Engpässen sowohl bei der Verwaltung des Szenengraphen in der CPU wie auch bei der Verarbeitung desselben innerhalb der Renderingpipeline in der GPU.
Die Performance des Fahrsimulators liegt daher bei Verwendung des 3D-Modells der virtuel len Versuchsstrecke bei ca. 8 bis 15 Hz. Der Qualitätsgewinn bei der Wiedergabe der Scheinwerferbeleuchtung wird durch den Einsatz der zahlreichen Polygone und der damit verbundenen Performance-Einbrüche somit teuer erkauft.
V-Phase 2: In V-Phase 2 wird der Shader-basierte Ansatz auf das für den Fahrsimulator aufbereitete 3D-Modell aus V-Phase 1 angewendet. Die zusätzlichen Polygonnetze im 3D-Modell erhöhen beim diesem Ansatz nicht die Qualität der Beleuchtung. Die Performance liegt mit 7 bis 18 Hz teilweise sogar noch unter der des Fahrsimulators aus Phase 1. Dies ist darauf zurückzuführen, daß sich neben der hohen Polygonlast noch ein zusätzlicher Aufwand für die Verarbeitung der Shader-Routinen ergibt. Die Anwendung der Pixel-Shader-Routinen ergibt dann einen zweiten Engpaß beim Pixel-Filling. An dieser Stelle wird deutlich, daß eine Reduzierung der in die Shader-basierte Renderingpipeline einfließenden Datenmenge durch die oben genannten Ansätze notwendig ist.
V-Phase 3: Um die Vorteile des Shader-basierten Verfahrens zu nutzen, wird in V-Phase 3 das für den Fahrsimulator aufbereitete 3D-Modell der virtuellen Versuchsstrecke für den Einsatz im Shader-basierten Verfahren optimiert. Dafür werden sämtliche Polygonnetze, die für das Per-Vertex Lighting des Fahrsimulator notwendig waren, eliminiert, indem die zahlreichen Polygonnetze zu wenigen großen Polygonen zusammengefaßt werden.
Da das Verfahren durch die pixel-genaue Beleuchtungsberechnung im Pixel-Shader unabhängig von der polygonalen Auflösung des 3D-Modells ist, führt eine Reduzierung der Polygone zu keinen Beeinträchtigungen bei der Darstellungsqualität (vgl. 14).
Ergebnis der Optimierung ist ein 3D-Modell, das nur noch ca. 170 Tsd. Polygone und damit weniger als 10 % der Polygone des 3D-Modells aus V-Phase 1 besitzt. Entsprechend beträgt die Polygonlast in Phase 2 weniger als 10 % des Wertes aus Phase 1 und die Performance des Verfahrens steigt auf 10 bis 22 Hz. Auffällig ist die hohe Varianz in der Performance. Je nach Position und Blickrichtung in der virtuellen Szenerie variiert die Performance zwischen 10 und 22 Hz. Der Grund hierfür liegt darin, dass die Polygonlast und Pixel-Filling abhängig von Position und Blickrichtung innerhalb der Szenerie sind.
In 15 zeigt Position A eine Szene mit wenigen 3D-Objekten, welche nur ca. 50 % des Bildes bedecken, so daß sich hier eine geringe Polygon- und Pixellast in der Renderingpipeline ergibt. Position B zeigt deutlich mehr Objekte, welche die Bildfläche zu ca. 75 % bedecken. Hier liegt daher eine hohe Polygonlast und eine mittlere Pixellast vor. Die Szenerie an Position C enthält weniger 3D-Objekte als Position A jedoch mehr als die Szenerie an Position B, was zu einer mittleren Polygonlast führt. Da in diesem Fall jedoch die gesamte Bildfläche von 3D-Objekten bedeckt wird, ist hier eine hohe Pixellast zu erwarten.
V-Phase 4: Zur Minderung der hohen Varianz in der Performance wird in V-Phase 4 ein Zoning eingeführt. Für das Zoning wird das 3D-Modell der virtuellen Versuchsstrecke schachbrettartig in einzelne Parzellen mit einer Kantenlänge von 200 m unterteilt (vgl. 16, oben). Die einzelnen Parzellen werden dann online abhängig von der Position und Blickrichtung des virtuellen Fahrzeugs ein- bzw. ausgeschaltet, sobald die Entfernung vom Fahrzeug größer als 700 m beträgt. Bewegt sich das virtuelle Fahrzeug über die Versuchsstrecke, sind zu jeder Zeit immer nur die Parzellen eingeschaltet, welche sich in unmittelbarer Nähe zum Fahrzeug befinden (vgl. 16 (Bild 5-14), linke Spalte). Im Gegensatz dazu sind bei deaktiviertem Zoning deutlich mehr Parzellen von Position C aus sichtbar (s. 16), oben rechts). Auf diese Weise bleibt die Anzahl der eingeschalteten Parzellen während der simulierten Nachtfahrt nahezu konstant und die Polygonlast ist dementsprechend gering (vgl. 16 (Bild 5-14) unten). Somit schwankt die Polygonlast in der Renderingpipeline bei Änderungen der Position oder Blickrichtung deutlich weniger als bei deaktiviertem Zoning.
Trotzdem ist die Performance immer noch nicht so konstant wie zu erwarten. Daher wird zusätzlich noch ein Culling an der Far-Clipping-Plane eingeführt, welches alle Objekte aus der Pipeline eliminiert, die mehr als 250 m vom Betrachter entfernt sind. Der Wert 250 m ist deutlich größer als die maximale Scheinwerferleuchtweite, so daß das Culling der 3D-Objekte an der Far-Clipping-Plane von der Fahrerposition aus nicht erkennbar ist. Die Objekte, welche durch das Culling an der Far-Clipping-Plane erfaßt werden, bedecken aber nur wenige Pixel in der Szene, so daß sich nur ein geringer Effekt auf das Pixel-Filling beim Rendering ergibt und nur zu einer geringen Erhöhung der Performance auf 20 bis 90 Hz führt.
V-Phase 5: Nach V-Phase 4 ist die Performance ausreichend groß, so daß in V-Phase 5 noch eine Dynamiksimulation integriert werden kann, damit für eine dynamische Evaluierung der Scheinwerfer ein realistisches Bewegungsverhalten des virtuellen Fahrzeugs zur Verfügung steht. Die Dynamiksimulation führt jedoch zu einem zusätzlichen Berechnungsaufwand, der weniger CPU-Reserven für die Aufbereitung der Daten und das Starten der Renderingpipeline in der GPU übrig läßt. Der Grund hierfür liegt hauptsächlich in der Verzahnung der Dynamik- und der Visualisierungsschleife.
Somit sinkt die Performance in V-Phase 5 wieder ein wenig auf 19 bis 78 Hz. Abschließend bleibt festzustellen, daß trotz aller Ansätze zur Performance-Optimierung immer noch eine hohe Varianz in der Performance entlang der virtuellen Versuchsstrecke festzustellen ist. Die Varianz ergibt sich aus den sehr unterschiedlichen Detaillierungen der Szenerie entlang der Strecke.
Hierdurch schwanken Polygonlast und Pixel-Filling erheblich. Abhilfe schaffen hier die Verwendung von Occlusion Culling-Verfahren oder eine Begrenzung der Bildwiederholrate auf einen Maximalwert, was zu einer konstanten Bildrate führt. Eine solche Begrenzung der Bildrate ist aber nur auf Graphiksystemen mit genügend Leistungsreserven sinnvoll, da der Maximalwert sonst zu niedrig angesetzt werden muß. Das Graphiksystem muß also über genügend Leistungsreserven verfügen, so daß es entlang der virtuellen Versuchsstrecke zu keiner Zeit zu Leistungsengpässen aufgrund der Polygonlast oder des Pixel-Filling kommt. Dies ist mit neuen Graphikkartengenerationen zu erwarten, da hier insbesondere die Performance bei der Verarbeitung von Shader-Routinen deutlich erhöht wird.
Für die Echtzeit-Visualisierung der virtuellen Nachtfahrt wurde eine prototypische Umsetzung des Verfahrens zur Darstellung der Scheinwerferlichtverteilungen implementiert. 17 zeigt die Architektur des Gesamtsystems der prototypischen Implementierung. Das Gesamtsystem umfaßt die Bereiche visuelle Simulation, Dynamiksimulation, Interaktion und visuelle Präsentation.
Die visuelle Simulation beinhaltet die Realisierung des weiter oben offenbarten Verfahrens zur Darstellung der Lichtquellenlich-/Scheinwerferlichtverteilungen. Der Bereich der Dynamiksimulation umfaßt die Integration einer Simulation der Fahrzeugdynamik für den realistischen Bewegungsinput zur dynamischen Evaluierung der Scheinwerfer. Durch den Bereich Interaktion erfolgt die Auswertung der Benutzeraktionen zur Steuerung der Anwendung. Die visuelle Präsentation umfaßt ein Projektionssystem für die visuelle Präsentation der Simulati onsergebnisse.
Das zentrale Modul der prototypischen Implementierung liegt im Bereich der visuellen Simulation und trägt in 18 die Bezeichnung Beleuchtungssimulation. Hier befindet sich die Simulationsschleife für die visuelle Simulation. Innerhalb dieser Schleife erfolgt die Auswertung der Benutzereingaben, das Anstoßen der Dynamiksimulation zur Berechnung der nächsten Simulationsschritte für die Fahrdynamik des virtuellen Fahrzeugs, die Berechnung der Beleuchtungssimulation und schließlich die Ausgabe der entsprechenden Bilddaten für die visuelle Präsentation. Für die visuelle Simulation der virtuellen Szenerie greift das Modul auf Datenbasen für die Darstellung der virtuellen Versuchsstrecke und des Fahrzeugs zurück. Für die Simulation der Fahrzeugscheinwerfer stehen zahlreiche durch das Konvertierungswerkzeug aufbereitete Scheinwerferdatensätze als LSV-Texturen zur Verfügung. Unterschiedliche Beleuchtungsmodelle können anhand verschiedener Shader-Routinen integriert werden.
Zur Simulation der fahrdynamischen Eigenschaften des virtuellen Versuchsfahrzeugs wurde eine echtzeitfähige Dynamiksimulation auf der Basis eines einfachen MKS-Modells eines Fahrzeugs mit der Beleuchtungssimulation gekoppelt. Die Fahrdynamiksimulation greift dabei auf ein Kinematikmodell des Fahrzeugs zurück, das anhand eines MKS-Modells die beweglichen Komponenten des Fahrzeugs, wie Achsen, Federung und Lenkung sowie deren Freiheitsgrade zueinander definiert. Ersatzmodelle zur Definition der dynamischen Eigenschaften der KS-Komponenten ergänzen das Fahrzeugmodell zur Wiedergabe des Beschleunigungs und Bremsverhaltens. In der Dynamiksimulation bewegt sich das Fahrzeug durch eine dreidimensionale Welt, die durch Kollisionsmodelle zur Versuchsstrecke und zum Fahrzeug definiert ist.
Zur Vermittlung der räumlichen Tiefe der virtuellen Szenerie kann die visuelle Präsentation für eine Mono- oder passiv Stereo-Darstellung über Polarisationsfilter konfiguriert werden. Dabei ist die Darstellung der Simulation abhängig von dem verwendeten Graphiksubsystem.
Die prototypische Implementierung ist modular aufgebaut, so daß einzelne Komponenten leicht angepaßt oder ausgetauscht werden können. So ist die Schnittstelle zwischen der visuellen Simulation und der Dynamiksimulation relativ einfach gehalten, so daß die komplette Dynamiksimulation bei Bedarf leicht durch eine andere Implementierung ausgetauscht werden kann. Die Schnittstelle tauscht lediglich Lenkbefehle für das virtuelle Fahrzeug sowie als Ergebnis der Dynamiksimulation Matrizen für die Positionierung und Orientierung der Komponenten des MKS-Modells zwischen der Beleuchtungssimulation und der Fahrdynamiksimulation aus.
Die Implementierung des Prototypen erfolgte auf der Basis von OpenScene-Graph (OSG) [OSG05-ol]. OSG ist eine objektorientierte Open-Source 3DGraphikbibliothek für die Entwicklung von echtzeitfähigen 3D-Graphikanwendungen für die Bereiche interaktive visuelle Simulation und Virtual Reality, deren Source-Code frei verfügbar ist. OSG bietet eine umfangreiche Basisfunktionalität für den Aufbau und die Verwaltung von 3D-Szenen sowie grundlegende Algorithmen für das Echtzeitrendering, auf denen bei der Entwicklung des Prototypen aufgesetzt werden konnte. OSG basiert auf den Graphikstandards OpenGL [OGL05-ol] bzw. DirectX 9.0 [DX05-ol] und kapselt deren Basisfunktionalitäten in abstraktere Funktionen innerhalb der Bibliothek.
Die Dynamiksimulation wurde auf Basis der Simulationssoftware VORTEX [CML04-ol] erstellt, welche speziell für echtzeitfähige Dynamiksimulationen für den Einsatz in VR-Anwendungen konzipiert wurde. Die Anbindung der Dynamiksimulation an die visuelle Simulation erfolgte über eine am HNI entwickelte Brückenbibliothek (physlib), welche eine Verbindung der Objektmodellwelten zwischen dem Dynamiksimulationssystem VORTEX und der OSG-basierten Anwendung zur visuellen Simulation darstellt. Die Shader-Routinen der Vertex- und Pixel-Shader-Programme für die Beleuchtungssimulation sind in der C-ähnlichen Hochsprache CG (C for Graphics) [Nvi05a-ol], [FK03], [MGA+03] geschrieben. Im sich rasant entwickelnden und schnellebigen Graphikmarkt stellt CG einen Standardisierungsversuch dar, der von den zahlreichen herstellerspezifischen Entwicklungsschnittstellen (engl. Applicaion Programming Interfaces, kurz API) abstrahiert und eine einheitliche Schnittstelle schafft. Von diesem Standard ausgehend kann auf die entsprechenden Herstellerformate compiliert werden. Neben anderen Standards wie Microsofts High Level Shading Language (HLSL) oder der OpenGL Shading Language [Ros04] ermöglicht CG auf diese Weise, die Shader-Programmierung von der Abhängigkeit von spezifischen Graphikplattformen zu befreien und den Shader-Code portabel zu halten. Als Verbindung zu OSG fungiert die Brückenbibliothek osgNV [Jez05-ol], ebenfalls als Open-Source Software frei verfügbar, welche die Features von CG auf die Basisfunktionalität von OSG abbildet. Hierdurch wird es möglich, die in CG verfaßten Shader-Routinen direkt in OSG einzubinden und innerhalb des Verfahrens für die Beleuchtungssimulation einzusetzen.

Claims

Verfahren für die Shader-basierte Beleuchtungssimulation technischer Beleuchtungssysteme, dadurch gekennenzeichnet, dass sich das Verfahren in zwei wesentliche Phasen unterteil, wobei: a. in der ersten Phase die Projektion einer LSV-Textur in die virtuelle Szenerie mittels Projective Texture Mapping gemäß den Projektionsparametern erfolgt, welche sich aus den, eine asymmetrische Projektion ergebenden, Öffnungswinkeln der Lichtquelle ableiten, wobei die Berechnung der Texturkoordinaten für die Abbildung der LSV-Textur auf das Polygonmodell der virtuellen Szenerie in einem Vertex-Shader erfolgt, in dem für jeden Eckpunkt des Polygonmodells die entsprechenden Texturkoordinaten der projizierten LSV-Textur berechnet werden; b. in der zweiten Phase, eine Farbberechnung für jedes Pixel zur Darstellung der Beleuchtung der virtuellen Szenerie durch die simulierten Lichtquellen erfolgt, wobei für die Wiedergabe der Beleuchtung Grautöne für eine Echtfarbdarstellung oder Farbwerte aus dem HSV-Farbmodell für eine Falschfarbdarstellung zum Einsatz kommen.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der ersten Phase ein Pre-Phase vorangestellt ist, in der zur Festlegung der zu projizierenden Lichtstärkeverteilungen (LSV) die in einem Kugelkoordinatensystem vermessenen Lichtverteilungen von Lichtquellen in ein kartesisches Koordinatensystem zur Darstellung der Texel einer Textur und Erzeugung einer konvertierten und verzerrten LSV-Textur umgerechnet werden;
Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Aufbereitung des LSV-Datensatzes in eine LSV-Textur durch ein separates Konvertierungsprogramm offline erfolgt.
Verfahren nach einem der Ansprüche 1, 2 oder 3, dadurch gekennzeichnet, dass der Dynamikbereich der LSV-Eingangswerte in Abhängigkeit von der verwendeten Kodierung auf den Wertebereich der LSV-Textur skaliert wird.
Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass LSV-Werte byte-weise in Farbtripel kodiert werden, welche in den einzelnen Farbkanälen der LSV-Textur gespeichert werden.
Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass die LSV-Werte in drei Bytes mit der Wertigkeit 256⁰, 256¹ und 256² kodiert und als RGB-Tripel in der LSV-Textur gespeichert werden.
Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass die Kodierung auf der Basis der Verwendung von High-Dynamic-Range (HDR) Daten erfolgt.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Ausgangswerte des LSV-Datensatzes durch eine planare Projektion auf die ebene Fläche der LSV-Textur abgebildet werden, um anhand des Projective Texture Mapping in die 3D-Szene projiziert werden zu können.
Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass eine Skalierung der Größe der LSV-Textur erfolgt, wobei die Skalierung derart gewählt ist, dass im Bereich der höchsten Dichte der LSV-Werte, das Abbild eines projizierten LSV-Wertes auf der LSV-Textur der Größe eines Texels entspricht.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Berechnung der endgültigen Farbe für die Beleuchtung jedes Pixels innerhalb eines Pixel-Shaders erfolgt.
Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass Reflexionsparameter auf der Basis der Flächennormalen des Polygonmodells gemäß den Reflexionsmodellen im Vertex-Shader berechnet und für die endgültige Farbberechnung des Verfahrens an den Pixel-Shader übergeben werden.
Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass im Pixel-Shader die pixelgenaue Berechnung der Distanz zwischen einem jeweiligen Punkt der virtuellen Szenerie und der Scheinwerferposition erfolgt.
Verfahren nach einem der Ansprüche 10 bis 12, dadurch gekennzeichnet, dass der jeweilige Beleuchtungswert mit der Texturfarbe des beleuchteten Objektes aus einer Modelldatenbank moduliert wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass es sich bei den Lichtquellen um Scheinwerfer handelt.
Vorrichtung für die Shader-basierte Beleuchtungssimulation technischer Beleuchtungssysteme, dadurch gekennzeichnet, dass die Architektur der Vorrichtung aufeinander abgestimmte Einrichtungen zur visuellen. Simulation, zur Dynamiksimulation, zur Interaktion und zur visuellen Präsentation umfaßt.
Vorrichtung nach Anspruch 15, dadurch gekennzeichnet, dass die Einrichtung zur visuellen Simulation eine Simulationsschleife für die visuelle Simulation aufweist, innerhalb welcher die Auswertung von Benutzereingaben, das Anstoßen einer Dynamiksimulation zur Berechnung der nächsten Simulationsschritte für die Fahrdynamik eines virtuellen Fahrzeugs, die Berechnung einer Beleuchtungssimulation und die Ausgabe der entsprechenden Bilddaten für eine visuelle Präsentation erfolgt.
Vorrichtung nach einem der Ansprüche 15 und 16, dadurch gekennzeichnet, dass die Einrichtung zur visuellen Simulation in Kommunikation mit Datenbasen für die Darstellung der virtuellen Versuchsstrecke und des Fahrzeugs steht, die durch ein Konvertierungswerkzeug aufbereitete Scheinwerferdatensätze als LSV-Texturen zur enthalten, wobei unterschiedliche Beleuchtungsmodelle anhand verschiedener Shader- Routinen integrierbar sind.
Vorrichtung nach Anspruch 16, dadurch gekennzeichnet, dass die Einrichtung zur Dynamiksimulation echtzeitfähig ist und basierend auf einem einfachen MKS-Modell eines Fahrzeugs mit der Beleuchtungssimulation gekoppelt ist
Vorrichtung nach einem der Ansprüche 15 bis 18, dadurch gekennzeichnet, dass die Einrichtung für die visuelle Präsentation zur Vermittlung der räumlichen Tiefe der virtuellen Szenerie kann für eine Mono- oder passiv Stereo-Darstellung über Polarisationsfilter konfiguriert ist.
Vorrichtung nach einem der Ansprüche 15 bis 19, dadurch gekennzeichnet, dass die Vorrichtung modular aufgebaut ist, so daß einzelne Komponenten leicht angepaßt oder ausgetauscht werden können.
Vorrichtung nach Anspruch 20, dadurch gekennzeichnet, dass die Schnittstelle zwischen der Einrichtung zur visuellen Simulation und der Einrichtung zur Dynamiksimulation derart ausgebildet ist, dass sie Lenkbefehle für ein virtuelles Fahrzeug sowie als Ergebnis der Dynamiksimulation Matrizen für die Positionierung und Orientierung der Komponenten des MKS-Modells zwischen der Beleuchtungssimulation und der Fahrdynamiksimulation austauscht.