Optimierungsmöglichkeiten bei Tesselation

[=Floi=]

Wo gibt es überall sinnvolle möglichkeiten die tesselation zu optimieren und zu beschleunigen?


ich denke mal bei geraden flächen kann man schon erheblich viele dreiecke sparen und den maximalen unterteilungsfaktor könnte man doch auch nur auf randbereiche anwenden. wie sieht es mit einem winkelabhängigen faktor aus?
welche ideen/vorschläge habt ihr?

An sich ist doch die idee einfach alles zu tesselieren viel zu verschwenderisch und altmodisch. Das erinnert mich an kyro, welche damals intelligenter an das rendering gingen und so die übermächtige konkurrenz teilweise sogar abhängten.

zum schluß noch ein kurzes beispiel:
http://unigine.com/devlog/70/
am flügel bringt tesselation quasi nichts.

[Neomi]

Du verwechselst hier Tesselation mit Displacement Mapping. Auch in den Randbereichen (z.B. bei den deutlich hervorstehenden Stacheln an der Drachenstatue) würde Tesselation alleine nur die Geometriedichte enorm erhöhen, ohne einen optischen Unterschied zu bewirken. Der kommt erst durch den Domainshader, der die neu hinzukommenden Vertices zur weiteren Verarbeitung bekommt. Und der ist frei programmierbar, Displacement Mapping ist nur eine der Anwendungsmöglichkeiten. Ein Domainshader könnte auch ganz andere Dinge tun, beispielsweise Vertices in der Ebene des Dreiecks verschieben (auch ein Displacement, aber nicht das übliche) statt entlang der Normale. Deshalb kann es keine festen Regeln zur Optimierung geben, die bei Tesselation grundsätzlich angewendet werden können.

Dazu kommt noch, daß solche Optimierungen, wie du vorschlägst, auch bei Displacement Mapping als konkreter Anwendung nicht wirklich greifen. In Bewegung (wenn man sich z.B. um die Statue herum dreht) würde das bestimmt störend auffallen, ein Standbild ist da nicht aussagekräftig. Flimmernde Pixelshader erkennt man ja auch erst in Bewegung. Und dann ist da noch ein Grund, weshalb man sogar in Standbildern bei Displacementmapping auf Flächen, die zur Kamera zeigen, auf so eine Optimierung verzichten sollte: die Tiefe. Was, wenn z.B. Softpartikel oder andere Volumeneffekte direkt vor dem Objekt sind? Der Effekt basiert auf der Tiefe des Partikels relativ zur Tiefe der dahinterliegenden Geometrie, eine solche Optimierung würde das Gesamtbild schon sehr ändern. Oder wenn man senkrecht runter auf ein Kopfsteinplaster blickt, bei der eine Fläche mit Wasser gerade in der richtigen Höhe liegt, um die Rillen zwischen den Steinen zu füllen. Soll das etwa beim Blick nach unten einfach verschwinden? Ich glaube nicht. Oder das gute alte Shadowmapping. Wenn ein Geometriedetail genau in Richtung Kamera aus einem Objekt hervorsticht, ändert es seine sichtbare Position auf dem Bildschirm nur unwesentlich. Für den durch dieses Detail geworfenen Schatten (oder den, der auf das Detail selbst geworfen wird) kann das aber erhebliche Auswirkungen haben.

Fazit: wenn du eine tolle Idee hast, auf die all die schlauen Entwickler bei AMD und NVidia nicht gekommen sind, dann war die Idee wahrscheinlich doch nicht so toll. ;)

[Geldmann3]

Ich vermute tatsächlich, dass uns hier in den nächsten Jahren noch eine ganze Reihe von Optimierungen erwartet. Dass eben nur das Berechnet wird, was zur aktuellen Authentizität der Szene beiträgt. Wenn wir an Fotorealismus herankommen wollen ist dies wohl unbedingt nötig. Als Beispiel können wir die Simulation Erde nehmen in der wir "Leben".

Wenn wir Quanten beobachten wollen verhalten sie sich wie Teilchen, unbeobachtet jedoch wie Wellen. Das liegt daran, dass im Normalfall nicht genügend Rechenleistung vorhanden ist um alle "Partikel" einzeln in ihrer gesamten Komplexität zu Rendern. Man vereinfacht die Rechnung indem man ein grobes Wellenmodell anwendet, was die Bewegung vieler Teilchen simulieren soll. Beobachtet man jedoch ein einzelnes steigt das LOD aufs Maximum an, sodass das Beobachtete Teilchen nun korrekt mit vollen Details und absolut genauer Laufbahn errechnet wird. Bis wir mit unseren Videospielen so weit sind, wird es noch ein wenig dauern. So 100 Jahre.

[RLZ]

ich denke mal bei geraden flächen kann man schon erheblich viele dreiecke sparen und den maximalen unterteilungsfaktor könnte man doch auch nur auf randbereiche anwenden. wie sieht es mit einem winkelabhängigen faktor aus?

Die Tesselation ist vorallem mal von der Curvature abhängig. Alles andere kann nur ein zusätzlicher Faktor sein.


Ich nehme an du meinst sowas:
http://img213.imageshack.us/img213/2360/tessh.jpg

Wie man am Datum erkennt keine neue Idee. ;)
*Quelle* (http://developer.download.nvidia.com/presentations/2008/GDC/Inst_Tess_Compatible.pdf)

[=Floi=]

ja genau. so etwas meinte ich. zumindest in unigine ist so etwas nicht standard. Ist es nötig so etwas erst selbst zu programmieren? gerade bei sehr hohen unterteilungsfaktoren kann man doch eine beträchtliche menge an dreiecken einsparen.

[Nasenbaer]

Alles gar kein Problem. Im Hull-Shader (darin legt man den Tesselierungsfaktor fest) kann man dazu auch relativ umfangreiche Berechnungen durchführen.
Angefangen von der reinen Betrachtung der Dreiecksnormale (um halt die Silhouetten zu betonen), bis zu Fehlerberechnungen, damit das ausgegebene Bild maximal x% von der maximalen Qualität abweicht.

Hab dazu auch ne Studienarbeit (http://tiny.cc/9cuw6) geschrieben.

[=Floi=]

da bin ich ja genau an den richtigen gekommen. ;)
also könnte ATI oder NV auch eine optimierte biliothek rausbringen und so die ganze geschichte erheblich einfacher für die programmierer machen. Es erstaunt mich auch, wie durchdacht und brauchbar das ganze jetzt schon ist.

[Nasenbaer]

Glaube kaum, dass man da eine extra Bibliothek rausbringt. Klar liessen sich einige Arbeitsschritte verallgemeinern, da man aber auf der GPU arbeitet ist die Bereitstellung allgemeiner Interfaces allerdings etwas problematischer.
Würde auf Anhieb mal behaupten, dass die Probleme meist zu spezifisch sind als, dass man da ein paar Funktionen schreiben könnte, die dann den Großteil erledigen.

[RLZ]

also könnte ATI oder NV auch eine optimierte biliothek rausbringen und so die ganze geschichte erheblich einfacher für die programmierer machen. Es erstaunt mich auch, wie durchdacht und brauchbar das ganze jetzt schon ist.
Du erliegst der typischen Fehlannahme, dass der Programmieraufwand in der Engine der limitierende Kostenfaktor ist.

Das wahre Problem liegt jedoch in der fehlenden Toolchain. Kosten verursachen vorallem die Horde an Artists. Fehlen die Tools damit diese effizient den tesselierbaren Content erstellen können, kann man es nicht einsetzen. Momentan müsste dies zudem transparent sein, damit man nicht für Konsolen und PC unterschiedlichen Content bauen muss. Imo kaum möglich...
Brauchbare Tesselation in Spielen werden wir wohl mit der nächsten Konsolengeneration bekommen.

Vorher gibts nur dort Tesselation, wo die Artists nichts anfassen müssen: Terrain und prozedurale Geometrie