DE19958329A1 - Verfahren für das zeitbasierte Schatten-Rendering - Google Patents

Abstract

Verfahren für das Rendering von großflächigen zeitbasierten Schatten. Ein erster Schritt sieht die Vorverarbeitung einer Datenbank mit dreidimensionalen Konstrukten vor, welche alle Elemente und Attribute der Elemente in der dreidimensionalen Umgebung definieren. Der Vorverarbeitungsschritt bestimmt das zeitlich relevante Verhalten der Schatten durch das Berechnen eines Winkels, bei dem das Element beleuchtet wird, und eines Winkels, bei dem die Beleuchtung aufhört. Der zweite Schritt sieht eine Verarbeitung der Datenbank in Echtzeit unter Verwendung der vorverarbeiteten Datenbank der dreidimensionalen Konstrukte und der vorberechneten Beleuchtungs- und Nicht-Beleuchtungswinkel vor.

Description

Die vorliegende Erfindung betrifft allgemein das Anzeigen von realistischen Bildern auf einer Grafikanzeige. Insbesondere betrifft die vorliegende Erfindung das Rendering von realistischen großflächigen Schatten, die durch angezeigte Objekte relativ zu den Objekten und einer wahrgenommenen Lichtquelle geworfen werden, um einen größeren Realismus oder eine Bildverbesserung für ein auf einer Grafikanzeige gezeigtes Bild vorzusehen, wobei sich die Schatten über die Zeit verändern.

Das Rendering von realistischen Bildern von dreidimensionalen simulierten Umgebungen in Echtzeit des Standes der Technik ist wegen der erforderlichen großen Berechnungsressourcen gegenwärtig eine schwierige und aufwendige Aufgabe. Trotzdem ist ein dreidimensionaler Szenenrealismus aus verschiedenen Gründen häufig das Ziel von computererzeugten Bildern. Folglich wurden im Lauf der letzten Jahre verschiedene Techniken entwickelt, um die Gesamtbildqualität und den Realismus zu verbessern. Diese Techniken umfassen etwa die Strukturierung, die Beleuchtung, das Anti-Aliasing und die Visualisierung, um den Realismus zu steigern. Einer der herausfordernden Aspekte des Szenen- Rendering betrifft die Schatten. Schatten steigern den realistischen Effekt eines Bildes beträchtlich. Objekte in Szenen ohne Schatten scheinen häufig in der Luft zu schweben. Schatten helfen dem Betrachter, die richtigen Beziehungen zwischen Objekten und Terrain in der Szene zu erkennen.

Es wurden verschiedene Algorithmen entwickelt, um Schatten zu rendern, wobei diese jedoch alle bezüglich der Computerressourcen sehr aufwendig sind. Diese Techniken werden häufig verwendet, wenn computeranimierte Filme oder TV- Werbespots produziert werden. Sie umfassen jedoch allgemein das Rendering von jedem einzelnen Bild, wobei die Bilder dann für die Wiedergabe mit schnelleren Geschwindigkeiten verwendet werden. Mit anderen Worten sind sie allgemein nicht für Anwendungen anwendbar, die ein Echtzeit-Rendering erfordern - etwa für Simulationssysteme, die für das Training verwendet werden. Die Vorteile des computersimulierten Trainings verleihen jedoch der Fähigkeit für das Rendering von realistischen dreidimensionalen simulierten Umgebungen eine verstärkte Bedeutung, weil eine derartige Technologie praktisch und kostensparend eingesetzt werden kann.

Es gibt viele Trainingsszenarios, die computererzeugte Bilder verwenden, um die Trainingserfahrung zu steigern. Für einige Anwendungen würde das Hinzufügen von Schatten die Effektivität des Trainings stark verbessern. Die erforderliche Genauigkeit der Schatten ist von der Trainingsanwendung abhängig. Um zum Beispiel Astronauten für das Andocken eines Objekts im Weltraum zu trainieren, sind extrem genaue und dynamische Schatten erforderlich. Der Astronaut verwendet die Schatten, um die relative Distanz und Position eines Raumfahrzeugs und des angenäherten Objekts zu schätzen. Im Gegensatz dazu können die Schatten viel weniger wichtig für einen Benutzer sein, wenn das Fahren eines Panzers trainiert wird. Bei dieser besonderen Anwendung kann der Primärwert der Schatten einfach in dem erhöhten Realismus liegen, weil Objekte manchmal über dem Terrain zu schweben scheinen, wenn kein Schatten vorhanden ist. Während dieser Mängel zwar ablenkt, ist er jedoch nicht kritisch und führt nicht dazu, daß lebensgefährliche Situationen übersehen werden. Die Wichtigkeit einer realistischen Trainingserfahrung sollte jedoch nicht unterschätzt werden.

Bei anderen Anwendungen sind Schatten absolut erforderlich, um Bedingungen der realen Welt nachzustellen. Weiterhin müssen sich diese Schatten über die Zeit verändern können, wenn sich die simulierte Sonne oder der simulierte Mond in einem simulierten Himmel bewegen. Zum Beispiel ist es beim Militär häufig erforderlich, daß Piloten einen Nachtflug durchführen, während welchem sie Nachtsichtbrillen tragen. Unter bestimmten Bedingungen sind nicht direkt durch das Mondlicht beleuchtete Bereiche schwierig durch die Brillen zu erkennen. Gebäude oder kleine Hügel können zum Beispiel vollständig für den Piloten unsichtbar bleiben, wenn sie im Schatten eines nahen Berges liegen. Diese Hindernisse stellen eine lebensgefährliche Situation für den Piloten dar. Die Situation wird weiterhin dadurch verkompliziert, daß die Schatten ganz anders beschaffen sein können, wenn der Pilot wenige Stunden später bei der Rückkehr von der Mission durch denselben Korridor fliegt. Wenn die Trainingsvorrichtung keine realistischen Schatten rendern kann, erhält der Pilot ein mangelhaftes Training und vielleicht ein falsches Sicherheitsgefühl, wenn simulierte Objekte in der Simulation im Schatten sichtbar sind, weil eine realistische Umgebung oder Bedingungen, welche die Wahrnehmung dieser Umgebung beeinflussen, wie etwa die Nachtsichtbrille, nicht korrekt gerendert werden.

Die Verbesserungen der vorliegenden Erfindung gegenüber dem Stand der Technik konzentrieren sich auf das zeitbasierte Rendering von Schatten. Es wäre zum Beispiel eine Verbesserung gegenüber dem Stand der Technik, eine relativ kostengünstige Lösung für das zeitliche Variieren von Schatten vorzusehen. Es wäre weiterhin eine Verbesserung, eine Vielzahl von Auflösungsstufen vorzusehen, wobei einige Aspekte des zeitbasierten Schatten-Renderings einfach durch einen beliebigen Computerbilderzeuger angewendet werden könnten. Natürlich sollte bei der höchsten Auflösungsstufe eine spezielle Rendering-Hardware in der Lage sein, alle Aspekte der Verbesserungen zu implementieren.

Eine große Anzahl von Rendering-Algorithmen aus dem Stand der Technik werden gegenwärtig für Nicht-Echtzeit-Anwendungen verwendet. Die meisten dieser Techniken sind gegenwärtig nicht für das Echtzeit-Rendering anwendbar, das in Echtzeit- Simulationen erforderlich ist. Während gewisse Erfolge mit Mehrschritt-Rendering-Techniken erzielt werden können, sind diese Techniken mit schweren Leistungsmängeln und Beschränkungen für die Szenarios verbunden. Weiterhin erfordern diese Techniken spezielle Hardware, die nur in High- End-Grafiksystemen verfügbar ist, wodurch die Anwendbarkeit der Verbesserungen begrenzt wird.

Die meisten Trainingsanwendungen, die Schatten erfordern, verwenden gegenwärtig Datenbankmodelltechniken. Zum Beispiel kann ein dunkles, halbdurchsichtiges Polygon mit der Unterseite eines sich bewegenden Fahrzeugs verbunden sein. Wenn sich das Fahrzeug bewegt, folgt das Schattenpolygon und läßt den darunterliegenden Boden dunkler erscheinen. Diese Schatten sind nicht sehr realistisch, können aber häufig einen ausreichenden Realismus für die Zwecke der Trainingsanwendung vorsehen. Dieser Ansatz funktioniert nur für relativ kleine Objekte innerhalb der Szene. Diese Ansätze sind nicht nützlich, um große Schattenbereiche vorzusehen, wie sie etwa von nahen Bergen oder Hügeln geworfen werden.

Es wäre deshalb eine Verbesserung gegenüber dem Stand der Technik für das Rendering von Schatten darstellen, wenn große Schatten gerendert werden könnten, die von der Zeit abhängig sind und ihre Position relativ zu einem sich dynamisch bewegenden Sonnen- oder Mondlicht ändern. Weiterhin sollte das Detailniveau oder die Auflösung auf die Fähigkeiten der in einem System verfügbaren Grafikrendering-Hardware angepaßt werden können.

Es ist eine Aufgabe der vorliegenden Erfindung, ein Verfahren für das Rendering von großen Schattenbereichen anzugeben, die eine beträchtliche Fläche des Terrains und eine große Anzahl von Objekten innerhalb einer grafisch simulierten dreidimensionalen simulierten Umgebung bedecken können.

Es ist eine andere Aufgabe, ein Verfahren für das Rendering von großen Schattenbereichen anzugeben, wobei das Verfahren proportional zu der Renderingleistung der Grafikhardware skaliert werden kann, um die Schatten immer in Echtzeit zu rendern.

Es ist eine weitere Aufgabe, ein Verfahren für das Rendering von Schatten anzugeben, die sich in Übereinstimmung mit der abgelaufenen Zeit verändern und die Bewegung einer simulierten sich bewegenden Lichtquelle wie etwa der Sonne oder des Mondes wiedergeben.

Es ist eine weitere Aufgabe, ein Verfahren für das Rendering von Schatten anzugeben, das ein kostengünstiges System verwendet, welches keine mehrfachen Durchläufe durch eine Renderingeinrichtung erfordert.

Es ist eine weitere Aufgabe, ein Verfahren für das Rendering von Schatten anzugeben, das keine Spezialfall- Schattenpolygone erfordert.

Es ist eine weitere Aufgabe, ein Verfahren für das Rendering eines zeitbasierten Schattenrandes anzugeben.

Es ist eine weitere Aufgabe, ein Verfahren für das Rendering eines zeitbasierten Schattenrandes anzugeben, welches den zeitbasierten Schattenrand relativ zu der Distanz zwischen einer Lichtquelle und einem Objekt, das den Schatten wirft, schärfer oder unschärfer machen kann.

Es ist eine weitere Aufgabe, ein Verfahren für das Rendering von großflächigen Schatten anzugeben, das erweitert werden kann, um dreidimensionale Merkmale vorzusehen, die in oder in der Nähe der Terrains liegen, wie etwa Bäume, Gebäude oder Fahrzeuge.

Die bevorzugte Ausführungsform der vorliegenden Erfindung ist ein Verfahren für das Rendering von großflächigen zeitbasierten Schatten. Ein erster Schritt besteht darin, eine Datenbank von dreidimensionalen Konstrukten vorzuverarbeiten, welche alle statischen Objekte und Attribute von Objekten in einer dreidimensionalen simulierten Umgebung definieren. Der Vorverarbeitungsschritt bestimmt das zeitlich relevante Verhalten der Schatten. Der zweite Schritt besteht darin, die Datenbank in Echtzeit unter Verwendung der vorverarbeiteten Datenbank der dreidimensionalen Konstrukte und zeitbasierten Schatten zu verarbeiten. Alle sich dynamisch bewegenden Objekte in der Szene müssen vollständig in Echtzeit behandelt werden.

In Übereinstimmung mit einem ersten Aspekt der vorliegenden Erfindung ist eine Einrichtung angegeben, welche die Schatten über die Zeit verändert, wenn die simulierte Lichtquelle ihre Position ändert. Die Anwendung der vorliegenden Erfindung verbessert nicht nur den Szenenrealismus und die Plausibilität, sondern sieht einen beträchtlich höheren Trainingswert für einige Anwendungen vor - etwa für ein Training mit Nachtsichtbrillen.

In Übereinstimmung mit einem zweiten Aspekt der vorliegenden Erfindung ermöglicht das System die Bestimmung der Fähigkeiten der Rendering-Hardware und -Software. Mit dieser Information kann das System dann Information zur Anwendungsstufe (Auflösung) verwenden, welche das Laufen der Simulation mit Echtzeit ermöglicht.

Diese und andere Aufgaben, Merkmale, Vorteile und alternativen Aspekte der vorliegenden Erfindung werden für den Fachmann durch die folgende ausführliche Beschreibung verdeutlicht, die auf die beigefügten Zeichnungen Bezug nimmt:

Fig. 1 ist eine Profilansicht von Beispielen von dreidimensionalen Konstrukten, die verwendet werden, um Objekte in einer dreidimensionalen simulierten Umgebung zu bilden.

Fig. 2 zeigt ein Beispiel für die Grenzen eines Schattens in der dreidimensionalen simulierten Umgebung relativ zu dem Ablaufen der Zeit, wenn sich eine simulierte Sonne (Lichtquelle) über die dreidimensionale simulierte Umgebung bewegt.

Fig. 3 ist ein erstes Flußdiagramm, das die Schritte der bevorzugten Ausführungsform darstellt, die in Übereinstimmung mit den Prinzipien der vorliegenden Erfindung beschrieben werden. Diese Schritte zeigen die Vorverarbeitungsstufe der vorliegenden Erfindung für die Datenbank zu der dreidimensionalen simulierten Umgebung.

Fig. 4 ist ein zweites Flußdiagramm, das die Schritte der bevorzugten Ausführungsform darstellt, die in Übereinstimmung mit den Prinzipien der vorliegenden Erfindung beschrieben werden. Diese Schritte zeigen die Echtzeit- Vorverarbeitungsstufe der vorliegenden Erfindung.

Im folgenden wird auf die Zeichnungen Bezug genommen, in denen verschiedene Elemente der vorliegenden Erfindung durch numerische Bezugszeichen angegeben werden. Die vorliegende Erfindung wird mit Bezug auf die Zeichnungen erläutert, um dem Fachmann die Realisierung und Verwendung der vorliegenden Erfindung verständlich zu machen. Dabei ist zu beachten, daß die folgende Beschreibung die Prinzipien der vorliegenden Erfindung lediglich beispielhaft darstellt und die beigefügten Ansprüche in keiner Weise einschränkt.

Bevor die bevorzugte Ausführungsform der vorliegenden Erfindung beschrieben wird, müssen einige Voraussetzungen verdeutlicht werden, die den beschriebenen Prozessen zugrunde liegen.

Fig. 1 zeigt eine beispielhafte Datenbank, die mehrere Basiskonstrukte in einer dreidimensionalen simulierten Umgebung umfaßt. Dabei ist zu beachten, daß die vorliegende Erfindung nicht auf die hier gezeigten Konstrukte beschränkt ist, sondern daß die ausgewählten Konstrukte lediglich der Erläuterung dienen.

Ein erstes Basiskonstrukt ist ein Objekt 10. Das Objekt 10 ist eine Zusammenstellung von verschiedenen Elementen, die gewöhnlich gemeinsam verwendet werden. In dem Beispiel von Fig. 1 gibt das Objekt 10 ein Haus 12 wieder.

Ein zweites Basiskonstrukt ist ein Polygon 14. Ein Polygon 14 ist ein grundlegender Oberflächentyp, der in den meisten Computergrafiksystemen verwendet wird. Das Polygon wird durch drei oder mehr Scheitelpunkte, eine Oberflächenfarbe und andere Oberflächeneigenschaften definiert. In dem in Fig. 1 gezeigten Beispiel gibt das innerhalb eines Kreises gezeigte Polygon 14 ein Fenster des Hauses 12 wieder.

Ein drittes Basiskonstrukt ist ein Scheitelpunkt 16. Ein Scheitelpunkt 16 ist ein Punkt, der an einer bestimmten Position in einem Koordinatensystem innerhalb der dreidimensionalen simulierten Umgebung definiert ist, die in der Datenbank gespeichert ist. Scheitelpunkte werden verwendet, um Positionen innerhalb des Koordinatensystems der Datenbank-Elemente zu definieren. In dem in Beispiel 1 gezeigten Beispiel gibt der innerhalb eines Kreises gezeigte Scheitelpunkt 16 eine der Ecken des Daches des Hauses 12 wieder.

Ein viertes Basiskonstrukt ist eine Struktur 18. Strukturen sind allgemein zweidimensionale Muster, die auf eine Oberfläche eines Elements ähnlich wie eine Tapete angewendet werden. Strukturen sehen typischerweise Farb- und Musterdetails für die Oberfläche vor, so daß wesentlich mehr Detail als nur durch die Polygonstruktur vorgesehen wird. Dabei wird jedes Farbstrukturelement innerhalb des Musters als ein "Texel" bezeichnet.

Bevor die vorliegende Erfindung im Detail beschrieben wird, soll hier noch etwas Hintergrundinformation zu den Schatten gegeben werden. Es sind wenigstens zwei Datenbankelemente erforderlich, um realistische Schatten zu erstellen: ein Element, das Licht blockiert und einen Schatten wirft, und ein zweites Element, auf welches der Schatten geworfen wird. Zum Beispiel kann das in dem oben angeführten Beispiel verwendete Haus 12 einen Schatten auf den darunter liegenden Grund werfen oder es kann ein naher Berg einen Schatten auf das Haus werfen.

Entsprechend sind zwei Prozesse erforderlich, um Schatten mit einer Computergrafikeinrichtung zu rendern. Der erste Prozeß besteht darin, zu bestimmen, wo der Schatten geworfen (oder projiziert) wird. Der zweite Prozeß besteht darin, zu bestimmen, wie der Schatten aussieht.

In der bevorzugten Ausführungsform der vorliegenden Erfindung, wird der erste Prozeß zum Bestimmen, wo der Schatten geworfen wird, in einem Offline- Vorverarbeitungsschritt (zumindest für statische Umgebungen) berechnet. Der zweite Schritt zum Bestimmen, wie der Schatten aussehen wird, wird als Echtzeit-Prozeß auf der Basis der aktuellen Position der simulierten Sonne oder des simulierten Mondes durchgeführt.

In vorteilhafter Weise ist der Vorverarbeitungsschritt am komplexesten und erfordert die größte Berechnungsleistung. Dieser Schritt in deshalb "in vorteilhafter Weise" komplex, weil er vor dem Echtzeit-Prozeß durchgeführt wird, der für in Echtzeit simulierte Umgebungen kritisch ist.

Die Komplexität der durchgeführten Berechnungen hängt stark von der Komplexität der vorverarbeiteten Datenbank ab. Viele Anwendungen der vorliegenden Erfindung können den Umfang dieses Vorverarbeitungsschrittes begrenzen, um die Berechnungen innerhalb von annehmbaren Zeitgrenzen zu halten. Für einen militärischen Nachtsichtbrillen-Trainingsflug zum Beispiel ist der Flugkorridor eines simulierten Flugzeugs häufig schon im voraus bekannt. Die Schattenberechnungen können also auf die Teile der Datenbank entlang des Flugkorridors begrenzt werden. Während dadurch die Fähigkeiten des Systems zum Abweichen von der vorbestimmten Flugroute begrenzt werden, kann die Komplexität der Schatten erhöht werden. Häufig ist es jedoch der Fall, daß die zum Durchführen der Schattenberechnung erforderlichen Computerressourcen verfügbar sind; und wenn die Berechnungen schnell genug durchgeführt werden können, kann die gesamte Datenbank verarbeitet werden. Der Benutzer kann am besten bestimmen, was für eine bestimmte Anwendung am wichtigsten ist.

Fig. 2 wird verwendet, um den Basisprozeß der vorliegenden Erfindung zu erläutern. Dabei ist es am wichtigsten, im Gedächtnis zu behalten, daß es viele verschiedene Ansätze zum Berechnen der erforderlichen Information gibt. Das hier beschriebene Beispiel ist nur eine Möglichkeit.

Es soll angenommen werden, daß die Sonne 20 auf der linken Seite der Zeichnung aufgeht und auf der rechten Seite untergeht. Für jedes Objekt in der Datenbank existiert ein Zeitpunkt (oder ein Winkel), wenn die simulierte Sonne 20 (oder der simulierte Mond) das Objekt 22 zu beleuchten beginnt. Dies ist der Zeitpunkt, zu dem das Objekt 22 aus dem Schatten 24 tritt. Das Objekt 22 wird dann bis zu einem späteren Zeitpunkt beleuchtet, zu dem die simulierte Sonne 20 (oder der simulierte Mond) untergeht, wodurch das Objekt 22 zurück in den Schatten 24 versetzt wird.

Es können einige Grundannahmen gemacht werden, um das in Fig. 2 gezeigte Szenario zu vereinfachen. Erstens besteht für jeden bestimmten Tag des Jahres eine Korrelation zwischen der Tageszeit und dem Winkel zur Sonne 20 (oder zum Mond). Zweitens kommen die meisten Objekte einmal pro Tag aus dem Schatten (für die Sonne oder den Mond, aber nicht für beide) und kehren einmal pro Tag in den Schatten zurück. Es kann also für jedes Objekt der Winkel berechnet werden, bei dem die Sonne 20 oder der Mond zuerst das Objekt 22 beleuchtet (Beleuchtungsbeginnwinkel), sowie der Winkel berechnet werden, bei dem die Beleuchtung endet (Beleuchtungsendewinkel). Diese zwei Parameter werden berechnet und dann für jedes interessante Objekt in der Datenbank gespeichert. Die vorliegende Erfindung ist jedoch nicht auf ein einmaliges An/Aus pro Objekt beschränkt. Es können mehrere Lichtquellen vorgesehen sein, die Objekte beleuchten, und das System kann diese Möglichkeit wiedergeben.

Mit dieser während der Vorverarbeitungsstufe berechneten Information wird der nächste Schritt in der Echtzeitstufe durchgeführt. In dieser Stufe des bevorzugten Verfahrens wird der aktuelle Winkel der Sonne oder des Mondes mit dem gespeicherten Beleuchtungsbeginnwinkel und dem Beleuchtungsendewinkel jedes interessanten Objekts in der durch die Datenbank definierten dreidimensionalen simulierten Umgebung verglichen. Der Vergleich gibt also schnell an, ob die Entität innerhalb oder außerhalb des Schattens ist, wobei die Entität dann dementsprechend gerendert werden kann. Dieses Verfahren nimmt natürlich an, daß der durch die Rendering- Hardware und -Software vorgesehene Rendering-Prozeß das Konzept einer Beleuchtung durch Lichtquellen unterstützt.

Der hier verwendete Begriff Objekt bezieht sich auf jedes gewünschte Datenbankkonstrukt. Das entsprechende zu verwendende Konstrukt hängt von den verfügbaren Computerressourcen und dem Realismus ab, der in einem resultierenden Bild dieser dreidimensionalen simulierten Umgebung erforderlich ist.

Es soll zum Beispiel angenommen werden, daß diese Berechnungen auf einer Objektstufe vorgenommen werden sollen. Das Haus 20 in Fig. 2 ist vollständig innerhalb oder vollständig außerhalb des Schattens 24. Folglich wird das Haus 20 zu dem entsprechenden Tageszeitpunkt plötzlich vollständig durch die Sonne (oder den Mond) beleuchtet. Entsprechend wird das gesamte Haus 20 zu einem späteren Zeitpunkt plötzlich nicht mehr beleuchtet. Diese Stufe des Realismus kann absolut annehmbar sein, wenn die Trainingserfahrung erfordert, daß der Pilot zu verschiedenen Tageszeiten durch den Korridor fliegt. Es besteht jedoch die Beschränkung, daß der Pilot nicht innerhalb des Bereichs sein sollte, wenn der Winkel der Sonne aktualisiert wird. Andernfalls wird die Illusion des Realismus wesentlich beeinträchtigt, wenn das Haus 20 plötzlich in oder aus dem Schatten springt.

Wenn der Rendering-Prozeß jedoch dafür ausgebildet ist, eine realistischere und dynamischere Steuerung der Beleuchtungsparameter vorzusehen, kann das Objekt in oder aus dem Licht geblendet werden, wenn sich die Position der Lichtquelle bewegt. Das Objekt "springt" dann nicht in oder aus dem Schatten, sondern wird allmählich ein- oder ausgeblendet.

Die Objektstufe (oder Auflösung) der Steuerung kann jedoch nicht für alle Objekte innerhalb der Szene adäquat sein. Zum Beispiel kann die Terrainoberfläche selbst nicht in nützliche Objekte, was zumindest die Schatten betrifft, aufgeteilt sein. Bessere Ergebnisse können durch das Steuern derartiger Oberflächen auf einer Polygon-Auflösungsstufe erhalten werden. Dementsprechend muß eine Bestimmung für jedes Polygon (oder anderes Element) innerhalb des Objekts vorgenommen werden. Dieser Ansatz erlaubt, daß Teile des Hauses (oder des Terrains) innerhalb des Schattens sind, während andere Teile außerhalb des Schattens sind. Es können wiederum weitere Verbesserungen erhalten werden, indem das Element in und aus dem Schatten geblendet wird und nicht in und aus dem Schatten springt.

Selbst diese Schattensteuerung auf der Element-(Polygon)- Stufe kann für einige Anwendungen nicht ausreichen, die eine größere Genauigkeit und Modellierung von Echtzeit-Bedingungen erfordern. Eine weitere Verbesserung kann erreicht werden, indem der Status an jedem Scheitelpunkt jedes Polybons bestimmt wird. Polygone, die vollständig innerhalb oder außerhalb des Schattens liegen, sind einfach zu behandeln. Polygone, die entlang der Grenze des Schattens liegen, erfordern jedoch eine weitere Verarbeitung. Wenn einige der Scheitel im Schatten liegen, während andere außerhalb des Schattens liegen, wird das Polygon entlang einer Schattengrenze abgeschnitten, um effektiv zwei neue Polygone zu bilden: eines innerhalb des Schattens und eines außerhalb des Schattens. Die Abschneideoperation kann durchgeführt werden, indem der aktuelle Winkel der Sonne (oder des Mondes) in Beziehung zu dem An/Aus-Winkel an jedem Scheitelpunkt verwendet wird.

Wenn alternativ dazu Algorithmen für die Pixelraten- Schattierung durch die Rendering-Hardware unterstützt werden, können ähnliche Techniken für die Schattenberechnungen angewendet werden. Standardalgorithmen für die Schattierung interpolieren an den Scheitelpunkten definierte Daten, um einzigartige Daten an jedem Pixel zu erhalten. Dieselben Algorithmen können zum Interpolieren der An/Aus-Zeit an jedem Scheitelpunkt verwendet werden, um die An/Aus-Zeit für jedes Pixel zu finden. Dadurch wird ermöglicht, daß die Schattengrenze irgendwo innerhalb des Elementes liegt, ohne daß ein extra Schritt zum Abschneiden erforderlich ist. Diese Grenze kann dann weich gemacht werden (Anti-Aliasing), indem das Licht an- und ausgeblendet wird, wenn sich die Pixel der Grenze nähern.

Eine zu den Polygonoberflächen hinzugefügte Struktur sieht Oberflächendetail vor, das die Polygonstruktur des Objekts weit überschreitet. Wenn die An- und Aus-Winkel als Teil der Struktur gespeichert sind, werden sie verwendet, um den Schattenstatus jedes Texels zu bestimmen. Weiterhin können Standardtechniken für das Filtern der Strukturen (wie etwa das MIP⁴-Trilinear-Blending) verwendet werden, um den Schattenstatus jedes Pixels auf dem Bildschirm zu berechnen. Dadurch wird nicht nur eine Schattensteuerung mit der Pixelauflösung vorgesehen, sondern der Strukturfilterprozeß kann auch verwendet werden, um die Schattengrenze zu glätten oder weich zu machen. Anstatt also nur zu entscheiden, ob das Pixel innerhalb oder außerhalb des Schattens ist, kann der Filter bestimmen, welcher Prozentsatz des Pixels innerhalb oder außerhalb des Schattens ist, um eine entsprechende Teilbeleuchtung oder ein Ausblenden entlang des Schattenumfangs vorzusehen.

Ein wichtiger Aspekt des oben beschriebenen Verfahrens besteht darin, daß die besondere durch den Benutzer ausgewählte Detailstufe in beiden Verarbeitungsstufen gleich sein muß. Wenn mit anderen Worten die Vorverarbeitung der Datenbank mit der Polygonauflösung vorgenommen wurde, kann die Echtzeit-Entscheidungsfindung nicht mit der Pixelauflösung vorgenommen werden und umgekehrt.

Dabei ist zu beachten, daß die Verwendung des Winkels zu der Lichtquelle den zusätzlichen Vorteil aufweist, daß Schattenränder genau wiedergegeben werden. Je näher das Objekt, das den Schatten wird, dem Objekt ist, das den Schatten empfängt, desto schärfer ist der Schattenrand. Umgekehrt verursacht ein entfernteres Objekt einen unscharfen Schattenrand.

Der Effekt eines schärferen oder unschärferen Schattenrandes kann auftreten, wenn der Schatten von einem kurzen oder langen Objekt geworfen wird. Wenn die simulierte Lichtquelle zum. Beispiel die Sonne ist und die Sonne im Zenit steht, dann ist der durch das Objekt geworfene Schatten relativ klein und kurz und deshalb scharf. Wenn die Distanz zwischen dem Objekt, das den Schatten wirft, und der Sonne größer ist, wirft das Objekt einen großen und längeren Schatten, der deshalb unscharf ist.

Mit Unterstützung durch eine entsprechende Hardware und durch entsprechende Algorithmen für die Vorverarbeitung kann die vorliegende Erfindung extrem realistisch aussehende Schatten für große Teile einer Datenbank erzeugen. Dieser Ansatz eignet sich jedoch nicht dazu, sich dynamisch bewegende Objekte innerhalb der Datenbank zu unterstützen. Die vorliegende Erfindung kann zwar angepaßt werden, um diese Bedingung zu unterstützen, wobei dies jedoch einen großen Berechnungsaufwand bedeutet. Der Grund dafür ist, daß die Verarbeitung der ersten Stufe vollständig in Echtzeit durchgeführt werden muß. Wenn jedoch ausreichende Berechnungsressourcen verfügbar sind, dann kann eine Echtzeit- Simulation erreicht werden.

Es sollte jedoch deutlich sein, daß die bevorzugte Ausführungsform der vorliegenden Erfindung erlaubt, daß sich die Lichtquelle in Echtzeit bewegt, solange sie dem Pfad folgt, der zum Vorberechnen der An/Aus-Zeiten verwendet wurde. Wenn also dieser Ansatz mit der Strukturauflösung oder den Pixelrateninterpolationen verwendet wird, ist es gut möglich, daß man die Lichtquelle beobachten kann, die sich ohne ablenkende Artefakte wie etwa Sprungbewegungen in Echtzeit bewegt.

Fig. 3 ist ein Flußdiagramm, das die Verarbeitungsschritte darstellt, die für die Vorverarbeitung durchgeführt werden. Anstatt eine robuste Universallösung für das Rendering von Schatten anzugeben, konzentriert sich die bevorzugte Ausführungsform auf eine beschränkte Klasse von Anwendungen, die sehr spezifische Anforderungen an Schatten stellen. Es ist also möglich, komplexe Berechnungen für die Projektion von Schatten auf einer Datenbank in der Form eines Offline-Prozesses und dann einfache Vergleiche in Echtzeit vorzunehmen, um auf der Basis der aktuellen Position der simulierten Lichtquelle, d. h. der Sonne und des Mondes, zu bestimmen, was innerhalb und was außerhalb des Schattens ist. Es ist jedoch wichtig, stets im Gedächtnis zu behalten, daß die Vorverarbeitungsschritte annehmen, daß das Grafiksystem in der Lage ist, Oberflächen zu rendern, die durch eine oder mehrere Lichtquellen beleuchtet werden.

Die vorliegende Erfindung kann erweitert werden, um komplexere Fälle wie sich bewegende Objekte oder sich bewegende Lichtquellen (die sich irgendwo anders als auf dem vorberechneten Pfad bewegen) zu unterstützen, wobei dadurch jedoch die Berechnungslast erheblich erhöht wird. Es ist also zu beachten, daß die vorliegende Erfindung nicht auf Schatten begrenzt ist, die durch die Sonne oder den Mond verursacht werden.

Wie im Flußdiagramm gezeigt, erfordert der Schritt 30, daß die Datenbank erzeugt werden muß, die alle Objekte innerhalb der dreidimensionalen simulierten Umgebung enthält. Dabei ist zu beachten, daß keine speziellen Beschränkungen bezüglich der Natur der Elemente innerhalb der Datenbank gelten. Es sollte jedoch im Gedächtnis behalten werden, daß bei einer Umgebung, die nicht statisch ist, die Berechnungsressourcen für die Echtzeit-Simulation groß sein müssen.

Bevor alle Vorverarbeitungsberechnungen durchgeführt werden, sollten die Anforderungen für die Genauigkeit der Simulation bekannt sein. Wenn diese bekannt sind, kann der Benutzer in Schritt 32 bestimmen, auf welcher Stufe, oder mit welcher Auflösung, die bevorzugte Ausführungsform angewendet werden soll. Als Auflösungsstufe kann zum Beispiel die Stufe des Objekts, der Struktur, des Polygons oder des Pixels ausgewählt werden. Je feiner die Auflösung, desto mehr Berechnungen müssen durch das System durchgeführt werden.

Der Schritt 34 erfordert, daß der "An"-Winkel jetzt für jedes Element berechnet wird. Insbesondere muß der Pfad der simulierten Lichtquelle bereits festgelegt sein. Wenn dieser Pfad bekannt ist, wird der Winkel bestimmt, bei dem die simulierte Lichtquelle im Himmel das Element zu beleuchten beginnt.

Der Schritt 36 erfordert, daß jetzt der "Aus"-Winkel für jedes Element berechnet wird. Mit dem bekannten Pfad der simulierten Lichtquelle, wird der Winkel bestimmt, bei dem die simulierte Lichtquelle im Himmel aufhört, das Element zu beleuchten.

Schließlich erfordert der Schritt 38, daß die in Schritt 34 und 36 berechneten An- und Aus-Winkel in der Datenbank für das Abrufen während der Echtzeit-Stufe gespeichert werden.

Die Schritte 34, 36 und 38 werden für jedes Element in der Datenbank wiederholt, so daß deutlich wird, warum dieser Schritt so rechenaufwendig ist und warum er in vorteilhafter Weise vor der Echtzeit-Stufe durchgeführt wird.

Bevor die Echtzeit-Stufe der vorliegenden Erfindung beschrieben wird, sollte erwähnt werden, daß es in einigen Fällen vorteilhaft sein kann, wenn in Schritt 32 mehr als eine Auflösungsstufe ausgewählt werden. Mit anderen Worten kann die Vorverarbeitungsstufe alle Berechnungen für An- und Aus-Winkel für alle Elemente in zwei oder drei Auflösungsstufen durchführen. Wenn diese Information in der Datenbank gespeichert ist, kann der Echtzeit-Prozeß die Grafikrendering- Hardware und -Software des Simulationssystems testen. Wenn die Rendering-Hardware und -Software ausreichende Fähigkeiten aufweisen, kann die höchste Auflösungsstufe in dem Echtzeit- Prozeß verwendet werden. Wenn die Rendering-Hardware und -Software jedoch beschränkt sind, kann eine niedrigere Auflösung verwendet werden. Entweder kann der Benutzer eine Auflösungsstufe wählen oder das System kann automatisch die höchste Auflösungsstufe auswählen, bei der eine Echtzeit- Simulation möglich ist.

Fig. 4 ist ein Flußdiagramm der Echtzeit-Stufe der bevorzugten Ausführungsform der vorliegenden Erfindung. Wenn die Berechnungen der Vorverarbeitungsstufe abgeschlossen sind, ermöglicht diese Stufe eine Echtzeit-Simulation.

Der Schritt 50 erfordert, daß die aktuelle Tageszeit in der Simulation bekannt sein muß. Wenn zum Beispiel ein Pilot eine Nachtangriffssimulation durchführt, ist die simulierte Lichtquelle der Mond an einer bestimmten Himmelsposition. Mit dieser Information wird der Winkel der simulierten Lichtquelle in Beziehung zu einer Horizontalebene bestimmt.

Der Schritt 52 erfordert, daß das System (oder der Benutzer) die Auflösungsstufe für jedes Element in der Datenbank auswählt, so daß auf eine entsprechende Information aus der vorverarbeiteten Datenbank zugegriffen werden kann.

Der Schritt 54 erfordert, daß das System den in Schritt 50 bestimmten Winkel mit An- und Aus-Winkeln vergleicht, die zuvor für jedes Element berechnet wurden.

Der Schritt 56 veranlaßt in Übereinstimmung mit dem in Schritt 54 vorgenommenen Vergleich, daß jedes Element entweder durch die simulierte Lichtquelle beleuchtet wird oder im Schatten ist. Die Elemente entlang der Schattengrenze können teilweise beleuchtet werden, um den Schattenrand zu simulieren.

Der Schritt 58 erfordert, daß die Elemente gerendert werden. Zu diesem Zeitpunkt kehrt das Verfahren zu Schritt 52 zurück, um die Berechnungen wiederum für jedes Element mit der ausgewählten Auflösungsstufe zu beginnen. Die Schritte 52, 54, 56 und 58 werden für jedes Element in der Datenbank für jedes Bild wiederholt, das in einer Grafikanzeige der simulierten Umgebung gerendert wird. Typischerweise ist ein Minimum von wenigstens 15 Bildern pro Sekunde erforderlich, um eine Echtzeit-Simulation ohne ablenkende Bewegungen auf der Grafikanzeige zu erreichen. Dementsprechend kann die Anzahl der Berechnungen sehr groß sein.

Es wurde zuvor erwähnt, daß eine Korrelation zwischen der Tageszeit und dem Winkel zu der simulierten Lichtquelle besteht. Offensichtlich können die Simulationen sehr genau gemacht werden. Folglich sind der geographische Breitengrad der simulierten Umgebung und die Jahreszeit andere Faktoren, welche den Winkel beeinflussen können. Dabei kann entschieden werden, ob der Realismus der Simulation ausreichend genau ist, um diese anderen Faktoren in der Berechnung des Winkels zu berücksichtigen.

Dabei ist zu beachten, daß die oben beschriebenen Anordnungen lediglich beispielhaft die Anwendung der Prinzipien der vorliegenden Erfindung illustrieren. Es können durch den Fachmann zahlreiche Modifikationen und alternative Anordnungen vorgesehen werden, ohne daß dadurch von dem Gedanken und dem Umfang der vorliegenden Erfindung abgewichen wird, der durch die beigefügten Ansprüche definiert wird.

Claims (33)

1. Verfahren für das Rendering von zeitbasierten Schatten in einer dreidimensionalen simulierten Umgebung, wobei das Verfahren folgende Schritte umfaßt:

• 1. Erzeugen einer Datenbank, die eine Vielzahl von Konstrukten umfaßt, welche alle Objekte innerhalb der dreidimensionalen simulierten Umgebung wiedergeben,
• 2. Vorverarbeiten der Datenbank, um Beleuchtungsdaten zu erzeugen und in der Datenbank zu speichern, welche wiedergeben, wann jedes aus der Vielzahl von Konstrukten durch eine simulierte Lichtquelle mit Bezug auf eine ausgewählte Zeitbasis beleuchtet und nicht beleuchtet wird, und
• 3. Verarbeiten der Datenbank in Echtzeit, wobei die Beleuchtungsdaten verwendet werden, um jedes aus der Vielzahl von Konstrukten selektiv mit Bezug auf die ausgewählte Zeitbasis und eine Position der simulierten Lichtquelle zu beleuchten oder nicht zu beleuchten, um wenigstens einen zeitbasierten Schatten zu rendern, wobei die dreidimensionale simulierte Umgebung unter Verwendung einer Grafikrendering- Hardware angezeigt wird.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Schritt zum Vorverarbeiten der Datenbank weiterhin folgende Schritte umfaßt:

• 1. Auswählen einer Anwendungsstufe für die Vielzahl von Konstrukten, wobei die Anwendungsstufe eine Auflösung für das Projizieren von wenigstens einem zeitbasierten Schatten definiert, so daß der wenigstens eine zeitbasierte Schatten auf die Vielzahl von Konstrukten mit der ausgewählten Schattenauflösung angewendet wird,
• 2. Berechnen eines ersten Winkels über einer Horizontalebene, oberhalb von welchem die simulierte Lichtquelle ein ausgewähltes aus der Vielzahl von Konstrukten beleuchtet,
• 3. Berechnen eines zweiten Winkels über einer Horizontalebene, unterhalb von welchem die simulierte Lichtquelle aufhört, das ausgewählte aus der Vielzahl von Konstrukten zu beleuchten,
• 4. Speichern des ersten und des zweiten Winkels, die in den Schritten (2) und (3) für das ausgewählte aus der Vielzahl von Konstrukten bestimmt wurden, in der Datenbank, und
• 5. Wiederholen der Schritte (2), (3) und (4) für jedes aus der Vielzahl von Konstrukten in der Datenbank.

3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt zum Auswählen der Anwendungsstufe aus der Gruppe von Konstrukten umfaßt, welche Objekte, Strukturen, Texels, Scheitelpunkte und Polygone umfaßt.

4. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das Verfahren weiterhin folgende Schritte umfaßt:

• 1. Bestimmen einer Schattenrendering-Auflösung der Grafikrendering-Hardware, und
• 2. Rendern des wenigstens einen zeitbasierten Schattens für die Vielzahl von Konstrukten in Übereinstimmung mit der Schattenrendering-Auflösung, um ein Schattenrendering der Datenbank zu ermöglichen.

5. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt zum Definieren eines festgelegten Pfades für die simulierte Lichtquelle innerhalb der dreidimensionalen simulierten Umgebung umfaßt.

6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt umfaßt, welcher es der simulierten Lichtquelle ermöglicht, sich mit einer konstanten Geschwindigkeit entlang des festgelegten Pfades und mit Bezug auf die ausgewählte Zeitbasis zu bewegen.

7. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt zum Auswählen der simulierten Lichtquelle als Lichtquelle umfaßt, deren Bewegung in Übereinstimmung mit einem bestimmbaren Pfad innerhalb der dreidimensionalen simulierten Umgebung definiert ist, wobei bei der Vorverarbeitung der Datenbank die von derselben geworfenen Schatten mit Bezug auf die ausgewählte Zeitbasis berechnet werden können.

8. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt zum Erzeugen der dreidimensionalen simulierten Umgebung mit Hilfe einer Ein- Schritt-Rendering-Grafikeinrichtung umfaßt, um das Rendering der dreidimensionalen simulierten Umgebung in Echtzeit zu ermöglichen.

9. Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt zum Erzeugen der dreidimensionalen simulierten Umgebung umfaßt, so daß die Vielzahl von Konstrukten statisch darin positioniert sind und die einzigen sich bewegenden Objekte die simulierte Lichtquelle, die zeitbasierten Schatten und eine perspektivische Ansicht sind, die einen Benutzer wiedergibt, der sich innerhalb der dreidimensionalen simulierten Umgebung bewegt.

10. Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt zum Erzeugen der dreidimensionalen simulierten Umgebung umfaßt, so daß die Vielzahl von Konstrukten dynamisch darin positioniert sind, so daß sich ein beliebiges aus der Vielzahl von Konstrukten bewegen kann, wobei eine Grafikeinrichtung erforderlich ist, um den ersten Winkel und den zweiten Winkel für jedes sich bewegende aus der Vielzahl von Konstrukten während der Echtzeit-Operation der Simulation neu zu berechnen.

11. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt zum Betreiben der ausgewählten Zeitbasis mit Bezug auf eine periodische Zeitreferenz umfaßt, so daß die Bewegung der Schatten damit übereinstimmend bestimmt werden kann.

12. Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt zum Berechnen des ersten Winkels mit Bezug auf eine periodische Zeitreferenz und den festgelegten Pfad der simulierten Lichtquelle umfaßt.

13. verfahren nach Anspruch 12, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt zum Berechnen des zweiten Winkels mit Bezug auf eine Tageszeit und den festgelegten Pfad der simulierten Lichtquelle umfaßt.

14. Verfahren nach Anspruch 13, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt zum Auswählen eines Breitengrads für jedes aus der Vielzahl von Konstrukten umfaßt, so daß der erste Winkel und der zweite Winkel mit Bezug auf den durch die Simulation wiedergegebenen Breitengrad bestimmt werden.

15. Verfahren nach Anspruch 14, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt zum Auswählen einer Jahreszeit umfaßt, die durch die dreidimensionale simulierte Umgebung simuliert werden soll, so daß der erste Winkel und der zweite Winkel mit Bezug auf die durch die Simulation wiedergegebene Jahreszeit bestimmt werden.

16. Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt zum Begrenzen der Anwendungsstufe für die Vielzahl von Konstrukten in Übereinstimmung mit einer wahrgenommenen Rechenleistungsgrenze der Grafikrendering-Hardware umfaßt.

17. Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt zum Begrenzen der Anwendungsstufe für die Vielzahl von Konstrukten entlang eines ausgewählten Pfades mit einer auswählbaren Breite innerhalb der dreidimensionalen simulierten Umgebung umfaßt, um dadurch die Größe und die Komplexität der in der Datenbank gespeicherten Beleuchtungsdaten zu steuern.

18. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt zum Rendern von realistischeren Schatten umfaßt, indem veranlaßt wird, daß sich ein Objekt, das zwischen einem beleuchteten Zustand und einem nicht beleuchteten Zustand wechselt, graduell in Abhängigkeit von der ausgewählten Zeitbasis ändert.

19. Verfahren nach Ansprüch 3, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt zum Bestimmen eines Beleuchtungsstatus an jedem Scheitelpunkt jedes Polygons der Vielzahl von Konstrukten umfaßt, so daß Polygone, die teilweise beleuchtet werden sollen, dementsprechend schattig dargestellt werden.

20. Verfahren nach Anspruch 19, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt zum Abschneiden eines teilweise beleuchteten Polygons umfaßt, wobei das Polygon in ein beleuchtetes Polygon und in ein nicht beleuchtetes Polygon unterteilt wird.

21. Verfahren nach Anspruch 19, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt zum Verwenden eines Pixelraten-Schattierungsprozesses umfaßt, um den ersten Winkel und den zweiten Winkel an jedem Scheitelpunkt eines teilweise beleuchteten Polygons zu interpolieren, um den ersten Winkel und den zweiten Winkel für jedes Pixel in dem teilweise beleuchteten Polygon zu bestimmen.

22. Verfahren nach Anspruch 21, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt zum teilweisen Beleuchten jedes Pixels umfaßt, das als in der Nähe einer Beleuchtungsgrenze des teilweise beleuchteten Polygons liegend bestimmt wird, so daß ein Anti-Aliasing für die Beleuchtungsgrenze vorgesehen wird, um das entsprechende Bild weicher zu machen.

23. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt zum Speichern des ersten Winkels und des zweiten Winkels als Element einer Struktur jedes Polygons umfaßt, um dadurch einen Beleuchtungsstatus jedes Texels innerhalb des Polygons zu bestimmen.

24. Verfahren nach Anspruch 23, dadurch gekennzeichnet, daß das Verfahren weiterhin folgende Schritte umfaßt:

• 1. Bestimmen eines Beleuchtungsstatus jedes Texels innerhalb des Polygons, indem ein Standardprozeß zum Strukturfiltern verwendet wird, und
• 2. Bestimmen, welcher Prozentsatz jedes Pixels beleuchtet wird.

25. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt zum Auswählen derselben Anwendungsstufe für die Vorverarbeitung der Datenbank und für die Verarbeitung der Datenbank umfaßt.

26. Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt umfaßt, welcher es der simulierten Lichtquelle ermöglicht, sich von dem festgelegten Pfad weg zu bewegen, so daß eine Grafikeinrichtung benötigt wird, um den ersten Winkel und den zweiten Winkel für jedes aus der Vielzahl von Konstrukten während der Echtzeit- Operation der Simulation neu zu berechnen.

27. Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt umfaßt, welcher es einer Vielzahl von Lichtquellen ermöglicht, die Vielzahl von Konstrukten zu beleuchten, wobei eine Gruppe von ersten Winkeln und eine Gruppe von zweiten Winkeln von der Vielzahl von Lichtquellen erzeugt wird.

28. Verfahren nach Anspruch 27, dadurch gekennzeichnet, daß das Verfahren weiterhin folgende Schritte umfaßt:

• 1. Auswählen einer Vielzahl von Anwendungsstufen für die Vielzahl von Konstrukten, wobei die Vielzahl von Anwendungsstufen eine Vielzahl von Auflösungen für das Projizieren von wenigstens einem Schatten definieren, so daß der wenigstens eine Schatten auf die Vielzahl von Konstrukten mit einer Anwendungsstufe angewendet wird,
• 2. Berechnen eines ersten Winkels über einer Horizontalebene, oberhalb von welchem die simulierte Lichtquelle ein ausgewähltes aus der Vielzahl von Konstrukten mit der Anwendungsstufe beleuchtet,
• 3. Berechnen eines zweiten Winkels über einer Horizontalebene, unterhalb von welchem die simulierte Lichtquelle aufhört, das ausgewählte aus der Vielzahl von Konstrukten mit der Anwendungsstufe zu beleuchten,
• 4. Speichern der Winkel, die in den Schritten (2) und (3) für das ausgewählte aus der Vielzahl von Konstrukten mit der ausgewählten Schattierungsauflösung bestimmt wurden, in der Datenbank, und
• 5. Wiederholen der Schritte (2), (3) und (4) für jedes aus der Vielzahl von Konstrukten in der Datenbank und für jede aus der Vielzahl von Anwendungsstufen.

29. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das Verfahren weiterhin folgende Schritte umfaßt:

• 1. Bestimmen einer Tageszeit, zu welcher die Simulation gegenwärtig ausgeführt wird, mit Bezug auf die ausgewählte Zeitbasis, um einen dritten Winkel zwischen der simulierten Lichtquelle und jedem aus der Vielzahl von Konstrukten zu bestimmen,
• 2. Auswählen einer Anwendungsstufe für die Datenbank, um es der Grafik-Hardware zu ermöglichen, den wenigstens einen zeitbasierten Schatten mit einer entsprechenden Auflösung zu rendern,
• 3. Vergleichen des ersten Winkels und des zweiten Winkels mit dem dritten Winkel, um einen Beleuchtungsstatus des Konstrukts zu bestimmen, und
• 4. Rendern des Konstrukts mit der entsprechenden Beleuchtung in Übereinstimmung mit der ausgewählten Anwendungsstufe.

30. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt zum Rendern des wenigstens einen zeitbasierten Schattens in der dreidimensionalen simulierten Umgebung in Echtzeit durch das Ausführen von Schritt 3) umfaßt, wobei die Datenbank in Echtzeit verarbeitet wird, um den wenigstens einen zeitbasierten Schatten dynamisch zu rendern.

31. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt zum Rendern eines zeitbasierten Schattenrandes relativ zu dem wenigstens einen zeitbasierten Schatten umfaßt, um einen realistischeren Effekt vorzusehen.

32. Verfahren nach Anspruch 31, dadurch gekennzeichnet, daß das Verfahren weiterhin einen Schritt zum Verwenden einer Position der simulierten Lichtquelle umfaßt, um eine Änderung in der Auflösung des zeitbasierten Schattenrandes vorzusehen.

33. Verfahren nach Anspruch 32, dadurch gekennzeichnet, daß das Verfahren weiterhin folgende Schritte umfaßt:

• 1. Scharfmachen einer Auflösung des zeitbasierten Schattenrandes, wenn die simulierte Lichtquelle relativ nahe zu der Vielzahl von Konstrukten angeordnet ist, und
• 2. Unscharfmachen einer Auflösung des zeitbasierten Schattenrandes, wenn die simulierte Lichtquelle relativ weit von der Vielzahl von Konstrukten angeordnet ist.