Anti-Jammer-Thread

[Jonathan]

Ja, ich arbeite noch an den Ergebnissen.

Zu den Quads: Hier gibt es eine Übersicht, nach welchen Mustern Tessellation zusätzliche Geometrie erzeugt: https://www.khronos.org/opengl/wiki/Tes ... primitives

Gibt man statt Vierecken jeweils zwei Dreiecke rein, kriegt man also eine ganz andere Verteilung heraus (weniger gleichmäßig, und abhängig davon, welche der zwei möglichen Diagonalen benutzt wird). Lustigerweise produziert aber auch der Quad-Tessellation-Modus am Ende bloß Dreiecke, aber halt im Quad-Layout. Und will man dieses "schöne" Layout haben (wollte ich) müssen vorne halt Quads reingeschmissen werden (nur der Indexbuffer ändert sich). Und um sicher zu stellen, dass immer die richtigen 2 Dreiecke zu einem Quad werden, sollte das Layout halt schon vor dem Export in Blender definiert sein, sprich Quads all the way through.

Gut, heutzutage ist Tessellation vielleicht selbst überholt und man sollte Nanite oder ähnliches verwenden. Aber das bau ich jetzt nicht mal eben so nach...

[Schrompf]

Godot will mich doch noch haben! Ich bin in der engeren Auswahl!

Godot hat ne Stiftung dahinter und bissl finanziellen Spielraum. Daher haben sie vor paar Monaten nach nem Coder gesucht, der auf Rechnungsbasis daran mitarbeitet. Ich hab mich damals beworben, hab ja schon einiges an OpenSource gemacht und hab 30 Jahre on and off Erfahrung mit 3DEngine-Entwicklung. Aber die haben halt auch jetzt schon viele Dutzend Freizeitcoder, die bei jedem Release aushelfen. Und daher hat es mich gar nicht gewundert, dass ich jetzt monatelang gar nix mehr von denen gehört habe.

Bis gerade eben 🥰

[Krishty]

Sehr geil! Gratulation!

[Matthias Gubisch]

Gratulation :) Freut mich für dich!

[Mirror]

Glückwünsche, hoffe Du kriegst den Job.

[Jonathan]

Noice!

[Tris]

Godot will mich doch noch haben! Ich bin in der engeren Auswahl!

Godot hat ne Stiftung dahinter und bissl finanziellen Spielraum. Daher haben sie vor paar Monaten nach nem Coder gesucht, der auf Rechnungsbasis daran mitarbeitet. Ich hab mich damals beworben, hab ja schon einiges an OpenSource gemacht und hab 30 Jahre on and off Erfahrung mit 3DEngine-Entwicklung. Aber die haben halt auch jetzt schon viele Dutzend Freizeitcoder, die bei jedem Release aushelfen. Und daher hat es mich gar nicht gewundert, dass ich jetzt monatelang gar nix mehr von denen gehört habe.

Bis gerade eben 🥰

Sehr cool, ich drück die Daumen!

[mtorc1]

Daumen sind gedrückt, Schrompf!

[Schrompf]

Danke, ist lieb, aber habe soeben gerade die Ablehnung erhalten. Naja, mach ich halt meinen eigenen Mist weiter

[Jonathan]

Fiesen Bug gefixt:

Kaputt:

Richtig:

Was war los? Ignorieren wir mal kurz auf der rechten Seite die Shadow-Mapping Probleme und schauen uns den linken Rand des Flusses an. Das Wasser am Ufer ist seicht, also wird es langsam transparent und es gibt keinen harten Übergang. Im kaputten Bild erkennt man aber eine sehr harte und hässliche Kante. Witzigerweise aber nur links, rechts ist der Übergang weich (wie gesagt, man muss den Schatten da erstmal ignorieren).

Die Landschaft wird von einer Heightmap per Tessellation gerendert. Das Wasser ist eine simples Viereck, und hat auch Zugriff auf die Terrain Heightmap. Aus Fragment-Position und Heightmap-Wert kann man dann sehr leicht die Wassertiefe bestimmen und den Alpha-Wert anpassen. Nun gibt es da irgendeine Art von dusseligen Offset, schaltet man das Terrain aus, sieht man, dass auch links das Wasser ausgeblendet wird, nur halt ein wenig zu spät. Mist.

Ich habe dann lange nach dem Fehler gesucht. Ich dachte, ich hätte im Tessellation irgendwo einen Offset-Bug. Denn Wasser hatte ich ja früher schon, und da funktionierte das Blending. Vielleicht ist auch die Terrain Auflösung zu niedrig, und Heightmap und Mesh haben unterschiedliche Höhen - aber eigentlich sollte ja Texturpixelinterpolation und lineare Interpolation zwischen den Vertexen des Dreiecks die selben Werte liefern. Hundert Kleinigkeiten die schief gehen könnten.

Am Ende war der Fehler mal wieder komplett woanders. Ich erstelle für das Terrain erst das Mesh zum Rendern (flach, weil ja später Tessellation kommt) und dann aus der selben Heightmap ein Triangle-Mesh für Bullet-Physics für Kollisionsbehandlung. Dabei muss ich auf die Pixel der Heigthmap zugreifen und bin entsprechend von 0 bis Auflösung-1 gegangen. Fürs Rendern hatte das Mesh aber einen Zeile und Spalte mehr (3x3 Vertexe für 2x2 Pixel der Heightmap, jajaja, ich weiß jetzt selber, dass das falsch war :P). Ok, aber was hat das Wasser mit Kollissionsabfrage zu tun? Nun, das Wassermesh wird etwas später erstellt, anhand der Größe der Landschaft, die sich aus der Bounding-Box des Kollissionsobjektes von Bullet ergibt. Die UV Koordinaten und Vertexpositionen wurden korrekt berechnet, nur war das Mesh leider 1/512 zu klein, was zu einem Mini-Offset führte, der jetzt mein Blending vom Wasser kaputt gemacht hat.

Ein richtig fieser Fehler also, einmal quer durchs gesamte Programm. Bin froh, dass ich das gefunden habe, rückblickend hätte ich daran auch noch sehr viel länger suchen können...

[Schrompf]

Sowas ist echt hart zu finden. Gute Arbeit!

[Jonathan]

Hab boost gerade als Abhängigkeit komplett entfernt.

Weil C++ nunmal so ist, wie es ist, will man ja immer möglichst wenig Abhängigkeiten haben. Und boost Speziell ist so unglaublich langsam zu kompilieren, das es echt keinen Spaß macht deren Header einzubinden. Und Vieles davon ist jetzt auch eh in der Standardbibliothek, weswegen ich jetzt als C++20 kompiliere und damit alle Features habe, die ich brauchte (Format-String, UTF8 konvertieren, Filesystem, etc.)

Aber ach, die Standardbibliothek ist auch einfach nicht schön zu benutzen. Wie bekommt man einen wstring von einem UTF8 String? So:

Code: Alles auswählen

	std::string text(...);
	wstring_convert<std::codecvt_utf8<wchar_t>> conv;
	std::wstring wtext = conv.from_bytes(text);

Weil es wäre ja viel zu einfach, wenn es dafür irgendeine Funktion gäbe, die das direkt macht. Stattdessen muss man über die Abstraktion der codecvt lernen (hab ich aber nicht, ich weiß jetzt weder was die Abkürzung bedeutet, noch was genau das sein soll), das richtige aussuchen (es gibt eine ganze Reihe davon) und dann ein Konverter-Objekt mit internen Zustand erzeugen und einmal benutzen. Weil ein wstring_from_utf8string() ja viel zu einfach und praktisch gewesen wäre, deswegen darf das nicht sein. hat mich dankt des obskuren Namens und der komischen Verwendung übrigens locker 15 Minuten gekostet, das zu finden. Meine Güte...

Tjo, war viel Arbeit mit wenig Effekt (ging ja vorher alles...) aber mir scheint ab und an muss etwas Clean-Up und Altlasten entfernen einfach sein. Über die Jahre kommt einiges Zusammen, je länger man nicht aufräumt, desto ärger wird es.

[Schrompf]

Glückwunsch! Ich (und mein Ex-Zwillingsbruder) sind auch seit Jahren schrittweise damit befasst. Signals ist schon ersetzt durch eine kleine eigene Struktur, format kann man ja recht reibungsarm mit C++20 ersetzen, boost::fcontext bau ich eh schon seit Jahren hardcore einzeln selbst, weil der Autor des Ganzen Flöhe kriegt. Hier und da gibt's noch lexical_cast, was ich vor ner Dekade mit großer Freude eingesetzt hab... das muss ich überall händisch ersetzen, das wird lästig.

[antisteo]

Heute mal mit den Kinder gecodet: Sie designen Räume und Missionen, ich fixe Bugs in der Usability und verbessere die Grafik

[Jonathan]

Das klingt ziemlich cool :)

[Schrompf]

Ich habe gestern final boost aus unserem Framework entfernt. Eine Dependency weniger ist nicht nur gut für meine zukünftigen CMake-Bestrebungen, Boost ist auch in vielen Teilen ein sinnlos überdesigntes unnötig kompliziert zu nutzendes Produkt, das mir unsympathisch ist. Und ein Total Rebuild braucht jetzt noch 9s anstatt ~20s vorher. Weil wir ja seit Anbeginn der Zeit Precompiled Header einsetzen und da halt alles an Includes drin haben, was wir irgendwo brauchen könnten - und wenn man da an ner zentralen Stelle sowas komplexes wie die Boost-Header raus nehmen kann, hat das stattlichen Einfluss.

[Jonathan]

Nice. Halbierung der Build-Zeit ist schon echt ne Hausnummer :D