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

Aktuelle Zeit: Fr Mär 29, 2024 08:16

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



Ein neues Thema erstellen Auf das Thema antworten  [ 18 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Autor Nachricht
BeitragVerfasst: Sa Aug 15, 2015 09:23 
Offline
DGL Member

Registriert: Sa Apr 14, 2012 14:28
Beiträge: 52
Programmiersprache: c++
Hallo zusammen,

derzeit versuche ich Tesselation sinnvoll in meine kleine Engine einzubauen, aber es gibt da ein par fragen die mir im Kopf rum schwirren.

Zunächst einmal, wann sollte ich Teselation einsetzen und wann eher einen Ansatz wählen, der auf Meshes mit unterschiedlichem LOD setzt? Nehmen wir z.B einen Zylinder: Wenn ich mir den umschlossen von einem Würfel vorstelle, kann ich jeweils vier rechteckige Patches mit 4 Vertices nehmen um die Seitenfläche zu rendern und jeweils ein rechteckiges patch für Boden und Deckel. Haken bei der Sache ist: ich brauche 2 Draw-Calls um zwischendurch die subroutine zu ändern, die die neuen Vertices platziert. Nehme ich einfach Meshes mit untershiedlichem LOD brauche ich nur einen Draw-Call, habe aber wesentlich mehr Speicherbedarf.

Nächste Frage wäre eher zur Programm-Struktur: Angenommen ich habe ein Objekt, das sowohl auf Quad- als auch Triangle-Patches setzt und gleichzeitig noch unterschiedliche Anzahl Vertices per patch braucht. Wenn ich das richtig verstanden habe, sind diese beiden Attribute innerhalb eines Programmes nicht änderbar (layout-qualifier). Das heißt ich muss jedes Mal zu einem Programm wechseln, das eigentlich genauso aufgebaut ist wie alle anderen und sich nur in der Tesselation stage unterscheidet. Wenn ich also eine einheitliche Szene rendere, brauche ich statt einem Programm nun mehrere. Wie handhabt ihr das üblicherweise? Gruppiert ihr eure Programmemit gleicher Funktionalität einfach in einem Container und wählt dann daraus, je nach benötigter Tesselation, oder gibt es da einen eleganteren weg? Sortiert ihr vorher noch die zu rendernden Objekte nach benötigtem Programm oder switcht ihr einfach Programme wie es halt eben grade kommt?

MfG

Der Troll


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Sa Aug 15, 2015 10:40 
Offline
DGL Member

Registriert: Do Dez 29, 2011 19:40
Beiträge: 421
Wohnort: Deutschland, Bayern
Programmiersprache: C++, C, D, C# VB.Net
Zwei Vorteile von Tesselation über LOD sind...
  1. Speicherbedarf (also auch Bandbreite)
  2. Keine Sprünge - zwischen Tesselationsstufen kann interpoliert werden

Ja, Shader-Programme werden in der Regel sortiert. Das sind mit die teuersten State Changes, die Draw Calls sollten da also sowieso im Schatten der Shader-Programm-Statewechsel verblassen.

Ich würde an deiner Stelle mich entweder für Dreiecke oder Quads entscheiden, diese aber nicht mischen. Da sich Quads sehr einfach in 2 Dreiecke umwandeln lassen, würde ich diese Option als erstes versuchen.


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Sa Aug 15, 2015 10:53 
Offline
DGL Member

Registriert: Sa Apr 14, 2012 14:28
Beiträge: 52
Programmiersprache: c++
Vielen Dank für die Antwort.

Ich werde heute mal versuchen einen Zylinder allein mit Triangle Patches zu rendern. Interessant wird hier die Mantelfläche, da dort so tesseliert werden muss, dass alle senkrecht verlaufenden Kanten parallel zur Zylinderachse sind, andernfalls, sieht die silouette komisch aus. Mal gucken ob ich das hinkriege. Die Ergebnisse werde ich dann mal posten und mögliche weitere Fragen stellen.

MfG

Der Troll


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Sa Aug 15, 2015 16:32 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Tesselierung kann auf 2 Arten in OpenGL erreicht werden und wären Tesselation Shader oder Geometry Shader.
Tesselierung verwendet man sehr häufig in verbindung mit Height-/Displacemen-Maps um ab einer bestimmten nähe zusätzliche Details ein zu blenden, die im LOD garnicht erst erfasst werden.
Wenn man Tesselierung im LOD einsetzt ist es zu empfehlen nur in der letzten Stufe zu tun und zwischen den Stufen ledeglich zu morphen.
Tesselation Shader bringen eine Basislast mit und je mehr man tesseliert eine zusätzliche Last.

Im Terrain Rendering benutzen einige Engines Tesselation Shader aber meistens nur als zusatzt und kleine oder sehr moderne Engines vollständig.
Das Problem am Tesselation Shader ist, dass er in OpenGL 2 nur als Extension vor liegt und später in den Core wanderte.
Spielefirmen, die ein großes Publikum abdecken wollten, haben daher es nur als Zusatz und nicht als Grundlage implementiert.
Terraindaten sind groß und LOD Stufen sind Teuer zu berechnen und machen die Tool-Pipeline langsamer und komplexer, daher ist eine Laufzeit LOD mit Tesselation Unit viel einfacher.
Ich hatte in mein Letzten Job mit 128kx64k Höhenmaps gearbeitet, die aber wegen kompatibilität LODs generieren und morphdaten berechnen musste.
Das erzeugen der Heightmap hat schon auf mehreren Rechnern mehrere Stunden gebraucht und dann das LOD erzeugen, vertices und morphdaten für heightmap pro Detailstufe raus exportieren hat nochmal solange gedauert.
Also brauchte eine Änderung in der Welt einige Stunden, bis man sie im Spiel angucken konnte oder man hat nur ein Teil geupdated und dann halt Kaputte Kachelübergänge in Kauf genommen(bis das ganze durch war).
Mit einem Tesselation Shader kann man sich die Hälfte der Arbeit sparen, weil man keine LODs und meshes mehr raus exportieren muss.
Civilization 5 hat ein Paper zu Tesselation Shader und Terrain generierung veröffentlicht, wo ziemlich genau auf die Vor- und Nachteile von Tesselation Shadern eingegangen wird.
Ich glaub das liegt im GDC 2014 Vault.

Es gab einige Bestrebungen Tesselation Shader in 2D Rendering von Bezierkurven zu benutzen und in ID Tech 5 konnte man auch 3D den Software Tesselator(wenn die Extension nicht verfügbar ist) und Hardware Tesselator in Aktion sehen.
Im 2D Bereich hab ich es nicht mehr gesehen, in Papers wurde es als ineffizient getestet und im 3D Bereich mh, es ist eher von Artist Seite rar, dass die mit Shapes arbeiten, statt Trianglesuppen und so gut ist der Support bei den Engines auch ned.
Ein vollständig auf Nurbs, Bezier, Splines und wie sie alle sich nennen zu bauen ist von großen Vorteil.
Man spart zum einem Speicherplatz und man ist Qualitätsunabhängig, wie man es auch von SVG kennt.
Der Nachteil ist, dass man Software oder Hardware Tesselation braucht und dieser ein Basislast hat, welche bei hohen Drawcalls zu Problemen führen kann.
Tesselation kann auf der GPU erstmal nicht parallelisiert werden, er ist seriell(skaliert schlecht) und erst wenn er durch ist kann die geometry parallel modifiziert werden(skaliert gut).
Daher sollten Tesselation Shader kurz sein und möglichst Berechnungen auf dem Vertex Shader passieren.
Es ist kniffelig, ab welchen Punkt ist die Berechnung von z.B. Position so komplex ist, dass es sich lohnt es in den einmal ausgeführten Tesselation Shader zu verladen und im Vertex Shader nur noch kleine Operationen zu haben oder muss ich die Komplexe Berechnung in den Vertex Shader verlagern, weil diese zu stark Vertexbezogen ist, dass eine parallele Berechnung besser ist.
Ich hab das in der Regel gebenchmarkt, weil die Resultate nie Sinn ergeben haben.

Geometry Shader können Effizienter als Tesselation Shader sein, wenn es um den Trianglecount geht aber Tesselation Shader sind fest vergossen und daher auch wieder schneller beim erzeugen von Triangle.
Hier hab ich das gleiche beobachtet, so ziemlich jede Vermutung von mir hat im Profiling ein anderes Ergebnis gehabt.

Man kann beim Tesselieren nicht zwischen den Arten wechseln, weil dann die Kanten nicht mehr zueinander passen, man hat auch in der Regel mehr Triangle als man braucht, einfach um eine Hardware Tesselierung schnell über die Bühne zu bekommen.

Ich render in der Regel wie folgt.
1)Z-Pass
2)Deferred/Forward Color Pass
-erst opaque dann transparent
3a)Post-Processing Pass
3b)UI Pass
4)zusammen führen der FBOs

Sortieren tu ich dann wie folgt.
1)ignorier alpha und render wie es kommt
2)sortier nach transparenz
-dann sortiere transparente auf Z-Achse(wenn man OIT hat dann kann man sich das sparen)
-dann alle nach Program Objekt(hier versuch ich immer zu optimieren)
3a)per logik fest gelegt
b)sortier nach Program Objekt(alles ist aktuell Transparent)
4)per logik fest gelegt

edit:
Man kann ein Tesselation Shader wie ein ThreadPool und ein Main Thread betrachten.
Man lastet ein 8Kern System nicht Effizient aus, wenn man ein Logik Prozessor(Main Thread) hat und dann diverse Jobs in den Threadpool feuert.
Das war das Größte Problem von der PS3, die ein Logik Prozessor und 6(eigentlich 7) Rechen Prozessoren hatte.
Man kann einfach nicht gut Arbeit verteilen, wenn man ein Zeitbudget hat und nicht weiß wielange die Task im einzelnen brauchen.
Geht man über das Zeitbudget, dann merkt man es in einem FPS drop/lag und liegt man drunter hat man Leistung verschwendet.
Der Main Thread wartet, bis alle Jobs erledigt sind und geht dann zum nächsten Frame über und nimmt die verlorende Zeit auch mit in die Mainloop, da der ja warten musste.
Das gleiche hat man beim Tesselation Shader, je länger man Zeit in der Emit Schleife verbringt, des so länger verbringt man im Tesselation Shader und blockiert den nächsten Render-Call.

_________________
"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: So Aug 16, 2015 23:12 
Offline
DGL Member

Registriert: Sa Apr 14, 2012 14:28
Beiträge: 52
Programmiersprache: c++
Danke für deine sehr ausführliche Antwort. So ganz hinterher gekomment bin ich ehrlich gesagt aber nicht überall. :mrgreen:

Bin halt nur nen hobby-programmierer. Aber auf deine Anmerkungen hin bezüglich der schlechten Parallelisierung der Tess-Shader werde ich auf jeden Fall mal gucken, dass ich alle Berechnungen die gehen in Vertex- und Geometrie shader verteile und das dann mal benchmarken. Würd mich interessieren wieviel das ausmacht.

Denke ich werd so viel mit Tesselation arbeiten wie es geht. Macht schon irgendwie Spaß einem Laien erklären zu können, dass die Kugel, die er grade sieht, eigentlich ein Würfel ist. :mrgreen: Bei externen models muss ich aber vermutlich wieder ganz ordinäre Triangles verarbeiten.

Das rendern eines tesselierten Zylinders klappt nun schon fast. Soll heißen, ich kann Mantel- als auch Deckflächen vernünftig rendern. Problem ist grad nur die noch nicht vollständig implementierte, automatische Positionierung in meiner Engine, sodass die Teile etwas mühsam zusammen zu fügen sind. Sobald das klappt, poste ich mal ein paar Bilder und etwas Code.

Habe mich nun übrigens dazu entschieden hauptsächlich quads als Patches zu verwenden, da ich es mit triangles nicht hinbekommen habe, eine saubere Silouette für Kurven in nur einer Raumrichtung zu erzeugen. Wenn ich mal triangle patches rendern muss, wird halt nach benötigtem Programm sortiert.

MfG


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mo Aug 17, 2015 10:44 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
Der Troll hat geschrieben:
Denke ich werd so viel mit Tesselation arbeiten wie es geht.

Ich würde Dir das Gegenteil empfehlen!
1. Wegen Kompatibilität: Vielleicht willst Du mal auf einer anderen Hardware deponieren (Handy, PlayStation, ... ). Dann darfst Du alles nochmal machen.
2. Weil es kompliziert ist, und somit nochmals Zeit frisst.

3. Weil es im Grunde sau langsam ist! Vor allem, wenn Du viele Patches hast, es lohnt sich meiner Meinung nach nur, wenn du ein paar Objekte hast, die dann massiv tesseliert werden müssen.
Für Terrains etc. ist z.B. Projected Grid viel besser.
Der Troll hat geschrieben:
Macht schon irgendwie Spaß einem Laien erklären zu können, dass die Kugel, die er grade sieht, eigentlich ein Würfel ist. :mrgreen:

Studier irgendwas Geisteswissenschaftliches, da brauchst Du bloß ein paar Wörter auswendig lernen, um deinen Gesprächspartner zu beeindrucken ;)

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


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mo Aug 17, 2015 12:45 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Vinz hat geschrieben:
3. Weil es im Grunde sau langsam ist! Vor allem, wenn Du viele Patches hast, es lohnt sich meiner Meinung nach nur, wenn du ein paar Objekte hast, die dann massiv tesseliert werden müssen.
Für Terrains etc. ist z.B. Projected Grid viel besser.

Für normales Terrain rendering gibt es diverse Möglichkeiten neben Tesselation, die effizienter sind aber mit steigende Größe ineffizienter gegenüber Tesselation Shader werden(wegen LOD).
Beim rendern von ganzen Planeten ist allerdings nen Tesselation Shader besser geeignet, man kann dann ein Cube mit Quad Tesselation und Heightmaps bzw. Prozedurale Funktionen füttern.

_________________
"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: Mo Aug 17, 2015 14:09 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
TAK2004 hat geschrieben:
Vinz hat geschrieben:
3. Weil es im Grunde sau langsam ist! Vor allem, wenn Du viele Patches hast, es lohnt sich meiner Meinung nach nur, wenn du ein paar Objekte hast, die dann massiv tesseliert werden müssen.
Für Terrains etc. ist z.B. Projected Grid viel besser.

Für normales Terrain rendering gibt es diverse Möglichkeiten neben Tesselation, die effizienter sind aber mit steigende Größe ineffizienter gegenüber Tesselation Shader werden(wegen LOD).
Beim rendern von ganzen Planeten ist allerdings nen Tesselation Shader besser geeignet, man kann dann ein Cube mit Quad Tesselation und Heightmaps bzw. Prozedurale Funktionen füttern.


Gebe zu, dass es Fälle gibt, wo es schon sehr praktisch ist, finde aber, dass die Nachteile meistens überwiegen.
Hier wird übrigens ein Plantetenrenderer mit Projected Grid erklärt:
https://www.youtube.com/watch?v=xtFxDCJE-0Y

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


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mo Aug 17, 2015 15:41 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Vinz hat geschrieben:
TAK2004 hat geschrieben:
Vinz hat geschrieben:
3. Weil es im Grunde sau langsam ist! Vor allem, wenn Du viele Patches hast, es lohnt sich meiner Meinung nach nur, wenn du ein paar Objekte hast, die dann massiv tesseliert werden müssen.
Für Terrains etc. ist z.B. Projected Grid viel besser.

Für normales Terrain rendering gibt es diverse Möglichkeiten neben Tesselation, die effizienter sind aber mit steigende Größe ineffizienter gegenüber Tesselation Shader werden(wegen LOD).
Beim rendern von ganzen Planeten ist allerdings nen Tesselation Shader besser geeignet, man kann dann ein Cube mit Quad Tesselation und Heightmaps bzw. Prozedurale Funktionen füttern.


Gebe zu, dass es Fälle gibt, wo es schon sehr praktisch ist, finde aber, dass die Nachteile meistens überwiegen.
Hier wird übrigens ein Plantetenrenderer mit Projected Grid erklärt:
https://www.youtube.com/watch?v=xtFxDCJE-0Y

Interessant.
Ich weiß noch als NVidia mit ihrer Wasserdemo das erstmal diese Technik vorgestellt hat und es wegen einiger Nachteile auch nicht weiter ausgebaut hat.
Die Nachteile waren folgende:
-fehlerhafte schattierung, weil die Edge quer durch das Quad immer gleich ausgerichtet ist und sich nicht immer mit der Neigung in der Heightmap deckt
-mesh zittern auch aus den gleichen grund
-schlechte verteilung der Triangle im entfernten und nahem Bereich(Lösbar in dem man zur Kamera hin in jeder reihe weitere Quads packt und das ganze auf Screenview staucht)
-skaliert schlecht, weil für die Projektion sehr viele texturzugriffe gemacht werden müssen(je höher man das projektionsmesh auflöst, des so schlimmer)
-funktioniert sehr schlecht mit mehreren Shadern
Vorteile:
-Konstante Last(sehr wichtig auf Konsolen und Mobile Geräten)
-Sehr einfach zu implementieren und Speichereffizient
-Funktioniert mit ziemlicher alter Hardware(mit OpenGL, D3D braucht sehr moderne, weil deren Vertexshader früher nicht auf Texturen zugreifen durften)

Das größte Bottleneck in Spielen ist der Speicherzugriff, weil viele Texturen und Framebuffer Operationen laufen, dann kommt Füllrate und dann Vertex Durchsatz.
Die Projektion erhöht die Last auf den Speicherbus und Tesselation auf den Vertex Durchsatz.
Von Generation zu Generation doppelt sich in etwa der Vertexdurchsatz aber bei Speicher ist das viel schwerer und teurer und deswegen skaliert der eher gering zwischen den Generationen.
Ausnahme war der jetzige Wechsel von AMD auf HBM und NV macht den wechsel im Q1 kommenden Jahres aber selbst HBM hat die Bandbreite nicht verdoppeln können aber die Zugriffszeit ~12-15x schneller gemacht.

Daher wird auch ein Tesselation Shader mit jeder neuen Generation schneller werden im Vergleich zur Projektion.
Frostbite Engine benutzt für Battlefield z.B. 2 Heightmaps(Terrain Height und Destruction Height) und ChunkLOD.
Im letzten Projekt, wo ich gearbeitet hatte, haben wir ChunkLOD mit einem Höhenmesh und morhping verwendet.
Der große unterschied zwischen Tesselation und Heightmap zu Höhenmesh liegt in der Beschaffung der Höhen-Daten.
Die ersten beiden nutzen Texturen und letztes nutzt ein VBO und belastet nie die Texture-Units.

In meinen never ending Tech-Prototypen arbeite ich an folgender Variante.
Höhenmesh wird aus Wavelet basierter Textur generiert und ein Tesselation Shader bringt Prozedural/Detailmap weitere feinheiten.
Es liegt in der Natur diverser Wavelets, schon die einzelnen LOD Level zu enthalten aber trotzdem die gleiche Datengröße zu haben.
Daher ist es recht schnell möglich eine LOD-Stufe von den benötig Ausschnitt zu bekommen und in ein Mesh um zu wandeln.
Der Vorteil ist, dass man die CPU und Arbeitsspeicher einmal auslastet und nicht wie bei Heightmaps jeden Frame.
Um sinnvoll zu morphen und damit ploppen zu vermeiden hatten wir ein delta mit reingequetscht und man konnte dann in beide Richtungen von 0.5 morphen.
Das zusätzliche hinzufügen von Detail will ich wie die Jungs von Outerra machen, die das Mesh hoch tesselieren und dann über Mathematische Funktionen und/oder Lookuptables und Shader weiteres detail generieren.

Prinzipiell empfehle ich mal Outerra dev blog, Präsi und vieleicht folgendes Buch kaufen und zu lesen.
http://www.virtualglobebook.com/

_________________
"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: Mo Aug 17, 2015 16:22 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
Nicht schlecht dieses Outerra.
Habe mal etwas mit Proland rumgespielt, ist quasi sowas wie Outerra, etwas weniger ausgereift vielleicht, aber mit Projected Grid und der code ist verfügbar.
Finde das Wasser sieht da echt in Ordnung aus, vor allem bei der Performance (https://www.youtube.com/watch?v=2AVh1x-Uqjs),
konnte eingentlch bei testen auch kaum Artefakte erkennen.

TAK2004 hat geschrieben:
Die Projektion erhöht die Last auf den Speicherbus...

Wieso das? Wenn man ein Mesh aus dem Screenspace auf eine Ebene am Boden projiziert, sind das doch allerhöchstens n paar Multiplilkationen.

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


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mo Aug 17, 2015 16:23 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
...pro Vertex natürlich.

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


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mo Aug 17, 2015 18:26 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Vinz hat geschrieben:
Wieso das? Wenn man ein Mesh aus dem Screenspace auf eine Ebene am Boden projiziert, sind das doch allerhöchstens n paar Multiplilkationen.

Also ich kenne das verfahren nur über cone-raytracing.
Zeichne die Hüllkörper im Z-Pass.
Zeichne alle anderen Sachen im Z- und Color-Pass.
Zeichne ein Festes Screenspace Grid im Color-Pass.
Für jedes Vertex ein cone-raycast um uv koordinaten zu finden, dann ein texture lookup auf die heightmap und bestimmen ob der punkt im grid nicht trifft und discarded wird oder die uv coords übernommen werden.
Der Fragment Shader ist ein normaler.

_________________
"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: Di Aug 18, 2015 10:34 
Offline
DGL Member

Registriert: Do Dez 29, 2011 19:40
Beiträge: 421
Wohnort: Deutschland, Bayern
Programmiersprache: C++, C, D, C# VB.Net
Ich habe bei meinen Terrainrenderer auch überlegt Tesselation zu nutzen, wenn es verhanden ist. Nach etwas überlegen kam ich aber zu dem Entschluss, dass man mit etwas mehr Arbeit eigentlich den selben Effekt selber hinbekommt (allerdings keine Planetenansicht). Die Höhen-/Texturinformation befindet sich in einem Vertex Buffer. Die X und Z Koordinate wird nicht gespeichert sondern im Shader aus der gl_VertexID erzeugt. Ich rendere mein Terrein in 256² Chunks die sich alle den selben Indexbuffer teilen. Darin befindet sich ein optimiertes Triangle Strip mit 16 Bit Indices. Für LOD tausche ich einfach nur den Index Buffer auf einem, der weniger auflöst ist und Vertices überspringt. Durch die Caching-Geschichte wäre es vielleicht auch noch eine Idee, dass man zu interpolierten Vertexdaten zugreift, weil die dann kontinuierlich vorliegen würden. Den Übergang zwischen den LOD-Stufen erreiche ich mit Index Buffern die ein Netz enthalten, das auf einer Seite enger wird.


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Di Aug 18, 2015 10:53 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
TAK2004 hat geschrieben:
Vinz hat geschrieben:
Wieso das? Wenn man ein Mesh aus dem Screenspace auf eine Ebene am Boden projiziert, sind das doch allerhöchstens n paar Multiplilkationen.

Also ich kenne das verfahren nur über cone-raytracing.
Zeichne die Hüllkörper im Z-Pass.
Zeichne alle anderen Sachen im Z- und Color-Pass.
Zeichne ein Festes Screenspace Grid im Color-Pass.
Für jedes Vertex ein cone-raycast um uv koordinaten zu finden, dann ein texture lookup auf die heightmap und bestimmen ob der punkt im grid nicht trifft und discarded wird oder die uv coords übernommen werden.
Der Fragment Shader ist ein normaler.


Ok, wenn es um beliebige Hüllkörper geht, ist dann wohl Tesselation performanter, aber wenn es um einfache Hüllkörper geht, kann man sich das Raytracen sparen und hat wirklich ein kontinuierliches LOD bei sehr guter Performance, z.B. bei einer Ebene (trivial) oder einer Kugeloberfläche (https://en.wikipedia.org/wiki/Line%E2%8 ... tersection), also sollte es auch für einen Planetenrenderer taugen.
Ein wichtiger Nachteil ist m.M. das Problem, das entsteht wenn, die Oberfläche weit aus dem Hüllkörper rausragt, oder nicht nur Heightmaps verwendet werden, sonder das Mesh auch in andere Richtungen deplaziert werden soll, also wenn die finale Geometrie ihren Ursprung an Stellen des Hüllkörpers hat, die nicht im (oder sogar weit vom) Screenspace liegen.

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


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Di Aug 18, 2015 11:08 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
OpenglerF hat geschrieben:
Ich habe bei meinen Terrainrenderer auch überlegt Tesselation zu nutzen, wenn es verhanden ist. Nach etwas überlegen kam ich aber zu dem Entschluss, dass man mit etwas mehr Arbeit eigentlich den selben Effekt selber hinbekommt (allerdings keine Planetenansicht). Die Höhen-/Texturinformation befindet sich in einem Vertex Buffer. Die X und Z Koordinate wird nicht gespeichert sondern im Shader aus der gl_VertexID erzeugt. Ich rendere mein Terrein in 256² Chunks die sich alle den selben Indexbuffer teilen. Darin befindet sich ein optimiertes Triangle Strip mit 16 Bit Indices. Für LOD tausche ich einfach nur den Index Buffer auf einem, der weniger auflöst ist und Vertices überspringt. Durch die Caching-Geschichte wäre es vielleicht auch noch eine Idee, dass man zu interpolierten Vertexdaten zugreift, weil die dann kontinuierlich vorliegen würden. Den Übergang zwischen den LOD-Stufen erreiche ich mit Index Buffern die ein Netz enthalten, das auf einer Seite enger wird.


Sowas hab ich mir auch mal überlegt. Es bedeutet halt Arbeit für die CPU.
Die Chunks müssen ja auf allen Seiten aneinander passen, und wenn man LOD-Differenzen von größer 1 vorsieht, wird es schon deutlich komplexer.
Würde mich aber sehr interessieren, ob und wie (Performance) es funktioniert.

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


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 18 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Foren-Übersicht » Programmierung » OpenGL


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 51 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.073s | 17 Queries | GZIP : On ]