Prozedurale Oberflächen, How-Not-To

Für Fragen zu Grafik APIs wie DirectX und OpenGL sowie Shaderprogrammierung.
Benutzeravatar
Schrompf
Moderator
Beiträge: 4267
Registriert: 26.02.2009, 00:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Prozedurale Oberflächen, How-Not-To

Beitrag von Schrompf »

Zudomon hat geschrieben:
11.04.2021, 12:04
Ich bin stolz auf dich, dass du nicht aufgegeben hast! Als ich dein erstes Bezier-Bild mit dem Dreieckssalat gesehen habe, dachte ich, es wird nichts mehr. Aber jetzt sieht dein Ergebnis recht solide aus. Und dein Noise gefällt mir richtig gut! Bin schon sehr gespannt, wie dein Fels in ein paar Tagen aussieht 👍
Danke! Dein Felsen ist aber schon noch ne höhere Liga. Was nimmst Du da? Ich sehe da eine Art Grünverfärbung in größeren Flecken. Das ist schon sehr cool. Dann hast Du da so dünne weiße Adern durchgezogen - ist das Noise mit nem Displacement aus nem zweiten Noise? Und diese fetten Einkerbungen sind sehr cool, aber die sind schon so groß, das könnte auch Level sein.
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Alexander Kornrumpf
Moderator
Beiträge: 1802
Registriert: 25.02.2009, 14:37

Re: Prozedurale Oberflächen, How-Not-To

Beitrag von Alexander Kornrumpf »

Zudomon hat geschrieben:
11.04.2021, 12:04
Schrompfs Idee, die Normalen für das Displacement stetig zu konstruieren, ist ein guter Ansatz dem entgegen kommen. Damit bleibt dann die Geometrie trotz Displacements schön bündig.
20210411_2.jpg
Ist halt schade, dass das LOD im linken Teil des Bilds so rapide so weit runter geht. Ich weiß dass die Kritik nicht neu ist und hier schon öfter genannt wurde, aber ich habe mir deine Screenshots nie genau genug angesehen um das selbst zu bemerken. Insbesondere nicht seit du meistens Videos postest, da ist die Hürde noch größer.

Der Felsen sieht richtig gut aus, aber wenn man das Auge versehentlich davon löst ist man sofort wieder in dem schon angesprochenen Uncanny Valley.

Unter der Annahme, dass das ein Tradeoff ist, wie du die Computational Power über das Bild verteilst würde ich vermuten, dass das globale Optimum für ein Spiel bei einer "etwas" gleichmäßigeren Verteilung liegt. So wie du den Tradeoff im Moment wählst, eignet es sich wohl vor allem als Tech-Demo und um eben solche Stillbilder zu produzieren. Was passiert eigentlich in deinem Bild, wenn ich die Kamera nach Links schwenke?
Benutzeravatar
Zudomon
Establishment
Beiträge: 2225
Registriert: 25.03.2009, 08:20
Kontaktdaten:

Re: Prozedurale Oberflächen, How-Not-To

Beitrag von Zudomon »

@Schrompf
Da werden auch nur verschiedene Layer Noises benutzt. Genau, die Grünfärbung ist dann nochmal Noise nur auf dem Albedo... und die Quartzadern etwas verändertes Noise. So, wie du es vermutest auch mit Noise in Noise sampeln. Außerdem kann man ja viel machen mit Kontrastveränderungen usw.
Auch die großen Einkerbungen sind dann nur nochmal Subtraktionen anderer Layer. Da muss man dann ein wenig an den Parametern spielen, bis es akzeptabel aussieht. Das ist ja auch schon meine X-te Iteration. Und wie echt sieht es damit auch noch nicht aus.

@Alexander
Ich freue mich sehr, dass es dir nun gelungen ist, meine Screenshots näher zu betrachten. Natürlich ist das jetzt etwas Off-Topic, weil ich dachte, es geht um die Normalen und das Zerreißen von Geometrie beim Displacement. Vielleicht hätte ich den Ausschnitt etwas einengen sollen, damit dein Auge nicht in den linken Bereich abdriftet. Sorry deswegen.
Du schreibst auch schon richtig, dass das LOD schon mehrfach angesprochen wurde. Bedauerlich allerdings, dass meine Begründungen nicht zu dir durchgedrungen sind. Es hat nämlich nichts mit absichtlicher Verteilung von "Computational Power" zu tun.
Alexander Kornrumpf hat geschrieben:
11.04.2021, 13:46
Was passiert eigentlich in deinem Bild, wenn ich die Kamera nach Links schwenke?
Ohne das jetzt nochmal händisch zu testen, würde ich aber vermuten, dass man dann übers Tal hinweg sieht.
Alexander Kornrumpf
Moderator
Beiträge: 1802
Registriert: 25.02.2009, 14:37

Re: Prozedurale Oberflächen, How-Not-To

Beitrag von Alexander Kornrumpf »

Zudomon hat geschrieben:
11.04.2021, 14:17
Du schreibst auch schon richtig, dass das LOD schon mehrfach angesprochen wurde. Bedauerlich allerdings, dass meine Begründungen nicht zu dir durchgedrungen sind. Es hat nämlich nichts mit absichtlicher Verteilung von "Computational Power" zu tun.
Sondern womit? Wenn du die Rechenpower zur Verfügung hast, das Bild überall gut aussehen zu lassen, dann mach das doch einfach.
Ohne das jetzt nochmal händisch zu testen, würde ich aber vermuten, dass man dann übers Tal hinweg sieht.
Lustig. Ich meinte was mit dem LOD passiert.
Benutzeravatar
Zudomon
Establishment
Beiträge: 2225
Registriert: 25.03.2009, 08:20
Kontaktdaten:

Re: Prozedurale Oberflächen, How-Not-To

Beitrag von Zudomon »

Alexander Kornrumpf hat geschrieben:
11.04.2021, 14:51
Zudomon hat geschrieben:
11.04.2021, 14:17
Du schreibst auch schon richtig, dass das LOD schon mehrfach angesprochen wurde. Bedauerlich allerdings, dass meine Begründungen nicht zu dir durchgedrungen sind. Es hat nämlich nichts mit absichtlicher Verteilung von "Computational Power" zu tun.
Sondern womit? Wenn du die Rechenpower zur Verfügung hast, das Bild überall gut aussehen zu lassen, dann mach das doch einfach.
Du sagst doch selbst, das Thema hatten wir schon mehrfach. Ist mir auch müßig das immer wieder zu erklären. Gibt es hier nicht auch eine Suchfunktion?
Alexander Kornrumpf hat geschrieben:
11.04.2021, 14:51
Ohne das jetzt nochmal händisch zu testen, würde ich aber vermuten, dass man dann übers Tal hinweg sieht.
Lustig. Ich meinte was mit dem LOD passiert.
Nichts passiert damit. Oder ist das eine Fangfrage?
Benutzeravatar
Zudomon
Establishment
Beiträge: 2225
Registriert: 25.03.2009, 08:20
Kontaktdaten:

Re: Prozedurale Oberflächen, How-Not-To

Beitrag von Zudomon »

@Alexander
Um dich nicht so frech stehen zu lassen, hab ich jetzt selbst mal die Suchfunktion bemüht. Ich hoffe, Schrompf verzeiht mir, dass ich hier nochmal Off-Topic poste.
Hier findet man nochmal gut ein paar Informationen:
viewtopic.php?f=10&t=3720&p=55601&hilit ... lod#p55601
Zusammenfassend also: Das Generieren der Objekte ist auf Flächen bezogen, auf die ich in den niederen LOD-Stufen keinen Zugriff habe.
Das müssen wir aber nicht weiter vertiefen. In der neuen Engine werde ich das grundlegend anders angehen.
Benutzeravatar
Schrompf
Moderator
Beiträge: 4267
Registriert: 26.02.2009, 00:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Prozedurale Oberflächen, How-Not-To

Beitrag von Schrompf »

dungeon_erstsand.png
Es entwickelt sich. Mein Surface Processing arbeitet jetzt (erstmal) nur noch im Texture Space, handelt also auch Displacement Offsets auf Texturen ab und lenkt Vertizes anhand Texturen aus. Das braucht dann Sub-Texel-Koordinatenmagie, damit es mir an den Kanten nicht wieder die Flächen auseinander reisst, aber ich habe es halbwegs unter Kontrolle. Außerdem wurde dadurch erstmal nur intern ermöglicht, dass ich in mehreren Passes über die Oberflächen drüber gehen kann. Und das ermöglicht mir hoffentlich langfristig eine menschen-editierbare Oberfläche z.B. auf Basis eines Node Graphs.

Außerdem habe ich inspiriert von Zudos Fels mal ne Stunde mit Noise rumgespielt: grüne Flecken und ne vertikale Strichelung ähnlich Sandstein, wo im Ozean herabsinkende Sedimente Schichten ausbilden und absinkender Wasserstand dann bodenparallele Kerben auswäscht. Die Kuhlen im Boden wollte ich mit Sand auffüllen, aber die Formel dafür explodiert gelegentlich noch je nach Neigung und Felshöhe. Eigentlich falsch, aber sieht irgendwie sehr cool aus... hachja, die Freuden von Procedural Content Generation.

Außerdem hab ich ne supersimple Idee, wie ich Textur- und Meshauflösung stufenweise je nach Kameraentfernung steuern kann, und wie ich die unvermeidlichen Säume billig gefüllt kriege. Dann kann ich dynamisch bei Annäherung der Spielerin die Oberflächen mit besserem Detail neu berechnen, und kriege nebenbei den astronomischen Speicherbedarf in sinnvolle Bereiche. Aktuell bin ich bei einem Set 2048er Texturen pro 2m x 2m-Segment und komme bei 48GB Texturdaten raus :-S

[edit] Zeig ich heute abend im Stammtisch, wenn ihr Zeit und Lust habt. Aber als Standbild hat man eigentlich schon alles gesehen :D
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Alexander Kornrumpf
Moderator
Beiträge: 1802
Registriert: 25.02.2009, 14:37

Re: Prozedurale Oberflächen, How-Not-To

Beitrag von Alexander Kornrumpf »

sehr sehr nice.
joeydee
Establishment
Beiträge: 765
Registriert: 23.04.2003, 15:29
Kontaktdaten:

Re: Prozedurale Oberflächen, How-Not-To

Beitrag von joeydee »

Ich habe mich zwischenzeitlich nochmal ein wenig mit Bezierpatches (bzw. mit Möglichkeiten, deren Kontrollpunkte bei Aneinanderreihung zu bestimmen) befasst.
Da lt. Schrompf seine Normalen-Kontinuität ja noch nicht ganz gelöst ist, poste ich meine Ergebnisse auch nochmal hier.

Erst nochmal die Grundlage: ein Bezier-Patch benötigt 16 Kontrollpunkte. Ich unterscheide hier die Vertices K1 (grün, 4x), die Kantentangentenpunkte K2 (blau, 8x) sowie deren Tangentenpunkte K3 (rot, 4x). K2- und K3-Punkte "gehören" jeweils zu einem Vertex (K1).

Konstruktionsgedanke bei benachbarten Patches:
- die gemittelte Normale eines K1-Vertex bildet eine Ebene (im Folgenden "die Ebene" meint immer diese)
- die K3-Punkte aller Nachbarn zu diesem Vertex bilden ein N-Gon (bei N zusammenstoßenden Flächen am Vertex) auf dieser Ebene.
- die K2-Punkte aller Tangenten zu diesem Vertex liegen auf den Kanten dieses N-Gons.

Hier beispielhaft mit 3 zusammenstoßenden Patches (weiße Kanten); das K3-NGon ist ein Dreieck (rot):
Bild

Nun gibt es verschiedene Möglichkeiten, dieses N-Gon zu konstruieren.
Z.B. die angrenzenden Flächenmitten auf die Normalenebene projizieren.
Oder die ursprünglichen Flächennormalen, ausgehend vom Vertex, auf die Ebene projizieren.
Oder die Kantenenden auf die Ebene projizieren und den Mittelpunkt zweier benachbarter Punkte als N-Gon-Ecke benutzen.

Auch wie man die Tangenten bstimmt, bietet mehrere Möglichkeiten.
Seitenmitten des N-Gons. Oder man berechnet sie zuerst, berechnet aus ihnen ein N-Gon, und projiziert die Tangenten-Enden dann auf die N-Gon-Seiten.

Möglichkeiten für Tangenten zuerst:
über die Normale und die Kanten Tangent-Spaces berechnen.
Oder Kantenabschnitte auf die Ebene projizieren.

Hier mal ein Testbeispiel mit Kontrollpunkten die die N-Gon-Bedingungen erfüllen:
Bild

Je nachdem wie man die N-Gons skaliert, beeinflusst das das Krümmungsverhalten:
Bild

Ob die Normalen an den Kanten wirklich stetig sind, würde erst ein Pixelshader optisch zeigen können.
Wirklich "wasserdicht" in dem Sinne wäre es vermutlich erst, wenn man gegenüberliegende K2-Tangenten auf einer Linie anlegen könnte, ohne die anderen Bedingungen zu zerstören. Bei einer Ecke mit 3 zusammenstoßenden Patches geht das natürlich grundsätzlich nicht.

Mein letztes Statement gilt noch:
Also würde ich auch mal CC ins Auge fassen. Evtl. gewichtetes Average, um Kontrolle über den Grad der Rundung zu bekommen, müsste eigentlich gehen.
(CC == Catmull-Clark-Subdivision)
Also auf erhaltende Ur-Vertices ganz verzichten. Da man hier ebenso die ganzen Nachbarschaftsinformationen benötigt, ist das evtl. sogar weniger Aufwand.
Antworten