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/publicatio ... cation.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 :D
In dieser Umfassendheit war mir "PHP" gar nicht bewusst.

[Jonathan]

Ich fand PHP schon immer doof, weil selbst die einfachsten Sachen auf stundenlange Fehlersuche hinauslaufen. Jetzt weiß ich, dass es wohl nicht an meiner mangelnden Erfahrung liegt.
Was empfiehlt sich denn sonst so für Webseiten? PHP ist ja mehr oder weniger Standard, wenn man das nicht benutzen will, was bleibt dann?

[Chromanoid]

Java, Ruby, Python, Perl, JavaScript, im Grunde alles was das Herz begehrt :D Ich würde Java nehmen, weil ich Java mag. http://tapestry.apache.org/ sieht nett aus. Java Hoster sind auch gar nicht mehr so selten, vielleicht ist ja auch die Google App Engine interessant für dich. GWT ist für Webanwendungen auch cool...

Facebook wird übrigens vorwiegend mit PHP entwickelt und dann in C++ konvertiert, Link den ich auch im Linkdump-Thema gepostet habe:

Exclusive: a behind-the-scenes look at Facebook release engineering, Ryan Paul, ars technica, 05.04.2012

[CodingCat]

Functional Programming in C++ - John Carmack über Nebenwirkungen, referenzielle Transparenz und die Vermeidung von Zustand.

[antisteo]

Ich fand PHP schon immer doof, weil selbst die einfachsten Sachen auf stundenlange Fehlersuche hinauslaufen. Jetzt weiß ich, dass es wohl nicht an meiner mangelnden Erfahrung liegt.
Was empfiehlt sich denn sonst so für Webseiten? PHP ist ja mehr oder weniger Standard, wenn man das nicht benutzen will, was bleibt dann?

Node.js rockt auch (hat aber ähnliche Probleme mit Fehlersuche [kann ich nicht beurteilen, hab nie einen Fehler in node.js gesucht und auch in PHP haben sich alle Probleme in Sekundenschnelle erledigt])

[simbad]

C/C++?

[kimmi]

Node.js == Javascript.

Gruss Kimmi

[Eike Anderson]

Real-time Realistic Rendering and Lighting of Forests, Éric Bruneton, und Fabrice Neyret, Computer Graphics Forum/Eurographics 2012, 2012
Eine Methode zum Echtzeitrendern von bewaldetem Terrain mit (hundert-)tausenden von Baeumen, entwickelt von der Computergrafikgruppe von INRIA (Frankreich). Weitere Publikationen der Gruppe und eine GPL Lib, die die Techniken implementiert gibt es hier: http://proland.inrialpes.fr

[eXile]

Clustered Deferred and Forward Shading

Wie gut, dass ich eh noch nicht mit einem Tile-based-Renderer angefangen habe. ;)

[rüp]

Ein Interview mit Knut Müller.

[antisteo]

Ihr fragt euch sicher, welche die am besten lesbare Programmiersprache ist.
Hier ist sie: https://github.com/substack/number-script

[Jörg]

ASTC Details Teil 1:
http://blogs.arm.com/multimedia/754-arm ... ce-part-1/

[Krishty]

Hm. So lange ich nur 50×100 Pixel große Beispielbilder mit bloß zwei Farbtönen drin sehe, haut mich da garnichts vom Hocker; zumal ich nicht glaube, dass die konzeptuellen Schwächen von DXT durch die höhere Zahl von Zwischenschritten aus der Welt geräumt werden können.

Andererseits frage ich mich seit eXiles Link zu den euklidischen Farbräumen, wie DXT wohl damit aussehen könnte.

[Jörg]

ASTC umschifft einige der DXT-Beschraenkungen, nicht alle. Aber wenn man bei gleicher Bitrate hoehere Qualitaet erhaelt und der HW-seitige Mehraufwand dabei gering ausfaellt, ist das wirklich was wert. Und das man mit einer Implementierung sowohl staerker als auch schwaecher als DXT komprimieren kann, erfreut hoffentlich die Grafiker.
Den perfektionistischen Rest erledigt dann Cric-TC im naechsten Jahr? ;)
Eines ist immer schwierig fuer die HW-Entwicklung: Sobald ein Format zu sehr aus dem Rahmen faellt, wird es haarig. Die Festlegung auf 128 bit/Block z.B. erlaubt eine Wiederverwendung der vorhandenen Prefetch und Cache-Module. Am Ende soll as neue Format beim Verwenden ja auch nicht langsamer erscheinen. Mit breiterer Context-Information kann man definitv besser Komprimieren, aber der Dekompressionsschritt wird einfach langsamer. Wahlfreier Zugriff auf die Texel schraenkt die effizienten Implementierungen ziemlich ein :/

[Krishty]

Dass man Blockkomprimierung braucht, ist klar. Dass die Blöcke fixed-size sein müssen, auch. Und dass bei ARM jeder Transistor zählt, sowieso.

Aber ein 15 Jahre altes Format durch ein paar zusätzliche Blockmodi und neue Farbtiefen aufzubohren; dabei keine fundamentalen Verbesserungen zu bringen (habt ihr auch was für Normal Maps?); und es dann mit einem daumengroßen Bildausschnitt vorzustellen halte ich für absolut übertrieben.

Und so hoch kann der Transistoraufwand auch nicht sein, wo ja Ericssons iPACKMAN ein Bisschen mehr als bloß Interpolation ist und auch trotzdem schon seit 2006 in Hardware verbaut wird.

[Jörg]

Auf ETC sowie (Tangentspace-)Normalmaps wird im 2. Teil kurz eingegangen. Und keine Sorge, der Testkorpus zum Ermitteln der durchschnittlichen Qualitaetsverbesserung enthaelt mehr als ein Bild: http://www.davemc.net/HPG2012/105-114.p ... t.pdf.html, da findest Du die 'nicht-gebloggte' Version verlinkt.