JLI Spieleprogrammierung

[Fallen]

Hallo Freunde der hohen Künste,

ich bastel derzeit an einem DX10 basierten Demoframework, oder anders gesagt ich bastel mir eine 3D Engine zusammen (erspart euch die: "mach Spiele keine Engines" floskel ).

Nun stellt sich eine kleine aber feine Designentscheidung und zwar geht es um die allseits beliebte Statesortierung.

Vor einiger Zeit habe ich mal den Ansatz verfolgt jede grobe Stateänderung am DirectX Device zu Kapseln in ein sogenanntes DeviceCommand. So ein DeviceCommand sah so aus das es ein Hash hatte zum eindeutigen identifizieren, eine Typbeschreibung und einige andere Werte, zB die Textur die gesetzt werden soll bei einem SetTextureDeviceCommand.

Das System was ich dazu entworfen hatte sah vor das meine Resourcen, wie zB ein Material oder ein MeshBuffer eine Reihe von DeviceCommands generieren und in einem DeviceCommandBuffer speichern. So sah zB der Buffer eines Materials aus welches ein Shader setzt sowie 2 Texturen (die Texturen unterscheiden sich hier zB durch den Hash im DeviceCommand):

MaterialDeviceCommandBuffer:

[PeaceKiller]

Erstmal muss ich sagen, dass ich es toll finde, dass jemand hier ausm Forum mal wieder was bastelt. Ich habe selber seit langem auch wieder was vor, seit ich Direct 2D gesehen habe. Vielleicht hast du irgendwann Zugriff auf DX11 Karten. Catmull-Clark in Hardware ist schon sehr verlockend und kommt denke ich auch in Demos gut.

Zum Thema:
Ich dachte, dass Engines, die jedes Polygon einzeln sortieren seit Q3A aus der Mode sind. Allerdings sind unnötige State-Changes es schon wert sie in Angriff zu nehmen. Außerdem gibt es heutzutage ja fast nur noch Dualcores, es wäre zu schade, wenn die ganze Rechenpower brachliegt. Vielleicht kann man das ganze ja auch geschickt cachen.
Leider kann ich sonst keinen qualifizierteren Kommentar abgeben.

Und bist du wirklich im klaren darüber, was für ein Aufwand eine eigene Engine ist?
_________________
»If the automobile had followed the same development cycle as the computer, a Rolls-Royce would today cost $100, get a million miles per gallon, and explode once a year, killing everyone inside.«
– Robert X. Cringely, InfoWorld magazine

[Dr. Best]

Ich hab ja auch eine eigene Engine. Das was man momentan auf Ultimate3D.org sieht ist schon lange nicht mehr aktuell, wird aber von vielen genutzt. Inzwischen arbeite ich mit Direct3D 9.0 und mache die Engine vorerst für die eigene Verwendung.

Zum Thema: Ich finde das ganze recht schwierig. Es gibt ja nicht nur ein Kriterium nach dem man sortieren kann:
- Man kann nach den Shadern und den damit verbundenen Einstellungen sortieren um das Wechseln von Shadern, Konstanten und States zu minimieren.
- Man kann nach den Vertex- und Indexbuffern sortieren.
- Man kann nach den Texturen sortieren.
- Man kann Front to Back sortieren um das Rendern unsichtbarer Fragmente zu minimieren.
Alles hat seine Daseinsberechtigung, aber man kann es nicht alles gemeinsam haben. Ich habe mal ein nVidia-Paper gelesen in dem Texturatlanten empfohlen wurden um wenigstens das Texturen wechseln loszuwerden. Bloß leider bleiben da dann trotzdem noch drei Kriterien. In meiner Engine setze ich momentan auf Front to Back (wobei ich allerdings Octree-Zweige und nicht einzelne Objekte sortiere). Desto voller die Pixel Shader werden, desto mehr lohnt sich das. Es ist immer wieder erfreulich in PIX zu lesen "This pixel was eliminated because: It failed the depth test." .

Ich habe keine konkreten Benchmarks gemacht. Man hört immer überall wie schlimm viele Batches den CPU und den BUS belasten und sie zu minimieren ist sicherlich sinnvoll, aber was man dafür in Kauf nehmen sollte bleibt fragwürdig. Was ich im Moment mache ist im Wesentlichen dein zweiter Ansatz. Der wesentliche Vorteil davon ist offensichtlich, dass man die Objekte in beliebiger Reihenfolge rendern kann und dadurch Back-to-Front-Sortierung möglich wird. Dein erster Ansatz reduziert die Anzahl der Batches bestimmt sehr wesentlich da es die optimale Mischung der oben genannten ersten drei Wege darstellt und ich kann mir vorstellen, dass es algorithmisch ziemlich interessant ist, aber wenn die Grafikkarte dann für jeden Pixel zehn Fragmente rendern darf hast du das ganze bis zum CPU Leerlauf optimiert.

Wenn du viele komplexe Pixel-Shader verwendest ist es denke ich sinnvoller den zweiten Ansatz zu wählen. Zusätzlich ist es natürlich unerlässlich ein gutes System für Instancing zu haben um damit die Batches zu reduzieren. Wenn du es genau wissen willst gibt es eigentlich nur einen Weg. Implementier beides, baue eine Testszene die den späteren Anforderungen entspricht und mache ein gründliches Benchmark.
_________________

Ich bin da, wer noch?

[PeaceKiller]

[Fallen]

Ah es sind ja doch noch ein par Aktiv

Den Ansatz oben habe ich schonmal implementiert, der Algo zum sortieren und optimieren ist wirklich sehr interessant und aktuell einer der Codefragmente auf die ich verdammt Stolz bin (sowas hatte ich bisher noch nie). Je Polygon wird auch hierbei nicht sortiert sondern nur nach den einzelnen Statechanges/Drawcalls, per PolySortierung, nein Danke das muss nicht sein

Ich bastel mir übrigens die Engine da es auf Scenepartys sehr doof aussieht wenn man etwas mit einer fertigen Engine bastelt, ein grosser Part ist da ja das technische KnowHow

Beides zu implementieren wird eine Fleißarbeit und ich bin nicht fleißig daher lasse ich das lieber

Vermutlich werde ich aber einfach mal Variante1 benutzen, auch wenn es vom Design her etwas umgewandelt wird, so das ich nicht pro DeviceCommand eine Klasse habe sondern weniger Informationen und dafür bestehende Strukturen ausnutze (zB DrawPrimitive direkt in der MeshBuffer Klasse.).

Dazu habe ich mir nur mal kurz nebenbei überlegt das ich ein Interface habe von dem alle CommandoNutzenden Klassen ableiten können:

[Fallen]

Ich habe die Sache nun bei mir mal implementiert läuft aktuell sogar sehr sauber, wie es mit komplexen Szenen abseits eines Würfels aussieht muss sich noch zeigen.

Aktuell sieht zB fürs darstellen eines Würfels der Code so aus:

(erstellen der Resourcen habe ich mal weg gelassen)