Computer-Graphik 2 SS 10 Real-time rendering

Transkript

1 lausthal omputer-raphik 2 Real-time Rendering by Advanced Visibility omputations lausthal University, ermany zach@in.tu-clausthal.de Klassifikation (Erinnerung) Problemklassen innerhalb des Bereichs "Visibility omputations": 1. Hidden Surface Elimination (Verdeckungsberechnung): welche Pixel (Teile von Polygonen) werden von anderen verdeckt? 2. ulling: welche Polygone können gar nicht sichtbar sein? (z.b., weil sie sich hinter dem Viewpoint befinden) Achtung: die renzen sind fließend Tendentieller Unterschied: bei HSE geht es eher darum, überhaupt ein korrektes Bild zu rendern, bei ulling geht es eher um eine Beschleunigung des Renderings großer Szenen omputer-raphik 2 SS

2 ulling Sei A = Menge A aller Primitive; sei S = Menge der sichtbaren Primitive. Alle bisher betrachteten Algorithmen arbeiten auf der gesamten Menge A, d.h., sie haben einen Aufwand mindestens in O( A ). Unproblematisch, wenn S A ist. Z.B., wenn Anzahl der Primitive im Vergleich zur Pixelanzahl klein ist. Erinnerung: Depth omplexity "to cull from" = "sammeln [aus ] / auslesen" "to cull ﬂowers" = Blumen pﬂücken omputer-raphik 2 SS 10 3 Aber: für komplexe Szenen ist die Anzahl der sichtbaren Primitive in der Regel wesentlich kleiner als die Anzahl der Primitive insgesamt ( S << A )! ulling ist eine wichtige Optimierung (im egensatz zu lipping) omputer-raphik 2 SS

3 Für S << A genügen die bisherigen Algorithmen nicht ulling-algorithmen versuchen, die Menge der nicht-sichtbaren Primitive = A \ S (oder Teilmenge davon), oder die Menge der sichtbaren Primitive S (oder Obermenge davon) zu bestimmen. Deﬁnition: Potentially Visible Set (PVS) = Obermenge S S Ziel: möglichst kleines PVS S' mit möglichst geringem Aufwand Triviales PVS (mit trivialstem Aufwand) ist natürlich A omputer-raphik 2 SS 10 5 ulling-arten view frustum detail backface porta omputer-raphik 2 SS 10 l occlusion 6 3

4 Back-Face ulling Deﬁnition: Solid = geschlossenes, opakes Objekt; also undurchsichtiges Objekt mit nicht-degeneriertem Volumen Beobachtungen: Bei Solids sind die Rückseiten (back-faces) nie sichtbar Bei konvexen Objekten gibt es genau 1 zusammenhängende Rückseite Bei nicht-konvexen Solids eventuell mehrere omputer-raphik 2 SS 10 7 Backface ulling = Nicht-Zeichnen der dem Viewpoint abgewandten Flächenstücke Klappt nur bei Solids! n Berechne Normale n des Polygons Berechne Vektoren v vom Viewpoint zu allen Punkten p des Polygons Orthogonale Projektion: v = [0 0 1]T y Perspektivische Projektion: v = p eye Abgewandt (nicht zeichnen) wenn Winkel zwischen n und v < 90 n.v > 0 x z omputer-raphik 2 SS

5 Beispiel N1 V = (2, 1, 2) ( 1, 0, 1) = 4 < 0 N1 front facing N2 V = ( 3, 1, 2) ( 1, 0, 1) =5>0 N2 back facing N2 = ( 3, 1, 2) N1 = (2, 1, 2) V = ( 1, 0, 1) omputer-raphik 2 SS 10 9 Backface ulling in OpenL Muß man nur einschalten: glullface( L_BAK ); glenable( L_ULL_FAE ); omputer-raphik 2 SS

6 Demo omputer-raphik 2 SS Wann lohnt sich Backface ulling? Erinnerung: raphik-pipeline Applikation 3D eometry Stage Rasterizer (2D) Eine Pipeline hat immer den Durchsatz wie das langsamste lied! Mögliche Bottlenecks in der raphik-pipeline: Im Rasterizer "ﬁll limited" In der eometry-stage "transform limited" Auf dem Bus zwischen App. und raphik-hardware "bus limited" Falls die raphikkarte schneller ist als die Applikation eometrie liefern kann "PU limited" (erkennt man an 100% PU-Auslastung) omputer-raphik 2 SS

7 Normal Masks [Zhang & Hoff, 1997] Zentrale Idee: Skalarprodukt ersetzen durch Klassiﬁzierung aller Normalen Bilde zunächst Klassen über der Menge aller Normalen Umschließe Normalenkugel (auß'sche Kugel) mit Würfel ("Richtungswürfel" oder "direction cube") d u u v v Ergibt 6.N2 viele Klassen (N = Anzahl itterunterteilungen) Klassiﬁzierung einer Normalen ist sehr einfach omputer-raphik 2 SS Kodierung einer Normalen (Preprocessing): Der gesamte Normalenwürfel Eine Normale = ˆ Bitstring der Länge 6.N2 = ˆ nur eine 1, sonst 0-en Kodierung als Offset + Teil des Bitstrings, der die 1 enthält Z.B.: unterteile Bitstring in Bytes, Offset = 1 Byte, ergibt 256x8 = 2048 Bits typedef struct PolygonNormalMask { Byte offset, bitmask; }; Offset (in Bytes) Mask Speichere diese 2 Bytes zu jedem Polygon Z.B.: wähle N = 16 Ergibt Unterteile die Normalenkugel in = 1536 Klassen omputer-raphik 2 SS

8 ulling (Initialisierung): Identiﬁziere alle diejenigen Normalenklassen, deren Normalen alle backfacing sind Orthographﬁsche Projektion: Perspektivische Projektion: welche Normalen backfacing sind hängt von Normalenrichtung und Position des Polygons ab! frontfacing backfacing Deswegen: berechne "konservative" Menge von Klassen, die unabhängig vom Ort des Polygons backfacing sind: omputer-raphik 2 SS backfacing α konservative Abschätzung α/2 α/2 α/2 α/2 backfacing In der Praxis: Teste jede Klasse in allen vier Ecken des View-Frustums Test einer Klasse = Test der 4 Normalen, die in die Ecken des Quadrats zeigen omputer-raphik 2 SS

9 Stelle diese Menge als Bitstring (z.b Bits = 256 Bytes) in einem Byte-Array dar: Byte BackMask[256]; ulling (zur Laufzeit): teste für jedes Polygon BackMask[byteOffset] & bitmask Beschleunigung: rendere die Szene "sektorenweise" damit ist der Winkel α/2 in jedem Sektor kleiner; für jeden Sektor eine eigene BackMask []. Resultat: die Autoren berichten Faktor 1.5 Speedup gegenüber OpenL-Backface-ulling omputer-raphik 2 SS Beispiel 216 Klassen ("cluster") 1536 Klassen ("cluster") BackMask für den aktuellen Viewpoint (grün = backfacing) omputer-raphik 2 SS

10 Speedup omputer-raphik 2 SS 10 lustered Backface ulling 19 [1998] Erinnerung: einfache Rechenregeln zu min/max: max(x + y ) max(x ) + max(y ) max(x y ) max(x ) min(y ) k max(x, y ), k 0 max(kx, ky ) = k min(x, y ), k < 0 Im folgenden seien ni und pi die Normale bzw. ein Vertex eines Polygons aus einem luster (einer Menge) von Polygonen. Sei e der Viewpoint. Achtung: wir verwenden im folgenden die "umgekehrte" Deﬁnition für Backfacing! n (e p) 0 omputer-raphik 2 SS

11 Annahme: luster (= Menge) von Polygonen ist gegeben Alle Polygone sind backfacing gdw. i : ni e pi 0 max ni e pi 0 (1) Obere Schranke für (1) ist max ni e pi max eni min ni pi (2) Setze d := min{ ni.pi } (precomputation) Schreibe (2) als max ni e pi max ex nxi + ey nyi + ez nzi d max ex nxi + max ey nyi + max ez nzi d omputer-raphik 2 SS 10 (3) 21 Annahme: e liegt im pos. Oktanten, d.h., ex, ey, ez 0; dann können wir eine obere Schranke von (3) angeben: max ni e pi ex max{nxi } + ey max{nyi } + ez max{nzi } d m e d, max{nxi } mit m = max{nyi } max{nzi } Analog gilt für ex, ey, ez 0: max ni e pi n e d, omputer-raphik 2 SS 10 min{nxi } mit n = min{nyi } min{nzi } 22 11

12 Für alle anderen Oktanten hat man die entsprechenden Kombinationen aus min & max Schreibweise: definiere eine Art If -Operator auf Vektoren uα if (e; u, v) := vα, eα 0, eα > 0 mit α {x, y, z } Damit kann man den (konservativen) Test dann so schreiben: if (e; n, m) e d 0 cluster is backfacing (4) Precomputation: pro luster n, m und d bestimmen Speicherbedarf pro luster: 28 Bytes (2 Vektoren + 1 Skalar) omputer-raphik 2 SS eometrische Interpretation Ungleichung (4) definiert 8 Ebenen (pro Oktant eine) Je 4 Ebenen (in angrenzenden Oktanten) schneiden sich in einem Punkt auf der dazwischenliegenden Koord.achse Beispiel: betrachte die 4 Ebenen in den Oktanten mit ex 0 Alle 4 Ebenen haben Normale der Form n = (mx,, ) sie schneiden alle die X-Achse im Punkt ( md, 0, 0). x Diese 8 Ebenen bilden ein geschossenes Volumen, das sog. "ulling-volumen" Falls der Viewpoint sich hier drin befindet, ist der luster komplett backfacing omputer-raphik 2 SS

13 Weitere Optimierung: lokale Test-Koordinaten Problem: wenn die Polygone weit vom Ursprung entfernt liegen, und der Ursprung auf der positiven Seite der Normalen liegt, dann wird d sehr weit negativ der Test fällt nie positiv aus Abhilfe: führe den Test in einem lokalen Koordinatensystem durch Verschiebe den lokalen Ursprung c so, daß d = min ni pi c möglichst weit positiv wird. esucht ist das optimale c. Frage: wird Rotation noch etwas bringen? In praxi: probiere Mittelpunkt und Ecken der BBox der Polygone als c. Speichere c zusätzlich zum luster; teste dann if (e c; N, M) (e c) d 0 omputer-raphik 2 SS Hierarchical lustered Backface ulling Zwei luster kann man zusammenfassen zu einem gemeinsamen: min nx1, nx2 n = min ny1, ny2 min nz1, nz2 d = min (d1, d2 ) max mx1, mx2 m = max my1, my2 max mz1, mz2 Diese beiden Vektoren und Ď liefern eine konservative Abschätzung D.h.: falls der gemeinsame luster unsichtbar ist, dann auch garantiert die beiden ursprünglichen luster-hierarchie Falls eine Hierarchie von lustern aufgebaut wird, deﬁniere analog folgenden Frontface-Test: Höre auf zu testen, falls kompletter luster front- oder backfacing Sonst: teste die Kinder auf komplett front- oder back-facing omputer-raphik 2 SS

14 Erzeugung der luster Zur Bewertung von luster-kandidaten in einem Algo benötigen wir ein Maß für die "üte" eines lusters Hier: Wahrscheinlichkeit, daß luster gecullt wird Heuristik: Volumen aller mo glicher Viewpoint-Standort V ol (U ) = Volumen des ulling-volumens Vol ( ) Vol() kann man exakt bestimmen Wähle als U die BBox der gesamten Szene U Falls lokale ulling-koordinaten verwendet werden: wähle als U = c. BBox(luster) ( Nahfeld-ulling-Wahrscheinlichkeit ) omputer-raphik 2 SS Frage: gegeben zwei luster A,B; ist es schneller A und B getrennt zu testen und zu rendern, oder als ein luster := A B? Sei T(A) die erwartete(!) Zeit, um den luster A zu testen und ggf. zu rendern. Dann ist T (A) = t + (1 P (A)) R (A) wobei P(A) = Wahrscheinlichkeit, daß luster A gecullt wird, und R(A) = Zeit zum Rendern von A (ohne weitere Tests), und t = Zeit zum Backface-Test eines lusters omputer-raphik 2 SS

15 A und B zusammenfassen lohnt sich gdw. T ( ) < T (A) + T (B ) t + (1 P ( )) R ( ) < 2t + (1 P (A)) R (A) + (1 P (B )) R (B ) (1 P ( )) (R (A) + R (B )) < t +... P ( ) > P ( ) > t + P (A)R (A) + P (B )R (B ) R (A) + R (B ) t r + P (A)nA + P (B )nb na + nb Ann.: R(A) = na.r, r=konstanter Aufwand für 1 Polygon Verhältnis t/r ist maschinenabhängig; kann aber leicht vorab experimentell und automatisch bestimmt werden (Hängt ab von raphikkarte, Anzahl Lichtquellen, Texturen, ) omputer-raphik 2 SS