ZFX + Developia

Verfasst: **08.04.2021, 21:38**

Meine runde Subdivision (inzwischen auf Basis von Bezier-Patches, vielen Dank euch allen!) läuft, und jetzt auch der Fels aus 6 Oktaven SimplexNoise. Die 3D-Noise-Funktion ist handoptimiertes AVX256, eigentlich eine völlige Verschwendung meiner raren Hobby-Lebenszeit, aber mir war danach. Und ich muss hier nochmal den VisualStudio-Debugger loben, der selbst bei solchem Vektorgedöns vorbildlich Vars auflöst und Werte anzeigt.

2m^2-Segment besteht jetzt aus 512 Dreiecken und ner 1024er Textur, jedes der paar hundert Segmente ist unikat. Generierung aller Segmente dauert aktuell ~15s auf 12+12 Kernen.

Ich habe allerdings immer noch sichtbar regelmäßige schräge Streifen drin. Die skalieren mit der Noise-Eingabe-Position, aber in der Farbtextur (die ich erstmal plump aus dem selben Noise speise), sind keine Streifen erkennbar. Die entstehen also irgendwie im Zusammenspiel zwischen Noise und NormalMap-Werteproduktion. Das wär vielleicht auch ein Thema für den anderen Thread. Vielleicht gibt's dafür ja etablierte Techniken oder coole Ideen.

Verfasst: **08.04.2021, 21:48**

Schrompf hat geschrieben: ↑08.04.2021, 21:38Und ich muss hier nochmal den VisualStudio-Debugger loben, der selbst bei solchem Vektorgedöns vorbildlich Vars auflöst und Werte anzeigt.

Ich dachte erst, du willst mich verhöhnen … aber ich vermute, dass du schlicht kein __vectorcall benutzt hast? Ich jedenfalls bin seit ein paar Jahren nur noch mit printf() unterwegs, weil Visual C++ mir kaum noch Vektoren anzeigen kann und das Ticket auf Won’t Fix steht.

imagine being krishty
> someone on the internet says Visual Studio worked well
> triggered
> furiously scroll through your list of VS bug tickets
> type a 200-word rant on a three-year old bug
> find out that they didn’t micro-manage calling conventions on live disassembly, therefore didn’t hit your bug
> delete everything and stop

Aber Respekt für’s Ergebnis! Sowas wollte ich auch mal ganz doll gern machen; beim Angucken geht mir einer ab.

Verfasst: **08.04.2021, 21:55**

Zeig mal bitte ohne Noise.

Verfasst: **08.04.2021, 23:13**

Ohne Noise sieht man noch die Normalen-Kanten. Das meinst Du wahrscheinlich. Hab jetzt auf die Schnelle vergessen, die Noise auch in der Farbtextur abzuschalten, aber egal.

Hab's auch auf die Schnelle nochmal mit ner Übertreibung / Untertreibung des Rausschiebens des mittlersten Stützpunktes versucht. Aber normaler Durchschnitt der drei Punktprodukte ist echt das Glatteste. Die Kanten in den Normalen gibt's immer.

[edit] Korrekt, kein vectorcall. Und Debug-Build, was bei handgeschriebenen Intrinsics mit MSVC ja egal ist. GCC und Clang optimieren angeblich selbst Intrinsics, MSVC nicht.

Verfasst: **09.04.2021, 01:35**

Schrompf hat geschrieben: ↑08.04.2021, 23:13GCC und Clang optimieren angeblich selbst Intrinsics, MSVC nicht.

Keine Ahnung, was du meinst?!

https://godbolt.org/z/MfTd5e817

Circa 2017/18 hatten sie den SIMD-Optimizer generalüberholt. Ist längst nicht so radikal wie der von Clang/GCC -O3, aber immerhin.

Verfasst: **09.04.2021, 08:01**

Schrompf hat geschrieben: ↑08.04.2021, 23:13 Die Kanten in den Normalen gibt's immer.

Hatte ich ja auch schon angesprochen. Es scheint, die Normalen an derselben Kante (Diagonale) zeigen in unterschiedliche Richtungen, je nachdem ob sie vom oberen oder vom unteren Dreieck berechnet wurden? Und es scheint auch harte Kanten in der Geometrie zu verursachen. Der angeschnittene Knubbel rechts vorn, der hat so einen Grat.
Ich würde mal mit Noise gar nichts machen, bis ich hier nicht eine Methode gefunden habe, da absolut glatte kontinuierliche Oberflächen zu erzeugen wo optisch keine Patch-Grenzen mehr feststellbar sind. Entweder Bug, oder Algo taugt hierfür gar nicht.
Aber ok, deine Prämisse war "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." - Das "halbwegs" hast du damit ja erreicht ;)
(Von diesem Problem unabhängig, aber auf deine Aussage bezogen: kontinuierliche Oberfläche verhindert nicht grundsätzlich die Durchdringung)

Verfasst: **09.04.2021, 08:28**

Da fehlt imho einfach ein smoothes Shading. Die Faces werden ja noch facettet angezeigt. Aber das Ergebnis ist schon klasse :)

Verfasst: **09.04.2021, 12:07**

Schrompf hat geschrieben: ↑08.04.2021, 23:13 screenshot0038.png

Ohne Noise sieht man noch die Normalen-Kanten. Das meinst Du wahrscheinlich.

Danke. Nein, eigentlich wollte ich nur sagen es sieht ohne Noise subjektiv besser aus als mit (das hatte ich vermutet). Das Ding bei so einem Felsen ist ja, dass er eben gerade nicht noisy ist, sondern Struktur hat.

Verfasst: **11.04.2021, 12:59**

Ich entwerfe gerade ein Alternativ-Format für SVG (und HVIF), hier sind die ersten Baby Steps:

Bild

Ziel des ganzen: Klein zu sein, sowohl in Spezifikation/Komplexität als auch als Dateiformat. Zudem soll alles mit Integer-Arithmetik funktionieren *können*, damit das Format auch für eingebettete Geräte gut benutzbar ist

Verfasst: **11.04.2021, 18:43**

Cool! Falls du nicht sowieso daran denkst, bau auf jeden Fall nen JavaScript/wasm zu SVG oder Canvas Renderer der sehr klein ist oder was ähnliches. :) dann kann man das auch im Web nutzen.

Verfasst: **11.04.2021, 18:54**

Chromanoid hat geschrieben: ↑11.04.2021, 18:43 Cool! Falls du nicht sowieso daran denkst, bau auf jeden Fall nen JavaScript/wasm zu SVG oder Canvas Renderer der sehr klein ist oder was ähnliches. :) dann kann man das auch im Web nutzen.

Sehr guter Punkt! Zig makes it possible! <3

Verfasst: **11.04.2021, 23:58**

Meine Layout-Engine hat endlich einen halbwegs stabilen Stand erreicht:

Bild

bzw.

Es war eine einzige Qual, und ich war zum ersten Mal wirklich gezwungen, test-driven zu entwickeln (statt die Unit Tests hinterher zu schreiben, wie sonst).

Das Layouting verbraucht endlich nicht mehr als 4 KiB Code. Aber ich will mich nur noch ganz schnell unter der Dusche zusammenrollen und weinen. Deshalb auch keine ausführliche Präsentation; ich habe nur ein paar mehr Worte hier geschrieben.

Verfasst: **12.04.2021, 07:48**

Sieht von hier aus reichlich fett aus. Schöne Sache! Details lese ich mir nachher durch.

Verfasst: **12.04.2021, 15:16**

Uff, ja. Ich habe für 'Der Landvogt' ja auch ein einfaches GUI-System geschrieben, dabei aber bewusst auf dynamische Größen verzichtet. Ich habe einfach nur eine Hierarchie aus verschachtelten Widgets fester Größe für die man die Ausrichtung (links, rechts, oben, unten, mittig) und die Abstände definieren kann. Meine Ausrede war dabei aber auch, dass die meisten Elemente eben als Sprites vorliegen und dynamische Fenstergrößen dafür echt schwer werden (man muss dann anfangen die Fenster in Rahmen und Inhalt aufzuteilen, den Rahmen dann wieder in Ecken und Seitenleisten, alles muss tilebar sein, etc...).
Es macht nicht wirklich sehr viel Spaß damit zu arbeiten, aber ich will auch einfach nicht 2 Wochen lang ein besseres System bauen. Zumal GUI ja irgendwie auch nie Spaß macht.

Verfasst: **13.04.2021, 17:31**

Jonathan hat geschrieben: ↑12.04.2021, 15:16Uff, ja. Ich habe für 'Der Landvogt' ja auch ein einfaches GUI-System geschrieben, dabei aber bewusst auf dynamische Größen verzichtet. Ich habe einfach nur eine Hierarchie aus verschachtelten Widgets fester Größe für die man die Ausrichtung (links, rechts, oben, unten, mittig) und die Abstände definieren kann. Meine Ausrede war dabei aber auch, dass die meisten Elemente eben als Sprites vorliegen und dynamische Fenstergrößen dafür echt schwer werden (man muss dann anfangen die Fenster in Rahmen und Inhalt aufzuteilen, den Rahmen dann wieder in Ecken und Seitenleisten, alles muss tilebar sein, etc...).

Ganz genau das war auch am Anfang mein Gedankengang: Ein paar statische Flächen definieren und die Lücken mit Kleber auffüllen. Es wurde aber ziemlich bald klar, dass ich sehr wohl Seitenleisten und dynamische Größen brauche … schon kniffliger. Aber dann kamen die Margins, und damit traf dann die Kacke den Ventilator …

Ich habe das dumpfe Gefühl, dass ich die Margins irgendwie mit Freiräumen verschmelzen und das System damit vereinfachen kann. Im Sinne von: GUI-Beschreibungen auf die Hälfte kürzen. Nach zwei Wochen kann ich es aber wirklich nicht mehr sehen und bin nur froh, dass es *irgendwie* funktioniert.

Verfasst: **18.04.2021, 11:02**

Hallo allerseits,

ich bin ziemlich froh, dass nach einigen Tagen Arbeit nun endlich shadow casting / field of view meines aktuellen Projekts funktioniert. Perspektivisch soll es mal ein 2D MOBA werden, aktuell ist es jedoch kaum mehr als eine Techdemo.

Ich hoffe, das GIF funktioniert!

Ich traue es mich ja kaum laut zu sagen, aber das ganze läuft im Browser und ist in TypeScript geschrieben. Das ganze benutzt einen Space Partitioning Manager (hatte erst einen Quadtree, bin aber auf Spatial Hashing umgestiegen), damit er später auch mit größeren Karten zurecht kommt. Ansonsten ist der Algorithmus im Wesentlich wie hier beschrieben: https://www.redblobgames.com/articles/visibility/ und https://legends2k.github.io/2d-fov/design.html. Einige Änderungen habe ich aber vorgenommen. Bei Interesse kann ich gerne ein wenig erläutern was und wieso.

Man sieht noch den ein oder anderen Glitch, z.B. das der Schatten manchmal etwas flackert oder dass mein Stencil Buffer (man muss ja eigentlich sagen Stencil Canvas) mit dem Scrollen auf der Map noch hakt, aber das wird noch.

So, das war's erstmal und ich wünsche einen schönen Sonntag

[EDIT] Die Zylinder habe ich vergessen für die Demo zu entfernen... das sind Türme, die auf den Spieler und seine Mobs schießen

Verfasst: **18.04.2021, 11:04**

Nice :)

Verfasst: **18.04.2021, 11:14**

Sieht klasse :) Spatial Hashing kannte ich noch nicht – muss ich selber auch mal ausprobieren!

Verfasst: **18.04.2021, 11:47**

Krishty hat geschrieben: ↑18.04.2021, 11:14 Sieht klasse :) Spatial Hashing kannte ich noch nicht – muss ich selber auch mal ausprobieren!

Anstelle einer Baumaufteilung werden beim Spatial Hashing mehrere Buckets (ein Bucket entspricht einem Leaf beim Quadtree) in einer eindimensionalen(!) Liste gespeichert. Jeder Bucket hat einen Hash, der sich aus der geometrischen Position errechnen lässt. Ich mache das bei mir derzeit so:

Code: Alles auswählen

/** Returns the hash of the bucket a certain point (in px) belongs to */
public hash(x: number, y: number): number {
  return (
    Math.floor((x - this.leftTop.x) / config.spm.shEdgeLength) |
    Math.floor((y - this.leftTop.y) / config.spm.shEdgeLength) << 16
  );
}

Folglich hätte ich bei einem 32-Bit-Integer (sowas gibt es in Javascript ja gar nicht) jeweils 2^16 Buckets in X- und Y-Richtung.

Der Vorteil sind halt (1) die extrem schnellen Zugriffszeiten und (2) ein schnelles Raycasting. Wenn ein Strahl von einem Bucket in einen anderen übergeht, ist der schneller gefunden. Dieses Umspringen war mir beim Quadtree zu viel Overhead.

Spatial Hashing wird afaik vor allem dann problematisch, wenn du viele große Objekte hast, die dann in mehreren Buckets liegen müssen.

Verfasst: **18.04.2021, 13:37**

mtorc1 hat geschrieben: ↑18.04.2021, 11:47Spatial Hashing wird afaik vor allem dann problematisch, wenn du viele große Objekte hast, die dann in mehreren Buckets liegen müssen.

Es hat einen Sweet Spot, wenn die Buckets ungefähr Objektgröße haben. Darüber und darunter wird es langsamer. Dieses Paper hat zwei schöne Diagramme dazu in Figure 5 und Figure 6.

Ich habe an OpenVDB mit Spatial Hashes gearbeitet, aber leider nur sehr flüchtig. Die Übersprungzeiten im Tree unterhalb der Hashes sind da große Probleme; wenn ich mal Zeit habe (lol) prüfe ich, ob es ganz ohne Tree schneller wird.

Verfasst: **18.04.2021, 14:53**

Es geht voran. Allerdings nur auf Themengebieten, die im Bild leider komplett unsichtbar sind: adaptiver Detailgrad. Die Lib erzeugt jetzt jedes Segment in einer Detailstufe, die nach aktueller Entfernung zur Kamera angemessen erscheint. Das hat den Speicherbedarf auf ein Drittel reduziert, aber wir sind immer noch im Bereich ~3,5GB für 1024er-Texturen. Ich muss in sehr ferner Zukunft mal gucken, ob ich irgendeine der üblichen Texturkompressionen in nem Compute Shader zum Laufen kriege. 2048er gehn auch und kommen bei ~11GB raus, aber da braucht die Berechnung auf der CPU dann schon so lange, dass man stressfrei der SurfaceGen davonlaufen kann.

Der Detailgrad wird auch für die Tesselation benutzt. Das ist eigentlich sinnlos, weil die Tesselation quasi keine Rechenzeit frisst und die paar tausend Polys pro Segment jede GPU im Vorbeigehen in die Tasche steckt. Aber irgendwann in der Zukunft wird man das brauchen, vermute ich, und daher wollte ich es gleich mit erledigen. Und weil es hässliche Lücken gibt, wenn man die beiden Flächen an einer Kante unterschiedlich unterteilt, gibt's jetzt auch noch "Saum"-Meshes, die diese Lücken füllen. Der SurfaceGen spuckt die gleich mit aus für alle Kanten des Segments, die Außenkontakt haben, die benutzen Vertizes und Texturen des Segments mit und werden halt in der Szene instanziiert oder entfernt, wenn es einen Detailstufen-Konflikt an einer Kante gibt.

Damit bin ich jetzt theoretisch erstmal zukunftssicher, was verschiedene Detailgrade angeht. Leider gibt es noch zwei weitere Ursachen für Risse in den Wänden: a) mein Sand-"Shader" arbeitet nur lokal auf der Punktnormale, und die Normalen sind ja nicht stetisch über Segment-Kanten hinweg. Und b) irgendne kleine Ungenauigkeit beim Auslenken der Vertizes, wodurch Haarrisse an den Segmentkanten entstehen. Die muss ich beide noch beseitigen, bevor ich mit echtem Content weitermachen kann.

Und theoretisch müsste das alles jetzt schon auf die GPU. Nur ist da halt debuggen und rumspielen so mühsam. Mäh.

Verfasst: **18.04.2021, 22:03**

Ich wurstel weiter am Vektor-Format und Rendering. Habe mich heute mit Vulkan beschäftigt und einen Headless Renderer gebaut:

Bild

Noch nicht perfekt, vorallem nicht die Linien, aber MSAA macht das ganze einfach sehr viel hübscher <3

Verfasst: **18.04.2021, 22:14**

xq hat geschrieben: ↑18.04.2021, 22:03Noch nicht perfekt, vorallem nicht die Linien, aber MSAA macht das ganze einfach sehr viel hübscher <3

Ganz ehrlich: Fehlendes MSAA wird irgendwann der Grund sein, dass ich GDI verlasse. Das wertet die Dinge echt ungemein auf. Sehr schick!

Verfasst: **18.04.2021, 22:43**

xq hat geschrieben: ↑18.04.2021, 22:03 ... einen Headless Renderer gebaut

Was ist das?

Verfasst: **18.04.2021, 22:47**

Zudomon hat geschrieben: ↑18.04.2021, 22:43
xq hat geschrieben: ↑18.04.2021, 22:03 ... einen Headless Renderer gebaut
Was ist das?

Das rendert quasi nur in eine Textur und hat keine Swap Chain => ich kann nicht auf den Bildschirm, sondern nur in einen RAM-Puffer rendern. Aber: für Icons ist das halt genau das, was ich möchte, ich will ja nicht hunderte Polygone pro Icon malen, sondern max. 2

Verfasst: **18.04.2021, 23:04**

Als ich sowas um 2005 brauchte, musste man einen Dummy-VGA-Adapter auf die Grafikkarten stecken, damit sie denken, da wäre ein Bildschirm.

Kam erst mit D3D 10, dass man zeichnen konnte, ohne den Bildschirm zu befüllen.

Geschichten aus dem Krieg.

Verfasst: **15.06.2021, 22:29**

Heute mal wieder was ganz anderes gmacht, ein paar NPR-Foliage-Experimente mit Vorgabe-Geometrie.
Geht ein klein wenig in Richtung Ghibli-Stil.

Zappel-Gif:

Ein paar Varianten:

Verfasst: **16.06.2021, 10:28**

Nice :)

Verfasst: **16.06.2021, 16:37**

Schrompf hat geschrieben: ↑18.04.2021, 14:53 Es geht voran. Allerdings nur auf Themengebieten, die im Bild leider komplett unsichtbar sind: adaptiver Detailgrad.

Bedeutet das nicht, dass du alles richtig gemacht hast? :)

Verfasst: **23.06.2021, 16:32**

Basierend auf einer freien 2D-Grafik:
Cartoon vector created by brgfx - www.freepik.com
https://www.freepik.com/free-photos-vec ... n%20goblin

ZFX + Developia

Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte

Re: Showroom - Aktuelle Arbeiten und Projekte