Szegény ember 3DS betöltője

[Geri]

Én nekem a magam részéről arra kell hogy kissé módosítva közkinccsé varázsoltassak valakivel egy jó és egyszerű 3ds loadert LGPL licensszel, mert a jelenlegi 3ds loaderek írtózatosan szarok, és egy füst alatt beleteszem az enginembe is. A tiedét, ha felteszed netre, egyszerűsíteni szándékozom, írni hozzá egy pointerkimenet alapú nagyon egyszerű infrastruktúrát, majd a sourceforgera feltenni.ha esetleg van msn vagy skype címed, hatékonyabban meg tudjuk kommunikálni a dolgot.azt meg, hogy a textúrát ez a kód töltse be közvetlenül, se a libraryhez, se a te saját kódodhoz nem javaslom, sokkal jobb az ha a kódok különálló szigetecskéket alkotnak, amelyen belül egy teljesen független alegység pl a 3ds betöltő, ami csak pointereket és pl textúra neveket szór vissza. de ha ez nem így lesz, mint már mondtam, én ilyenre át fogom írni, mert így illeszthető be meglévő projektekbe (pl példának okáért az enyémbe) a legkönnyebben – gondolom mások is hasonlóképpen vannak a dologgal.

[Caiwan]

Én is ugyanezt szeretném megtenni, csak az egész frameworkkel, köré épül a demó. Bár, ezzel a lépéssel én inkább megvárom az őszi Functiont, és megnézem hogy az ezzel készült demó hogyan teljesít.Nos, nem használ dinamikus tárterületet az adatok tárolásához, mert nekem perpillanat így sokkal kényelmesebbnek tünt. Az objektum pointerét vagy az egyes részek adatait meg könnyű továbbadni egy másik függvénynek (a & operátorral) Ez csak annyit csinálna, hogy kiszedné a textúrák (file)neveit, és a betöltő másik része meg behúzza őket, figyelve hogy ugyanazt ne töltse be kétszer, satöbbi satöbb.Távolabbi célom meg az lenne hogy ez – némi átalakítás után – képes legyen 64k intrót is elbírni.

[Charlie]

A 3DS betöltő nem tud full független alegység lenni, mert olyan formátumban kell visszafosnia a 3D file adatait, amit a fölötte futó engine használ. Ez sima XYZUV-nél még sacc/kb. nem téma, de pl. a kamera és light trackoknál és/vagy a különböző transzformációknál már vannak 3DS formátum specifikus dolgok,ha jól rémlik, amit az engine-ben kezelni kell. A materialoknál dettó. Ha meg a 3D engine-det egy adott betöltőhöz és formátumhoz igazítod, akkor ugyan a betöltő független alegység, de az engine nem. :) Ha meg teszel az engine-ed meg a betöltő közé egy konverziós layert, akkor akár már exportert is írhatsz tetszőleges 3D szerkesztőhöz…

Egyébként ez az OOP vs. nem OOP vita is teljes facepalm és bikeshed… Ha már egzotikus (kézi)konzoloknál tartunk, az endian és alignment issue-k sokkal jelentősebbek lesznek, főleg ha memcpy()-val másolod csak odébb pl. a vertex adatokat, semmint hogy most struct-ban vagy egy ojjektumban vagy egy arrayban kapod vissza az adatokat, meg hogy exceptiont dob a betöltő vagy hibakóddal tér vissza… (Az én betöltőmből van endian fixed, ami fut pl. 68k-n meg PowerPC-n, de az nincs kiadva, csak az eredeti változat…) Vagy pl. az, hogy az adott platformon egyáltalán nincs is float, csak valami fixed pontos trutymó. (Nintendo DS, például.)

[pohar]

“kézikonzolon futó … általában csak sima C támogatás szokott lenni,”

erre mondanál néhány példát?

én is mondok olyanokat, amire van C++: PocketPc/PDA/Windows Mobile, PNA/WinCE, Sony PSP, iPhone, Android

[Geri]

Tudtommal pl a play station és a play station 2 is ilyen (nem mintha ezek kézi konzolok lennének). Lehet hogy azóta már írtak hozzá c++ compilert is, nemtom.  Ájfonyára meg objectivec a divat és nem c++, igaz, létezik hozzá valami arm-darwin-g++ nevű csoda is, tudtommal. De én erre azért semmit nem alapoznék. Mikrokontrollerekre se nagyon szokott c++ fordító lenne, csak asm és c. Charlie: az egy más szemlélet, szerintem a legtöbben ilyen extra adatokat hogy pl fény meg kameramozgások, nem a 3ds loaderen keresztül fognak kezelni, hanem engine vagy script szinten. A 3ds amúgy is szar, arra jó hogy kb minden tudja exportálni és importálni, meg arra jó hogy kiszedd az uv-t, geometriát, normalokat, textúrákat. Aztán a többi dolog úgy is annyira bugosan van benne megírva, hogy sokszor még az egyik 3d studio max által kimentett fájlt a másik be se olvassa helyesen. Tehát szerintem maradjunk annál hogy vertex,normal,uv,textúranevek. Ha valaki egy fájlformátumra alapozza az enginejét, vagy akár egy modelviewerjét, az egy zsákutca szerintem, úgyhogy ezt a precíziós vonulatot ne erőltessük.

[Charlie]

Geri wrote …
Ájfonyára meg objectivec a divat és nem c++, igaz, létezik hozzá valami arm-darwin-g++ nevű csoda is

Először is, örülök, hogy tisztában vagy egy standard cross-gnu toolchain elnevezési sémáival, ha már ennyire crossplatform fejlesztésben gondolkozol. Másrészt meg, azt írja a az Apple oldala, hogy “From within Xcode or Terminal, you have a complete set of open-source C, C++, and Objective-C compilers optimized by Apple”. Böff. (Egyébként én rühellem a C++-t, szóval engem nem kell meggyőzni, hogy miért C only. De hülyeséget ne beszéljünk már.)

[blueghost]

Én ugyanolyan formában tárolom a modelleket, ahogy a memóriában is vannak. Vagyis egy memóriaképet tárolok. Egymás után hányva: vertexek száma, vertex array, texcoord array, normal array, index array, és az egész egyben libz-vel tömörítve. A betöltés csak annyiból áll, hogy behúzom a memóriába és beállítom a pointereket. Szerintem felesleges tovább bonyolítani.

[Geri]

charlie: én ugyanezt mondtam. Azt nem állítottam hogy nem létezne ájfonra c++ fordító, sőt példát is mondtam rá, viszont neten akaratlanul is folyton abba futok bele, hogy ez-az-amaz a c++ kód nem hajlandó normálisan lefordulni, kényelmetlen, bugos, lefagy, kijön belőle a maszkos sorozatgyilkos, megöli a cicákat, stb… blueghost: igen. Szerintem fölösleges is túlbonyolítani. Vagy hogyha valaki már megtette, akkor érdemes írni neki egy olyan bemenetet ami így egyszerűen lekezeli az ömlesztett adatok pointereit és átvarázsolja az engine natív bemenetére. Én pl így tettem nemrég, írtam egy pointerbementet hogy lehessen értelmesen generált geometriát megetetnem az enginevel.

[Caiwan]

Az enyém ezzel ellentétben feldolgozza, és nem áíítgat pointereket, de most hogy így mondjátok, lehet majd egy későbbi verióban átírom.
Normalokat meg nem érdemes eltárolni, mert ki is lehet számolni.

[Geri]

De, tárold el a normálokat, sokan fény-árnyékjátékot csinálnak vele (pl az orr mellett kicsit eltorzítják a normálokat hogy önárnyékosnak tűnjön a fej), szóval a normálok az must have!

[Caiwan]

jah, úgy igen

[Geri]

Haladunk. vagyis Caiwan halad, én még nem csináltam szart se, de már majdnem nem fagy le! :D

[Caiwan]

Igenám, de akkora nagy memory corruption van benne, amilyet a tankönyv említ példaként. “Buta kisnyúl” módjára statikus tömbökben tárolom a szineket. Igen ám, de ezek az első adandó blokk végén azt mondják hogy vége, a cím meg lóg a levegőben. Mert a chunkok meg ilyen otromba módon vannak feldolgozva.Ezt biztosan át kell majd írni jobbra, mert kezd siralmas lenni az én szememben :/

[Geri]

mondjuk hosszú távon az lenne a legjobb ha az oop írmagját is kiírtanád belőle

[Caiwan]

hosszabb távon nem. Sőt. Az oop olyan mint a biciklizés: egyszer megtanulod, és csak azzal gondolkodol sokáig. Aztán rájössz hogy mindenhova mégsem jó, de rengeteg dolgot akkoris azzal fogsz megírni, mert milyen jó :)

[Geri]

te nem lefeküdtél már? :D

[Travis]

Geri, jól értem? A grafikusod egy rajzfilmfigura? A loadernek meg azért kell C-ben lennie, hogy mikrokontrolleren fusson? Mintha mikrokontrolleren nem lennének hagyományos értelemben vett fájlok. Ezen kívül LFT-nek nem hiszem, hogy szüksége lenne 3ds betöltőre, mivel tudtommal egyedül ő csinál mikrokontrolleres demókat.

[Caiwan]

:D Nekünk legalább élő személy a grafikus. Objektum-orientáltam meg lényegesen könnyebb programozni mint anélkül. Most ha csak win és linux alá írsz, akkor nem kell vele szenvedni.
És Geri, ne offolj.

[Geri]

Igen, a grafikusom egy rajzfilmfigura, aki mikrokontrollerekre modellez demókat, a lodernek meg azért kell c-ben lennie, hogy fusson a paksi atomerőmű szellőzőrendszerének a vezérlőchipjén, amit down kóros kislányok nyálaznak össze ritmusra, miközben egy fagylaltos bohóc az elültetett macskákat kapálja a reaktorzónában.

[Caiwan]

Nahszóval, a nép (Geri) nomására gyorsan kiadom az én 3ds töltőmet (amit az utolsó két pillanatba gányoltam össze ilyenre, hogy vakok és gyengénlátoknak is jó legyen) mert szegény gyerek alig várja hogy megkaphassa a játékát, de még írok ide pár tagmondatot hogy teljen az idő, meg kinyujtózhassak, meg miegymás.Íme a kód. Objektumos, szóval elvileg viszonylag könnyen lehet kezelni. Kész nincs teljesen, ez bennevan a readme-vel egybeházasított példakódban.Eredetileg úgy találtam ki hogy a model osztály tagfüggvényei fogják majd a rajzolást végezni, ezért ilyen. Amit viszont kellene vele csinálni az az, hogy orrvérzésig mindenféle 3ds filet betölttetni vele, és tesztelni tesztelni és tesztelni. Egyelőre ez ilyen bizonytalan release, és senki ne vegye kézpénznek, és buta kisnuszi módjára beletolni a saját kódjába, mert nem biztos hogy jó lesz (főleg kételkedem a vector osztály miatt) Már nem vagyok teljesen biztos abban, hogy ez a módszer jó, ahogy ezt csináltam, így jogos kérdésem mindenki felé: hogyan lehetne javítani, optimalizálni, stb?Remélem nem ez lesz a gengepontja a demónknak. Function után ha lesz egyáltalán valami, akkor megfűzöm a többieket, és kiadjuk az engine többi részét, azon célból, hátha talál valaki benne olyan dolgot, amit jobban is meg lehetne csinálni (biztos lesz)

[Charlie]

Caiwan wrote …
Íme a kód.

Aki memcpy()-vel másol odébb 4, hovatovább 2 byte-ot, az a bűn állapotában leledzik.

[Caiwan]

Akkor mit helyette? Pointert úgy ahogy van? Pedig jó ötletnek tünt.

[Geri]

*(unsigned short int*)cica=*(unsigned short int*)kutya

[Geri]

FWmodels::model3ds test(filedata, flen); puff elszáll a test.3ds-re. Amúgy asszem mégse volt jó ötlet a részemről ez a szegényember3dsbetöltője cucc, mert mindenki full máshogy fogja fel egy modellfájl betöltését, és az egyik ember annyira nem tudja felfogni e téren a másik ember kódját, hogy karbantarthatatlan lesz az egész.de közben már gcc kompatibilissé gyártottam.

[Caiwan]

jajj, hát persze! Rájöttem. Akkor reggel a délelőtti órákban megyek gyónni a c++ könyv társaságában. Mégia a Kettnek volt igaza.

[Geri]

hmm a defaultokhoz beraktam ilyeneket az unknown chunkok miatt hogy
ukchkFAIL++;
if(ukchkFAIL>1024) return; // fail
mert a végtelenségig pörgette a semmit

[Geri]

hmm itt valami nagyon nem smakkol, te, ugye egy facehez nem egy uv tartozik? :D

[Charlie]

Geri wrote …
*(unsigned short int*)cica=*(unsigned short int*)kutya

… és már szét is szállt a kód bármilyen big endian procin. (pl. XBox360, PlayStation összes művei, Wii, PowerPC Mac-ek, Sparc, stb.) Bár gondolom ez nem szempont.

[Geri]

egyelőre nem.http://legend.uw.hu/sm3DS.cpptessék Caiwan itt a 0.02, kijavítottam benne ezt a végtelenchunk izélődést, aztán egy fájllá gyártottam össze az egészet, megcsináltam hozzá a sad man interfészt, és átírtam úgy hogy forduljon GCC alatt is. Teszteltem és működik a tesztmodellel, már amennyire meg van írva. A freeket elfelejtettem beleírni, majd holnap – meg a változók nullázását is.tettem egy kommentet így hogy: // ebből még kéne 2 másik. hol van?!erről a pontról folytassuk majd a munkát

[Caiwan]

Uh, várjá, kihagytam valamit. Először is uv_3ds[number_of_mesh_3ds][j*6 +0]=(test.objects[i]).uvList[(test.objects[i]).meshList[j].x].u; uv_3ds[number_of_mesh_3ds][j*6 +1]=(test.objects[i]).uvList[(test.objects[i]).meshList[j].x].v; uv_3ds[number_of_mesh_3ds][j*6 +2]=(test.objects[i]).uvList[(test.objects[i]).meshList[j].y].u; uv_3ds[number_of_mesh_3ds][j*6 +3]=(test.objects[i]).uvList[(test.objects[i]).meshList[j].y].v; uv_3ds[number_of_mesh_3ds][j*6 +4]=(test.objects[i]).uvList[(test.objects[i]).meshList[j].z].u; uv_3ds[number_of_mesh_3ds][j*6 +5]=(test.objects[i]).uvList[(test.objects[i]

wrote …
).meshList[j].z].v;

így. Mert este volt. Aztán:

wrote …
default: ASSERT(log <<<” unknown chunk” << endl); reloff += chunk.len; ukchkFAIL++; if(ukchkFAIL>1024) return; // fail break;

Ez itt úgy ahogy van hülyeség, én ilyenkor hex editort rántok, és megnézem hogy melyik pozícióról próbál olvasni, és mit. Ésha beáll végtelenbe akkor mér nem viszi tovább az offsetet, stb … Úgy látom a legjobb az lesz, ha fogok valami gcc-t és optimalizálom ahhoz. Mellesleg ez a szegényember réteg is első ránézésre siralmas, legalább névtérbe tedd bele. A vector3d template meg több szempontból is hasznos lehet, gondolom látod :) Ezért mondtam hogy nem kéne kézpénznek venni mindent, mert mivan ha nincs uv? meg ezmegaz? azt le kéne ellenőrizni előtte, mert megint ottvagy ahol elkezded, hogy csak egy filehoz lesz jó.

[Author]

Posts