Konservatives Frustum- und Occlusion-Culling aufbauen

Sichtbare Beiträge erhalten

Visibility Culling verwirft Arbeit, bevor aufwendig gezeichnet wird. Frustum-Tests sortieren Objekte aus, die ausserhalb des Kameravolumens liegen; Occlusion-Tests sortieren Objekte aus, die hinter anderer Geometrie verdeckt sind. Hüllkörper (Bounding Volumes) dienen dabei als günstigere Stellvertreter für diese Entscheidungen. [1] Ein sicheres Aussortieren darf keinen Beitrag entfernen, der für die jeweilige Ansicht benötigt wird.

Die Ansicht ist explizit zu wählen. Ein Objekt ausserhalb der Hauptkamera kann für eine Shadow Map oder eine Spiegelung dennoch relevant sein; eine einzige Sichtbarkeitsliste genügt daher nicht automatisch für jeden Pass.

Verzögerte Ergebnisse verstehen

Jedes Objekt zu testen und sofort auf jedes Ergebnis zu warten, kann teurer sein als das Zeichnen selbst. Hierarchische Gruppierung und das Verzahnen von sinnvoller Renderarbeit mit den Queries entschärfen dieses Scheduling-Problem. Der ursprüngliche Ansatz mit kohärenter Hierarchie nutzt die Sichtbarkeit aus dem vorherigen Frame, um die aktuelle Arbeit einzuplanen. [2]

Verfügbarkeit eines Ergebnisses ist etwas anderes als ein Ergebnis von null sichtbaren Samples. Vulkan stellt die Verfügbarkeit von Queries bereit und weist darauf hin, dass wiederverwendete Query-Slots noch Ergebnisse aus einer früheren Verwendung enthalten können, solange das Zurücksetzen nicht ausgeführt wurde. [3] Jedes Ergebnis ist deshalb dem vorgesehenen Frame oder der vorgesehenen Generation zuzuordnen.

Ein anschauliches Rechenbeispiel

Angenommen, eine Szene enthält 10'000 Kandidatenobjekte. Eine Frustum-Stufe verwirft 7'000, es bleiben 3'000. Aktuelle Occlusion-Ergebnisse verwerfen weitere 1'800, sodass 1'200 Kandidaten zum Zeichnen übrig bleiben. Die reduzierte Anzahl allein sagt nichts über die Einsparung bei der Frame-Zeit aus: Das Testen winziger, billiger Objekte kann mehr kosten, als die vermiedene Zeichenarbeit einspart.

Nun sei das Innere eines verdeckten Gebäudes unter einem einzigen konservativen Hüllkörper zusammengefasst. Ist dieses Elternobjekt vollständig verdeckt, lassen sich viele untergeordnete Objekte gemeinsam überspringen. Schneidet es einen sichtbaren Türdurchgang, ist in die Hierarchie abzusteigen oder konservativ zu zeichnen. Dieser gruppierte Fall ist mit dem Test pro Objekt bei identischem Kamerapfad zu vergleichen.

Hüllkörper und Ergebnisverarbeitung prüfen

Hüllkörper sind über animierten, geskinnten und prozedural verschobenen Meshes zu visualisieren. Dabei ist die maximale Bewegung auszureizen, statt nur die Ruhepose zu prüfen. Es ist sicherzustellen, dass ein Occlusion-Proxy-Test seine Box nicht versehentlich in den Tiefenpuffer der Szene schreibt. [1]

Getestet werden sollten Kamera-Teleports, sich öffnende Türen, schnell bewegte Occluder und neu erzeugte Objekte. Unbekannte oder ungültig gewordene Ergebnisse gelten als sichtbar, bis ein gültiges Aussortieren möglich ist. Sinnvoll ist es, aussortierte Gruppen, Kandidatenzahlen, das Alter der Queries, die CPU-Scheduling-Zeit und die GPU-Testkosten zu protokollieren. Der Vergleich mit einer Referenz ohne Culling hilft, fehlende Objekte zu finden.

Entscheiden, wann sich das Testen lohnt

Grosse verdeckte Gruppen sind vielversprechend; offene Luftansichten bieten möglicherweise kaum nutzbare Verdeckung. [2] Es sollte eine Möglichkeit bestehen, die aufwendige Stufe für Workloads, bei denen sie nur Mehraufwand verursacht, abzuschalten oder zu reduzieren.

Mit konservativen Hüllkörpern wird unter Umständen unsichtbare Geometrie zum Zeichnen übergeben, zu klein bemessene Hüllkörper können dagegen sichtbare Inhalte verschwinden lassen. Hüllkörper werden erst optimiert, nachdem die Korrektheit gesichert ist. Die Gruppierungsstrategie ist zu überprüfen, wenn sich das Level-Layout oder die Verformung ändert; bewertet wird die gesamte Frame-Zeit und nicht eine hohe Aussortierquote.

Quellen

• [1] Efficient Occlusion Culling — Dean Sekulic, Croteam; NVIDIA GPU Gems.
• [2] Hardware Occlusion Queries Made Useful — Michael Wimmer und Jiří Bittner; NVIDIA GPU Gems 2.
• [3] vkGetQueryPoolResults — Khronos Group.