[Projekt] Rayworld-NG
Forumsregeln
Bitte Präfixe benutzen. Das Präfix "[Projekt]" bewirkt die Aufnahme von Bildern aus den Beiträgen des Themenerstellers in den Showroom. Alle Bilder aus dem Thema Showroom erscheinen ebenfalls im Showroom auf der Frontpage. Es werden nur Bilder berücksichtigt, die entweder mit dem attachement- oder dem img-BBCode im Beitrag angezeigt werden.
Die Bildersammelfunktion muss manuell ausgeführt werden, die URL dazu und weitere Details zum Showroom sind hier zu finden.
This forum is primarily intended for German-language video game developers. Please don't post promotional information targeted at end users.
Bitte Präfixe benutzen. Das Präfix "[Projekt]" bewirkt die Aufnahme von Bildern aus den Beiträgen des Themenerstellers in den Showroom. Alle Bilder aus dem Thema Showroom erscheinen ebenfalls im Showroom auf der Frontpage. Es werden nur Bilder berücksichtigt, die entweder mit dem attachement- oder dem img-BBCode im Beitrag angezeigt werden.
Die Bildersammelfunktion muss manuell ausgeführt werden, die URL dazu und weitere Details zum Showroom sind hier zu finden.
This forum is primarily intended for German-language video game developers. Please don't post promotional information targeted at end users.
[Projekt] Rayworld-NG
Hallo zusammen,
nach Dekaden C/C++ und anderen habe ich mich, wie hier ja auch schon erwähnt, Anfang des Jahres einmal Zig gewidmet. Als Spielprojekt musste ein Evergreen herhalten: ein Oldschool-Raycaster mit ein paar modernen Erweiterungen. Dazu zählen Spiegelungen, Lichtbrechung und eine kleine Hintergrundsimulation, um die SIMD-Features zu testen.
Als initialen Projektstand poste ich hier einfach mal Screenshots der GitHub-Seite, um einerseits die Einstiegshürde zu nehmen und etwas zu zeigen und andererseits nicht alles neu zu schreiben.
Bei Interesse gerne reinschauen:
https://github.com/bfeldpw/rayworld-ng
nach Dekaden C/C++ und anderen habe ich mich, wie hier ja auch schon erwähnt, Anfang des Jahres einmal Zig gewidmet. Als Spielprojekt musste ein Evergreen herhalten: ein Oldschool-Raycaster mit ein paar modernen Erweiterungen. Dazu zählen Spiegelungen, Lichtbrechung und eine kleine Hintergrundsimulation, um die SIMD-Features zu testen.
Als initialen Projektstand poste ich hier einfach mal Screenshots der GitHub-Seite, um einerseits die Einstiegshürde zu nehmen und etwas zu zeigen und andererseits nicht alles neu zu schreiben.
Bei Interesse gerne reinschauen:
https://github.com/bfeldpw/rayworld-ng
Re: [Projekt] Rayworld-NG
Danke :-)
Was ich bislang immer wieder vergessen habe, ist eine einfache Art von Flat-Shading für den Anfang, bevor es richtig an die Beleuchtung geht, die den Raycaster-Code nutzen sollte.
Das Flat-Shading ist nicht ganz so "flat", da jeder Sichtstrahl einen anderen Winkel zur Normalen hat und damit auch Flächen einen leichten Verlauf aufweisen. Das führt in Ecken zu einem automatischen AO-Effekt und natürlich wird alles etwas stimmiger und Säulen plastischer. Für < 10 Zeilen zusätzlichen Codes eine echte Low-Hanging-Fruit, die endlich gepflückt werden wollte.
- Schrompf
- Moderator
- Beiträge: 4942
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas
- Wohnort: Dresden
- Kontaktdaten:
Re: [Projekt] Rayworld-NG
Schick, echte Retro-Stimmung
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Re: [Projekt] Rayworld-NG
Danke :-)
Es macht schon fast mehr Spaß, sich mittels Minimap statt in der 3D-Szene zu bewegen, die Strahlengänge sind einfach (gerade in Bewegung) immer wieder faszinierend. Wer genau hinschaut, findet in einem größeren Glasblock auch die eine Zelle, die ein Material mit anderem Brechungsindex aufweist :-) Ansonsten habe ich mal meine Funktionen zur Performance-Messung überholt und die rudimentäre GUI damit gefüttert. Je nach Einstellung sind die Werte gemittelt, hier über eine Sekunde, jetzt sehe ich wenigstens live, wo noch wieviel Luft nach oben ist:
Es macht schon fast mehr Spaß, sich mittels Minimap statt in der 3D-Szene zu bewegen, die Strahlengänge sind einfach (gerade in Bewegung) immer wieder faszinierend. Wer genau hinschaut, findet in einem größeren Glasblock auch die eine Zelle, die ein Material mit anderem Brechungsindex aufweist :-) Ansonsten habe ich mal meine Funktionen zur Performance-Messung überholt und die rudimentäre GUI damit gefüttert. Je nach Einstellung sind die Werte gemittelt, hier über eine Sekunde, jetzt sehe ich wenigstens live, wo noch wieviel Luft nach oben ist:
- Schrompf
- Moderator
- Beiträge: 4942
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas
- Wohnort: Dresden
- Kontaktdaten:
Re: [Projekt] Rayworld-NG
Ich glaube gern, dass damit rumzuspielen Spaß macht. Das Ding würde sich auch für diffuse Spiegelungen anbieten, wo Du nicht mehr nen Strahl, sondern eine Cone durch die Szene traced. Aber da schlägt wieder meine Obsession mit vorintegrierten Traces durch.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Re: [Projekt] Rayworld-NG
Hey Schrompf, ja, mit den Cones ist grundsätzlich eine gute Idee, wobei, kannst du mir nochmal ein Stichwort geben, was du genau mit "vorintegrierten Traces" meinst?
Tatsächlich bin ich gerade dabei, die Datenstrukturen so umzustellen, dass "gesplittet" werden kann. Hauptsächlich, um bei Glas Reflexion und Lichtbrechung gleichzeitig zu verfolgen. Da hatte ich auch schon die Überlegung, je nach Material z.B. 8 oder 16 Strahlen in einem materialabhängigen Öffnungs- und Reflexionswinkel zu "spawnen", das käme dem Cone ja schon recht nahe.
Die, ich sage mal einfachste Form von Diffusion, ist bereits enthalten. Jedes Segment hat einen Scatter-Parameter, der bestimmt, wie sehr der Ausfallswinkel bei der Reflexion gestreut wird. Es wird zwar in dem Sinne nicht diffus, allerdings sind die Kanten reflektierter Wände nicht mehr sauber/glatt, sondern eher "wellig", bzw. in der Höhe etwas verrauscht. Das gibt bereits einen gewissen Eindruck von Unschärfe und damit subjektiv Diffusion im Sinne rauer Wände, die nicht ideal reflektieren.
Der Parameter ist allerdings default stark reduziert, da es sonst passiert, dass ein Strahl direkt die Ecke einer vorstehenden Wand trifft, der nächste dann, wegen der Streuung, daran vorbeigeht und der dritte wieder trifft. Diese Lücken sehen nur gut aus, wenn man die Augen zusammenkneift ;-). Und eine Glättung über die Horizontale gibt es (noch) nicht.
Edit: Zu letzterem noch zwei Screenshots, Spielersicht und Blick hinter (über) die Kulissen -- zum Verdeutlichen mit sehr starker Streuung:
Tatsächlich bin ich gerade dabei, die Datenstrukturen so umzustellen, dass "gesplittet" werden kann. Hauptsächlich, um bei Glas Reflexion und Lichtbrechung gleichzeitig zu verfolgen. Da hatte ich auch schon die Überlegung, je nach Material z.B. 8 oder 16 Strahlen in einem materialabhängigen Öffnungs- und Reflexionswinkel zu "spawnen", das käme dem Cone ja schon recht nahe.
Die, ich sage mal einfachste Form von Diffusion, ist bereits enthalten. Jedes Segment hat einen Scatter-Parameter, der bestimmt, wie sehr der Ausfallswinkel bei der Reflexion gestreut wird. Es wird zwar in dem Sinne nicht diffus, allerdings sind die Kanten reflektierter Wände nicht mehr sauber/glatt, sondern eher "wellig", bzw. in der Höhe etwas verrauscht. Das gibt bereits einen gewissen Eindruck von Unschärfe und damit subjektiv Diffusion im Sinne rauer Wände, die nicht ideal reflektieren.
Der Parameter ist allerdings default stark reduziert, da es sonst passiert, dass ein Strahl direkt die Ecke einer vorstehenden Wand trifft, der nächste dann, wegen der Streuung, daran vorbeigeht und der dritte wieder trifft. Diese Lücken sehen nur gut aus, wenn man die Augen zusammenkneift ;-). Und eine Glättung über die Horizontale gibt es (noch) nicht.
Edit: Zu letzterem noch zwei Screenshots, Spielersicht und Blick hinter (über) die Kulissen -- zum Verdeutlichen mit sehr starker Streuung:
Re: [Projekt] Rayworld-NG
Schöne Sache :)
Ich glaube was Schrompf mit "vorintegriert" meinte, war grob gesagt: Die Rauminformation ist hierarchisch in Voxel verschiedener Größenstufen eingeteilt, wobei z.B. die nächstgröbere Stufe den Durchschnitt der acht (2x2x2) enthaltenen Subvoxel enthält ("vorintegriert", bzw. 3D-Mipmaps mehr oder weniger). Wenn man nun einen Cone durch den Raum schickt, muss er theoretisch nur auf die vorintegrierte Rauminfo zugreifen, die seiner Breite an jener Stelle entspricht. Und muss nicht auf viele einzelne Voxel oder Rays aufgeteilt werden. Was die Ausführungsgeschwindigkeit unabhängig vom Cone-Durchmesser relativ konstant halten würde. Wodurch auch keine Information verpasst würde (z.B. sehr helles kleines Objekt in weiter Ferne, welches durch Ray-Sampling übersehen werden könnte oder stark flackert bei Bewegung).
Aber ich mag mich im Detail täuschen, er hatte das mal beim Stammtisch vorgestellt, aber wahrscheinlich hatte ich nur 10% seiner Ausführungen wirklich verstanden ;) Denn so wie ich es hier zu erklären versuche fühle ich da mehr Probleme als Lösungen aufpoppen.
Ich glaube was Schrompf mit "vorintegriert" meinte, war grob gesagt: Die Rauminformation ist hierarchisch in Voxel verschiedener Größenstufen eingeteilt, wobei z.B. die nächstgröbere Stufe den Durchschnitt der acht (2x2x2) enthaltenen Subvoxel enthält ("vorintegriert", bzw. 3D-Mipmaps mehr oder weniger). Wenn man nun einen Cone durch den Raum schickt, muss er theoretisch nur auf die vorintegrierte Rauminfo zugreifen, die seiner Breite an jener Stelle entspricht. Und muss nicht auf viele einzelne Voxel oder Rays aufgeteilt werden. Was die Ausführungsgeschwindigkeit unabhängig vom Cone-Durchmesser relativ konstant halten würde. Wodurch auch keine Information verpasst würde (z.B. sehr helles kleines Objekt in weiter Ferne, welches durch Ray-Sampling übersehen werden könnte oder stark flackert bei Bewegung).
Aber ich mag mich im Detail täuschen, er hatte das mal beim Stammtisch vorgestellt, aber wahrscheinlich hatte ich nur 10% seiner Ausführungen wirklich verstanden ;) Denn so wie ich es hier zu erklären versuche fühle ich da mehr Probleme als Lösungen aufpoppen.
- Schrompf
- Moderator
- Beiträge: 4942
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas
- Wohnort: Dresden
- Kontaktdaten:
Re: [Projekt] Rayworld-NG
Ja, joeydee hat schon den Finger drauf. Ich hab ja versucht, einen "Strahl mit Dicke" durch eine Voxelwelt zu schießen und dabei auszurechnen, wieviel jeder getroffene Voxel die Farbe des Strahls verändert. Also kein bool "Getroffen oder nicht", sondern anteilig "43% des Strahls nehmen die Farbe Orange an". Und bei Dir, der Du prinzipiell nur in 2D traced, Deine Strahlen-Oberfläche also effektiv nur eindimensional ist (nur eine Breite hat), müsste man das ziemlich einfach berechnen können.
Der "Strahl mit Breite" trifft ne Wand - wenn die ganze Strahlbreite das Wandsegment trifft, kannst Du die Textur einfach aus ner MipMap entsprechend der Strahlbreite sampeln - hast ja aber gar keine Texturen bisher :-) Du kannst als Reflektion von da aus einfach einen entsprechend ab Start breiten Strahl tracen. Du kannst als Brechung nen entsprechend schmaleren Strahl weitertracen. Und wenn Du anteilig ne Wand triffst, kannst Du einfach nen Reststrahl mit reduzierter Breite weitertracen und die Oberfläche mit nem anteilig versetzten schmaleren Strahl behandeln.
Und Du kannst diffuse Reflektionen bequem mit nem entsprechend breiteren Strahl behandeln. Da kriegt man dann zwar nicht die korrekte Specular-Verteilung, aber ich habe so den Verdacht, dass im eindimensionalen Fall das Integral vielleicht sogar lösbar ist.
Soooo viele Möglichkeiten :-)
Der "Strahl mit Breite" trifft ne Wand - wenn die ganze Strahlbreite das Wandsegment trifft, kannst Du die Textur einfach aus ner MipMap entsprechend der Strahlbreite sampeln - hast ja aber gar keine Texturen bisher :-) Du kannst als Reflektion von da aus einfach einen entsprechend ab Start breiten Strahl tracen. Du kannst als Brechung nen entsprechend schmaleren Strahl weitertracen. Und wenn Du anteilig ne Wand triffst, kannst Du einfach nen Reststrahl mit reduzierter Breite weitertracen und die Oberfläche mit nem anteilig versetzten schmaleren Strahl behandeln.
Und Du kannst diffuse Reflektionen bequem mit nem entsprechend breiteren Strahl behandeln. Da kriegt man dann zwar nicht die korrekte Specular-Verteilung, aber ich habe so den Verdacht, dass im eindimensionalen Fall das Integral vielleicht sogar lösbar ist.
Soooo viele Möglichkeiten :-)
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Re: [Projekt] Rayworld-NG
Ah, okay, danke euch beiden für die Erklärungen. Ich werde es mal genauer durchdenken, aber so langsam muss ich auch die GUI erweitern, um den Map-Editor angehen zu können.
@Schrompf: Doch, doch, Texturen sind auf jedem Block. Das sind aber sehr subtile und naive brushed-metal-Imitationen, die in 2min in Gimp entstanden sind, einfach mal die Bilder in groß anschauen. Ich hänge aber auch nochmal einen Screenshot mit offensichtlicherer Textur an.
@Schrompf: Doch, doch, Texturen sind auf jedem Block. Das sind aber sehr subtile und naive brushed-metal-Imitationen, die in 2min in Gimp entstanden sind, einfach mal die Bilder in groß anschauen. Ich hänge aber auch nochmal einen Screenshot mit offensichtlicherer Textur an.
Re: [Projekt] Rayworld-NG
In der letzten Zeit habe ich mich nochmal ein wenig der GUI gewidmet, zum einen, weil ich gerade Lust darauf hatte, zum anderen sollte früher oder später ein Level-/Map-Editor integriert werden.
Bislang waren die Overlays einfach nur Rechtecke mit Text. Ein paar Features sind hinzugekommen:
Bislang waren die Overlays einfach nur Rechtecke mit Text. Ein paar Features sind hinzugekommen:
- Title und entsprechende Parameter wie das Alignment (links, zentriert, rechts)
- Alignment des Overlays (zentriert oder zum Bildschirmrand)
- Diverse Eigentschaften wie Randbereiche zwischen Widget und Overlay
- Auto-resize zum Anpassen an den Widget-Inhalt
- Word- (oder eher Char-)Wrap, falls kein Auto-Resize gewählt ist
- Nur vertikales Auto-Resize und Word-Wrap ist möglich
- Wahlweise snapping an den Bildschirmrändern und in der Mitte
- Sortieren und Hervorheben/Fokussieren von Overlays
Re: [Projekt] Rayworld-NG
Der erste Schritt sind simple, transparente Polygone, um das grundsätzliche Verhalten und die spätere Architektur zu testen - ich muss mich erst wieder in VBOs, VAOs, FBOs usw einfinden. Spiegelungen, Glas, Wände und Säulen scheinen zu funktionieren, jetzt können Beleuchtung, Texturen und Shader kommen, bzw. angepasst werden.
Re: [Projekt] Rayworld-NG
Kleines Update ohne Screenshot, denn der hätte auch von weiter oben kommen können: Ich bin jetzt gewissermaßen auf "feature parity" bzgl. der alten Version, nur jetzt eben mit OpenGL core profile.
Hinzu kam eine kleine Ergänzung: "hot shader reload". Natürlich ist es sehr einfach und plausibel, auf Knopfdruck die Shader im laufenden Betrieb nachzuladen, aber irgendwie habe ich nie so richtig drüber nachgedacht. Und weil es gerade so spannend war, wurde der Knopfdruck durch "inotify" auf dem Linux-Dateisystem ersetzt. Schon sehr nett und praktisch zum Shaderentwickeln. Für andere Plattformen wird der Teil derzeit nicht mitkompiliert, hier ist weiterhin der Knopfdruck notwendig. Es wird sicherlich auch ähnliche Mechanismen auf den anderen Plattformen wie Windows geben, aber das ist dann die Kür, wenn ich mal die Muße habe, mich damit zu beschäftigen.
Hinzu kam eine kleine Ergänzung: "hot shader reload". Natürlich ist es sehr einfach und plausibel, auf Knopfdruck die Shader im laufenden Betrieb nachzuladen, aber irgendwie habe ich nie so richtig drüber nachgedacht. Und weil es gerade so spannend war, wurde der Knopfdruck durch "inotify" auf dem Linux-Dateisystem ersetzt. Schon sehr nett und praktisch zum Shaderentwickeln. Für andere Plattformen wird der Teil derzeit nicht mitkompiliert, hier ist weiterhin der Knopfdruck notwendig. Es wird sicherlich auch ähnliche Mechanismen auf den anderen Plattformen wie Windows geben, aber das ist dann die Kür, wenn ich mal die Muße habe, mich damit zu beschäftigen.
Re: [Projekt] Rayworld-NG
Mit Shadern war es dennoch etwas tricky (für meine Kenntnisse bislang zumindest), da ich keine 3D-Geometrie habe, sondern eben nur vertikale Linien (bzw. Quads/Doppeldreiecke bei Unterabtastung). Und ich wollte nicht auf eine spezifische GL4.6 NVidia-Erweiterung ausweichen, die mir die baryzentrischen Koordinaten verfügbar macht, um die Interpolation steuern zu können. Es gibt wohl Hacks, über Attribute (1, 0, 0), (0, 1, 0),... mitzuschicken und damit implizit die baryzentrischen Koordinaten zu erhalten, ist aber laut Internet auch unschön und mit Problemen behaftet.
Letztlich gebe ich als Attribut pro Vertex die Höhe der "Linie" mit (und das Zentrum, da die vertikale Kamerabewegung und das gefakte Nicken auch noch einen Einfluss haben) und kann so über gl_FragCoord bestimmen, wo ich mich auf der vertikalen befinde. Damit kann dann die Farbe exponentiell verdunkelt werden (+ etwas weniger Alpha, um den Übergang zu der noch nicht texturierten Decke/Boden weicher zu gestalten).
Ich hoffe, ich habe es nicht zu kompliziert gemacht, aber es funktioniert erstmal und ist performant.
- Schrompf
- Moderator
- Beiträge: 4942
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas
- Wohnort: Dresden
- Kontaktdaten:
Re: [Projekt] Rayworld-NG
Ich versteh nicht viel von der Erklärung, aber das Bild sieht schon cool aus!
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Re: [Projekt] Rayworld-NG
Ja sieht cool aus. Vllt kannst Du ja mal ein Video davon machen?
Re: [Projekt] Rayworld-NG
@Schrompf: Danke und sorry, ist wahrscheinlich sehr umständlich beschrieben oder schwer ohne Skizze verständlich. Maßgebliche Aussage: Auch in modernem OpenGL fällt es schwer, die lineare Interpolation zwischen den Vertices einfach (im Shader, ich hätte das irgendwie erwartet) zu umgehen. Das ist in einer "echten" 3D-Geomtrie zugegebenermaßen wahrscheinlich eher selten notwendig, aber in meinem speziellen Fake-3D-Fall irgendwie schon, es wäre zumindest sehr praktisch.
@scheichs: Uff, also ja, definitiv eine gute Idee, muss ich mich mal damit beschäftigen. Habe mich noch nicht wirklich mit Screengrabbern (unter Linux) oder Streaming-Diensten beschäftigt, an GIFs bin ich in dem Zusammenhang etwas verzweifelt (oder eher unzufrieden mit dem Ergebnis). Ein Freund hat Peer-Tube empfohlen, ich schaue mal, was ich machen kann.
@scheichs: Uff, also ja, definitiv eine gute Idee, muss ich mich mal damit beschäftigen. Habe mich noch nicht wirklich mit Screengrabbern (unter Linux) oder Streaming-Diensten beschäftigt, an GIFs bin ich in dem Zusammenhang etwas verzweifelt (oder eher unzufrieden mit dem Ergebnis). Ein Freund hat Peer-Tube empfohlen, ich schaue mal, was ich machen kann.
- Schrompf
- Moderator
- Beiträge: 4942
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas
- Wohnort: Dresden
- Kontaktdaten:
Re: [Projekt] Rayworld-NG
ScreenCapture mit OBSStudio ist easy, außer auf Linux, wo ich Probleme hatte, das Mikrofon mit in die Tonspur aufzunehmen. Auf Windows gibt's dann ScreenToGif und Freunde, aber das kann OBS auch, glaube ich
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Re: [Projekt] Rayworld-NG
Hallo,
ich habe mal vokoscreenNG unter Linux getestet, das funktioniert sehr gut, muss jetzt nur noch einen YouTube-Account (oder eine Alternative) anlegen.
Zur Entwicklung: Ich habe mich mal rangesetzt, etwas zu optimieren. Da ich sehr große VBO-Updates pro Frame habe, da meine sich ständig ändernden, vertikalen Linien ja letztlich die Geometrie darstellen, wollte ich den Flaschenhals CPU->GPU betrachten. Zunächst waren die Farben dran. Ich habe ganz naiv pro Vertex 2 Koordinaten (ich zeichne ja wie gesagt nur vertikale "Quads"), 2 Texturkoordinaten, Payload wie die Wandhöhe für die oben beschriebene AO und: 4x Farbe (RGBA - Float) übertragen.
Letztere, RGBA, also 4 Floats sind nicht notwendig. Daher sind die Farben jetzt in einem getrennten VBO, RGBA mit je 8bit in einem uint32 codiert. CPU-seitig wird mit bit-shifts die Farbe eingepackt, OpenGLs übernimmt die Normierung auf 0-1, der Shader kann mittels letztlich wieder 4 Floats daraus machen. Das hat die CPU-Performance merklich erhöht, GPU-seitig merkt man das Unpack nicht negativ.
Da ich nur zweidimensional unterwegs bin und die Positionen Bildschirmkoordinaten sind, könnte ich in Zukunft ebenso die 2D-Position in einen 32bit Wert (2x16) packen. Und auch für Texturkoordinaten sollte die Präzision ausreichen. Allerdings gehe ich das erst an, falls es kritisch wird, die Farben hatten mit 4 Komponenten ein gutes Verhältnis von Aufwand zu Performance-Gewinn.
Langfristig möchte ich die Karte (also das Grid mit Wandeigenschaften) in einen Buffer auf der GPU rendern. So muss ich gar keine Farbinformationen mehr Richtung GPU übertragen, sondern nur noch die Kollisionen in der Karte. Sämtliche Farb- und Beleuchtungsberechnungen können dann auf der GPU laufen.
ich habe mal vokoscreenNG unter Linux getestet, das funktioniert sehr gut, muss jetzt nur noch einen YouTube-Account (oder eine Alternative) anlegen.
Zur Entwicklung: Ich habe mich mal rangesetzt, etwas zu optimieren. Da ich sehr große VBO-Updates pro Frame habe, da meine sich ständig ändernden, vertikalen Linien ja letztlich die Geometrie darstellen, wollte ich den Flaschenhals CPU->GPU betrachten. Zunächst waren die Farben dran. Ich habe ganz naiv pro Vertex 2 Koordinaten (ich zeichne ja wie gesagt nur vertikale "Quads"), 2 Texturkoordinaten, Payload wie die Wandhöhe für die oben beschriebene AO und: 4x Farbe (RGBA - Float) übertragen.
Letztere, RGBA, also 4 Floats sind nicht notwendig. Daher sind die Farben jetzt in einem getrennten VBO, RGBA mit je 8bit in einem uint32 codiert. CPU-seitig wird mit bit-shifts die Farbe eingepackt, OpenGLs
Code: Alles auswählen
glVertexAttribPointer
Code: Alles auswählen
unpackUnorm4x8
Da ich nur zweidimensional unterwegs bin und die Positionen Bildschirmkoordinaten sind, könnte ich in Zukunft ebenso die 2D-Position in einen 32bit Wert (2x16) packen. Und auch für Texturkoordinaten sollte die Präzision ausreichen. Allerdings gehe ich das erst an, falls es kritisch wird, die Farben hatten mit 4 Komponenten ein gutes Verhältnis von Aufwand zu Performance-Gewinn.
Langfristig möchte ich die Karte (also das Grid mit Wandeigenschaften) in einen Buffer auf der GPU rendern. So muss ich gar keine Farbinformationen mehr Richtung GPU übertragen, sondern nur noch die Kollisionen in der Karte. Sämtliche Farb- und Beleuchtungsberechnungen können dann auf der GPU laufen.
Re: [Projekt] Rayworld-NG
Magst du das mal ein wenig ausführen? Ich erinnere mich dunkel an perspektivisch korrekte Interpolation , aber warum genau das hier alles kaputt macht verstehe ich auf Anhieb nicht. Der angesprochenen Hack klingt für mich auch gar nicht so schlimm, eigentlich sollte man doch eine nette Formel herleiten können, die die Standardinterpolation invertiert. Ist natürlich minimal mehr Aufwand, aber Vertex-Processing wird nun wirklich nicht dein Problem sein, deshalb sehe ich erstmal nichts, was dagegen spricht.smurfer hat geschrieben: ↑20.11.2023, 10:20Und ich wollte nicht auf eine spezifische GL4.6 NVidia-Erweiterung ausweichen, die mir die baryzentrischen Koordinaten verfügbar macht, um die Interpolation steuern zu können. Es gibt wohl Hacks, über Attribute (1, 0, 0), (0, 1, 0),... mitzuschicken und damit implizit die baryzentrischen Koordinaten zu erhalten, ist aber laut Internet auch unschön und mit Problemen behaftet.
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
https://jonathank.de/games/
Re: [Projekt] Rayworld-NG
[Edit] Ich glaube, ich hatte dich erst falsch verstanden
Falls deine Frage speziell auf die Mögllichkeit abzielt, mittels dreier zusätzlicher Vertex-Shader-Attribute die Positionen (1,0,0),(0,1,0),(0,0,1) mitzuliefern und damit eben implizit die baryzentrischen Koordinaten an den Fragment-Shader zu übergeben: Ja, das ist in meinem 2D-Fall auch korrekt und nicht von der Perspektive beeinflusst. Das wäre also eine Lösung, dass es in meinem Fall ein "problembehafteter Hack" ist, habe ich falsch formuliert.
Ich hatte einfach erwartet, das OpenGL das nativ kann und es sehr grundlegend für die Arbeit im Fragment-Shader ist.
Ich habe es jetzt etwas anders gelöst: Über glFragCoord kenne ich zumindest im Fragment-Shader meine Position im Framebuffer, übertrage ich dann noch Höhe und vertikalen Mittelpunkt der Linie, kenne ich auch meine Position innerhalb (vertikalen) der Linie und kann mit beliebigen Funktionen interpolieren.
Falls deine Frage speziell auf die Mögllichkeit abzielt, mittels dreier zusätzlicher Vertex-Shader-Attribute die Positionen (1,0,0),(0,1,0),(0,0,1) mitzuliefern und damit eben implizit die baryzentrischen Koordinaten an den Fragment-Shader zu übergeben: Ja, das ist in meinem 2D-Fall auch korrekt und nicht von der Perspektive beeinflusst. Das wäre also eine Lösung, dass es in meinem Fall ein "problembehafteter Hack" ist, habe ich falsch formuliert.
Ich hatte einfach erwartet, das OpenGL das nativ kann und es sehr grundlegend für die Arbeit im Fragment-Shader ist.
Ich habe es jetzt etwas anders gelöst: Über glFragCoord kenne ich zumindest im Fragment-Shader meine Position im Framebuffer, übertrage ich dann noch Höhe und vertikalen Mittelpunkt der Linie, kenne ich auch meine Position innerhalb (vertikalen) der Linie und kann mit beliebigen Funktionen interpolieren.
Re: [Projekt] Rayworld-NG
Hallo zusammen,
ich hatte immer noch keine Geduld für ein Video, aber dennoch etwas Fortschritt:
Framebuffer sind endlich relativ sauber implementiert. Damit ergibt sich Folgendes
ich hatte immer noch keine Geduld für ein Video, aber dennoch etwas Fortschritt:
Framebuffer sind endlich relativ sauber implementiert. Damit ergibt sich Folgendes
- Die Szene kann in einer geringeren (als der nativen) Auflösung gerendert werden, dort, wo es mit der Performance kritisch wird
- Die Szene kann mit einer höheren (als der nativen) Auflösung gerendert werden -> Super Sampling
- Mit dem Framebuffer kann die Planeten-Hintergrundsimultation als Textur (Ingame-Bildschirm auf einer Wand) live in die Szene gerendert werden (hier ein erster Hack und ja, das wird als Video besser rüberkommen)
Re: [Projekt] Rayworld-NG
Hallo zusammen,
so, jetzt bin ich wirklich fertig mit der Umstellung auf das OpenGL Core Profile. Die gesamte, rudimentäre GUI funktioniert wieder, Karte und Asteroidensimulation können dank FBOs und Render-to-Texture sowohl auf Wände als auch auf die GUI gemappt werden. In der folgenden Szene haben die beiden entsprechenden GUI-Fenster bewusst keinen Titel: Hier sieht man den Edit-Mode und zwei Debug-Fenster, in diesem Fall mit Titel und Rahmen: Schaut man auf die Statistiken rechts oben, mag auffallen, dass es recht viele Drawcalls, Shader- und Texturwechsel sind (zumindest für das simple Bild). Das ist darauf zurückzuführen, dass es recht viele Reflektionen gibt und pro Sichtstrahl eine Spalte gerendert wird. Das ist schon einigermaßen optimiert, indem für jede Reflektionsebene nach Texturen sortiert wird. Dennoch summiert es sich am Ende natürlich (nicht zuletzt auch wegen der sortierten GUI-Fenster und deren Inhalt).
so, jetzt bin ich wirklich fertig mit der Umstellung auf das OpenGL Core Profile. Die gesamte, rudimentäre GUI funktioniert wieder, Karte und Asteroidensimulation können dank FBOs und Render-to-Texture sowohl auf Wände als auch auf die GUI gemappt werden. In der folgenden Szene haben die beiden entsprechenden GUI-Fenster bewusst keinen Titel: Hier sieht man den Edit-Mode und zwei Debug-Fenster, in diesem Fall mit Titel und Rahmen: Schaut man auf die Statistiken rechts oben, mag auffallen, dass es recht viele Drawcalls, Shader- und Texturwechsel sind (zumindest für das simple Bild). Das ist darauf zurückzuführen, dass es recht viele Reflektionen gibt und pro Sichtstrahl eine Spalte gerendert wird. Das ist schon einigermaßen optimiert, indem für jede Reflektionsebene nach Texturen sortiert wird. Dennoch summiert es sich am Ende natürlich (nicht zuletzt auch wegen der sortierten GUI-Fenster und deren Inhalt).