HSR: Hidden Surface Removal

14. November 2002 / von aths / Seite 5 von 5

   HSR in Software (Fortsetzung)

In der "freien Landschaft", also in Außenwelten, gibt es jedoch keine Türen. Eine HSR-Methode arbeitet hier mit Anti-Portalen. Diese ist weniger effizient als eine Indoor-Engine mit Portalen, doch das liegt nun einmal an der Levelgeometrie. Anti-Portale sind gedankliche Flächen, die um große Objekte gelegt werden. Dann wird geprüft, ob diese nicht andere Objekte verdecken.

Richtig effizient wäre es, wenn getestet würde, ob eine Kombination von Vordergrund-Objekten - z.B ein Haus und ein Hügel - gemeinsam ein im Hintergrund befindliches Objekt verdecken. Kombinationen abzutesten erweist sich aber als sehr schwierig. Einerseits gäbe es eine Vielzahl solcher Kombinationen, andererseits braucht das "Zusammenlegen" von Anti-Portalen zusätzliche Rechenzeit. Deshalb muss oft darauf verzichtet werden.

Die "Hülle" von Objekt A überdeckt Objekt C, welches daher nicht gerendert werden muss. A und B zusammen überdecken D,
doch weil auf kombinierte Deckung in der Regel nicht getestet wird, muss D gerendert werden.

Anti-Portale sind also weniger effizient als Portale, aber besser als nichts. Für Outdoor-Engines stellen sie aber eine Möglichkeit dar, wenigstens teilweises HSR zu realisieren.

Zukünftige Grafik wird mehr und mehr PixelShader einsetzen, also kleine Programme welche die Pixelfarbe bestimmen. Dank standardisierter PixelShader-Funktionalität kann moderne 3D-Hardware (ab DirectX8 Compliancy, in OpenGL dank Hersteller-Extensionen oft auch ältere Hardware) mehr und mehr Funktionalität eines "professionellen" Renderprogrammes (wie z.B. TrueSpace) übernehmen. Solche Berechnungen brauchen pro Pixel aber sehr viele Takte, also kommt es hier ganz besonders darauf an, verdeckte Pixel gar nicht erst rendern zu müssen.

Deshalb geht die Doom III Engine einen besonderen Weg: Zunächst wird der Z-Buffer gerendert und dann das Bild. Um den fertigen Z-Buffer zu erzeugen, ist ein kompletter Rendering-Pass notwendig, allerdings mit ausgeschalteten Texturen und Framebuffer-Zugriffen. Je nach Overdraw-Faktor ist damit zu rechnen, dass die Grafikkarte hierfür pro Pixel im Schnitt gut ein bis zwei Takte beschäftigt ist.

Das anschließende "richtige" Rendern eines Pixels kann aber je nach Grafikkarte gut und gerne 6 oder auch 14 Takte dauern. Weil der Z-Buffer aber schon fertig ist, kommen dank dem EarlyZ-Feature (ab GeForce3 und Radeon 8500) nur noch wirklich sichtbare Pixel in die Pipeline. Der Weg, mittels einem extra Z-only-Rendering-Pass komplettes vorgezogenes HSR zu "emulieren", lohnt sich. Hierfür dedizierte Hardware einzusetzen, bleibt natürlich effizienter.

   Fazit

Portale und Anti-Portale, Sortierung von Objekten - all das belastet die CPU. Die Geschwindigkeit des Hauptprozessors bleibt also (neben der ohnehin anfallenden Geometrie-Arbeit) ein sehr wichtiger Faktor, um 3D-Grafik zu beschleunigen. Mechanismen wie ein Early-Z-Test können den Overdraw zwar abmildern, aber für "vernünftiges" dem Rendern vorgezogenes HSR bleibt der CPU ein großer Arbeitsanteil überlassen.

Komplettes dem Rendern vorgezogenes HSR kann des Aufwands wegen ausschließlich von dedizierter Hardware vorgenommen werden, welche sinnvollerweise möglichst nahe an der eigentlichen Rendering-Logik sitzt, kurz gesagt in den Grafikchip integriert wurde. Man erhält dafür aber 50-100% mehr fps pro Megapixel Füllrate.