Hallo Marcel,
erstmal Danke für den Lob und eine dicke Entschuldigung, dass ich erst jetzt antworte und du wohl nie wieder diesen Blog lesen wirst...
Dein Einwand ist leider komplett richtig: Ich schmeiße die beiden Begriffe total durcheinander und als Leser hat man sicherlich den Anschein, als wäre es das selbe.
Zu den einzelnen Punkten werd ich nicht so viel sagen, weil ich vorhabe in naher Zukunft (falls ich Zeit finde) einen 2. Artikel zu veröffentlichen, in dem ich Lösungen für meine 5 genannten Probleme erläutere. Vorallem habe ich einen Interview-Partner gehabt, der total in der Materie steckt (den Programmierer von Atomontage). Daher nur kurz:
1. Mir wurde erklärt, dass durch sehr effiziente Kompressions Algorithmen dieses Problem mit Leichtigkeit zu umgehen ist (wie du schon gesagt hast)
2. Ja, es gibt viele gute Ansätze, ich habe aber von einem sehr interessanten gehört, den du jetzt nicht erwähnt hast. Verschieben durch Offset ist natürlich gut machbar. Ich möchte zu deinen "statischen" Objekten noch anmerken: Ja es gibt viel statisches, aber das ändert sich in modernen Spielen immer mehr. Es geht immer weiter in die Richtung, dass alles Zerstörbar ist. Vegetation jeder weht im Wind usw.. Also viel statisches wird es wohl nicht geben.
3.+4. Jein. Es erfolgt vieles auf der Bildebene, ja. Auch Verdeckungstechniken wie SSAO sind tatsächlich auf Bildebene zu machen, wie du schon gesagt hast. Allerdings gibt es auch immer noch mehrere Techniken die nicht auf Bildebene arbeiten (siehe zb. die Realtime Global Illumination aus Crysis 2).
Ich bedanke mich sehr für die Kritik, du hast in deinen Punkten absolut recht. Geplant war allerdings auch, dass ich wenige Tage nach diesem Artikel einen weiteren Artikel schreibe, der exakt die Vorteile bzw. Problemlösungen aufzählt. Daraus ist dank fehlender Zeit/Motivation nichts geworden.
LG
Lukas
Hallo,
ich bin per Zufall auf deine Seite gestoßen und möchte ein paar Worte zu deinem Artikel/Blog-Eintrag verlieren. Zunächst einmal ist es eine schöne Zusammenfassung für den Laien, die das recht komplexe Thema verständlich darstellt. Allerdings wirfst du durch die Abstraktion für den Laien auch ein paar Begriffe etwas durcheinander, wodurch womöglich Missverständnisse auftreten können. Auch muss ich dir bei ein paar Punkten widersprechen.
Zunächst einmal ist ein Oct-Tree nur eine Baum-Datenstruktur, welche sich zum Speichern räumlicher Daten eignet und ein schnelles Auffinden dieser an einer bestimmten Position im Raum ermöglicht. Außerdem ist es möglich verschieden Detailstufen in dieser Datenstruktur abzulegen, so dass z.B. bei weiter Entfernung von einem 3D-Modell nur eine vereinfachte Version geladen und dargestellt werden muss. Am Anfang des Artikels hört sich die Beschreibung noch korrekt an, aber am Ende könnte der Laie vermuten Voxel und Oct-Tree sind Synonyme, was natürlich falsch ist. Der Vergleich ist also nicht zwischen Modellen aus Oct-Trees und Modellen aus Polygonen sondern zwischen Modellen aus Voxeln/Punktwolken und Modellen aus Polygonen. In vielen Engines werden Oct-Trees nämlich auch dazu verwendet um effizient nur die Teile eines Levels zu laden, die auch auf dem Bildschirm sichtbar sind bzw. in nächster Zeit sichtbar werden können(da in den meisten Fällen nicht der gesamte Level in den Arbeitsspeicher bzw. Videospeicher passt). Zusätzlich kann auch verhindert werden, dass Polygone zum rendern an die Grafikkarte geschickt werden, die nicht auf dem Bildschirm sichtbar sind und ohnehin durch die Rendering-Pipeline verworfen werden.
Zu deinen 5 Punkten die gegen eine Voxel-Engine sprechen:
1. Das Modelle auf Voxelbasis extrem viel Speicher benötigen ist vollkommen richtig. Auch mit immer größer werdenden Festplatten und Arbeitsspeicher wird das weiterhin ein Problem bleiben. John Carmack hat zwar für eine kommende id-Tech-Engine einen sehr effizienten Kompressions-Algorithmus in Aussicht gestellt(durchschnittlich 1,5 Bit pro Voxel), am Ende muss aber trotzdem immer der gerade für das Rendering benötigte Teil der Voxel als Oct-Tree vorliegen. Und eine Dekompression bedeutet immer zusätzlichen Rechenaufwand.
2. Voxel lassen sich nicht so leicht animieren wie Modelle auf Polygon-Basis. Auch dieser Punkt ist richtig. Die von dir genannte Translation(also eine einfacher Verschiebung im Raum) stellt aber kein großes Problem dar. Sie lässt sich durch einfache Offsets beim Suchen in der Datenstruktur verwirklichen, vorausgesetzt das verschiedene Modelle in unabhängigen Quad-Trees abgelegt sind. Eine Rotation hingegen ist weitaus komplexer und nicht so einfach zu realisieren wie bei polygon-basierten Modellen. Aber auch hier gibt es schon effiziente Ansätze mit gewissen Einschränkungen z.B. http://www.youtube.com/watch?v=Tl6PE_n6zTk.
In einem Spiel gibt es allerdings auch viel Geometrie die gar nicht animiert werden muss. Terrain, Häuser, Bäume und andere statische Objekte mit Voxeln darzustellen ist also durchaus ein handhabbares Problem.
3. und 4. Bei den vielen modernen Rendering-Engines erfolgt Beleuchtung, Shadow-Mapping und andere Effekte erst in einem Post-Processing-Schritt, also auf Bildebene. Für diese Techniken ist es absolut irrelevant aus welchen 3D-Modell die benötigten Eingabe-Informationen erstellt wurden. Sie können somit mit minimalen Anpassungen genauso auf Voxel-Modelle angewendet werden wie auf Polygon-Modelle. Ein Voxel-Renderer könnte z.B. ein Farbbild(oft als Albedo bezeichnet) und ein Tiefenbild aus einem Voxel-Model erzeugen. Aus dem Tiefenbild kann anschließend ein Normalen-Bild abgeleitet werden, indem man die Nachbarpixel um einen Pixel berücksichtigt und mit Hilfe der Bildschirmposition und Tiefe der Pixel eine Ebene im Raum errechnet. Zu dieser Ebene kann dann ziemlich leicht die entsprechende Normale ermittelt werden. Mit Hilfe der Informationen Farbe, Tiefe und Normale für jeden Pixel können ohne Probleme die bekannten Effekte wie Beleuchtung, Shadow Mapping, Screen Space Ambient Occlusion, Depth of Field usw. auf die Ausgangsbilder angewendet werden. Auch die Aufwand für die Berrechnung wäre gleich, da diese nur von der Auflösung des zu rendernden Bildes abhängig ist und nicht von der Komplexität der Eingabe-Geometrie.
5. Schon heute können komplexe Voxel-Modelle mit gewissen Einschränkungen in Echtzeit dargestellt werden, wenn GPGPU-Feature(Cuda, OpenCL oder DirectCompute) der Grafikkarte genutzt werden. Von einem vollständig voxel-basierten Spiel(mit ansprechender Grafik) ist das natürlich noch weit entfernt, aber eine Mischung aus Voxel- und Polygon-Modellen ist vorstellbar bzw. in einigen Spielen schon umgesetzt. Falls die Hardware-Hersteller in Zukunft Hardware auf die Darstellung von Voxel-Modellen optimieren(nativer Hardware-Support für effiziente Zugriffe in Oct-Tree-Datenstrukturen, entsprechendes Streaming usw.), könnte das die Verbreitung von Voxel-Rendering deutlich beschleunigen.
Um mal ein bekanntes Beispiel zu nennen: die Cry-Engine 3 verwendet für bestimmte Teile des Terrains Voxel anstatt von Polygonen. Dadurch lassen sich viel besser Höhlen und andere feingliedrige Strukturen darstellen als es mit Polygonen möglich wäre.
Ich hoffe du verstehst die konstruktive Kritik nicht falsch. Wollte dich auf keinen Fall angreifen. Wie gesagt eine sehr schöne Zusammenfassung, die aber leider auch ein paar fachliche Fehler enthält.
Grüße
Marcel
Vielen Dank für den verständlich geschriebenen Überblick!