06:02:58 xq: moin moin
06:04:21 Schrompf joined the channel
06:26:39 xq: moin Schrompf!
06:27:07 Schrompf: heyhohuhi
06:32:09 xq: https://cdn.discordapp.com/attachments/785499283368706060/829965688596070420/unknown.png
06:32:13 xq: boy, that improvement
06:32:34 xq: Zig Stage 1 (C++-Beta-Compiler) vs. Stage 2 (Selfhosted Compiler mit DOD)
06:32:46 Schrompf: hübsch
06:33:05 xq: speedup ist halt enom :O
06:35:54 IceMichael: moin ihr Recken
06:36:05 IceMichael: ja, so was ist nice
06:36:44 IceMichael: hm, falls ihr Lust habt, könnt ihr gern meine Compiler-n00b Frage beantworten, wieso der switch für Stage1 vs Stage2 hier mit -no-LLVM ist?
06:36:49 IceMichael: müsste nochmal nachsehen was LLVM überhaupt ist
06:37:20 Schrompf: so ne art compiler-build-lib
06:37:21 xq: llvm = low level virtual machine
06:37:32 xq: das ist ein compiler-framework, worauf auch clang basiert
06:37:45 Schrompf: clang das verlockend?
06:37:47 IceMichael: oha... VM klingt nach langsam
06:37:55 xq: du hast ne intermediate representation (llvm ir)
06:38:15 xq: dein frontend (C, C++, Rust, Zig, ...) compilieren quasi nach LLVM IR
06:38:27 IceMichael: wie dieser Zwischencode, der auch bei Java im Interpreter erzeugt wird?
06:38:27 Schrompf: nö, es ist ne art code generator. ursprünglich ein c++-compiler, aber deren flexibles software-design und die zugänglichkeit haben dafür gesorgt, dass jede menge programmiersprachen und anwendungen damit gebaut werden
06:38:31 xq: dann kommen passes (diese optimieren das LLVM IR)
06:38:41 IceMichael: ah
06:38:49 xq: und dann kommt ein backend (x86, x86_64, aarch64, ...), welches dann maschinensprache ausspuckt
06:39:50 IceMichael: okay :)
06:40:04 xq: llvm ist *der* hotte compiler, wenns um perf geht
06:40:07 IceMichael: aber anscheinend ist es dann ja wirklich langsam, wenn dein stage2 es schlägt? (was ist DOD hier?)
06:40:15 xq: Data Oriented Design
06:40:22 IceMichael: ah, das
06:40:29 xq: ("mein" stage2 ist die arbeit von andrew :D)
06:40:43 xq: LLVM optimiert halt brutal, aber das spielt hier keine rolle
06:40:51 xq: der stage1 compiler ist einfach auch scheiße implementiert
06:41:12 xq: das sind halt 4 jahre "ich lern mal programmiersprachen bauen"-pfusch von andrew und anderen
06:42:38 IceMichael: ok, spannend
06:43:52 xq: der neue compiler (in zig dann) ist halt sehr viel geplanter und besser optimiert von vornherein
06:44:22 xq: ich schätze, dass projekte in der größe von chromium in vllt. 10 Minuten frisch neu gebaut sind
06:44:39 Schrompf: mir ist gerade intellij clion abgekackt wegen speichermangel der VM
06:45:35 xq: ouch
06:45:38 Schrompf: LLVM befeuert inzwischen auch quasi jeden Indexer auf diesem Planeten
06:45:57 Schrompf: und refactoring-tools und problem-analyse-tools und sonstwas
06:46:02 Schrompf: weil's ne so geile lib ist
06:46:40 Schrompf: und das alles nur, weil die GCC-Pfeiffen ihre software bewusst so gestrickt haben, dass sie nach möglichkeit nicht separat nutzbar ist und nur als block funktioniert
06:46:57 Schrompf: weil sie sauer waren, dass leute ihre opensource-arbeit für andere opensource-projekte "missbrauchen" wollten
06:46:59 IceMichael: xq, das wäre natürlich nice. Also ist der zig-optimierte Compiler für C++ jetzt schneller als ein C++-Compiler selbst? (Chromium ist doch c++-based oder gibt's das irgendwie in zig?)
06:47:26 IceMichael: Schrompf, haben die OSS verstanden? :D
06:47:45 Schrompf: weiß nicht. ist lange her, und der erfolg von Clang hat den GCC heftig unter druck gebracht
06:47:51 xq: IceMichael: Chromium nur als Größenordnung, der C++-Compiler in der Zig Toolchain bleibt clang
06:47:57 Schrompf: und das ist gut so. da war deutlich zuviel ego im spiel
06:48:19 IceMichael: das war sarkastisch... OSS ist doch gerade zum Teilen da, das ist doch die Grundidee?! wie kann man dann sauer sein, dass es weiterverwendet wird
06:48:30 Schrompf: ego
06:48:41 IceMichael: ja, also warum man so fühlt ist mir auch klar, aber... ach egal
06:48:50 IceMichael: xq, ok, schade. Schnellere C++-Compiler wären mir sehr recht :D
06:48:54 xq: heh
06:49:03 xq: das wird in C++ leider relativ unmöglich werden glaube ich
06:49:11 xq: die sprache ist nicht dafür gebaut worden, schnell compiliert zu werden :D
06:49:34 Schrompf: ja, in anbetracht des ärgers, den mir GCC mit seinen reichlich zweifelhaften auslegungen von UB beschert hat, hege ich einen groll gegen sie und wünsche ihnen erstmal weiterhin alles schlechte
06:49:34 IceMichael: hm ja, man könnte sich höchstens ein kleines build-cluster zusammenstecken, so teuer ist CPU ja eigentlich nicht
06:49:44 IceMichael: gibt bestimmt distributed clang oder so?
06:49:52 Schrompf: eher distributed make
06:50:07 xq: frag mal mirlix in #sppro, die nutzen afaik sowas
06:50:26 IceMichael: stimmt, make macht mehr Sinn
06:50:46 Schrompf: IncrediBuild aus dem schönen Isreal ist die Standardlösung seit jahrzehnten, aber es dürfte auch konkurrenten geben
06:51:06 IceMichael: hab mirlix direkt mal gefragt, mal sehen
07:30:31 joeydee joined the channel
07:30:39 joeydee: moin
07:31:26 Schrompf: hi
07:31:32 joeydee: Jetzt habe ich mich diese Woche mehr mit Bezier als mit meinem Tool befasst :D aber halt auch höchst interesant.
07:31:41 joeydee: +s
07:31:41 xq: huhu
07:31:47 xq: joeydee: und das an zwei ecken!
07:31:56 joeydee: jepp :)
07:32:04 Schrompf: cool! falls du raus kriegst, wie man die erste ableitung stetig hinbekommt, sag bitte bescheid
07:32:22 Schrompf: ich muss jetzt noch das daily hinter mich bringen, dann kann ich an den felsen weiterbauen
07:32:34 Schrompf: hab inzwischen ne idee, wo die muster in meinem normalmap-noise herkommen
07:33:50 joeydee: Ich weiß *theoretisch* wo der Fehler liegen könnte, wie es mit Quads richtig gehen könnte, was der fehlende Kontrollpunkt (bei Quad: 4 mittlere KPs) erfüllen muss, und warum es mit Dreiecken evtl. grundsätzliche Probleme gibt.
07:34:38 Schrompf: hm, sowas hab ich befürchtet
07:35:05 Schrompf: ich akzeptiere nur antworten der Klasse "Du musst ganz einfach nen Faktor 2 bei XYZ einsetzen, dann geht's"
07:36:51 joeydee: "Du musst einfach genug Noise draufpacken, dann fällts nicht mehr auf" - ok so?
07:38:29 Schrompf: wie zufällig ist das genau mein plan
07:38:47 Schrompf: (man sieht leider die kanten auch durch's noise, aber echt ma ein ding für später)
07:39:48 joeydee: Aber trotzdem interessiert mich, wie man absolut glatt und nahtlos Bezier-Patches aneinanderhängt, die sich ausschließlich durch die Eckvertices und -Normalen bestimmen lassen.
07:39:57 Schrompf: ja, mich auch
07:44:32 joeydee: Um jetzt meinen Ansatz zu testen, brauche ich erstmal einen Patch-Renderalgo, der nach Lehrbuch 16 Kontrollpunkte richtig in eine Bezier-Oberfläche umsetzt. Muss aber auch erstmal daily machen :D
07:44:57 Schrompf: ich kann dir meinen code irgendwohin kopieren, wenn dir das was nützt
07:46:43 joeydee: Ne, ich muss auf Quads testen. Aber ist ja ein gelöstes Problem, muss es nur machen. "Tensor Product Spline Surface" ist das Stichwort.
07:46:57 Schrompf: aha.
07:47:04 joeydee: https://www.ibiblio.org/e-notes/Splines/bezier3d.html
07:47:08 Schrompf: du machst das schon
07:47:59 joeydee: Wie die Tage schon angedeutet: man hat die 4 Kanten als Splines definiert. Und muss die irgendwie übers Quad sweepen.
07:48:20 Schrompf: ok, das ergibt tatsächlich sinn
07:48:29 joeydee: 1 Kante = 2 Verts und 2 Kontrollpunkte.
07:50:16 joeydee: Jetzt nimmt man einen der Kontrollpunkte der vorderen Kante, das ist der virtuelle Vert einer neuen virtuellen Bezierkurve. Der andere Vert ist der korrespondierende der gegenüberliegenden Kante.
07:50:47 joeydee: Die bekommen nun ihre Kontrollpunkte, damit sie nicht linear, sondern auch als Bezier interpoliert werden können.
07:51:01 joeydee: Daher ergebn sich insgesamt 16 Kontrollpunkte
07:51:45 joeydee: Also die Kontrollpunkte sind selbst Eckpunkte von Beziers, eine Ebene höher sozusagen
07:51:52 Schrompf: und wahrscheinlich braucht's dafür eine ordnung höher, sonst veränderst du mit den stützpunkten auch gleich direkt den verlauf
07:52:10 Schrompf: dann *müsste* es aber auch für dreiecke gehen, wenn ich mir das richtig ausmale
07:52:41 joeydee: Wenn hierfür der Subdivider sauber umgesetzt ist, ist nur noch die große Frage: wie an die Kontrollpunkte kommen?
07:52:48 joeydee: also die 4 mittleren
07:54:07 joeydee: ich würde sagen, wenn man die Diagonalen betrachtet, sollten sie ebenfalls auf einer Tangenten liegen, die durch den nächsten Vertex geht.
07:57:12 joeydee: Und wenn man nur ein Dreieck isoliert betrachtet, sind 2 der mittleren Kontrollpunkte auf einer Dreieckskante, und 1 in der Fläche. Um den zu bekommen, kann man aber keine Diagonale mehr ziehen, die Info über den gegenüberliegenden Punkt fehlt.
07:57:27 Schrompf: hm, diese kontrollpunkte sind ein bissl ... freestyle. ich hab meine jetzt hingefaked, aber ich hab keine ahnung, ob's dafür eine offizielle lösung gibt
07:58:28 joeydee: Die Kontrollpunkte, die zu einem Vertex benachbart sind, sollten *alle* auf einer Ebene liegen, damit es ein glattes Mesh gibt, imho.
07:59:08 joeydee: Und die Normale dieser Ebene==Vertexnormale
08:00:27 joeydee: (Was in 2D die Tangente war, wo alle Kontrollpunkte draufliegen müssen damits keine Knicke gibt, ist hier der Tangent-Space, bzw die u-v-Ebene darin)
08:00:34 Schrompf: genau. die vertexnormalen klappen ja auch. und daher auch meine intuitive vermutung, dass man an den kanten die normale mit den benachbarten kontrollpunkten nachbilden muss, also einen satz mehr braucht als bei den quadratischen bezierkurven, die bei nem dreieck ja 7 stützpunkte haben
08:03:04 joeydee: Das "Nachbilden" der Normalen dachte ich gestern auch noch, aber wenn ich mir die Tensorgeschichte ansehe, könnte es das lösen. Ich muss es echt mal umsetzen.
08:04:14 Schrompf: ja, mach mal. und stell den code irgendwo hin :-)
08:08:25 joeydee: Stattdessen jetzt: letztjähriges InDesign-Dokument auseinanderfrickeln, säubern, Jahreszahlen ändern, die in 5 Mails verteilten Korrekturen vornehmen, dem Kunden bis Montag zur Verfügung stellen.
08:08:43 joeydee: hurra
08:12:13 Schrompf: immerhin wird's bezahlt
08:13:37 joeydee: jau, und das nicht schlecht. Ich sollte mich nicht beschweren. Also nochmal "hurra" minus Sarkasmus ;)
08:17:05 joeydee: Ist kommenden Di eigentlich wieder Stammtisch?
08:17:25 Schrompf: stimmt. ja, soll
08:28:21 Schrompf: so, arbeit zuende. /me klappt mit dramatischer geste ein großes buch zu, das überhaupt nix mit dem job zu tun hat und allgemein bei nem programmierer lächerlich deplatziert wirkt
08:28:34 joeydee: Harry Potter?
08:28:49 Schrompf: Deutsche Gesetze und Verordnungen
08:30:03 joeydee: ok, fast richtig ...
12:32:46 xq: erst mal nur public API bauen und auf linkerfehler spekulieren
12:33:06 xq: implementieren kann man später :D
12:33:42 Schrompf: klingt gut
12:33:52 Schrompf: ich bin gerade demotiviert
12:34:14 Schrompf: obwohl ich eigentlich nur meine noise-funktion acht mal aufrufen müsste, um die streifen loszuwerden
12:34:16 Schrompf: sorry
12:34:22 Schrompf: ne halt
12:34:26 Schrompf: völliger quatsch
12:35:35 Schrompf: wenn ich nachher zusätzliche einflussfunktionen wie z.b. den flachen sand aufm boden bauen will, muss ich doch eh ne context aware funktion bauen
12:35:45 Schrompf: da kann ich das offset doch gleich in ne textur ausrendern
12:36:58 xq: und dann kannste trivial ne normal map ausm gradient berechnen \o/
12:37:38 Schrompf: so isses :-)
12:39:47 xq: so. gleich feierabend
14:45:05 Essex20 joined the channel
14:45:14 Schrompf: das mit der "heightmap" geht, nur leider gibt's hier und da fehlpixel. grmpf
15:15:51 Schrompf: es felst: http://www.splitterwelten.info/privat/dungeon_fels.png
15:59:40 Essex20: ok
16:19:44 xq: Schrompf: du hast aber immer noch ne unstetigkeit zwischen den blöcken
16:24:10 Schrompf: ja. pixelgroße lücken in der normalmap
16:25:06 xq: huch
16:25:12 xq: die mein ich nicht
16:28:46 xq: https://mq32.de/public/8b4d0c80a38285133dacad0ce01b71971638304d.mp4
16:28:55 xq: hups :D
16:32:50 xq: Schrompf: https://mq32.de/public/7ac8381f265c2c7fbfb7d2f4f53c90f0b42c4366.png die da mein ich
17:21:49 joeydee joined the channel
17:21:56 joeydee: moin
17:22:29 joeydee: wieder mal auf engl. Layout gerutscht, yfx gejoined und gewundert das keiner da ist.
17:29:43 Essex20: https://freebies.indiegala.com/runestone-keeper
17:30:03 Schrompf: xq: das sind die normalen-sprünge, über die ich schon mit joeydee gestern fachsimpelte
17:30:09 Schrompf: weiß nicht, wie ich die wegkriegen soll
17:31:47 joeydee: Ich weiß jetzt immerhin woher sie kommen.
17:33:08 joeydee: Ich dachte ja, die 2D-Idee, Tangenten anhand der Normalen zu konstruieren, führt in 3D dazu, wenn man alle Kontrollpunkte auf der Tangentenebene zu einem Vertex hat, dann ist das auch automatisch an den interpolierten Kanten so. Ist aber wohl nicht der Fall.
17:33:31 joeydee: Bleibt leider nur an den Punkten stetig.
17:34:33 joeydee: https://www.phoximages.de/uploads/2021/04/i68284b6574s.jpg
17:34:44 joeydee: https://www.phoximages.de/uploads/2021/04/i68285b2wh95.jpg
17:34:47 joeydee: shit.
17:35:07 joeydee: Da muss man wohl mehr Nachbarschaftsinformation verwursten.
17:36:30 joeydee: Allerdings nehme ich gerade Abschied von der Idee, die Ecken und deren Normalen als "fix" zu betrachten, sondern stattdessen die Flächenmitten. In 2D (Linienmitten sind Verts, Linienenden sind Kontrollpunkte) klappt das wunderbar.
17:37:10 joeydee: Kommt dann auch der Catmull-Clark-Subdivision nah.
17:37:54 joeydee: Welche übrigens auch simpel ist.
17:41:21 joeydee: Also statt wie oben, neu, wie unten die Kurven annähern: https://www.phoximages.de/uploads/2021/04/i68286bmvau4.jpg
17:42:29 joeydee: Aber wie/woraus genau dann in 3D das ganze Patch konstruieren, so weit bin ich noch nicht gekommen.
17:43:11 joeydee: Falls das zu kompliziert würde, würde ich Catmull-Clark, evtl. parametrisiert für mehr Kontrolle, ausprobieren.
17:43:23 Schrompf: du machst tolle skizzen. genau so eine skizze hab ich vor ein paar tagen für IceMichael gemacht :-)
17:43:54 Schrompf: ich hatte diese version vorher, aber ich habe sie nicht kontinuierlich gekriegt an den stellen, wo konvexe kanten und konkave kanten aufeinander trafen
17:45:42 joeydee: Und wie hattest du interpoliert? Bezier kam doch erst nach der Normalen-Idee im Forum dazu, oder?
17:56:51 Schrompf: interpoliert habe ich so: dreieck tesselieren, für jeden vertex die interpolierte normale berechnen, vertex offseten entlang dieser normale anhand eines "kurvenfaktors", dem skalarprodukt zwischen ecknormale und interpolierter normale
17:57:13 Schrompf: reisst keine lücken in die oberflächen, also zumindest position ist stetig
17:57:40 Schrompf: eskaliert aber hässlich an konvex-konkaven kontaktkollisionen
18:43:44 joeydee: Catmull-Clark nimmt nicht die Average-Normale, sondern bestimmt den Vertex-Offset durch reine Punkt-Averages. Also eigentlich so ähnlich, nur ohne Normale.
19:13:36 Schrompf: aber womit averagest du den punkt?
19:13:41 Schrompf: naja, irgendwann les ich mir das mal an
19:23:24 joeydee: Engl. Wiki zeigt das Schritt für Schritt. Zu einem Vertex erst angrenzende Flächenmitten, dann angrenzende Kantenmitten mit diesen mitteln, dann den Vertex anhand dieser Punkte gewichtet mitteln.
19:34:33 Schrompf: hab gerade meine normalmap-berechnung aus der height-offset-irgendwas-map nochmal umgeschrieben, jetzt muss sie nicht mehr TexGröße+1 breit und hoch sein und ich habe plötzlich das ganze Fließkomma-Grenzfall-Gedöns beim Dreiecke-Mappen beseitigt
19:34:38 Schrompf: jetzt geh ich zocken