Freigeben über

Darstellen von PRT mit Texturen (Direct3D 9)

  • Artikel

Das PRTDemo-Beispiel und der PRTCmdLine-Simulator im DirectX SDK stellen Übertragungsvektoren an den Scheitelpunkten eines Gitters dar. Um das PRT-Signal genau darzustellen, kann dies Tessellationen erfordern, die für aktuelle Spiele möglicherweise unpraktisch sind. Die Darstellung von Übertragungsvektoren in Texturzuordnungen ist ein alternativer Ansatz, der unabhängig von der Gitterkomplexität die gleichen Datenkosten aufweist. Es gibt mehrere Möglichkeiten, mit der D3DX PRT-Bibliothek Übertragungsvektortexturzuordnungen zu generieren.

Vorberechnung von Übertragungsvektoren

Ein Ansatz wäre das Ändern der PRTDemo- und PRTCmdLine-Beispiele, um einen Übertragungsvektor an jedem Texel in einer Parametrisierung einer Oberfläche zu berechnen. Gehen Sie dazu folgendermaßen vor:

  1. Ändern Sie den Aufruf von D3DXCreatePRTEngine , um Texturkoordinaten aus dem Gitter zu extrahieren (ExtractUVs müssen TRUE sein).
  2. Ersetzen Sie D3DXCreatePRTBuffer-Aufrufe durch D3DXCreatePRTBufferTex mit derselben Texturgröße.

Mit Ausnahme von ComputeBounceAdaptive, ComputeSSAdaptive, ComputeSSAdaptive, ComputeSS Und ComputeDirectLightingSHAdaptive funktionieren alle ID3DXPRTEngine-Methoden mit texelspezifischen Simulationen. Während die Texturraumsimulation das richtige Ergebnis generiert, kann sie häufig recht langsam sein, da sie wahrscheinlich Übertragungsvektoren mit hoher Dichte berechnen wird.

Ein weiterer Ansatz besteht darin, eine adaptive PRO-Vertex-PRT-Simulation zu berechnen (mit Texturkoordinaten, die für die pro-Texel-Daten verwendet werden) und dann ID3DXPRTEngine::ResampleBuffer aufzurufen (unter Verwendung eines Ausgabepuffers, der mit D3DXCreatePRTBufferTex in der entsprechenden Auflösung erstellt wurde). Dies funktioniert mit allen D3DX PRT-Funktionen im SDK und kann oft viel effizienter sein als das direkte Berechnen eines Pro-Texel-Übertragungspuffers.

Laufzeitberechnungen

Wenn ein einzelner Cluster verwendet wird, können die Ergebnisse wie jede andere Textur gefiltert und mip zugeordnet werden, und der Pixel-Shader ist identisch mit dem Vertex-Shadercode, der mit PRTDemo ausgeliefert wird.

Wenn die Komprimierung mehrere Cluster generiert, können Sie die Daten nicht filtern oder mipmaps, da Clusteringindizes nicht kontinuierlich sind. Im Folgenden finden Sie einige Alternativen für die Verarbeitung von Daten mit mehreren Clustern:

  • Führen Sie die gesamte Filterung im Pixel-Shader selbst aus. Leider ist dies aus Leistungsgründen in der Regel unpraktisch.
  • Wenn es sich bei den Texturen um Nicht-Mip-zugeordnete Texturen mit niedriger Auflösung handelt (d. h. Lichtkarten), ist es höchstwahrscheinlich effizienter, die Beleuchtung direkt im Texturraum zu berechnen , in dem keine Filterung stattfindet, und das Objekt mit einer schattierten Textur zu rendern. Dies ist im Wesentlichen eine dynamische Lichtkarte, die vollständig auf der GPU erstellt wird.
  • Wenn ein Texturatlas verwendet wird (siehe Verwenden von UVAtlas (Direct3D 9)), können Sie die Szene manuell gruppieren, indem sich alle Übertragungsvektoren in einer verbundenen Komponente im Texturraum im gleichen Cluster befinden. Auf diese Weise können Sie die Textur filtern, da sich alle Texels, auf die zugegriffen wird, im selben Cluster befinden würden. Die Cluster-ID für ein bestimmtes Gesicht kann vom Scheitelpunkt-Shader weitergegeben werden.

Pixel-Shader verfügen über viel weniger konstanten Register, die nicht indiziert werden können, sodass sich der Pixel-Shader etwas vom Vertex-Shader unterscheidet. Das Speichern der Arbeit pro Cluster in einer dynamischen Textur mit niedriger Auflösung und die Verwendung von Texturlasten wäre die effizienteste Möglichkeit zum Rendern, wenn mehrere Cluster verwendet werden.

Vorcomputed Radiance Transfer

PRT-Demobeispiel

PRT Simulator (prtcmdline.exe)