Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Mi Dez 25, 2024 18:47

Foren-Übersicht » Programmierung » OpenGL
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 11 Beiträge ] 
Autor Nachricht
BeitragVerfasst: Do Apr 16, 2015 23:31 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
Hallo allerseits!

Folgendes Szenario:
Ich rendere sehr viele große Partikel, die räumlich überhaupt nicht sortiert sind, ohne Alphablending, DepthTest und DepthMask sind an.
Für jedes Fragment werden Texturenwerte gefetcht und Berechnungen ausgeführt.

Frage 1: Werden all dieses Operationen (aus dem Fargmentshader) für jedes Fragment, wenn es über ein weiter entferntes gelegt wird, immer wieder neu ausgeführt, oder ist die Pipeline/Rasterisation so ausgelegt, dass ohne Alphablending weitere Operationen nur ausgeführt werden, wenn es das oberste Fragment (im gezeichneten Array/Buffer) ist, also der Tiefentest zuerst für alle ausgeführt wird. (Über Links zum Thema würd ich mich freuen)

Frage 2: Falls es so ist, dass immer wieder übereinander gezeichnet wird, wäre es dann nicht performanter, nur die benötigten Daten in ein FBO zu schreiben, und dann im Postprozess die Fragmente fertig zu malen (also deferred shading zu machen)?

Schöne Grüße,
Vinz

_________________
"Pixel, ich bin dein Vater."
-Darf Shader


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Apr 17, 2015 10:11 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Solange du im Fragment Shader nicht die Tiefe veränderst (via gl_FragDepth), kann der Early Depth Test greifen. Dann werden Fragmente raussortiert, bevor der Fragment Shader läuft.

Im Allgemeinen kommt der Tiefentest nach dem Fragment Shader, und v.a. greift der auch, wenn du Blending an hast. Also müsstest du, wenn deine Partikel transparenzen hätten, die nicht durch den Alpha Test auflösbar sind (also nicht nur 1 und 0 sind), deine Partikel sortieren, und zwar so, dass sie von hinten nach vorne gerendert werden.

Siehe auch: Depth Test, Transparency Sorting.

Zur zweiten Frage, das hängt sehr davon ab, wieviel Overdraw du tatsächlich praktisch hast, wie komplex dein Fragmentshader ist und wie groß der Anteil der Displayfläche ist, die deine Partikel abdecken. Gegebenenfalls ist nämlich die Füllrate, die du dann für das Fullscreen-Triangle brauchst teurer als einfach alles direkt zu rendern.

viele Grüße,
Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mo Mai 04, 2015 11:43 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2622
Wohnort: Berlin
Programmiersprache: Go, C/C++
1.)Der Tiefentest funktioniert auf die weise, wie du ihn ein stellst und du kannst auch für Transparente Objekte early discard verwenden aber will keiner die Probleme von falsch sortierten oder sich schneidenden Objekten haben und der Tiefentest kostet ja auch GPU Zeit.
Daher schaltet man den Tiefentest für Transparente Objekte ab.
Bei Hard Alpha kann man diesen aber verwenden, weil er den Pixel vollständig verdecken wird und glDepthFunc regelt die Funktionsweise vom Tiefentest.
Die GPU hat viele Shader Units, jede davon Rendert mehrere Triangles und in diesem Rasterisierungs Prozess fällt auch der Tiefentest. Dabei wird für das Triangle Fragment für Fragment durchlaufen und für jedes Fragment wird ein Tiefentest gemacht, wenn er aktiviert ist und ob der Fragment Shader ausgeführt wird hängt davon ab ob die mit glDepthFunc gesetzte Bedingung Wahr wird.
Wenn man also seine Partikel von Vorne nach hinten rendert, diese deckungsgleich übereinander liegen und man GL_GREATER gesetzt hat, dann wird nur für das erste Partikel gezeichnet, alle weiteren wird der Vertex Shader laufen und der Tiefentest für jedes Fragment aber kein Fragment Shader.
Dies will ich bei Hard-Cutout haben aber nicht bei alpha blending.
Da sortiere ich meine Partikel von hinten nach vorne, damit ein korrektes blending gemacht wird aber ich hab noch den overhead vom Tiefentest und weil ich weiß das er nicht greifen kann, schaltet man den in diesem Fall ab.

Wenn ich ein nicht Transparentes Mesh render, welches sehr viele Triangle hat und viele Ebenen, dann wird der Tiefentest sehr interessant.
Kommerzielle Middleware optimiert diese Meshes beim Laden oder im Pre-Prozess so, dass triangle von aussen nach innen gerendert werden. So verringert sich der overdraw, welcher je nach Fragment Shader sehr viel Performance kosten kann.
Overdraw, State change reduzieren und performante Fragment Shader sind das A&O bei Kommerziellen Middle Ware wie z.B. Scaleform, SpeedTree, Sympligon und co.

2.)Es gibt hier Lösungen wie Sand am Meer.
Es zeichnet sich aber ab, dass deine Vermutung die dominierende Lösung wird.
Man hat viel mit Deep Peeling rum probiert aber die Leistung ist stark GPU abhängig und trotzdem sehr limitiert.
Früher oder später bricht das Konzept ein, weil mehr Layer benötigt werden als die GPU effizient sortieren kann.
Daher gibt es für OpenGL4 einige Techdemos die auf MRT setzen und grob gesagt die Partikel Transparenz, Farbe sowie Hintergrund Farbe und Transparenz in mehrere Render Targets zeichnen und über ein 2. Pass dann erst den eigentlichen Fragment Shader laufen lässt. Das kommt dem Zero-Driver Overhead Konzept von OpenGL 4 und 5 entgegen, weil man stumpf alle Partikel rendert kann, ohne rücksprache mit der CPU haben zu müssen(z.B. State changes, Sortierung).

Bei Deep Peeling hat man das Problem, dass es recht komplex ist und man es trotzdem noch in die Knie bekommt.
Das Problem ist, dass man bei einem Komplexen Model, mit mehreren States entsprechend mehr Layer benötigt und damit mehr Listen verwalten muss. Das ganze ist nicht dynamisch, man muss also schon vorher wissen, was die maximale Layer Anzahl ist und wieviele Triangles pro layer passen. Wenn man mehr Triangle hat, dann muss man in weiteren Passes rendern und die Ergebnisse über die Passes kommunizieren. Tiled Varianten können das Problem reduzieren aber nicht lösen.
Wie man unschwer lesen kann, wird das ganze Konstrukt immer komplexer, je komplexer die eigene Szene werden soll.
AMD hatte diese Thematik los getreten(da gabs ne Mech Demo und Paper) und auch bis ins Extrema getrieben(mit tiled deep peeling) aber ich denke, dass Weighted OIT der bessere Weg ist.

Overview
Sorting/Depth Peeling
Weighted rendering

Transparente Triangle sind leider teuer, weil man für das blending noch mal auf den texel im Textur Target zugreifen muss um das finale Pixel zu zeichnen und hebt man das ganze auf das Level mit Multi Sampling blocken sich die die einzelnen Shader Units. Man kann erst das Fragment schreiben, wenn die nachbarn auch den Texel gelesen haben.
Shader Units arbeiten in 16x16 bzw. 32x32 Rastern laut Sympligon Paper, also passiert das nur an den Rändern.

Es lohnt sich bei Partikel Systemen Occlusion Query zu verwenden.
FrostBite Engine machte das per Software Rasterizer mit 1/4 der Render Auflösung und einem early kickout.
Die neue Engine soll das nun auf GPU mit extra Render Target und indirect render call können.

Bei Bäumen kann man z.B. Hard-Cutout verwenden.
Dabei wird das blenden ausgeschalten und mit discard Funktion(im Fragment Shader) kann man dann den Pixel überspringen.
SpeedTree und auch alle Spiele an den ich mit Entwickelt hab benutzen diese Variante.
Alpha to coverage ist die Multi Sampling optimierung.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Do Mai 07, 2015 10:50 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
Lord Horazont hat geschrieben:
Solange du im Fragment Shader nicht die Tiefe veränderst (via gl_FragDepth), kann der Early Depth Test greifen. Dann werden Fragmente raussortiert, bevor der Fragment Shader läuft.


Habe mit dem Early Depth Test rumexperimentiert, aber obwohl ich nicht gl_FragDepth geschrieben haben, gab es dann Probleme an Stellen, an denen Fragmente discarded wurden.

Bin mir grad nicht sicher, aber bedeutet glDepthMask(GL_TRUE) nicht auch, dass gl_FragDepth geschrieben wird?
Dass also der Early Depth Test nur Sinn macht, wenn der DepthBuffer nicht geupdated wird?

_________________
"Pixel, ich bin dein Vater."
-Darf Shader


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Do Mai 07, 2015 11:28 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
TAK2004 hat geschrieben:
Daher schaltet man den Tiefentest für Transparente Objekte ab.

Verstehe grad nicht, wie das gehen soll.
Wenn ich den Tiefentest abstelle, und dann alle transparenten Objekte rendere, passt es, aber nur wenn die besagten Objekte nach der Tiefe sortiert sind.
Nicht transparente (oder einfach andere) Objekte müssen aber schon davor geschrieben sein, wenn sie hinter den transparenten Objekten liegen, und dürfen erst danach geschrieben werden, wenn sie davor liegen.
Das wird aber z.B. kompliziert wenn ich ein Mesh als ganzes rendern will, wo ein Teil vor und ein Teil hinter den transparenten Objekten liegt, denn selbst wenn transparenten Objekte die Tiefenmaske aktualisieren, ist ja nur bekannt wo das vorderste transparente Objekt liegt...
Im Grunde müsste dann doch alles mehr oder weniger sortiert sein, und ich bräuchte evtl. gar keinen Tiefentest.

Was ich mich diesbezüglich auch gefragt habe:
Wenn ich zunächst alle soliden Objekte rendere mit Tiefenmaske.
Kann ich dann ohne Tiefenmaske aber mit Tiefentest transparente Partikel unsortiert mit additivem Blending reinzeichnen?
Vielen Dank für die ausführlichen Antworten jedenfalls, muss das erst mal verdauen.

_________________
"Pixel, ich bin dein Vater."
-Darf Shader


Zuletzt geändert von Vinz am Do Mai 07, 2015 16:53, insgesamt 1-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Do Mai 07, 2015 11:40 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
Nachtrag: Bin mir nicht sicher, ob additives Blending der richtige Ausdruck/Blendmodus ist.
Ich möchte mit Partikeln quasi inhomogenen Nebel/Dunst in die Szene reinzeichnen, und zwar in einem großen Bereich mit sehr unterschiedlichen Konzentrationen, und dass natürlich so günstig wie möglich.

_________________
"Pixel, ich bin dein Vater."
-Darf Shader


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Do Mai 07, 2015 14:54 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Nov 08, 2010 18:41
Beiträge: 769
Programmiersprache: Gestern
Hi, wenn du es über Shader lösen willst ist es eigentlich sehr einfach. Du kannst zum Beispiel erst einmal deine komplette Szene rendern und dabei den Tiefenpuffer in einer Low-Res Textur abspeichern (macht sich besser wenn du weiche Übergänge etc. haben willst). Sobald alles fertig ist schaltest du alle Tiefenpuffer Funktionen ab (also schreiben und Test) und zeichnest deine Partikel. Im Shader kannst du nun die Tiefe deines Nebelpixel mit der des Tiefenpuffer vergleichen.... Im Prinzip ist es genau das gleiche wie Deferred Shading mit Tiles. Sortieren musst du jetzt nur noch die Partikel die kein Blending haben sollen.

_________________
Meine Homepage


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Do Mai 07, 2015 16:07 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
yunharla hat geschrieben:
Hi, wenn du es über Shader lösen willst ist es eigentlich sehr einfach. Du kannst zum Beispiel erst einmal deine komplette Szene rendern und dabei den Tiefenpuffer in einer Low-Res Textur abspeichern […] Im Shader kannst du nun die Tiefe deines Nebelpixel mit der des Tiefenpuffer vergleichen.... Im Prinzip ist es genau das gleiche wie Deferred Shading mit Tiles. Sortieren musst du jetzt nur noch die Partikel die kein Blending haben sollen.
Wo ist der Unterschied zu aktiviertem Tiefentest aber deaktiviertem Tiefenschreiben?

Vinz hat geschrieben:
Nachtrag: Bin mir nicht sicher, ob additives Blending der richtige Ausdruck/Blendmodus ist.
Ich möchte mit Partikeln quasi inhomogenen Nebel/Dunst in die Szene reinzeichnen, und zwar in einem großen Bereich mit sehr unterschiedlichen Konzentrationen, und dass natürlich so günstig wie möglich.
Ich glaube das ist, wenn dein Nebel nicht leuchtet, kein additives Blending, und auch nicht kommutativ. Das müsste man aber am Besten einfach mal ausprobieren ob’s aus irgendeinem Blickwinkel bei unsortierten Partikeln merkwürdig aussieht.

Ansonsten könntest du bei solchen Anwendungsszenarien auch darüber nachdenken, im Shader zu Raytracen. Je nach Anzahl der Partikel und Skala der Inhomogenität deines Nebels könnte das Performanter sein – vor allem, wenn ein Großteil der Inhomogenität zufällig ist und daher im Shader gut ohne Daten approximiert werden kann.

viele Grüße,
Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Mai 08, 2015 11:31 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
yunharla hat geschrieben:
...Sortieren musst du jetzt nur noch die Partikel die kein Blending haben sollen.

Wieso das? Ohne Blending hat man doch den Vorteil, dass man bei aktiviertem Tiefentest nicht sortieren muss.
Ich habe mir also gedacht, es ist am sinnvollsten, erst alles nicht-transparente mit Tiefenmake und Tiefentest zu zeichnen, und dann alles Transparente ohne Tiefenmaske, und unsortiert, wenn der Blendmodus es zulässt.

_________________
"Pixel, ich bin dein Vater."
-Darf Shader


Zuletzt geändert von Vinz am Fr Mai 08, 2015 12:02, insgesamt 1-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Mai 08, 2015 11:53 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
Vinz hat geschrieben:
TAK2004 hat geschrieben:
Daher schaltet man den Tiefentest für Transparente Objekte ab.

Verstehe grad nicht, wie das gehen soll.
Wenn ich den Tiefentest abstelle, und dann alle transparenten Objekte rendere, passt es, aber nur wenn die besagten Objekte nach der Tiefe sortiert sind.
Nicht transparente (oder einfach andere) Objekte müssen aber schon davor geschrieben sein, wenn sie hinter den transparenten Objekten liegen, und dürfen erst danach geschrieben werden, wenn sie davor liegen.
Das wird aber z.B. kompliziert wenn ich ein Mesh als ganzes rendern will, wo ein Teil vor und ein Teil hinter den transparenten Objekten liegt, denn selbst wenn transparenten Objekte die Tiefenmaske aktualisieren, ist ja nur bekannt wo das vorderste transparente Objekt liegt...
Im Grunde müsste dann doch alles mehr oder weniger sortiert sein, und ich bräuchte evtl. gar keinen Tiefentest.

Was ich mich diesbezüglich auch gefragt habe:
Wenn ich zunächst alle soliden Objekte rendere mit Tiefenmaske.
Kann ich dann ohne Tiefenmaske aber mit Tiefentest transparente Partikel unsortiert mit additivem Blending reinzeichnen?
Vielen Dank für die ausführlichen Antworten jedenfalls, muss das erst mal verdauen.


Ich nehms zurück, denke jetzt weiß ich, wies geht.
Den Tiefentest tranparenter Objekte auf transparente Objekte abstellen sollte kein Problem sein, wenn man alles andere schon zuvor gerendert hat.
Ob man diese sortieren muss, hängt wohl vom Blendmodus ab, und davon, ob die Farben der transparenten Objekte sich unterscheiden.
Manchmal sieht man den Wald vor lauter Bäumen nicht...
Wenn mans aber ganz genau nimmt, reicht das Sortieren in manchen Fällen auch noch nicht, weil sich die sortierten Polygone wiederum überschneiden können, wenn sie nicht parallel zueinander sind.

Grüße,
Vinz

_________________
"Pixel, ich bin dein Vater."
-Darf Shader


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Mai 08, 2015 12:18 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Nov 08, 2010 18:41
Beiträge: 769
Programmiersprache: Gestern
Hi, Vorweg deine Reihenfolge funktioniert ohne Probleme. Quake machte es genauso. Vielleicht gibt es aber noch bessere Wege wenn man erweiterte Effekte haben will... Stichwort Beleuchtung und co.

Zu der Sache mit den Tiefentest:
Das hängt ganz davon ab was du machen willst. Ich habe es in meinen Beispiel deaktiviert weil es gerade bei Nebel und Rauch oft zu harten Kanten kommen kann wenn sich Objekte schneiden. Das Beispiel nutzt stattdessen eine Tiefentextur, damit man sich hier selbst etwas bauen kann :)

Zur Sortierung:
Das ist ein bisschen Tricky. In den meisten Fällen reicht es aus wenn du deine Alphaoberflächen und Partikel nach Typ sortierst. Auf diese Weise kannst du dann zum Beispiel erst den Fleck auf dem Boden, dann die Explosion und zum Schluss den Rauch zeichnen...

Wenn nun aber zwei Explosionen vorkommen dann sollte man schon dafür Sorgen das diese nicht verdecken. Stell dir einfach vor du zeichnest zuerst den vorderen Sprite und dann kommt dahinter noch einer.... das kann sehr schnell Blöd aussehen wenn man einfach in den Depthbuffer zeichnet ... muss aber nicht :P

_________________
Meine Homepage


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 11 Beiträge ] 
Foren-Übersicht » Programmierung » OpenGL


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 11 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.038s | 16 Queries | GZIP : On ]