HDRR: D3DFMT_A16B16G16R16F oder D3DFMT_A16B16G16R16F?
-
Hi Leute!
Ich mach mich derzeit etwas mit HDRR vertraut. Dabei ist mir aufgefallen, dass es 2 Formate gibt, die in Frage kommen.
Einmal das 64-Bit Format D3DFMT_A16B16G16R16F und das 128-Bit Format D3DFMT_A32B32G32R32F.Welches wird häufiger verwendet?
Welches wird häufiger unterstützt?Klar verbraucht das 64 Bit Format nur die Hälfte vom 128er. Aber da reicht auch die Genauigkeit?
Vieleicht sollte ich noch erwähnen, welche PP-Effekte ich vorhabe als HDR zu implementieren:
- Ambient Occlusion
- Tone Mapping
- Bloom
- Blur
In dieser Reihenfolge.
-
ich glaube du hast dich vertippt beim format, anyway. man benutzt die 16bit versionen. ja die reichen voll aus, in ganz seltenen faellen, z.b. direkt die sonne anschauend, kann es berechnungsfehler geben, aber sonst reicht es immer.
zu den effekten.
- Ambient Occlusion
gibt zig implementationen fuer AO, aber HDR braucht eigentlich keine davon.- Blur
braucht kein HDR- Bloom
- Tone Mapping
diese sollten HDR nutzen, bzw konvertiert tone mapping nur von HDR zu LDR bei den meisten spielen.
-
Vertippt? Nein, eigentlich nicht. ABGR@16F ist schon richtig. Zumindest spuckt die DX-Doku nichts von ARGB@16F aus.
Ist die Berechnung von AO (in meinem Falle will ich SSAO probieren) und Blur wirlich schneller, wenn "nur" mit LDR gerechnet wird?
-
Blaze schrieb:
Vertippt? Nein, eigentlich nicht. ABGR@16F ist schon richtig. Zumindest spuckt die DX-Doku nichts von ARGB@16F aus.
Einmal das 64-Bit Format D3DFMT_A16B16G16R16F
und das 128-Bit Format D3DFMT_A16B16G16R16F.sicher nicht vertippt?
Ist die Berechnung von AO (in meinem Falle will ich SSAO probieren) und Blur wirlich schneller, wenn "nur" mit LDR gerechnet wird?
SSAO verwendet nur den zbuffer,
blur ist schneller da halbe bandbreite.
-
Blaze schrieb:
Vertippt? Nein, eigentlich nicht. ABGR@16F ist schon richtig. Zumindest spuckt die DX-Doku nichts von ARGB@16F aus.
Seh den Zusammenhang zwar gerade nicht, aber schätze auch mal auf einen Tippfehler, da es D3DFMT_A32B32G32R32F nämlich sehr wohl gibt was dann 128 entsprechen würde.
-
Doch vertippt. Ihr habt Recht. Habs geändert.
Gut also Planänderung.
Ich würde dann ungefähr so vorgehen:
1.) D3DDevice ganz normal mit MultiSampling, BackBuffer und Z-Stencil-Buffer erstellen. Obwohl: eigentlich kann ich mir den ZSB hier sparen, da ich eh selber einen erstelle.
2.) Texturen für BackBuffer im 64-Bit-Format (HDR) und im 32-Bit-Format (LDR) erstellen, dazu noch 32-Bit Textur für ZSB. Dann ein Rendertarget-Surface (HDR, MS) und ein ZSB-Surface (LDR, MS).
3.) Die Surfaces einsetzen
4.) Scene rendern
5.) Mit StretchRect die HDR-Textur mit den Daten aus dem RT-Surface füllen. Das gleiche mit der ZSB-Textur und dem ZSB-Surface.
6.) die HDR-Textur runtersampeln auf eine Farbe. Leuchtkraft bestimmen und mit ToneMapping die HDR-Textur in die LDR-Textur rendern.
7.) Mit andere PP-Shadern (SSAO, Bloom, Blur) die LDR-Textur in den (offiziellen) BackBuffer rendern. Fertig!Lohnt es sich performance-technisch für das "bildschirmfüllende" Viereck einen Vertexbuffer anzulegen?