Artikelempfehlungen, interessante Publikationen o.Ä.

[Chromanoid]

Hehe das hab ich vor nicht allzu langer Zeit durchgemacht ^^

[Artificial Mind]

Font rendering per Signed Distance Fonts:
http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf

Ich werd dann mal einen OGL 3.3 Font Renderer mit der Technik schreiben

[CodingCat]

Zurück zum Forward Rendering?

[eXile]

Zurück zum Forward Rendering?

Hatte ich mir auch heute morgen reingezogen, und bei Schritt 4.2 fielen mir die Kroketten aus dem Mund. Außerdem ist nach meiner Definition ein Z-Pre-Pass bereits ein kleiner Deferred-Shading-Renderer.

[CodingCat]

Hatte ich mir auch heute morgen reingezogen, bei Schritt 4.2 fielen mir die Kroketten aus dem Mund.

Die Listen sollten eine ziemlich gute lokale Cache-Kohärenz aufweisen, die Schleifenrümpfe haben offensichtlich eine gute lokale Ausführungskohärenz. Auf moderner Hardware könnte das durchaus akzeptable Performance liefern?

Außerdem ist nach meiner Definition ein Z-Pre-Pass bereits ein kleiner Deferred-Shading-Renderer.

Letztlich sind die Grenzen doch immer fließend. Interessant an diesem Hybrid wären insbesondere schnelles und genaues MSAA, temporales Aliasing und nicht rekonstruierbare Sub-Pixel Features wären damit vermutlich wieder wesentlich unproblematischer. Das dezentrale Materialsytem hat wohl zwei Seiten. Einerseits ist es schön, wieder jedem Objekt einfach so beliebige Shaders mit beliebigen BRDFs zuweisen zu können; andererseits geht man wieder eine Kopplung von Geometrieverarbeitung und Beleuchtungsberechnung ein, welche mit Deferred Shading gerade so schön überwunden schien. Abgesehen von transparenten Objekten, diese wären mit dem beschriebenen Forward Rendering wieder wesentlich homogener in den Renderablauf integriert.

[eXile]

Die Listen sollten eine ziemlich gute lokale Cache-Kohärenz aufweisen, die Schleifenrümpfe haben offensichtlich eine gute lokale Ausführungskohärenz. Auf moderner Hardware könnte das durchaus akzeptable Performance liefern?

Dass das effizient wird, hatte ich mir schon gedacht. Mir ging es eigentlich eher um die einfache Formel „Tile-based-Deferred-Renderer minus G-Buffers = Tile-based-Forward-Renderer“. Die Effizient kommt eher aus dem „tile-based“ und nicht aus dem forward oder deferred Renderer. So wie es sich für mich darstellt, sind das einfach orthogonale Komponenten, die man im beliebigen Kreuzprodukt (tile-based, normal) × (forward Renderer, deferred Renderer) kombinieren kann.

(Es gab ja schon deferred Renderer vor tile-based Verfahren, daher ist es durchaus plausibel, dass ein deferred Renderer nun einmal im Vergleich zu einem forward Renderer etwas bringt.) Ich mache hier sozusagen gerade eine Komplexitätsreduktion meiner Argumentation.

Die Entscheidung tile-based forward Renderer vs. tile-based deferred Renderer ist also die gleiche, wie die Entscheidung, ob man einen forward oder deferred Renderer nehmen soll. Die Diskussion darüber wird seit über fünf Jahren geführt und ist ausgelutscht. (Effiziente Verdeckungsrechnung und komplexes AA und OIT vs. nicht ganz so effiziente Verdeckungsrechnung und straight-forward AA und Transparenz.) Auch das Argument mit den beliebig komplexen Materialien ist ausgelutscht, da muss man sich einfach nur genug fette G-Buffer nehmen, was ich in Zeiten von Graphikkarten mit bald 4 GiB VRAM nicht mehr so kritisch wie früher sehe.

Man muss halt nur das „wir stopfen alle Parameter in eine Textur/Buffer“ und das „wir frickeln uns alle Parameter wieder aus der Textur/Buffer zurück“ automatisieren und mit einer Material-ID verknüpfen, und fertig isses.

[dot]

Auch das Argument mit den beliebig komplexen Materialien ist ausgelutscht, da muss man sich einfach nur genug fette G-Buffer nehmen, was ich in Zeiten von Graphikkarten mit bald 4 GiB VRAM nicht mehr so kritisch wie früher sehe.

Das seh ich nicht so. Auch wenn der VRAM immer größer wird, das Bottleneck schlechthin auf modernen GPUs ist die Speicherbandbreite. Und genau das ist die Achillesferse von Deferred Rendering. Auch wenn du deinen megafetten G-Buffer in Zukunft problemlos in den VRAM geparkt bekommst: Die Anzahl der Parameter die du pro Pixel und Lichtquelle anfassen kannst bis die Performance im Erdkern ist, ändert sich dadurch nicht.

Die Frage ob die Rückkehr zum Forward Rendering kommt, stellt sich imo nicht. Die Frage ist nur wann sie kommt. Und all zu lang wirds vermutlich nichtmehr dauern.

Deferred Rendering war nie was anderes als ein Hack, wie die meisten Screenspace Methoden die heute in aller Munde sind.
Die Zukunft liegt imo in Richtung Global Illumination. Und dort haben Screenspace-Hacks eben rein prinzipiell keinen dauerhaften Platz, auch wenn man ein bisschen was, was ein wenig nach Global Illumination aussieht, heute ganz passabel damit hinfaken kann...

[eXile]

Auch das Argument mit den beliebig komplexen Materialien ist ausgelutscht, da muss man sich einfach nur genug fette G-Buffer nehmen, was ich in Zeiten von Graphikkarten mit bald 4 GiB VRAM nicht mehr so kritisch wie früher sehe.

Das seh ich nicht so. Auch wenn der VRAM immer größer wird, das Bottleneck schlechthin auf modernen GPUs ist die Speicherbandbreite. Und genau das ist die Achillesferse von Deferred Rendering. Auch wenn du deinen megafetten G-Buffer in Zukunft problemlos in den VRAM geparkt bekommst: Die Anzahl der Parameter die du pro Pixel und Lichtquelle anfassen kannst bis die Performance im Erdkern ist, ändert sich dadurch nicht.

Problematisch ist die Anzahl der Texturzugriffe im Pixel-Shader. Aber wie soll das besser werden, wenn du die gleiche Anzahl an Parametern halt nicht aus G-Buffern fischst, sondern aus Constant Buffern und normalen Texturen? Das ist doch alles eine unifizierte Speicherachitektur auf modernen Graphikkarten, da ist es relativ egal, aus welchem logischen Objekt die Daten nun physikalisch stammen. Man kann höchsten mit der Cache-Kohärenz hier argumentieren; aber die Graphikkarte sollte schnell merken, dass die G-Buffer wichtig sind.

Und was ist mit den ganzen Speicherzugriffen, die man dank perfekter Verdeckungrechnung mit Deferred Shading erst gar nicht durchführen muss?

Die Frage ob die Rückkehr zum Forward Rendering kommt, stellt sich imo nicht. Die Frage ist nur wann sie kommt. Und all zu lang wirds vermutlich nichtmehr dauern.

Deferred Rendering war nie was anderes als ein Hack, wie die meisten Screenspace Methoden die heute in aller Munde sind.

Lolwut? Deferred Rendering ist genauso wie ein Z-Pre-Pass oder ein Deferred Renderer mit Light-Pre-Pass einfach nur eine Caching-Variante. Du ziehst einfach ein paar Variablen aus der innersten Schleife raus, in weiter außen liegende Schleifen. Das hat nichts mit anderen Screenspace-Methoden zu tun, wie z.B. SSAO und Konsorten.

Die Zukunft liegt imo in Richtung Global Illumination. Und dort haben Screenspace-Hacks eben rein prinzipiell keinen dauerhaften Platz, auch wenn man ein bisschen was, was ein wenig nach Global Illumination aussieht, heute ganz passabel damit hinfaken kann...

Deferred Shading hat nichts mit globaler Illumination zu tun. Gar nichts.

[CodingCat]

Aus gegebenem Anlass im anderen Thread: Compact Normal Storage for small G-Buffers

[CodingCat]

Rectilinear Texture Warping for Fast Adaptive Shadow Mapping - Gezielte Verzerrung der Shadow Map mal andersrum: Anstatt mit viel Mühe die doch recht unflexible Sichtpyramide so zu verbiegen, dass am Ende möglichst viele Pixel der Shadow Map in der Nähe der Kamera des Betrachters landen, wird die Verteilung potentiell verschatteter Pixel anhand des G-Buffers aus Sicht des Betrachters (oder wahlweise sehr niedrigaufgelöster Ansicht des Lichts) analysiert und in einer Warp Map festgehalten. Diese verzerrt lineare Lichtraumkoordinaten zu an die gemessene Verteilung angepassten, nur noch stückweise linearen Koordinaten in verschieden aufgelösten Teilrechtecken der Shadow Map. Das Rendern der Shadow Map wird dabei so verändert, dass alle Vertices nach der Projektion durch diese Koordinatentransformation wandern, und so in der gewünschten Auflösung in den jeweiligen Teilrechtecken landen. Um den Fehler durch die nichtlineare Transformation zu minimieren, wird Tessellation eingesetzt. Beim Sichtbarkeitstest wanden ebenfalls einfach alle Koordinaten durch einen Lookup in der Warp Map. Abgesehen von der zusätzlichen Indirektion beim Vertex Texture Fetch im Shadow Map Pass und nach der Reprojektion in den Lichtraum zur Sichtbarkeitsberechnung ändert sich im Vergleich zu herkömmlichen Verfahren also nichts. Durch die Warp Maps sollte sich jedoch eine wesentlich gezieltere Auflösungsverteilung erreichen lassen, als das bei bisherigen perspektivischen Verzerrungen der Fall gewesen ist.

[eXile]

Frames, Quadratures and Global Illumination: New Math for Games

Verdammt gute Idee. Man macht einen Tradeoff zwischen räumlicher Lokalisierung und Frequenz-Lokalisierung. Dadurch hat man zwar keine Orthogonalbasis mehr, aber wie man sieht geht's auch ohne. Auch die Anzahl Koeffizienten macht hellhörig: Bei Ordnung 5 nur 12 Koeffizienten (das passt gut in drei Texturen). Die ersten Plots sehen schon mal nach weniger Ringing bei weniger Koeffizienten aus. Könnte eine kleine Renaissance der PRT-Methoden geben (natürlich bei gleichen Einschränkungen wie statischer Geometrie bei dynamischer Beleuchtung; dass es trotzdem praxisrelevant ist, zeigt Halo 3 mit ihren SH-Maps). Oder auch hier:

Deferred Radiance Transfer Volumes: Global Illumination in Far Cry 3

(Beide Paper frisch aus dem Twitter-Äther abgeschnorchelt.)

[CodingCat]

Okay, das liest sich sehr interessant und fundamental. Aber bevor ich jetzt weiterlese, muss ich ins Bett, damit mir nicht gleich wieder alles für die morgige CG-Klausur aus hinten dem Kopf purzelt.

Die Far Cry 3 Präsi hatte ich heute Mittag auch schonmal überflogen, es sieht tatsächlich aus, als würde indirekte Beleuchtung demnächst Standard. Sehr spannende Zeiten, zusammen mit den vielen faszinierenden entkoppelten Rasterisierungsmethoden, die mit DirectX 11 HW nun möglich und gerade entdeckt oder neu aus den Software-Rasterisierungszeiten ausgegraben werden.

[CodingCat]

Über einen Link von eXile darauf gestoßen: Understanding the Efficiency of Ray Traversal on GPUs - Der Bottleneck beim GPU Ray Tracing ist nicht zwangsläufig, wie gerne angenommen, die Inkohärenz der Speicherzugriffe beim Durchlaufen der Szenenstrukturen, sondern mindestens genauso wahrscheinlich das primitive GPU Scheduling beim Abarbeiten der Strahlen durch die GPU. So sind gerade bei Strahlen mit sehr unterschiedlichem Aufwand viele Threads die meiste Zeit idle, nur weil sie zusammen mit wenigen sehr aufwändigen Strahlen losgelaufen sind, und nun architekturbedingt erst mit Beendigung des letzten Strahls wieder frei für Arbeitszuteilung durch die GPU werden. In verlinktem Paper werden stattdessen alle Threads dauerhaft am Laufen gehalten, mittels primitiver eigener Work Queue wird in einer Schleife direkt nach Beendigung eines Strahls einfach der nächste Strahl abgearbeitet. Die Arbeitsverteilung durch die GPU wird so vollständig ausgeschaltet, und selbst absolut inkohärente Speicherzugriffe fallen überraschend wenig ins Gewicht.

[CodingCat]

Alt, allseits be- und anerkannt, und doch in dieser neuen Form so umfassend und gewitzt, dass sich alleine der Link in den Favoriten lohnt, nur um ihn fortan jedem, der es nötig haben sollte, um die Ohren hauen zu können; anstatt einmal mehr selbst (zeitraubend, diffus und lückenhaft) die Highlights des Schreckens zusammenklauben zu müssen: PHP: a fractal of bad design

[Artificial Mind]

PHP: a fractal of bad design

Na danke, ich hab mir den ganzen Artikel durchgelesen und nun muss ich weinen
In dieser Umfassendheit war mir "PHP" gar nicht bewusst.