Nem semmi a csóka, 1 hét alatt összedobott egy komplett 3D modellező programot. Mivel C-ben írta, így gond nélkül wasm-ra is fordítható, és böngészőben is fut. Mindezt szépen le is dokumentálta, tecső videóval, bloggal stb.
Külön érdekesség, hogy a videóban azt is elmondja, miért választotta a Signed Distance Field-et a mesh helyett, és remek animációkkal még a működési elvét is elmagyarázza, roppant tanulságos!
ví dejó: https://youtu.be/-Xb3Kk3HhIw (akkor is érdemes megnézni, ha nem érdekel a megvalósítás)
webdemó: https://danielchasehooper.com/projects/shapeup/ (interaktív, kipróbálható)
forrás: https://github.com/danielchasehooper/ShapeUp-public
blog: https://danielchasehooper.com/posts/shapeup/ (itt belemegy az implementációs részletekbe is)
A blogon egyébként arra is kitér, hogy miért a C-t választotta. SPOILER: pont azokat az érveket hozza fel, amiket már én is jó ideje hangoztatok, pedig nem valószínű. hogy ez a Daniel gyerek sokat olvasná a HUP-ot :-D
És mindezt tokkal vonóval 1 hét alatt! (Ebben benne van a videó elkészítése is, ami állítólag tovább tartott, mint a programot megírni)
Hozzászólások
👍
👍
Kemény, mint a kád széle. Nagyon tisztelem az ilyet. Főleg, hogy nem hype-olt nyelven írta, és ilyen rövid idő alatt. Az ötlet is érdekes, hogy kivágós, illesztős, transzformálós technikával állít benne elő mindent. Kár, hogy nem vagyok egy CAD-es, modellező alkat, mindig is béna voltam ezekhez a programokhoz, Blender és társai. Elfirkálgatok benne, de a végeredmény sose áll össze értelmessé, használhatóvá.
Ami még talán hiányzik belőle, az egy script-nyelv lenne, amiben mindezt utasításokkal lehet leírni, annak, aki nem akar egerezni, gamepad-ezni hozzá, hanem kódból akarja a modelleket generálni.
Egyelőre csak a videót néztem meg, de később olvasom a többi linket.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Igen, ez a része nekem is kifejezetten tetszik, hihetetlenül egyszerűvé és kényelmessé teszi a felület használatát.
Nem hiszem, hogy ennek bármi akadálya lenne, pl. Luával. Szerintem itt inkább csak az 1 hetes határidő volt a para, mert aki nem jártas Lua intergrációban, az könnyen megjárhatja, így gondolom nem merte még ezt is bevállalni ilyen rövid időn belül (azért mondom a Luát, mert az is C-ben íródott, és azt a legkönnyebb illeszteni. Python egy-pár nagyságrenddel macerásabb).
Ez egy érdekes kérdés, hogy általános szkript nyelv vagy DSL a jobb, de valószínűleg a kettő keveréke, azaz dobozos szintaktika és motor, de az adott célra szabva.
Alternatíva, ha simán kivezeti api-ra a funkciókat és mindenki úgy hívja ahogy tetszik.
Mindkét módszer karbantartása munkás, amíg forr a fejlesztés, nagyon le tudja lassítani
Nem értem, miért lenne ez két külön módszer. Szerintem egy és ugyanaz (adott célra szabni = kivezetni API-ra).
És nem is különösen munkás, amikor legutóbb csináltam ilyen Lua illesztést, semmit sem lassított a fejlesztésen.
Igaz, úgy csináltam meg, hogy egy ciklussal betöltöm a Lua state machine-ba az API-t, magát az API listát meg Makefile-ból generálom. A 165 függvényből csak 6-ot kellett külön megírni (azokat is csak azért, mert szar a Lua yield() interfésze, nem úgy működik, ahogy a doksi állítja), a maradék 159 fejlesztésénél tökre el is felejtettem, hogy Lua-val is automatikusan illeszti fordításkor, annyira semmi dolgom sem volt velük.
Ami sokkal inkább macera volt, az a Lua biztonságossá tétele. Magyarán az volt nehezebb, hogy szintaktikára és motorra lecsupaszítsam, hogy aztán tényleg csak a betöltött API funkciókat lehessen használni vele, pl. egy "system()" hívást külsős programra ne. Egyszerűbb lett volna, ha az egész baselibet kihagyom, de akkor a nyelv jelentős része is ment volna a kukába (különösen a sztring- és táblaműveletek hiányoztak volna nagyon).
Persze ha valaki nem annyira security mániás, mint én, az használhatja a stock Luát, és akkor sem a yield()-el, sem ez utóbbi hardened baselib-el nincs semmi gondja, csak be kell tölteni egy Lua modult a 3D modellező API-jával és már kész is. A modul függvénylistáját (ami lényegében egy Lua tábla) ugyanúgy elő lehet állítani automatikusan egy ciklussal, mint ahogy én is csináltam.
Mindkét megoldásnak megvan az előnye. A saját nyelv minimalistább lehet, de implementációs hibáktól hemzseghet. Ha viszont kész scriptnyelvet használ valaki mástól, akkor viszont nem kell a fejlesztőnek feltalálni a kereket, csak egy interface-t kell írnia hozzá, meg az általános scriptnyelvek Turing képesek is, meg azokat több ember máris ismeri, így kisebb lesz a beletanulási nehézség a szoftverbe.
Sok projekt ezért is épít be Python-t, Lua-t, mert azoknak máris nagy a felhasználói tábora, van egy csomó lib, JIT megoldás hozzá, így csak kényelmes a használata.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
OpenSCAD, full szkriptelhető
Tudom, ismerem, nekem az a kedvencem, ajánlottam is itt egy kollégának nemrég, aki szkriptelhető CAD-et keresett egy másik topikban. Igazából a többi elterjedt CAD alternatíva alá is van szkriptmegoldás, azért is írtam, hogy ebben az egyhetes projektben is elkelne.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Így még (valószínűleg) nekem is menne Cben.
Let the flame begin.
Nem látom a problémát. Kb. 1 perc lenne átírni realloc-ra, vagy még annyi se, semmi para nincs benne.
Elmondja részletesen, hogy azért nem tette meg mégsem, mert a GLSL része nincs optimalizálva, így 100-nál több alakzatot egyébként sem tudna kezelni, szóval felesleges lenne a memóriafoglalással vesződni, mikor úgyis van más bottle-neck. Azt is elmondja, hogy az 1 hetes határidő miatt nem volt ideje optimalizált GLSL-t generáltatni a proggiból (ui. ahogy használod a szerkesztőt, úgy menet közben generálja a GLSL-t az alakzathoz).
Nem kisebbítve az érdemeit, de mi az a raylib a lib könyvtárban?
init+gui+input+audio+asset loading, gyakorlatban mindent ad, a vége már csak legózás. Ha mellé rak még egy sdf lib-et is, akkor az egy hetes fejlesztésből 1 nap lesz
// Happy debugging, suckers
#define true (rand() > 10)
Pontosan, plusz platformfüggetlen réteg. Azaz bitre ugyanaz a forrás lefordul Linux-ra (OpenGL vagy Vulkan), Windows-ra (DirectX), Mac-re (Metal), Android-ra és iOS-re (GLES) vagy WebAssembly-re (WebGL), egyáltalán nem kell törődnöd a részletekkel.
Egy függvényhívás mind fölött :-D
oké, de azért érezzük, hogy akkor ő nem 0-ról írt egy modellező eszközt, hanem használt egy könyvtárat ami a feladat elég jelentős részét megoldja neki.
Hülyeségeket beszélsz. A raylib nem old meg semmit a feladatból, csak a keretrendszert adja, pont mint mondjuk az SDL.
Ennyi erővel aki nem direktben syscall-okat használ Windows-on, az már semmit nem csinál, mert a feladat jelentős részét megoldotta helyette a GDI; vagy aki nem bájtokat ír az X11 socketbe / Wayland pipeba, hanem GTK-t / Qt-t / stb.-t használ, annak is a feladat jelentős részét megoldották már...
Meg ne haragudj, de kb. ekkora hülyeség, amit mondtál.
Ja, hát végülis a gui-n, a vektor támogatáson, a shader betöltésen, a textúra kezelésen, a renderingen, az input-output kezelésen mást nem is ad.
A raylib egy alacsony szintű függvénykönyvtár, akárcsak az SDL, az nem az én bajom, ha nem tudod, ez mit jelent.
azért azt lássuk be, hogy a raylib gyakorlatilag az összes szívástól megment, ha pedig életedben legalább 1x csináltál sdf ray marching -ot, akkor igen nyugodt tempóban 1 hét. A legmacerásabb része az egésznek talán az export
// Happy debugging, suckers
#define true (rand() > 10)
Nem látom be, mert nem igaz. Mondd csak, hány programot írtál már alacsony szintű függvénykönyvtár használatával, mint a raylib vagy az SDL? Fogadjunk, hogy a válasz nulla, azért beszélsz ilyen hülyeségeket.
Csak azért, mert közvetlen OpenGL és DirectX hívás helyett van egy egységes függvényhívásod, ami mindkettőre le tud fordulni, még egyáltalán nem lesz könnyebb dolgod. A bemenő paramétereket, az EBO-t és VBO-t továbbra is ugyanúgy neked kell összerakni, ebben semmit sem segít.
Ugyanez igaz az ablakkezelésre, közvetlen XCreateWindow() vagy DialogBox() hívások helyett van egy egységes InitWindow() hívás, de ennyi.
Az eseménykezelés dettó, XNextEvent() és DlgProc() callback helyett van egy csomó platformfüggetlen Is*() meg Get*() gettered, de ennyi, csak az esemény lekérdezése lett egységesítve, a feldolgozásban már semmit sem segít.
...stb. A raylib nem nyújt olyan magas szintű absztrakciókat, mint a GDI, a GTK, a Godot vagy épp a Unity.
"Fogadjunk, hogy a válasz nulla, azért beszélsz ilyen hülyeségeket."
Tény, hogy raylib-et csak próbáltam, de SDL azért rendszeresen előfordult, de jobb szeretem a saját dolgokat :)
"Csak azért, mert közvetlen OpenGL és DirectX hívás helyett van egy egységes függvényhívásod, ami mindkettőre le tud fordulni, még egyáltalán nem lesz könnyebb dolgod" & "A raylib nem nyújt olyan magas szintű absztrakciókat, mint a GDI, a GTK, a Godot vagy épp a Unity."
Szóval, ezek azok amiket a raylib szerinted nem ad és valahogy mégis voltak használva egy sima dx/ogl context-hez képest, anélkül hogy implementálni kellett volna: Teljes GUI / Ablakkezelés / Eseménykezelés / Periféria kezelés / Text rendering / Vektor transzformációk / Camera kezelés / Collision detection
Csak a text rendering egy külön művészet, ezzel szemben összelegózni egy minimal ui-t ahol egy tömböt tutujgatsz amiből aztán sorban végzel SDF feldolgozást, kb a vicc kategóriája :)
"Nem látom be, mert nem igaz."
Akkor kérek példát ogl / dx alatt csak a következő egy hívásos dolgokra, amiket emberünk használt: DrawRectangle / DrawText
Plugin / library értelemszerűen nem játszik (DirectWrite az külső library, nem a DX része), elvégre pont azt mondod hogy a raylib nem ad semmit
// Happy debugging, suckers
#define true (rand() > 10)
Nyugtass meg, hogy nem szoftverfejlesztőként dologozol...
Nyilvánvaló hazugság, ha így lenne, akkor tudnád, hogy sem az SDL, sem a raylib egyáltalán nem is ad ui funkcionalitást, nagyokos.
(Az a raygui bövítmény lenne, magában a raylib könyvtárban semmi ilyesmi sincs, az SDL meg még szöveget sem tud megjeleníteni rendesen SDL_ttf nélkül, hivatalos ui bővítménye meg nincs is.)
Hazudsz, sosem állítottam ilyent. Sőt.
Megint hazudsz, ilyent se mondtam; konkrétan azt mondtam, hogy alacsonyszintű könyvtár, tehát magasszintű absztrakciókat nem nyújt. Az nem az én hibám, hogy nem tudod, mi a különbség a kettő között.
Nem semmi! (pun intended, érvényes a tudatlanságodra és a különbségre is :-) )
Ennek megint semmi köze ahhoz, amit állítottam, ráadásul ez még véletlenül sem az OpenGL / DirectX réteg dolga, te tanulatlan tuskó. Csak kötözködsz, miközben fingod sincs róla, hogy miről beszélsz.
Full disclosure: raylib fejlesztő és kontribútor vagyok (azaz voltam, amíg szét nem cseszték a github-ot), és azt is pontosan tudom, mekkora meló a text rendering, lásd Scalable Screen Font.
Ezzel szemben te még az alapfogalmakkal sem vagy tisztában, azt se tudod, melyik rétegnek mi a szerepe, ráadásul pofátlanul hazudsz, mint egy Rogán-propagandista, így nincs miről beszélnünk a továbbiakban.
És elfogyott a popcornom is. Ágyő!
Értem én, hogy most megpróbálod agresszióval kompenzálni, de ezzel gyakorlatilag csak magadból csinálsz hülyét, nem belőlem.
"Nyilvánvaló hazugság, ha így lenne, akkor tudnád, hogy sem az SDL, sem a raylib egyáltalán nem is ad ui funkcionalitást, nagyokos."
Szóval ha az általad linkelt github repo-ban megnézem a következő file-t: src/main.c, majd legörgetek pl. az 1916 -os sorig ami DrawText -el kezdődik és ráklikkelve, jobbra pedig megjelenik a "Definitions" résznél a raylib repository, akkor az egy nyílvánvaló hazugság, mert ő olyat nem ad.
"Ennek megint semmi köze ahhoz, amit állítottam, ráadásul ez még véletlenül sem az OpenGL / DirectX réteg dolga, te tanulatlan tuskó."
Tudom, hogy nem ez a dolga, de ha nem a raylib -ből jön és nem pl. az ogl dolga, a repo-ban pedig nincs text rendering, akkor mégis honnan jön? (tudom a választ, mert ott van a "Definitions" résznél)
OAR: bár tisztelem és elismerem a munkásságodat, de azt a mérhetetlen arroganciát amit képviselsz még azon áron is, hogy saját magadnak egy hsz-en belül is ellentmondasz, nehéz pozitívan értékelni, ezzel pedig csak a saját munkásságodat tiprod sárba amire egyébként teljesen jogosan lehetnél büszke
// Happy debugging, suckers
#define true (rand() > 10)
en se estem hanyatt tole. CSG modellezes a 90-es evekbe volt divat, mert opengl-el stencil layert hasznalva kb 0 eroforrassal ki lehetett renderelni, anelkul hogy ki kene szamolni a metszesvonalakat. az ipari CAD rendszerek ezert is hasznaltak akkoriban.
a blobos (marching cube) modellezes se ujdonsag, 20 eve a zbrush nevu progi mar alkalmazta.
egy ilyen modellezonel amugy is a GUI es az optimalizalas a legnagyobb munka, de lathatoan egyikkel se foglalkozott :)
A másik, hogy ne keverjük össze a tech demót egy szoftverrel. Az a pár száz-ezer sor kód erre jó. Tök jó, hogy fognak ebből egy blender szintű tudással rendelkező tool-t írni? Valószínűleg sehogy, mert nem fog skálázódni.
Miről beszélsz? Pár száz-ezer??? Pontosan 2024 sornyi az egész!
Pár száz - kötőjel - ezer sor. A kétezer az a pár ezer kategória. Plusz a könyvtár, amit elegánsan kihagyunk.
Ahhoz képest egész jól elfut még egy böngészőablakban is, natívban meg tényleg csak úgy repeszt. Képzelem mi lenne, ha még optimalizálná is :-D Arról nem is beszélve, hogy a felülete intuitív módon kb. azonnal használatba vehető.
Bezzeg az agyonoptimalizált Blender még egy egyszerű modellel is vért izzad és felzabálja az összes memóriát, a prociventi meg persze visít közben. Hogy a felhasználói felületének használhatóságáról ne is beszéljünk, ami igazi pilótavizsgás, és verzióról verzióra mindig újra kell tanulni :-(
Majd térjünk vissza a témára ha annyi funkció lesz benne, mint a Blenderben.
Nem. Majd akkor térünk vissza a témához, ha Te felfogod, mi a különbség egy céleszköz és egy általános célú monstrum között.
Az nem bántja a csőröd, hogy a Paint nem tud annyit, mint a Photoshop???
Vagy az mcedit annyit, mint az Eclipse / Sublime / Visual Studio / XCode / stb. csoda IDE???
A válasz: azért nem, mert nem is dolguk, nem ugyanarra valók.
Te azt állítod hogy összedobott egy komplett 3d modellező programot. Ez nem egy komplett 3d modellező. Ez egy techdemó, minimális funkcionalitással. Aranyos, jópofa, de nem egy "komplett 3d modellező".
igy van, ez max a paint, es nem a photoshop...
Már megbántam, elnézést.