spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Würde mich auch interessieren. Und Google hat mir nicht sehr geholfen, Shader spielen dabei wohl eine große Rolle.

Wahrscheinlich wird diese Geometrie direkt auf der GPU generiert (mittels Geometry Shader) und muss daher nirgendwo (permanent) gespeichert werden. Sowas nutzt man z. B. für gekurvte oder strukturierte Oberflächen, die je nach Entfernung zum Betrachter unterschiedlich fein in Dreiecke aufgelöst werden.

Sie haben einen auf winzige Dreiecke spezialisierten Rasterizer in ComputeShader implementiert. Was ich sehr sexy finde, weil ich seit ner Weile ähnliche Experimente versucht habe. Sie schreiben allerdings irgendwo, dass sie in einigen Fällen den klassischen Hardware Rasterizer nicht schlagen konnten und daher rumschalten, wie sie's brauchen.

Die eine Milliarde Dreiecke war Marketing. Im Video selbst erklärt der Sprecher ja, dass sie ne Statue mit 30 Mio Polys 600fach instanziiert haben. Das plus gutes Streaming und die moderne Texturkompression (BXT oder wie hieß sie?) und das passt alles in 16GB.

Das ist aber grundsätzlich der Ansatz hinter Nanite. Auszurechnen, "wieviel % vom Pixel konsumiert werden", nennt man "analytisches Antialiasing". Und wenn man auf der Meshauflösung arbeitet, kann man wirklich alles weglassen. Ein Dreieck wäre dann grundsätzlich nur noch ein Datensatz "Position, Normale, PBR-Zeugs", und wahrscheinlich kann man das auf ner Textur speichern und mit cleverer Positionierung bequem MipMapping benutzen. Da flog heute auf Twitter ein Paper an mir vorbei, wo jemand Geometriedaten so auf Texturen gelegt hat, dass er die Texturen dann komprimieren konnte und MipMapping verwenden konnte, und der Mesh blieb grob erhalten.

Ich weiß nicht, wie weit dieser Ansatz trägt: das Mesh-Lodding über Textur-Mipmaps geht ja nur solange, wie jeweils vier Dreiecke genau ein detailreduziertes Dreieck ergeben. Und das ist bei normalen Meshes selten der Fall. Bei Micro Triangles kann man aber vielleicht über weite Strecken davon ausgehen... wer weiß.

Meine Versuche zum analytischen Antialiasing:
https://twitter.com/DerSchrompf/status/1029267091118088197
https://zfx.info/viewtopic.php?p=61478#p61478

Mal ne Frage zu dem analytischen Anti Aliasing ... Allein mit der Berechnung, wieviel % eines Pixels vom Dreieck überdeckt wird, ist es doch noch nicht getan, oder? Man müsste doch auch die Verdeckung zwischen den Dreiecken untereinander berücksichtigen. Also die Frage müsste lauten: Welcher Flächenanteil eines Pixels wird vom Dreieck überdeckt, der von keinem weiter vorne liegenden Dreieck überdeckt wird? Kann man das überhaupt sinnvoll lösen ohne wieder diskret zu samplen (durch einen extrem hoch auflösenden Z-Buffer)?

Das ist ne gute Frage. Bei meinem Punktwolken-Renderer hab ich die Frage ignoriert und von vorn nach hinten gerendert. Bei Dreiecken ist das komplizierter.

Es betrifft erstmal nur das Blending mit dem bisherigen Farbwert des Pixels. Für ne einfache Oberfläche kann man die Coverage durch jedes Dreieck einfach aufaddieren. Wenn man richtig gerechnet hat, müsste 1 rauskommen, oder halt <1 für Silhouetten-Außenkanten. Schwierig wird es, sobald Überdeckung mit anderen Oberflächen kommt, also immer. Ich habe hier mal einen Ansatz von Tim Sweeney gehört, der nen kleinen BSP-Tree pro Pixel aufbaut, um zu tracken, wie sich ein Dreieck in das bestehende Konglomerat einfügt. Weiß nicht, ob man das performant hinbekommt. Ich würde stattdessen eine Heuristik anhand der Tiefe probieren. Bildschirm in Tiles einteilen, pro Tile alle Dreiecke raussuchen und von vorn nach hinten sortieren. Jetzt könnte man pro Pixel beim vordersten Dreieck beginnen und alle nachfolgenden Dreiecke als "connected" annehmen und additiv blenden, wenn sie nicht mehr als eine Mikrodreiecksgröße weiter entfernt liegen. Alles weiter entfernt wird "drunter geblendet", also anhand der bestehenden Coverage anteilig geschwächt. Außerdem würde ich bei jedem Dreieck eine neue Richttiefe speichern, damit auch für die zweite/dritte/vierte Schicht die "Connected"-Heuristik eine Chance hat, sinnvoll zu arbeiten.

Irgendwann will ich das mal ausprobieren.

Außerdem: irgendwie bezweifle ich, dass die da tatsächlich noch einen echten Mesh im Sinne von Dreiecken aus drei Eck-Vertizes berechnen. Das wäre bei der Polydichte doch eine absurde Verschwendung. Ich glaube auch, irgendwo aufgeschnappt zu haben, dass das ne implizite Oberfläche ist. In dem Fall kann man wahrscheinlich die exakte Form jedes Dreiecks ignorieren und die Gewichtung irgendwie aus der Oberfläche ableiten. Anders kann ich mir auch nicht vorstellen, wie sie das implizite "LOD ohne Preprocessing" hinkriegen wollen, von dem sie im Video gesprochen haben. Und ich überlege gerade, wieviel man tatsächlich daneben liegen würde, wenn man statt Dreiecken einfach irgendwie geformte Punktwolken auf den Zentren der Dreiecke malt. Das Rechteck bietet sich als Form an, weil das Flächenintegral trivial ist. Kreis war hässlich, hab ich nicht ninbekommen, aber vielleicht schafft es jemand mit nem Mathehirn. Bei echten Dreiecken hast Du doch x Fallunterscheidungen und Grenzfälle, und musst unnötig viel Informationen mitführen, die doch eh keiner sieht.