ZFX + Developia

Hab jetzt kein passendes Bild, aber:

Ich beschäftige mich in letzter Zeit wieder etwas mit Webentwicklung, unter anderem für 'Der Landvogt'. Benutzt hatte ich dafür zuletzt Hugo, ich wollte einen statischen Webseitengenerator, unter anderem weil die Installation so einfach ist, alles immer auch offline funktioniert und man sich quasi keine Gedanken um Sicherheitslücken machen muss. Es gibt da hunderte, aber Hugo scheint mir mit am populärsten zu sein.

Nachdem ich einige Tage Arbeitszeit investiert habe um Hugo zu lernen habe ich die Schnauze voll. Das Ding mag ok sein wenn man ein vorgefertigtes Layout runterlädt und nur noch mit Inhalt bestückt, aber wer will das schon. Meine Webseite ist jedenfalls komplett selbst gemacht, nicht weil ich zu stolz wäre fertige zu benutzen, sondern weil ich mit keinem einzigen Template zufrieden war.
Aufgegeben habe ich schließlich, als ich eine einfache Slideshow dynamisch gestalten wollte. Sprich, es sollten einfach alle Dateien mit einem bestimmten Namensschema in einem bestimmten Order angezeigt werden. Den html / Java Code hatte ich recht schnell am laufen, bloß den dynamisch mit Inhalt zu füllen habe ich auch nach stundenlanger Recherche nicht hinbekommen. Und das so etwas triviales so lange dauert (oder vielleicht sogar unmöglich ist?) hat mich dann derartig aufgeregt das ich beschloss Hugo nie wieder zu verwenden.

Die Alternative lautet Python mit jinja2 als Template-Engine und markdown als Markdown->HTML Konverter. Die beiden Pakete sind schnell installiert und man hat mit 50 Zeilen Python-Code innerhalb von zwei Stunden seinen eigenen Webseiten-Generator geschrieben. Der HTML/JavaScript/CSS-Code für meine Seite konnte ja einfach übernommen werden, an den Templates waren auch nur kleinere Anpassungen nötig. Und schon kann ich alle Features so wie ich sie brauche in Python implementieren. Und seien wir ehrlich, die allermeisten (wie das Beispiel oben) sind irgendwo trivial und wenn man Erfahrung in Python hat hat man sie von Hand schneller Implementiert als man in der dusseligen Hugo-Dokumentation irgendeine Möglichkeit findet, es dort umzusetzen.

Kein großer Fortschritt, aber ich bin mal wieder dran: Voxel Cone Tracing. Ich habe ein fieses Datenmengen-Problem, und ich glaube, ich habe den Ursprung gefunden. So sieht's gerade aus:
Was man hier sieht: Pro Pixel die Voxelauflösung der vorsortierten SVT-Nodes: hinten blau, das heißt Baumtiefe >= 4 (80cm-Voxel und größer). Grün ist Baumtiefe 1,2,3, also 10cm bis 40cm Voxelgröße. Und Rot final ist volle Voxelauflösung, also 5cm-Voxel. Die Helligkeit der Anteile besagt die Anzahl der Nodes in der Vorauswahl für dieses 4x4-Pixel-Segment. Und da sieht man: das geht in die Sättigung, also jeweils >256 Stück. Allein in der Vorauswahl. Hier ist was faul. Denn selbst wenn der Cone Tracer jeden SVT-Node vorauswählen würde, egal ob gefüllt oder leer, wären das bei 5cm-Voxeln trotzdem 10m an Voxelmasse. Die gibt's in dieser Szene nicht. Und das ganze Bild wirkt wie weichgezeichnet. Jedes Element der Ursprungsszene hat ein weiches Halo um sich rum, das kann nicht sein. Ich vermute, irgendwas an meiner VoxelCone ist deutlich größer, als mir lieb ist. Und ich werde es finden, weil das Kind gerade von der freundlichen Nachbarin betreut wird.

Schnapp es dir! Der Cone hat jetzt seinen letzten Köttel geschissen!

Ne. Stellte sich beim Debuggen heraus, dass die Node-Vorauswahl wahrscheinlich korrekt so ist und es wirklich so viele Nodes sind. Sind ja nicht nur Nodes hintereinander, sondern jeder berührte Node, also 2 bis drei Nodes neben- und übereinander. Anderthalb Stunden wertvolle Freizeit und zurück auf 0. Ficken McNuggets.

[edit] Dafür hat ne Mini-Änderung an ner anderen Stelle das Tempo mal eben verdoppelt. Nuja, ist halt alles noch sehr roh.

Mein Projekt der letzten Wochen war zwar sehr PC-bezogen, aber wurde nicht auf dem PC durchgeführt. Habe mir einen neuen Rechner gebaut:



Bild anklicken für mehr Bilder, auch aus dem Montage-Prozess

Der ConeTracer dekomprimiert jetzt auch die Leaf Nodes des Sparse Voxel Trees: 8³ bitkomprimierte palettierte Voxelblöcke. Weil das fäkalienviel Rechenzeit frisst, hab ich einen kleinen Cache dazwischen geschaltet. Teile von all dem sind jetzt schon hübsch vektorisiert. Es fehlt allerdings immer noch das finale Flächenintegral Pixel vs. Voxelblob. Das wird alles so absurd langsam werden, dass ich es eigentlich gleich sein lassen kann.

Ein paar erste Versuche mit Gui-Skinning, Scale-9-Methode zum Zeichnen von Rechtecken beliebiger Größe.
Die Designs sind nur experimentell, aktuell kein besonderer Verwendungszweck angedacht, und auch nicht wirklich zu Ende designt.
Font-Rendering diskutieren wir jetzt mal nicht ;) Bis auf Weiteres gibts bei mir lediglich Monospaced mit Bilinear-Filter.
Layoutsystem fürs Gui ist dasselbe wie immer bei mir, immediate in 3 Stufen (Layouting, Handling, Rendering) und adaptiv.

Schick! Einige Styles sehen für mich sogar live verwendbar aus, so gar nicht nach Programmer's Art

Was ist neu? Ich meine außer dass ich ein paar Zeilen in der Main umgestapelt habe, damit die Framerate mit aufm Screenshot ist? Fricking dreifache Framerate, Bitchinnen und Bitcher! Ich habe einfach die Schleifen umgekrempelt. Vorher bin ich pro Bild-Subsegment durch alle vorselektierten Nodes gegangen, jetzt gehe ich pro Node in der Vorauswahl durch alle Bild-Subsegmente. Erspart ne Menge Voxelblock-Dekompressionen und damit massiv Rechenzeit.

Ich bin am Überlegen, ob ich meine "Vom Groben zum Feinen"-Unterteilung noch kleiner mache. Aktuell reduziert der das Detail im Verhältnis 4 zu 1, das heißt ein Bildteil wird in 4x4 Untersegmente aufgeteilt. Das erspart zwar einiges Umstapeln, aber sorgt leider auch dafür, dass meine Wanderfunktionen durch den Voxelbaum rekursiv sind. Wenn ich auf "2 zu 1" umstellen würde, könnte ich fest davon ausgehen, dass jeder Unter-Strahl durch die Szene halb so groß ist wie die Bounding Cone des Parents. Dann weiß ich auch mit Sicherheit, dass ich jeden Node der Vorauswahl nur eine Stufe im Voxelbaum weiter gehen muss, also keine Rekursion mehr und eine Gelegenheit, die 2³ Subnodes vektorisiert im Ganzen zu verarbeiten.

Keine Ahnung, ob das mehr bringt, als die zusätzlichen Zwischenschritte kosten. Bei Gelegenheit.

joeydee hat geschrieben: ↑31.01.2021, 12:30Ein paar erste Versuche mit Gui-Skinning, Scale-9-Methode zum Zeichnen von Rechtecken beliebiger Größe.
Die Designs sind nur experimentell, aktuell kein besonderer Verwendungszweck angedacht, und auch nicht wirklich zu Ende designt.
Font-Rendering diskutieren wir jetzt mal nicht ;) Bis auf Weiteres gibts bei mir lediglich Monospaced mit Bilinear-Filter.
Layoutsystem fürs Gui ist dasselbe wie immer bei mir, immediate in 3 Stufen (Layouting, Handling, Rendering) und adaptiv.

Sehr cool. Wenn ich meine unterschiedlich aussehenden GUIs betrachte (klassisch Win32 ggü. Fluent) sind die Farben weniger das Problem, als viel mehr das Layout mit komplett unterschiedlichen Margins und so. Sollte man nicht unterschätzen.

Schrompf hat geschrieben: ↑31.01.2021, 13:35Ich bin am Überlegen, ob ich meine "Vom Groben zum Feinen"-Unterteilung noch kleiner mache. Aktuell reduziert der das Detail im Verhältnis 4 zu 1, das heißt ein Bildteil wird in 4x4 Untersegmente aufgeteilt. Das erspart zwar einiges Umstapeln, aber sorgt leider auch dafür, dass meine Wanderfunktionen durch den Voxelbaum rekursiv sind. Wenn ich auf "2 zu 1" umstellen würde, könnte ich fest davon ausgehen, dass jeder Unter-Strahl durch die Szene halb so groß ist wie die Bounding Cone des Parents. Dann weiß ich auch mit Sicherheit, dass ich jeden Node der Vorauswahl nur eine Stufe im Voxelbaum weiter gehen muss, also keine Rekursion mehr und eine Gelegenheit, die 2³ Subnodes vektorisiert im Ganzen zu verarbeiten.

Keine Ahnung, ob das mehr bringt, als die zusätzlichen Zwischenschritte kosten. Bei Gelegenheit.

14 fps ist was, Respekt.

Das „bei Gelegenheit mal implementieren und benchmarken“ ist leider auch die einzige Strategie, die ich habe. Mit meinem Voxel-Kram habe ich viele sehr schlaue und sehr gut auf SIMD abgestimmte Algorithmen implementiert, und die meisten waren am Ende doch irgendwie langsamer als der naive erste Versuch :(

Erste Ergebnisse des echten PixelRechteck vs. VageRunderVoxelBlob-Integrals. Es stimmen noch tausend Sachen nicht, und es rendert aktuell nur ein 4³-tel der echten Voxelauflösung, und es ist popolangsam. Aber es tut.

Fortschritte. VoxelBlobs sind jetzt einfache Rechtecke, weil der Profiler gezeigt hat, dass 40% der gesamten Rechenzeit allein für die powf() im PixelRechteck vs. VoxelBlob-Flächenintegral draufgegangen sind. Und ich habe die Farbbestimmung für alle Detailstufen ausprogrammiert, die vorher gerne mal mangels echter Funktionalität Einheitsweiß eingesetzt haben. Und da lauert noch irgendwo ein Bug in der "Durchschnittsfarbe von 8 Voxeln bestimmen"-Funktion, die im Debugger völlig valide aussieht, aber eine ganze Tiefenschicht in dichtes Schwarz hüllt.

Außerdem gibt's jetzt ne einfache Tiefensortierung durch taktisches Invertieren der Reihenfolge, in der Subelemente eines SVT-Nodes durchgegangen werden. Vorteil: es kostet quasi keine Rechenzeit. Nachteil: er sortiert nur die Subnodes innerhalb eines Nodes um, weswegen man an den Grenzen großer SVT-Nodes doch wieder Kanten aus der Tiefe durchschimmern sieht. Aber auch die perfekt anti-aliased. Pff.

Weiß nicht, wie weit ich das noch treiben will. Eigentlich müsste ich endlich mal die echte Voxelauflösung rausholen, aktuell schaltet der schon bei nem Viertel der echten Tiefe auf die nächstgrößere Voxelstufe um. Aber dann wird's noch langsamer, und es ist jetzt schon unerträglich. Ne echte Tiefensortierung täte auch Not. Ist doch alles Kacke.

Schrompf hat geschrieben: ↑03.02.2021, 15:19dass 40% der gesamten Rechenzeit allein für die powf() im PixelRechteck vs. VoxelBlob-Flächenintegral draufgegangen sind

Als jemand, der eine eigene powf()-Implementierung pflegt, bin ich überrascht, dass das so schnell war :D

Es gibt sogar Intrinsics für powf, exp(), log(), die 8x float32 verarbeiten. Allerdings ohne Angabe von Throughput oder Latenz. Jemand auf StackOverflow will wissen, dass es daran liegt, dass die Intrinsics eine komplexe Reihe µOps generieren, deren Kenndaten man nicht so einfach ermitteln könnte. Ich würde aber zumindest gern eine Größenordnung wissen. Nuja, den Teil will ich auch noch avxen, dann werde ich es wahrscheinlich merken.

Größenordnung: 50 Takte für meine Version und günstige Parameter (nur positive floats)

Mein Pessimismus hätte der double-Version gelten sollen – float kommt tatsächlich ohne Schleifen aus!

AVX hat keinen pow-Befehl*. Die alte FPU hatte einen(?), und der löste zu einer µOp-Sequenz auf. Wenn du ein Intrinsic für AVX-powf() siehst, ist das im Grunde nur eine Inline-Funktion, die der Compiler bereitstellt.

Nach meiner Erfahrung ist ein großes Problem die Behandlung von Randfällen (wenn die Basis negativ ist, darf der Exponent nur eine ungerade Zahl ungleich Null sein, …). Schau dir mal diese Liste an. Für jeden dieser Fälle muss man entweder Inf oder NaN zurückgeben, oder eine vernünftige errno setzen Ausnahme werfen. Die CPU hat Sprungvorhersage, klar – aber wenn du 10 Slots verbrauchst, um vorherzusagen, dass dein powf() immer nur positive Basen+Exponenten mit endlichen Ergebnissen kriegt, fehlen die halt wo anders.

Und bei SIMD bedeutet das, dass du immer alle Zweige berechnen, und dann pro Spur durchschalten musst.

Hier könnte ein Compiler mit seinen Intrinsics gut was sparen, wenn die Eingabewerte in einem bekannten Bereich liegen. Meine eigenen Versionen machen schlicht Garbage-in-Garbage-out; das hat sie drastisch zusammengestutzt.

double ist noch einmal eine andere Nummer (größere Lookups, längere Polynome, double-Genauigkeit nicht ausreichend für exakte Berechnung). Meine gestutzte Version zählt 150–200 Takte für günstige Werte. Hui.

* Einer der neuesten AVX-512-Befehlssätze bringt einen nativen exp2()-Befehl mit, sehe ich. Das beschleunigt pow(), da das üblicherweise als Folge von log2() und exp2() realisiert ist. Das Ergebnis ist aber nur eine Annäherung auf 2^23 und muss weiter verfeinert werden, wenn man volle float-Genauigkeit haben möchte.

Water Breakout, ein kleiner Breakout-Clone.

Das war ursprünglich mal ein Studentenprojekt, ich habe es aber neulich nochmal ausgegraben und will es jetzt ein wenig aufpolieren. Unter anderem werden Musik und Soundeffekte hinzugefügt, und ein paar kleinere Anpassungen vorgenommen. Das ganze sollte dann in ein paar Tagen fertig sein, dann stelle ich es richtig vor.

Hallo zusammen,

ich wollte mich mal etwas tiefer in die GPU-Programmierung stürzen und damit verbunden das Readback zur CPU. Dafür eignet sich 2D-Fluiddynamik hervorragend. Dadurch ist ein kleines Projekt "BattleSub" entstanden, noch nicht fertig, aber mein kleiner Ausflug in die genannten Gefilde. Ich hinterlasse einfach mal den GitHub-Link, bevor ich es mit den eingebetteten Bildern hier verdaddel:

https://github.com/bfeldpw/battlesub

Kleiner Disclaimer für die, die es tatsächlich testen wollen: Das Ganze ist unter Linux entstanden und erstmal mit den Build-Skripten auch nur so lauffähig, mit Windows kenne ich mich leider kein bisschen aus.
Kleiner Disclaimer für die, die in den Code schauen: Nachdem ich sonst alles ordentlich und selbst machen wollte, habe ich mich hier maßgeblich zweier großartiger Bibliotheken bedient (Magnum Graphics im Prinzip als OpenGL-Wrapper und EnTT als Entity-Component-System) und ansonsten versucht, schnell etwas umzusetzen. Daher ist vieles eher Quick 'n' Dirty.

Beste Grüße

Edit: Okay, ich probiere es doch mal mit einem Screenshot: Zu sehen sind zwei statische Geschwindigkeits-/Dichtequellen zum Testen, die U-Boote (daher der Titel BattleSub), ein sehr dunkler Felsen und klein in orange ein paar abgefeuerte Projektile (deren Bahn kann man im Fluidfeld erahnen).

Hi,

und danke für die Informationen: Magnum Graphics und EnTT! Das sieht sehr vielversprechend aus; und da ich schon viel von diesem Entity Component System gehört, aber irgendwie nicht verstanden habe, freue ich mich über ein Framework dazu; mir geht es meist so, dass wenn ich mit einem Thema in der Praxis zu tun habe, es besser verstehe.
Mal sehen, denn ich habe vor in Zukunft wieder mehr im Freizeitsektor zu programmieren.

Auch danke für deinen Quellcode. Ich finde es immer schön zu sehen wie andere Entwickler arbeiten; vlt kann ich da noch etwas lernen.

Ach und: schöner Screenshot. Finde ja dieses Partikelgedöns schon ziemlich beeidruckend, auch weil ich nicht wüsste wie ich so etwas umsetzen sollte.

Gruß :)

Danke für die Rückmeldung.

Ja, Magnum und EnTT sind sehr gut gepflegt und viel benutzt, aber immer noch eher Middleware, das passt mir ganz gut in den Kram. Und nicht zuletzt gibt es viele Bereiche, gerade das sinnvolle Speichermanagement bei ECS', wo ich einfach gar nicht wüsste, wo ich anfangen soll. Nach irgendwelchen naiven Speicherpools mittels std::vector oder std::deque hört es bei mir momentan auf, an eigene komplexe Speicherallokatoren oder so wage ich mich auch aus Zeitgründen lieber nicht ran ;-)

Auf der GitHub-Seite sind noch mehr Screenshots, die etwas mehr den Blick hinter die Kulissen erlauben.

Hab die Rundung meines Dungeons hinbekommen. Basismesh ist eine klassische DungeonMaster-artige TileMap aus 2m-Würfeln, weil ich seit Jahren das diffuse Verlangen nach einem Grid Based Dungeon Crawler mit mir rumtrage. So richtig mit Feuerball-Fallen, versteckten Knöpfen und Bodenplatten. Und weil ich das in Sachen Assets sicher nicht gestämmt kriege, dachte ich - hey Meshes nur aus rechteckigen zueinander senkrechten Flächen wären doch ein super Testballon für meine Oberflächengenerierungs-Lib.

Also sollen die Dungeonwände jetzt Höhlen werden. Ein paar Layer Simplex-Noise, ein bissl Materialblenden hier und da - sollte eigentlich machbar sein, ne? Ich brauch ja nur eine halbwegs kontinuierliche Oberfläche entlang der Kanten, damit ich da tesselieren und extruden kann, ohne das das Zeug sich nahe den Kanten selbst durchdringt. Pustekuchen. Hab ja oft genug im IRC darüber gejammert, was dabei alles schief gehen kann. Vor allem weil hier konvexe und konkave Krümmungen aufeinander treffen, und alle Weisheiten, die ich im Internet fand (Z.b. Chamfer - https://en.wikipedia.org/wiki/Chamfer_(geometry) - Danke an xTrim für den Tipp), versagen bei solchen Konstellationen. Grmpf.

Jetzt habe ich eine Krümmungstechnik gefunden, die rein auf dem Kontrast Flächennormale zu Vertexnormale basiert. Klappt noch nicht ganz perfekt, manche Kurven sind überkrümmt, aber hey - als Basis für ne Extrusion sollte es doch reichen.

Das heißt, wenn ich dich richtig verstehe, dass die Meshes der einzelnen Tiles immer passend miteinander abschließen, weil der Algorithmus allein aus Position und Vertex-Normale der "Konnektionspunkte" die Krümmung (bzw. Zwischen-Vertices?) generiert. Und daher auch der aktuelle "Sinuskurven-Look". Oder habe ich das falsch aufgefasst?
Wäre es nicht klüger, gemeinsame Vertex-Positionen an den Schnittstellen der Tiles zu definieren. Quasi ein Tile gibt es vor und die anderen müssen schauen, wie sie daran Anschluss finden. Wie genau man idelaerweise realisiert wüsste ich ad-hoc auch nicht, aber ich glaube auf Dauer fällt das dem Auge unangenehm auf, dass die Verbindungen zu uniform sind.

Schaut aber witzig aus auf dem Bild. Ich musste spontan an "Röhrenbauten" denken wie bei U-Booten oder Raumschiffen.

Die Vorgabepunkte bewegen sich gar nicht. Das ist der Unterschied zu den bisherigen Versuchen, wo ich die Eckpunkte nach "innen" oder "außen" verschoben habe und die Flächenmitten blieben. Und das Schöne an all diesen Lösungen ist, dass sie isoliert arbeiten können: dadurch, dass die Eingabeparameter dieselben sind, ist die sich ergebende Kurve auch dieselbe, und es reisst Dir auch ohne Berücksichtigung der Nachbarschaft keine Lücken in den Mesh.

Es bleibt so allerdings nicht, das hier ist nur ne Arbeitsbasis, um jetzt Displacement und CSG draufzuhauen. Wie ich oben schon schrieb: wenn Du Displacement auf die ursprünglichen Würfelflächen haust, dann läufst Du Gefahr, dass Dir nahe der Kanten die Geometrie ineinander ragt.

Meine Noise-Funktion hat anscheinend Unstetigkeiten... stellt sich heraus, dass man selbst in der Interpolation einex 2³-float-Blocks noch Fehler machen kann.

Sieht iwie stylisch aus. Erinnert mich wegen vom Look ein wenig an Bound

Und technisch erinnert mich das irgendwie an das hier... 😂
viewtopic.php?p=22211#p22211

Ja, passt. Aber da Du nie schreibst, wie Du's machst, isses für mich eigentlich egal, was Du tust :-)

Schrompf hat geschrieben: ↑04.04.2021, 23:03 Ja, passt. Aber da Du nie schreibst, wie Du's machst, isses für mich eigentlich egal, was Du tust :-)

Ich hingegen finde es interessant, dass du den gleichen Entwicklungsprozess durchläufst.
Bin auch schon gespannt, wann du auf Halbmeterblöcke runter gehst.

Was den Vorwurf betrifft, erinnere ich mich an Projekt - Antialiased triangle rendering

Schrompf hat geschrieben: ↑23.07.2020, 21:53 Dein Ergebnis sieht schon ziemlich gut aus, aber da Du nicht verrätst, was Du da tust, kann ich das nicht bewerten.

woraufhin ich dir den Quellcode gepostet habe...

Und außerdem will ich dich ja auch nicht zu sehr mit meinen Ratschlägen belästigen 😂

Schrompf hat geschrieben: ↑14.02.2020, 20:57 Ich will nichts von Dir wissen, Danke.

Ok, das war sehr allgemein formuliert, sorry. Korrekter wäre: Du hast *in diesem Fall* nicht verraten, wie Du es machst, also habe ich ohne Deine Lösung rumexperimentiert. Ich hab das theoretisch auch schonmal für die Splitterwelten geschrieben, aber damals hat das auch noch nicht so gut funktioniert. Das Dreieck war ja ein späterer Zudomon, und da habe ich mich ja auch öffentlich drüber gefreut. Tut mir leid, wenn Dich diese empfundenen Kränkungen nach all den Jahren immer noch grämen.

Schrompf hat geschrieben: ↑05.04.2021, 13:44 Ok, das war sehr allgemein formuliert, sorry. Korrekter wäre: Du hast *in diesem Fall* nicht verraten, wie Du es machst, also habe ich ohne Deine Lösung rumexperimentiert. Ich hab das theoretisch auch schonmal für die Splitterwelten geschrieben, aber damals hat das auch noch nicht so gut funktioniert. Das Dreieck war ja ein späterer Zudomon, und da habe ich mich ja auch öffentlich drüber gefreut. Tut mir leid, wenn Dich diese empfundenen Kränkungen nach all den Jahren immer noch grämen.

Ja, das klingt schon viel besser, da freut sich der noch spätere Zudomon... danke 😄

Bei der damaligen Version gab es aber auch nichts "zu verraten". CodingCat hatte ja damals gefragt, wie ich die Texturen mappe... und hatte ja geschrieben, dass es Normalenabhängige Überblendungen waren. Das hattest du ja in Splitterwelten bereits verwendet. Und die Minecraft Cubes ist ja nichts besonderes. Wenn man die Displacen will, ist ja auch klar, dass man die Gouraud Normalen nutzten muss, damit das alles nicht auseinanderreißt.