[DX 10] Frage zu Deferred Renderer + Transparenz

[beuschl]

Hi

Ic spiele schon einige Zeit mit meinen Deferred Renderer herum und bin jetzt zu dem unangenehmen Punkt gelangt bei dem ich transparente Objekte einbauen will.

Das ist ja einer der großen nachteile bei einem deferred Renderer. Also hab ich mir überlegt den oftmals beschriebenen Ansatz umzusetzen, bei dem man zuerst die normale Geometry rendert und dann am Ende die transparenten Objekte mit normalen forward Rendering macht.

Soweit stellt das für meine Anforderungen nicht soo ein Problem da, weil ich eher sehr wenige transparente Objekte in meiner Szene haben werden (aber eben doch ein paar).

Meine Frage ist jetzt: Wie kann man diesen Ansatz umsetzen? Im speziellen hab ich das Problem mit meinem Tiefenbuffer. Also wenn ich jetzt nach meinem Deferred Render Pass ein Objekt rendere stimmt der Z-Buffer für dieses nicht, da ich ja die Tiefenwerte meiner Geometry im Deferred Renderer in ein Depth Rendertarget schreibe.
Hat jemand eine Idee/Ansatz wie ich das Problem lösen könnte?

[Aramis]

Ich verstehe das Problem nicht so ganz .. wenn du deine opake Geometrie in deine G-Buffer ausrenderst, hast du doch ganz normal den Tiefentest aktiviert und hast also hinterher ein perfektes z/w Abbild im Tiefenbuffer.

[beuschl]

ja schon. danach rendere ich die Lichter und füge den Light Buffer und G-Buffer zusammen.. hab also im Backpuffer das fertige Bild
Danach rendere ich ein transparentes Bild. Kann ich jetzt mein Depth RenderTarget vom G-Buffer verwenden um einen Tiefentest mit den transparenten Objekten zu machen?

und falls ja wie mache ich das? Weil

g_D3DDevice->OMSetRenderTargets(1, &engine->pRenderTargetView, engine->pDepthStencilView);

verlangt ja für den Depth Buffer ein DepthStencilView

[Krishty]

Hi,

Kann ich jetzt mein Depth RenderTarget vom G-Buffer verwenden um einen Tiefentest mit den transparenten Objekten zu machen?

Nein.

Der Grund, warum das Unsinn ist: Dein G-Buffer wäre viel ineffizienter als der gewöhnliche Tiefenpuffer, der extra zu diesem Zweck entwickelt wurde (und z.B. Z-Compression unterstützt, worauf dann weitere Optimierungen beim Early-Z-Culling aufbauen) und damit viel mehr Dreiecke in viel weniger Zeit beurteilen kann.

Da du den besseren, normalen Z-Buffer nahezu kostenlos mitgeliefert bekommst, solltest du den auch weiterhin benutzen.

Gruß, Ky

[beuschl]

mhm ist logisch

ich rendere jetzt meine Geometry mit aktivierten Z-Buffer in meinen G-Buffer (color, normal, depth renderTargets), danach das Licht (licht RT) ohne Z-Test und dann füg ich das colorRT und lichtRT zusammen auf dem backpuffer (Z-Test aktiviert)

Wenn ich jetzt ein objekt am Backpuffer rendere (ohne dem deferred renderer, also ganz normal) mit aktivierten Z-Buffer dann stimmt das ganze leider nicht. Also Sachen die hinter dem Objekt sein sollten schaun dann durchs Objekt durch usw.

Mache ich jetzt grundsätzlich was falsch an meiner vorgehensweise bzw. irgendwas spezielles beachten?

[Schrompf]

Das sollte so funktionieren. Du wirst wahrscheinlich irgendwo vergessen haben, eine ZBuffer-Einstellung zu entfernen/zu setzen. Die Projektionsmatrix, insbesondere die Near- und Far-Plane, sollte auch übereinstimmen. Und vermeide den ZBuffer-Discard-Flag bei der Device-Erstellung... ich weiß nicht, ob es den unter DX10 überhaupt noch gibt, aber unter DX9 hatte der besagt, dass bei Frame-Wechsel der ZBuffer-Inhalt gern weggeworfen werden darf. Und manche Treiber interpretierten das dann so, dass der ZBuffer bei jedem Rendertarget-Wechsel seinen Inhalt verloren hat.

Nebenbei: normalerweise rendert man die Lichtvolumen auch mit aktiviertem ZTest. Dann werden Pixel, die vor dem Lichtvolumen liegen und damit gar nicht vom Licht beeinflusst werden können, bereits frühzeitig ausgelassen. Das spart einiges an Performance.

[edit] Äh halt. Das stimmt doch nicht ganz so. Die korrekte Reihenfolge sollte sein:

a) GBuffer rendern. ZTest und ZWrite aktiv.
b) Lichter rendern. ZTest aktiv oder nicht, je nach Geschmackssache, aber kein ZWrite.
c) Kombination von GBuffer und Licht-Buffer. Kein ZTest, kein ZWrite.
d) Transparente Objekte mittels Forward-Renderer. ZTest aktiv, ZWrite nach Geschmackssache.

[Krishty]

Anmerkung am Rande: Ab D3D11 sollte man dieses Problem nicht mehr haben, dann kann man normal vor sich hin rendern und sich der gleichen Techniken bedienen wie bei Order-Independent-Transparency. Reduziert den nötigen Shader-Code und die Render-Pfade drastisch. Zumindest hat man mir das erzählt.

[beuschl]

directx11 werd ich so bald nicht benutzen unter anderem weil ich in nächster Zeit noch keine DirectX11 fähige Grafikkarte haben werde ;)

@Schrompf: danke für deine Erklärung. Ich rendere jetzt ein testobjekt nach dem Deferred Renderer und das ganze mit dem Z-Buffer haut jetzt hin. Das Objekt selber ist jetzt noch ncht transparentweil ichs erstmal so testen wollte. Weil ales funktioniert hat, hab ih mir gedacht: cool geht soweit alles, machen wir das Objekt also mal so halbtransparent.

Also hab ich im Shader einfach den Alphakanal der fertig berechneten Pixelfarbe auf pixelColor.a = 0.5f; gesetzt. Nur bewirkt das ganze nichts... :( (verwendete Textur im Shader hat einen AlphaKanal den ich auch brav mitsample). Ich weiß die Frage mag jetzt etwas eigenartig wirken, aber ich arbeite jetzt zum allerersten mal mit Transparenzen, Alpha Kanälen usw.

Ich mach wohl irgendwas falsch bzw geht das ganze wohl nicht so eifnach das ich einfach den alpha Wert des Pixels auf zb 0.5f setze

[Krishty]

Wie hast du die Blend-States gesetzt?

[Dirk Schulz]

Hi,

wäre das nicht auch eine Alternative:

http://diaryofagraphicsprogrammer.blogs ... erred.html ?

Dort wird die Transparenz im Pre-Pass eingebunden, ich habs mir jetzt aber nicht so genau angesehen, kann also nicht sagen, wie aufwendig das ganze ist.

Es gibt dazu auch ein Video, was sehr beeindruckend ist, wenn das Flimmern nicht wäre, aber das schiebe ich einfach mal auf die Kompression des Videos. ;)

Nur mal als Anregung.

Dirk Schulz

[beuschl]

@Khrishty: BlendState war das richtige Stichwort ;) hatt ich vergessen... es funktioniert nun *freu*

@Dirk Schulz: das ganze liest sich schon sehr interessant. Werd mir den link aufjedenfall mal für die Zukunft merken