Ein wesentliches Merkmal, das produktionsfähige Renderer von Hobby-Renderern unterscheidet, ist ein Textur-Cache-System.
Ein gut implementiertes Textur-Cache-System ermöglicht es einem Produktions-Renderer, Szenen mit potenziell vielen TBS Texturen zu rendern, aber in einem vernünftigen Fotoprint, der in ein paar Dutzend oder hundert Gb RAM passt.
So ziemlich jeder Produktions-Renderer verfügt heute über ein robustes Textur-Cache-System. Arnold leitet bekanntlich eine beträchtliche Leistung aus einer extrem effizienten Textur-Cache-Implementierung ab. Ähnliches gilt für Vray/Corona oder Renderman, die alle ihre eigenen, ähnlich effizienten Systeme haben.
In diesem Beitrag werden wir darüber berichten, wie ein gekacheltes Textur-Caching-System in den Hobby-Renderer Takua Render implementiert wurde. Wir werden auch einige der interessanten Herausforderungen besprechen, denen die Entwickler dabei begegnet sind. Dieser Beitrag wird sich auf den Mipmapping-Teil des Systems konzentrieren. Der Aufbau eines gefliesten Mipmapping-Systems, das gut mit bidirektionalen Path-Tracing-Techniken funktioniert, war besonders schwierig, aus Gründen, auf die wir später in diesem Beitrag eingehen werden.
Wir werden auch die akademische Literatur über Ray-Differenziale und Mipmapping mit Pfad-Tracing durchgehen und einen Blick darauf werfen, was verschiedene Renderer so alles leisten können. Die Szene, die wir als Beispiel in diesem Beitrag verwenden, ist eine benutzerdefinierte Nachbildung einer Waldszene aus Evermotion`s Archmodels 182, die vollständig mit Takua Render gerendert wurde:
Textur-Caches und Mipmaps.
Textur-Caching ist typischerweise mit irgendeiner Form eines gefliesten, mipgemappten Textursystems gekoppelt: der Textur-Cache entält bestimmte Kacheln eines Bildes, auf die zugegriffen wurde, im Gegensatz zu einer gesamten Textur. Diese Kacheln werden typischerweise bei Bedarf in einen Cache geladen (Peachey 1990), was bedeutet, dass der Renderer nur die Speicherplatzkosten für Teile einer Textur bezahlen muss, auf die der Renderer tatsächlich zugreift.
Ein Teil dieses Beitrags stellt eine Zusammenfassung dessen dar, was Mipmaps sind, die Auswahl der Mipmap-Ebene und die Strahlenunterschiede für den weniger erfahrenen Leser. Wir diskutieren auch ein wenig darüber, welche Techniken verschiedene Produktions-Renderer heute verwenden.
Mipmapping funktioniert, indem es mehrere Auflösungen einer Textur erzeugt und für eine bestimmte Oberfläche nur die letzte Auflösungsstufe lädt, bei der das Frequenzdetail bei Betrachtung von der Kamera aus unter die Nyquist-Grenze fällt. Da Texturen oft viel höher auflösend sind als die endgültige Framebuffer-Auflösung, bedeutet Mipmapping, dass der Renderer enorme Speichereinsparungen erzielen kann, da für Objekte, die weiter von der Kamera entfernt sind, die meisten geladenen Mip-Level deutlich niedriger auflösend sind als die ursprüngliche Textur. Mipmaps beginnen mit der ursprünglichen Textur in voller Auflösung als „Level 0“, und anschließend ist jedes Level, welches von 0 aufsteigt, die Hälfte der Auflösung des vorherigen Levels. Die höchste Level ist jenes, auf der die Textur in der Auflösung nicht mehr halbiert werden kann.
Bevor wir ins Detail gehen, müssen wir eine wichtige Anmerkung machen. Wir werden im Moment nicht allzu viel über Texturfilterung schreiben, vor allem, weil wir in Takua nicht viel mit Texturfiltern bisher gemacht haben. Mipmapping wurde ursprünglich als elegante Lösung für das Problem der teuren Texturfilterung im Raster-Rendering entwickelt: wenn eine Textur Details aufweist, die häufiger sind als der Abstand zwischen benachbarten Pixeln im Framebuffer, tritt beim Abtasten der Textur Aliasing auf. Mipmaps werden typischerweise mit vorberechneter Filterung für Mip-Werte oberhalb der ursprünglichen Auflösung erzeugt, so dass einzelne Texturproben antialiasiert erscheinen können.
Im Moment verwendet Takua nur einen Point-Sampler für alle Texturfilterungen. Unser Interesse an Mipmaps gilt hauptsächlich der Speichereffizienz und dem Textur-Caching anstelle von Filtern. Unser Meinung nach wird in einem Path Tracer, der Hunderte oder sogar „Tausende“ von Pfaden für jedes Framebuffer-Pixel erzeugen wird, der Bedarf an Single-Sample-Antialiasing etwas reduziert, da wir bereits im Grund bereits das Supersampling abgeschlossen haben. Gute Texturfilterung ist natürlich immer noch ideal, aber sich auf das Supersampling zu verlassen, um Textur-Aliasing in der primären Sichtbarkeit loszuwerden, ist nicht unbedingt die schlechteste kurzfristige Lösung. Darüber hinaus bedeutet die Verwendung von Just Point Sampling, dass jede Texturprobe nur zwei Textur-Lookups benötigt: eine aus dem Integer-Mip-Level und eines aus dem Integer-Mip-Level unterhalb des Continous Float-Mip-Levels an einem Sample Point. Die Verwendung von nur zwei Text-Loopups pro Texturbeispiel ist sehr effizient, da der Speicherzugriff minimiert und die Verzweigung im Code minimiert wird. Interessanterweise ist das Moonray-Team von Dreamworks Animation zu mehr oder weniger der gleichen Schlußfolgerung gekommen. Sie weisen ihn Ihrem Beitrag darauf hin, dass die geometrische Komplexität im Grund genommen unendlich häufig ist, während vorgefilterte mipgemappte Texturen bereits bandbegrenzt sind. Infolgedessen sollte die Anzahl der Proben, die zur Auflösung von geometrischem Aliasing benötigt werden, mehr als ausreichend sein, um auch jedes Textur-Aliasing aufzulösen. Das Moonray-Team stellte fest, dass dieser Ansatz gut genug funktioniert, um ihr Standardmodus in der Produktion zu sein.
Mipmap Level Auswahl und Ray-Differentiale.
Der schwierigste Teil der Verwendung von gemippmapten Texturen besteht darin, herauszufinden, welche Mipmap-Ebene an einen bestimmten Punkt gesampelt werden soll. Da das Ziel darin besteht, eine Mipmap-Ebene mit einem Frequenzdetail zu finden, das so nah wie möglich an der Textur Sampling Rate liegt, müssen wir ein Gefühl dafür haben, wie die Textur Sampling Rate an einem bestimmten Punkt im Raum im Verhältnis zur Kamera sein wird. Genauer gesagt, wollen wir die Differenz der Oberflächenparametrisierung in Bezug auf die Bildebene. Da die Bildebene zweidimensional ist, werden wir am Ende für jede UV-Achse in Bezug auf jede Achse der Bildebene ein Differenzial erhalten. Wir nennen diese Differenziale dudx/dvdx und dudy/dvdy, wobei u/v für UV-Koordinaten und x/y für Pixelkoordinaten der Bildebene steht. Die Berechnung dieser Differenzen ist in einem Rasterizer einfach genug: Für jedes Pixel der Bildebene nehmen Sie die Texturkoordinate des Fragments und subtrahieren Sie sie mit den Texturkoordinaten der benachbarten Fragmente, um den Gradienten der Texturkoordinaten in Bezug auf die Bildebene zu erhalten, und skalieren Sie anschließend mit der Texturauflösung. Sobald wir dudx/dvdx und dudy/dvdy haben, müssen wir für einen nicht-fantasievollen Boxfilter nur noch den längsten dieser Gradienten nehmen und seine Logarithmusbasis 2 berechnen, um die Mipmap-Ebene zu erhalten. Ein Code-Snippet könnte beispielsweise wie folgt aussehen:
Beachten Sie, dass der Füllstandswert ein kontinuierlicher Float ist. Normalerweise ist es ein besserer Ansatz, die beiden ganzzahligen Mipmap-Ebenen über und unter dem kontinuierlichen Pegel zu erfassen und zwischen den beiden Werten mit dem Bruchteil des Levels zu mischen, anstatt sie auf eine ganze Zahl zu runden. Diese Überblendung hilft enorm bei der Glättung von Übergängen zwischen Mipmap-Ebenen, was bei der Darstellung einer animierten Sequenz mit Kamerabewegung sehr wichtig werden kann.
In einem Raytracer ist es jedoch nicht so einfach wie in einem Rasterizer, dudx/dvdx und dudy/dvdy herauszufinden. Wenn wir nur Primärstrahlen betrachten, können wir etwas Ähnliches wie im Fall der Rasterung tun: einen Strahl von einem bestimmten Pixel und Feuerstrahlen von den benachbarten Pixeln abfeuern und den Gradienten der Texturkoordinaten in Bezug auf den Screen-Space berechnen, indem wir die Trefferquote jedes benachbarten Strahls untersuchen, der auf die gleiche Oberfläche wie der Primärstrahl trifft. Dieser Ansatz fällt jedoch aus folgenden Gründen und mehr schnell auseinander:
Eine bessere Lösung für diese Probleme ist die Verwendung von Strahlendifferenzen, die mehr oder weniger nur ein Strahl zusammen mit der partiellen Ableitung des Strahls in Bezug auf den Screen-Space sind. Das Betrachten eines Strahldifferentials als im Wesentlichen ähnlich wie ein Strahl mit einer Breite oder einem Kegel, ähnlich wie das Balkenzeichnen, das Bleistiftzeichnen oder das Kegelsuchen, ist nicht völlig falsch, aber die Strahlendifferentiale sind etwas nuancierter als alle anderen der oben genannten. Anstatt mit jedem Kamerastrahl einen Haufen unabhängiger Nachbarstrahlen zu verfolgen, besteht die Idee darin, dudx/dvdy und dudy/dvdy an jedem Trefferpunkt mit simulierten Offsetstrahlen zu rekonstruieren, die mit der partiellen Ableitung des Strahls rekonstruiert werden. Strahlungsdifferenzen werden neben den Kamerastrahlen erzeugt: wenn ein Strahl von der Kamera verfolgt wird, werden Offsetstrahlen für ein einzelnes Nachbarpixel vertikal und ein einzelnes Nachbarpixel horizontal in der Bildebene erzeugt. Anstatt diese Offsetstrahlen jedoch unabhängig voneinander zu verfolgen, gehen wir immer davon aus, dass sie sich in einer gewissen Winkelbreite vom Hauptstrahl befinden. Wenn der Hauptstrahl auf eine Oberfläche trifft, müssen wir für die spätere Verwendung das Differential der Oberfläche am Schnittpunkt in Bezug auf den UV-Raum berechnen, das dpdu und dpdv genannt wird. Verschiedene Oberflächentypen erfordern unterschiedliche Funktionen zur Berechnung von dpdu und dpdv. Für ein Dreieck in einem Triangle-Mesh benötigt der Code die Position und die UV-Koordinaten an jedem Node:
Die Berechnung von Oberflächendifferenzen verursacht zwar einen kleinen Aufwand für den Renderer, aber die Kosten können mit etwas Sorgfalt minimiert werden. Der naive Ansatz für Oberflächendifferenzen besteht darin, sie mit jedem Schnittpunkt zu berechnen und als Teil der Trefferpunktinformation zurückzugeben, die durch die Strahlentransversale erzeugt wird. Diese Berechnung ist jedoch verschwendet, wenn die Shadingoperation für einen bestimmten Trefferpunkt nicht tatsächlich zu Texturnachschlägen führt. In Takua werden Oberflächendifferenzen nach Bedarf bei der Texture Lookup anstelle der Ray Intersection Zeit berechnet. Auf diese Weise müssen wir die Berechnungskosten für die obige Funktion nicht bezahlen, es sei denn, wir müssen tatsächlich Texture Lookups durchführen. Takua unterstützt auch mehrere UV-Sets pro Mesh, so dass die obige Funktion durch die UV-Set-ID parametrisiert wird und die Funktion einmal für jeden UV-Satz aufgerufen wird, den eine Textur angibt. Oberflächendifferenzen werden auch innerhalb einer Shadingoperation pro Trefferpunkt zwischengespeichert, so dass, wenn ein Shader mehrere Textur-Lookups innerhalb eines einzigen Calls durchführt, die erforderlichen Oberflächendifferenzen nicht redundant berechnet werden müssen.
Die Variante von Sony Imageworks von Arnold (wir werden sie als SPI Arnold bezeichnen, um sie von Solid Angle`s Arnold zu unterscheiden) tut etwas noch Fortgeschritteneres. Anstelle der oben genannten expliziten Oberflächendifferenzberechnung implementiert SPI Arnold ein automatisches Differenzierungssystem mit Doppelarithmetik. SPI Arnold verwendet OSL weitgehend für die Schattierung: das bedeutet, dass sie in der Lage sind, zur Laufzeit zu verfolgen, welche Abhängigkeiten ein bestimmter Shader-Ausführungspfad erfordert, und somit, wenn ein Shader jegliche Art von derivativen oder differentiellen Informationen benötigt. Die Aufrufe des automatischen Differenzierungssystems werden dann in den Ausführungspfad des Shaders übertragen, so dass Shader-Autoren nie wissen müssen, wie Derivate im Renderer berechnet werden. Die Entscheidung des SPI Arnold Teams, eine doppelte arithmetisch basierte automatische Differenzierung einzusetzen, wird durch die Erfahrungen beeinflusst, die sie zuvor mit dem Finite-Differenzierungssystem von BMRT gemacht hatten, das für das inkohärente Pfad-Tracing viele externe Shading-Berechnungen erforderte. Zumindest für unsere Zwecke. Wir haben festgestellt, dass der einfachere Ansatz, den wir in Takua gewählt haben, sowohl in Bezug auf den finalen Overhead als auch auf die Codekomplexität hinreichend vernachlässigbar ist, so dass wir wahrscheinlich so etwas wie den SPI Arnold Ansatz vorerst überspringen werden.
Sobald wir das Oberflächendifferenzial haben, können wir anschließend die lokale Oberflächengeometrie am Schnittpunkt mit einer Tangentialebene approximieren und die Offsetstrahlen mit der Tangentialebenen schneiden. Um die entsprechenden UV-Koordinaten für die versetzten Strahlentangentialebenen zu finden, können dpdu/dpdv, der Hauptstrahlkreuzungspunkt und die versetzten Strahlenkreuzungspunkte verwendet werden, um ein Linearsystem aufzubauen. Die Lösung dieses linearen Sytems führt uns direkt zu dudx/dudy und dvdx/dvdy.
Da wir nun dudx/dudy und dvdx/dvdy haben, funktioniert das Erhalten des richtigen Mipmap-Levels genau wir im Rasterisierungsfall. Der obige Ansatz ist genau das, was wir im Takua Renderer für Kamerastrahlen implementiert haben. Ähnlich wie bei Oberflächendifferentialen speichert Takua dudx/dudy und dvdx/dvdy Berechnung pro Shaderaufruf pro Trefferpunkt, so dass mehrere Texturen, die den gleichen UV-Set verwenden, nicht mehrere redundante Aufrufe der obigen Funktion erfordern.
Der Ray-Derivat-Ansatz zur Auswahl der Mipmap-Ebene ist im Grunde genommen der Standardansatz im modernen Produktrendering von heute für Kamerastrahlen. PBRT, Mitsuba und Solid Angle`s Version von Arnold verwenden alle Strahldifferenzsysteme, die auf diesem Ansatz für Kamerstrahlen basieren. Renderman verwendet eine vereinfachte Version von Ray-Differentialen, die nur zwei Floats pro Strahl verfolgt, anstatt der vier Vektoren, die für die Darstellung eines Full Ray Differentials benötigt werden. Renderman verfolgt eine Breite am Ursprung jedes Strahls und einen Spreizwert, der die lineare Änderungsrate der Strahlbreite über eine Einheitsstrecke darstellt. Dieser Ansatz kodiert nicht so viele Informationen wie der Full Ray Derivate Ansatz, aber dennoch ist er ausreichend, da in einem Path Tracer jedes Pixel im Wesentlichen mit einer Supersampledarstellung endet. Hyperion verwendet ein ähnlich vereinfachtes Schema.
Eine kurze Nebenbemerkung. Die Möglichkeit, die Differenz für Oberflächennormals in Bezug auf den Screen-Space zu berechnen, ist unter anderem für das Bump-Mapping nützlich, und die Berechnung ist direkt analog zum obigen Pseudocode für calculateDifferentialSurfaceForTriangle() und calculateScreenSpaceDifferential(), nur mit Oberflächennormals, die für Oberflächenpositionen ersetzt wurden.
Strahlendifferenzierung und Path Tracing.
Wir wissen jetzt, wie man Filter-Footprints mit Hilfe von Strahlendifferenzen für Kamerastrahlen berechnet, was großartig ist, aber was ist mit Sekundärstrahlen? Ohne Strahlungsdifferenzen für Sekundärstrahlen verschlechtert sich das Zugriffsverhalten auf das Path Tracing von Texturen stark, da Sekundärstrahlen auf Punktabtastungstexturen auf der untersten Mip-Ebene zurückgreifen müssen. Es gibt eine Reihe von verschiedenen Schemata zur Berechnung von Filter-Footprints und Mipmap-Ebenen für Sekundärstrahlen.
Igehi zeigt, wie man Strahlungsdifferenzen durch perfekt spiegelnde Reflexions- und Refraction-Events propagiert, die sich einige einfache Erweiterungen der Grundmathematik für optische Reflexion und Refraction reduzieren. Allerdings brauchen wir noch ein Mittel zur Behandlung des Glanzes (also keine Zero-Surface-Roughness), was eine erweiterte Version von Strahldifferentialen erfordert. Pfad-Differenzen berücksichtigen mehr als nur partielle Ableitungen für jeden Bildflächenpixel-Footprint. Mit Pfad-Differenzen können partielle Ableitungen auch bei jedem steuernden Ereignis entlang einer Reihe von Dimensionen vorgenommen werden. Als Beispiel für die Handhabung eines beliebig geformten BSDF-Kolbens können neue partielle Ableitungen entlang eines Parameters des Kolbens berechnet werden, der die Form des Kolbens beschreibt, der in Form eines Bündels zusätzlicher Streurichtungen um die Streurichtung des Hauptstrahls vorliegt. Wenn wir uns vorstellen, die Hauptstreuungsrichtung nach unten zu richten und eine konvexe Hülle um die zusätzlichen Streurichtungen herum zu konstruieren, ist das Ergebnis ein polygonaler Footprint, der die Strahldifferenz über dem Streuereignis beschreibt. Dieser Footprint kann dann durch das Auffinden der Haupt- und Nebenachse des polygonalen Footprints approximiert werden. Obwohl die Methode allgemein genug ist, um mit beliebigen Faktoren umzugehen, die sich auf die Strahlrichtung auswirken, kann sie in der Praxis leider ziemlich komplex und teuer zu berechnen sein, und Unterschiede für einige Arten von Ereignissen können sehr schwer anzuleiten sein. Aus diesem Grund verwendet keiner der großen Produktions-Renderer heute diesen Ansatz. Es gibt jedoch eine nützliche Beobachtung, die sich aus Pfad-Differenzen ableiten lässt: Im Allgemeinen haben Primärstrahlen in den meisten Fällen schmale Breiten und Sekundärstrahlen größere Breiten. Diese Beobachtung ist die Grundlage für die Ad-hoc-Techniken, die die meisten Produktions-Renderer anwenden.
In jüngster Zeit sind Forschungsergebnisse aufgetaucht, die einen völlig anderen, prinzipientreuen Ansatz für die Auswahl von Filter-Footprints auf der Grundlage von Kovarianz-Tracing bieten. Die übergeordnete Idee hinter dem Kovarianz-Tracing ist, dass lokale Lichtwechselwirkungen wie Transport, Okklusion, Roughness usw. als 5D-Kovarianzmatrizen kodiert werden können, die wiederum zur Bestimmung idealer Samplings verwendet werden können. Kovarianz-Tracing bildet einen tatsächlichen, implementierbaren Rendering-Algorithmus, der auf früheren, meist theoretischen Arbeiten zur Analyse der leichten Transportfrequenz basiert. Belcour stellt eine Erweiterung der Kovarianzverfolgung zur Berechnung von Filter-Footprints für beliebige Shading-Effekte, einschließlich Textur-Map-Filterung, vor. Der auf Kovarianz-Tracing basierende Ansatz unterscheidet sich von Pfad-Differenzen in zwei Schlüsselbereichen. Während beide im Path-Space arbeiten, sind Pfad-Differenzen viel teurer zu berechnen als die auf Kovarianz-Tracing basierende Technik. Die Komplexität der Pfad-Differenzen skaliert quadratisch mit der Pfadlänge, während das Kovarianz-Tracing immer nur eine einzige Kovarianzmatrix auf einem Pfad für einen bestimmten Effekt trägt. Außerdem können Pfad-Differenzen nur von der Kamera aus erzeugt werden, während die Kovarianz-Verfolgung von der Kamera und dem Licht funktioniert.
Kovarianz-Tracing-basierte Techniken sind vielversprechend und der bisher bekannteste Ansatz zur Auswahl von Filter-Footprints entlang eines Pfades. Das ursprüngliche Kovarianzmusterpapier hatte einige Schwierigkeiten bei der Handhabung hoher geometrischer Komplexität. Die Kovarianzmessung erfordert eine voxilierte Version der Szene zur Speicherung lokaler Kovarianzinformationen, und Kovarianzschätzungen können sich stark verschlechtern, wenn das Kovarianzmuster der Okklusion nicht hoch genug ist, um kleine geometrische Details zu erfassen. Bei großen Szenen im Produktionsmaßstab können geometrische Komplexitätsanforderungen die Kovarianzverfolgung entweder verlangsamen und die Qualität verschlechtern. Der Voxelizationsschritt ist jedoch kein so großes Hindernis für die Praktikabilität, wie es zunächst scheint. Bei der kovarianzabhängigen Filterung kann die Sichtbarkeit vernachlässigt werden, so dass der gesamte Schritt der Szenenvoxifizierung übersprungen werden kann. Belcour zeigt, wie das geht. Da die auf Kovarianz-Tracing basierende Filterung mit den gleichen Annahmen und Daten wie die Strahlendifferenziale verwendet werden kann, aber sowohl in der Qualität besser als auch allgemeiner als die Strahlendifferenziale ist, wären wir nicht überrascht, wenn mehr Renderer diese Technik im Laufer der Zeit anwenden würden.
Derzeit verwenden jedoch so gut wie alle Produktions-Renderer heute verschiedene Ad-hoc-Methoden, um die Strahlbreite für Sekundärstrahlen zu verfolgen, anstatt eine der oben genannten Techniken zu verwenden. SPI Arnold verfolgt die kumulierten Roughness-Werte eines Strahls: Trifft ein Strahl entweder auf ein diffuses Ereignis oder erreicht er einen ausreichend hohen kumulierten Roughness-Wert, geht SPI Arnold automatisch auf den grundsätzlich höchsten verfügbaren MIP-Wert. Dieses Schema erzeugt eine sehr aggressive Texturfilterung, bietet aber wiederum ausgezeichneten Texturzugriffsmuster. Solid Angle Arnold verwendet ebenfalls eine Ad-hoc Mikrofacet-inspirierte Heuristik für Sekundärstrahlen. Renderman behandelt Reflexion und Refraction mit etwas Ähnlichem wie Igehy, aber modifiziert für die single-float-width ray differential representation, die Renderman verwendet. Für glänzende und diffuse Ereignisse verwendet Renderman eine empirisch ermittelte Heuristik, bei der höhere Strahlbreitenspannen durch PDFs mit geringerer Streuungsrichtung angetrieben werden. Wetas Manuka verfügt über ein einheitliches Roughness-Schätzssystem, das in das Shading-System integriert ist, das eine mittlere Cosinus-Schätzung zur Berechnung von Strahlungsdifferenzen verwendet.
Im Allgemeinen scheinen Roughness-getriebene Heuristiken in der Produktion recht gut zu funktionieren, und die eigentlichen Heuristiken müssen eigentlich nicht zu kompliziert sein. In einem experimentellen Zweig von PBRT fand Matt Pharr heraus, dass eine einfache Heuristik, die ein Strahlendifferenzial verwendet, das etwa 1/25 der Hemisphäre für diffuse Ereignisse und 1/100 der Hemisphäre für glänzende Ereignisse abdeckt, im Allgemeinen recht gut funktionierte.
Strahlungsdifferentiale und bidirektionale Techniken.
Bisher war alles, war wir besprochen haben, für eine unidirektionale Wegverfolgung, die von der Kamera aus beginnt. Wie sieht es mit Strahlungsdifferentialen und der Auswahl des Mip-Pegels für Wege, die von einem Licht ausgehen, und im weiteren Sinne für bidirektionale Wegverfolgungstechniken aus? Leider hat niemand eine gute, robuste Lösung zur Berechnung von Strahldifferenzen für den Strahlengang. Die Berechnung von Strahldifferenzen für Lichtwege ist grundsätzlich ein schlecht definiertes Problem: Eine Strahldifferenzierung muss in Bezug auf einen Pixel-Footprint im Rasterbereich berechnet werden, der für Kamerapfade gut funktioniert, da der erste Strahl von der Kamera ausgeht, aber für Lichtwege ist der letzte Strahl im Pfad derjenige, der die Kamera erreicht. Mit Lichtpfaden haben wir so etwas wie ein Hühner- und Ei-Problem. Es gibt keine Möglichkeit, irgendetwas in Bezug auf den Pixel-Footprint eines Screen-Spaces zu berechnen, bis ein Lichtpfad bereits vollständig konstruiert ist, aber die Shading-Berechnungen, die zur Konstruktion des Pfades erforderlich sind, sind die Berechnungen, die überhaupt Differentialinformationen wollen. Selbst wenn wir eine gute Möglichkeit hätten, eine Startstrahl-Differenz aus einem Licht zu berechnen, kann die entsprechende Pfad-Differenz nicht so breit werden wie bei einem Kamerapfad, da der Lichtpfad zu jedem Zeitpunkt zur Kamera hin streuen könnte und daher einen Footprint von nicht mehr als einem einzelnen Pixel des Screen-Spaces beibehalten werden muss.
Einige Forschungsarbeiten sind in diese Frage eingeflossen, aber es sind weitere Arbeiten zu diesem Thema erforderlich. Die zuvor diskutierte auf Kovarianz-Tracing basierende Technik erlaubt es, eine ideale Texturfilterbreite und Mip-Level zu berechnen, sobald ein Lichtweg vollständig konstruiert ist, aber auch hier besteht das eigentliche Problem darin, dass Footprints während des Wegebaus und nicht danach verfügbar sein müssen. Mit dem bidirektionalen Path Tracing wird es noch schwieriger. Um einen bidirektionalen Pfad unvoreingenommen zu halten , müssen alle Verbindungen zwischen Kamera- und Lichtwegvertices in der Mip-Ebene, die sie erfassen, konsistent sein. Dies ist jedoch schwierig, da die Strahlendifferenzen von den Streuereignissen an jedem Wegpunkt abhängen. Belcour zeigt, wie wichtig eine konsistente Texturfilterung zwischen zwei Nodes ist.
Derzeit haben nur eine Handvoll Produktions-Renderer umfangreiche Unterstützung für bidirektionale Techniken – von diejenigen, die diese Funktion bieten, ist die gebräuchlichste Lösung zur Berechnung von Strahlendifferenzen zu bidirektionale Pfaden. Leider bedeutet dies, dass sich bidirektionale Techniken darauf verlassen müssen, dass der Punkt die niedrigste Mip-Ebene erfasst, was den gesamten Punkt des Mipmappings besiegt und die Leistung des Textur-Caching zerstört. Das Manuka-Team spielt auf die Verwendung von Strahlendifferenzen für Photonenmap-Sammelbreiten in VCM an und stellt fest, dass diese Strahlendifferentiale als Teil Ihres vielfältigen Schätzsystems für das nächste Ereignis implementiert sind, aber es gibt nicht genug Details in Ihrem Paper, um herausfinden zu können, wie dies tatsächlich funktioniert.
Kamerabasierte Mipmap-Level-Auswahl.
Takua hat Implementierungen von Standard bidirektionalem Path Tracing, progressive Photon Mapping und VCM, und wir wollten, dass Mipmapping mit allen Integratortypen in Takua funktioniert. Wir sind daran interessiert, Takua zu verwenden, um Szenen mit sehr hohen Komplexitätsstufen mit fortschrittlichen Lichttransportalgorithmen zu rendern, aber das Erreichen von Produktionsstufen der Shading-Komplexität ohne einen mipgemappten Textur-Cache ist einfach nicht möglich ohne riesige Mengen an Speicher. Aus den oben beschriebenen Gründen würden jedoch Standardstrahl-Differenztechniken zur Berechnung von Mip-Werten nicht mit den bidirektionalen Integratoren von Takua funktionieren.
Das Fehlen einer Strahldifferenzlösung für Lichtwege führte zu hohen Zeitverlust, bis Ende 2017, als wir einen frühen Entwurf dessen gelesen haben, was schließlich das Manuka-Paper in der ACM Transactions on Graphics Sonderausgabe zum Produktionsrendering wurde. Wir empfehlen dringend, alle fünf Production Renderer System Papers in der ACM TOG Sonderausgabe zu lesen. Wenn Sie jedoch bereits allgemein damit vertraut sind, wie ein moderner Renderer im PBRT-Stil funktioniert und nur Zeit zum Lesen eines Papers haben, würden wir das Manuka-Paper empfehlen, nur weil die Architektur von Manuka und die vom Manuka-Team getroffenen Kompromisse und Entscheidungen sich so stark von dem unterscheiden, was jeder andere moderne Produktions-Path-Tracer im PBRT-Stil tut. Was wir schließlich in Takua umgesetzt haben, ist direkt von Manuka inspiriert, obwohl es nicht das ist, was Manuka tatsächlich tut.
Das wichtigste architektonische Merkmal, das Manuka von Arnold/Renderman/Vray/Corona/Hyperion unterscheidet, ist seine Shade-before-hit-Architektur. Wir möchten an dieser Stelle darauf hinweisen, dass sich Schatten in diesem Zusammenhang auf den Mustererzeugungsanteil der Schattierung bezieht, im Gegensatz zum bsdf-Auswertungs-/Samplinganteil der Schattierung. Die kurze Erklärung ist, dass Manuka die Mustergenerierung volständig von der Pfadkonstruktion und der Pfadprobennahme entkoppelt, im Gegensatz zu dem, was alle anderen modernen Pfad Tracer tun. Die meisten modernen Pfad Tracer verwenden Shade-on-Hit, was bedeutet, dass die Mustergenerierung ausgewertet wird, um bei Bedarf bsdf-Parameter zu erzeugen, z.B. wenn ein Strahl auf eine Oberfläche trifft. In einem Schatten auf der Trefferarchitektur werden Mustererzeugung und Pfadabtastung verschachtelt, da die Path Sampling von den Ergebnissen der Mustererzeugung abhängt. Die Trennung von Geometrieverarbeitung und Bahnbau ist bei den meisten modernen Produktionsbahntracern ziemlich standard, was bedeutet, dass Unterteilung/Tessellierung/Verschiebung stattfindet, bevor irgendwelche Strahlen verfolgt werden, und die Versetzung beinhaltet in der Regel eine gewisse Menge an Mustererzeugung. Allerdings trennt kein anderer Produktionspfad-Tracer die gesamte Mustergenerierung von der Pfadabtastung, wie Manuka es tut. Beim Rendern führt Manuka eine Geometrieverarbeitung durch, die die gesamte eingegebene Geometrie in Mikropolygongitter schneidet und anschließend die Mustergenerierung auf allen Mikropolygonen durchführt. Das Ergebnis der Mustererzeugung ist ein Satz von bsdf-Parametern, die in den Mikropolygonnodes eingebrannt werden. Manuka baut anschließend einen BVH auf und fährt mit normalen Pfad-Tracing fort, aber an jedem Pfadnode müssen Shading-Graphen ausgwertet und Textur-Lookups durchgeführt werden, um bsdf-Parameter zu berechnen. Die bsdf-Parameter werden direkt aus den vorberechneten zwischengespeicherten Werten, die in die Mikropolygonnodes eingebakt wurden, nachgeschlagen. Anders ausgedrückt, anstelle eines Shader-Ausführungsmodells im PBRT-Stil Manuka bewahrt die gridbasierte Shading-Kohärenz von REYES und bietet gleichzeitig mehr Flexibilität beim Path Sampling und dem Lichttransport, die sich nicht mehr darum kümmern müssen, dass die Mustergenerierung das Shading verlangsamt.
Also, wie hängt das alles mit dem Problem des birektionalen Path Tracings bei der Auswahl des Mip-Levels zusammen. Die Antwort lautet: In einer Shade-before-hit-Architektur muss der Renderer, wenn dieser Lichtwege verfolgt, keine Mip-Level-Auswahl mehr treffen, da beim Path-Sampling keine Textur-Lookups mehr erforderlich sind. Während des Path Samplings wertet Manuka bsdfs an jedem Trefferpunkt mit vorab schattierten Parametern aus, die bilinear aus den nächsten Mikropolygonpunkten interpoliert werden. Alle Textur-Lookups wurden bereits in der Pre-Shade Phase des Renderers durchgeführt. Mit anderen Worten, zumindest im Prinzip kann ein Renderer im Manuka-Stil das Problem dem bidirektionalen Path Tracing bei der Auswahl von Mip-Levels vollständig umgehen. Auch in einer Shade-before-hit-Architektur gibt es keine Probleme mit der Vorspannung bidirektionales Path-Sampling von verschiedenen Kamera-/Lichtwegvertex-Verbindungen mit unterschiedlichen Mip-Levels. Da alle Entscheidungen zur Auswahl des Mip-Levels und zur Texturfilterung vor dem Pfad-Sampling getroffen werden, ist die Sicht auf die Welt, die dem Path-Sampling präsentiert wird, immer konsistent.
Takua ist jedoch kein Shade-before-hit Renderer, und aus einer Vielzahl von Gründen haben wir es die Entwickler nicht vor, Takua danach weiterzuentwickeln. Share-before-hit präsentiert eine Reihe von Tradeoffs, die sich in Manukas Fall wegen der Probleme und Anforderungen, die das Manuka-Team lösen und erfüllen wollte, lohnen, aber Takua ist ein Hobby-Renderer, der auf etwas ganz anderes als Manuka abzielt. Der größte Nachteil von Shade-before-hit ist die Startzeit, die mit dem Voreinschalten der gesamten Szene verbunden ist. Diese Startzeit kann ziemlich groß sein, aber im Gegenzug kann die gesamte Renderzeit schneller sein, da das Path-Sampling effizienter wird. In einer Reihe von Workflows ist die Zeit bis zum vollständigen Rendern jedoch nicht annähernd so wichtig wie die Zeit bis zu einer minimalen Stichprobenanzahl, an der eine künstlerische Entscheidung über ein verrauschtes Bild getroffen werden kann. Darüber hinaus ist die volle Renderzeit weniger wichtig, solange sie sich in einem vernünftigen Rahmen bewegt. Takua hat derzeit eine schnelle Startzeit und erreicht schnell einen ersten Satz von Proben, und wir wollten dieses Verhalten beibehalten. Daraus resultierte die Frage: Gibt es in einer Shade-on-Hit-Architektur eine Möglichkeit, die eine konsistente Sichtweise von Shade-on-Hit auf die Welt zu simulieren, bei der Texturfilterentscheidungen von Path-Sampling getrennt werden?
Den Ansatz, den wir gefunden haben, besteht darin, die Auswahl der Mip-Ebene auf der Grundlage einer Metrik für den Weltraumabstand zur Kamera zu steuern, ohne jegliche Abhängigkeit vom eingehenden Strahl an einem bestimmten Trefferpunkt. Dieser Ansatz ist nicht einmal annähernd neu. In gewisser Weise ist dieser Ansatz wahrscheinlich die offensichtlichste Lösung von allen. Hier finden Sie einen kleinen Überblick darüber, wie wir die kamerabasierte Mip-Level-Auswahltechnik implementiert haben:
Die Rationalität für die Verwendung der engsten Differenzen in Schritt 1 besteht darin, zu gewährleisten, dass die Texturfrequenz für alle Pixel im Screen-Space Subpixel bleibt, auch wenn das bedeutet, dass wir einige Pixel mit einer höheren Auflösung im Mip-Bereich abtasten als jedes Pixel im Screen-Space, das wir ebenfalls akkumulieren. In diesem Fall ist es besser, mit unserer Mip-Level-Auswahl zu konservativ zu sein als mit der Auswahl eines zu niedrigen Mip-Levels die sichtbare Textur zu verschwimmen.
Takua verwendet den oben genannten Ansatz für alle Pfadtypen, einschließlich der Lichtwege in den verschiedenen bidirektionalen Integratoren. Da die Auswahl der Mip-Pegel ausschließlich auf dem Abstand zur Kamera basiert, ist für die Lichttransportintegratoren ein völlig einheitliches Weltbild gegeben. Dadurch ist Takua in der Lage, das Differentialproblem des Lichtweges zu umgehen, ähnlich wie es eine Shade-before-hit-Architektur kann. Es gibt einige spezielle Implementierungsdetails, die dadurch etwas kompliziert werden, dass Takua Unterstützung für mehrere UV-Sets pro Mesh hat.
Ergebnisse.
Wie gut funktioniert also die kamerabasierte Mipmap-Ebenenauswahl im Vergleich zu einem eher standardisierten Ansatz, der auf Pfad-Differenzen oder Stahlbreiten vom einfallenden Strahl basiert? Typischerweise arbeiten Mipmaps in einem Produktions-Renderer in Verbindung mit gekachelten Texturen, bei denen die Kacheln eine feste Größe haben. Daher ist die nützlichste Vergleichsmetrik, wie viele Texturkacheln jeder Ansatz im Laufe eines Renderings zugreift. Je mehr ein Ansatz auf höhere Mipmap-Ebenen zugreift, desto weniger sollten insgesamt auf Kacheln zugegriffen werden, da niedrigere Auflösungs-Mipmap-Ebenen weniger Kacheln haben.
Für das unidirektionale Path Tracing von der Kamera aus können wir vernünftigerweise erwarten, dass der kamerabasierte Ansatz weniger gut anschneidet als eine Pfad-Differenz oder Stahlbreitentechnik. Beim kamerabasierten Ansatz muss jedes Textur-Lookup einen Footprint verwenden, der ungefähr einem Pixel Footprint auf dem Bildschirm entspricht, während bei einem eher standardmäßigen raybasierten Ansatz die Footprints mit jedem aufeinanderfolgenden Bounce größer werden, was zu höheren Mipmap-Ebenen führt. Abhängig davon, wie aggressiv die Strahlbreiten bei diffusen und glänzenden Ereignissen vergrößert werden, können strahlengestützte Ansätze schnell die höchsten Mipmap-Ebenen erreichen und im Wesentlichen den größten Teil des Renderings nur für den Zugriff auf hohe Mipmap-Ebenen ausgeben.
Für bidirektionale Integratoren hat die kamerabasierte Technik jedoch den großen Vorteil, dass sie sowohl für Kamera- als auch für Lichtpfade vernünftige Mipmap-Ebenen bereitstellen kann, während die standardmäßig strahlenbasierten Ansätze auf das Point Sampling der niedrigsten Mipmap-Ebene für Lichtpfade zurückgreifen müssen. Infolgedessen können wir für bidirektionale Pfade erwarten, dass ein strahlenbasierter Ansatz irgendwo dazwischen liegen sollte, wie ein strahlenbasierter Ansatz im unidirektionalen Fall funktioniert und wie Point Sampling nur die niedrigste Mipmap-Ebene im unidirektionalen Fall funktioniert.
Als Ausgangspunkt wurde auch ein strahlenbasierter Ansatz mit einer relativ aggressiven, sich erweiternden Heuristik für glänzende und diffuse Ereignisse implementiert. Für die Waldszene aus der oberen Abbildung haben wir die folgenden Ergebnisse bei einer Auflösung von 1920×1080 mit 16 Samples pro Pixel erhalten. Wir verglichen unidirektionales Pfad Tracing von der Kamera und standardmäßige bidirektionales Pfad Tracing. Statistiken werden als Gesamtzahl der zugreifenden Texturkacheln geteilt durch die Gesamtzahl der Texturkacheln über alle Mipmap-Ebenen dargestellt. Je niedriger der Prozentsatz, desto besser:
Wie erwartet, greift der kamerabasierte Ansatz im unidirektionalen Fall auf etwas mehr Kacheln zu als der strahlengestützte Ansatz, und beide Ansätze übertreffen das Point-Sampling der untersten Mipmap-Ebene deutlich. Im bidirektionalen Fall greift der kamerabasierte Ansatz auf etwas mehr Kacheln zu als im unidirektionalen Fall, während der strahlenbasierte Ansatz irgendwo zwischen dem strahlenbasierten Ansatz im unidirektionalen und dem Point Sampling des niedrigsten Mipmap-Levels im unidirektionalen Bereich liegt. Was mich überrascht hat, ist, wie nah der kamerabasierte Ansatz im Vergleich zum strahlenbasierten Ansatz im unidirektionalen Fall war, zumal ich mich für eine ziemlich aggressiv erweiternde Heuristik entschieden habe.
Um zu veranschaulichen, auf welche Mipmap-Ebene zugegriffen wird, haben wir in Takua ein neues AOV implementiert, das Oberflächen Farben zuweist, basierend darauf, auf welche Mipmap-Ebene zugegriffen wird. Bei der kamerabasierten Auswahl der Mipmap-Ebene zeigt dieses AOV einfach an, auf welche Mipmap-Ebene alle Strahlen zugreifen, die einen bestimmten Punkt auf einer Oberfläche treffen. Jede Mipmap-Ebene wird durch eine andere Farbe dargestellt, mit Unterstützung von bis zu 12 Mipmap-Ebenen.
Im Allgemeinen sieht alles so aus, wie wir es in einem funktionierenden Mipmapping-System erwarten würden. Oberflächenpunkte, die weiter von der Kamera entfernt sind, greifen im Allgemeinen auf höhere Mipmap-Ebenen zu, und Oberflächenpunkte, die näher an der Kamera liegen, auf niedrigere Mipmap-Ebenen. Die Farne in der Vorderseite des Rahmens in der Nähe der Kamera greifen auf höhere Mipmap-Werte zu als der große gefallene Stamm in der Mitte des Rahmens, obwohl die Farne näher an der Kamera sind, da die Texturen für jedes Blatt extrem hochauflösend sind und die Farnblätter im Screen-Space sehr klein sind. Oberflächen, die unter starkem Blickwinkel von der Kamera aus betrachtet werden, neigen dazu, auf höhere Mipmap-Ebenen zuzugreifen als Oberflächen, die der Kamera zugewandt sind. Dieser Effekt ist am einfachsten auf den Felsen unten vor dem Rahmen zu sehen. Die interessante plötzliche Verschiebung der Mipmap-Ebene auf einigen der Baumstämme kommt von den Baumstämmen mit zwei verschiedenen UV-Sets. Der untere Teil jedes Baumstammes verwendet eine andere Textur als der obere Teil, und die Haupttexturen werden mit einer Mischmaske in einem anderen UV-Raum als die Haupttexturen gemischt, da die unterschiedliche Oberfläche teilweise von der UV-Parametrisierung abhängt, können verschiedene UV-Sets zu einem unterschiedlichen Auswahlverhalten der Mipmap-Ebene führen.
Takua wurde auch ein Debug-Modus hinzugefügt, der den Zugriff auf die Mipmap-Ebene pro Texturprobe verfolgt. In diesem Modus splittet der Renderer für eine bestimmte Textur in ein Bild die niedrigste erreichbare Mipmap-Ebene für jedes Texturbeispiel. Das Ergebnis ist eine Art Heatmap, die auf der untersten Mipmap-Ebene der Originaltextur überlagert werden kann, um zu sehen, welche Teile der Textur mit welcher Auflösung abgetastet werden.
Bisher hat sich ein kamerabasierter Ansatz zur Auswahl des Mipmap-Levels in Kombination mit einem reinen Point-Sampling an jeder Texturprobe in Takua sehr gut bewährt. Tatsächlich wurde die skandinavische Raumszene von Anfang dieses Jahres ebenfalls mit dem in diesem Beitrag beschriebenen Mipmap-Ansatz gerendert. Es gibt jedoch eine relativ einfache Art von Szene, die Takuas kamerabasierter Ansatz bei der Handhabung schwer versagt: die Refraction in der Nähe der Kamera. Wenn ein Objektiv direkt vor der Kamera platziert wird, das einen Teil der Szene deutlich vergrößert, kann eine reine Weltraummetrik für Filter-Footprints dazu führen, dass zu hohe Mipmap-Ebenen gewählt werden, was zu sichtbarer Texturunschärfe oder Pixelbildung führt. Es wurde bisher noch nichts implementiert, um diesen Fehlerfall zu lösen. Eine mögliche Lösung, um die nachgedacht wurde, besteht darin, zunächst eine Reihe von Strahlen aus der Kamera mit Hilfe der traditionellen Strahldifferenzialpropogation für spiegelnde Objekte zu verfolgen und die resultierenden Mipmap-Level in der Szene zwischenzuspeichern. Dann, während des eigentlichen Renderings, konnte der Renderer die kamerbasierte Metrik aus den nächstgelegenen N zwischengespeicherten Metriken vergleichen, um daraus abzuleiten, ob ein niedrigerer Mipmap-Level benötigt wird als der, den die kamerabasierte Metrik erzeugt. Ein solches System würde jedoch die Auswahllogik der Mipmap-Ebene erheblich verteuern, und es gibt eine Reihe von Implementierungskomplikationen zu berücksichtigen. Wir fragen uns, wie Manuka auch mit dem „Objektiv vor der Kamera“ umgeht, da das Shade-before-hit-Paradigma bei diesem Szenario aus den gleichen Grümdem ebenfalls scheitert.
Langfristig würden wir gerne mehr Zeit damit verbringen, nach einem auf Kovarianz-Tracing basierenden Ansatz zu suchen. Während Takua derzeit nur mit Point Sampling auskommt, wird die Filterung für andere Effekte, wie z.B. glänzende Mikrofacet-Materialien, viel wichtiger, und die Kovarianz-Tracing-basierte Filterung scheint die derzeit bekannteste Lösung für diese Fälle zu sein.
Vielen Dank für Ihren Besucg.