Na netu imas dosta loadera za raznorazne formate, pogotovu za ASE, pogledaj jedan od njih. Sve je to vec uradjeno, nema razloga raditi sve ispocetka. Takodje u zavisnosti od graficke biblioteke koju koristis, obicno imas neki native format za koji dobijas alate, u D3Du je to X format za koji dobijas gotove pluginove za 3DS i Mayu. Verovatno i za OpenGL postoji tako nesto.

ma gledao sam te loadere medjutim problem je sto nisu odradjeni do kraja, primera radi svi ti ase loaderi umeju da procitaju samo trouglove, sto ce reci ako je radio neko model iz cetvorouglova ili poligona da ce loader da poveze samo prva tri temena, posto taj detalj ocigledno nije odradjen ostaje pitanje da li je i ostalo pokupljeno i shvaceno kako radi a pravo da ti kazem da svaki model moramo detaljno da proveravamo bas i nije neka fora. Kako stoji stvar sa Mayinim formatom (obj) ?

Pa znas kako, graficke kartice ionako rasterizuju samo trouglove, tako da to nije lose. Ionako bi ti cetvorouglovi bili podeljeni u dva trougla, tako da je bolje da to uradis u grafickom programu, barem graficari mogu da vide na sta ce to da lici.

Za sta ti treba ucitavanje cetvorouglova?

Koliko sam se ja bavio ovim formatom, samo se trouglovi i exportuju. Em je to osnova za rendering (k'o što Relja reče) em bi to bilo nepotrebna komplikacija da ti sad imaš i trouglove i četvorouglove itd.

Pa koliko sam video ne eksportuju se samo trouglovi evo primer kocke, koja u sebi ima cetvorouglove http://www.math.iastate.edu/burkardt/data/ase/cube.ase tako da sa te strane malo mi smorno svako objekat koji dizajneri urade da rucno proveravam.

Relja ja koliko znam openGL radi pored trouglova i sa cetvorouglovima i poligonima(n temena) jedini uslov je da tacke budu planarne(u istoj ravni) i da bude konveksan. Verovatno openGL radi trisekciju svih poligona u implementaciji ali to pravo da ti kazem ne znam jer nisam imao prilike ni jednu implementaciju da gledam. A cinjenica da 3d studio moze da eksportuje i objekte koji nisu trouglovi. Opet kazem ako ovo nisu uradili kako treba sumnjam da im jos nesto nije podletelo. Zato sam radije voljan da imam specifikaciju. A samo parsiranje se uradi za 10 minuta koristeci lex.

Potrazi u nekom od NEHE primera, a mozes i u googlu da ukucas libase.
Moja preporuka ti je da ako imas instaliran MAX i MAX-SDK modifikujes
ASE exporter za koji postoji source u MAX-SDK. Podatke snimi u svoj
fileformat i uzivaj.

yooyo

Dejane, taj cetvorougao ce se svakako pretvoriti u dva trougla negde na putu do kartice. U velikoj vecini slucajeva bolje je da to bude sto ranije da bi graficar mogao da vidi kako ce to da ispadne, a ne da se iznenadi kada izadje nova verzija drajvera. Uostalom sta ces tacno da radis sa meshom koji sadrzi i trouglove i pravougaonike? Koliko ces da imas vertex buffera? Jedan po tipu primitive? Koju ce vrednost imati interpolirani registri u pixel shaderu? To zavisi od toga kako se pravougaonik cepa na dva trougla. Sve u svemu, osim ako ne exportujes kocke ili druge trivijalne objekte sastavljene samo od pravougaonika, imaces problema jer ce pola stvari biti trouglovi, a pola nesto drugo.

To sto 3DS Max ume da exportuje i Nurbsove ne znaci da mozes da ih nacrtas posle bez pretvaranja u trouglove.

Zato ti savetujem da svoje mesheve pretvoris u trouglove, da ih optimizujes (attribute sort i cache size pre svega) i koristis neki gotov kod, a sopstveni fajl format gledaj da ostavis za kasnije. Ako ti sve ostalo bude radilo, lako ces da napravis i sopstveni fajl format. Naravno, ne znam za sta planiras da koristis ovo, tako da je moguce da gresim.

Moram priznati da nisam nikad do sad video .ase fajl sa mnogouglovima. A zamisli tek taj krš od loadera, šta bi sve trebao da uradi - jer koliko sam video u tom fajlu, čiji si link ostavio, ne vidim da negde piše: e sad idu četvorouglovi itd. Znači unapred ne znaš šta te čeka. O renderovanju da ne govorim.
Pogledaj ase viewer koji sam napravio - imaš ga na mom sajtu.
Inače je ovo jedan od formata koji se najsporije čita. Ja sam za sebe onda pravio konverter koji to baci u neki mali binarni fajl. Prosto šibneš sve što imaš kao raw data i posle isto tako učitaš. Naravno, druga je situacija kad se radi u grupi, pa bolje poslušaj neke iskusnije.

Vecina komercijalnih (pa i ovih drugih) enginea importuje samo trouglove,
a retko koji trouglove i cetvorouglove. Kao sto kaze Relja, svi poligoni
ce definitivno postati trouglovi, pa je bolje da se engine ne bavi time
nego da odma radi sa trouglovima (i samo sa njima).
To sto LW i MAX i ostali programi prikazuju poligone sa n-strana, to je zato
sto je nekad sa njima laksi rad, ali to ne znaci da se oni trebaju ostaviti
na kraju - niti da imaju veliku primenu.
Da li si nekada video neki objekat iz neke igre sa poligonima sa vise od
3 (eventualno 4) tacke?

[primer]
Kad se pravi valjak sa 24 bocne stranice, LW napravi poklopce (vrh i dupe)
od po jednog poligona sa 24 tacke. Ukoliko bi se te tacke malo ''izmakle'' tako
da nisu sve u istoj ravni - poklopac bi ''puk'o'' ili bi na njemu svetlo ispalo
tragicno lose.
Zato i postoji u prozoru sa statistikom obavestenje o broju poligona sa >4
tacaka. Oni se mogu ''triplovati'' tj. jednom komandom izdeliti na trouglove
i to treba raditi i pored toga sto LW moze da iscrtava poligone sa n strana.
[/primer]

Savet1: Neka ti engine podrzava samo trouglove.
Savet2: Drzi sve objekte koji su modelovani tako da su sastavljeni samo od
trouglova i cetvorouglova, pre importa tripluj objekat i snimi pod drugim
imenom, tako da sacuvas ''netriplovani'' objekat, zato sto su objekti koji
imaju samo trouglove ili imaju poligone sa vise od 4 tacke dosta nepregledni
i malo ih je teze dalje doradjivati ili vrsiti odredjene manipulacije na njima
(pogotovu ako su komplikovani organski objekti kao covek ili kakva zivotinja:)).

Ako ti je za utehu, Doom3, Unreal2 i LS3D (Mafia) rade samo sa trouglovima.

To da su cetvorouglovi vidi se iz ovoga



tamo gde su trouglovi vide se samo temena A: B: C: ono sto nisam provalio sta znaci ono AB:1 i koja je razlika izmedju AB:0 mada opet kazem ASE ne znaci da ce biti finalni format mozda se odlucim i obj da koristim od maye. On mi nekako deluje kompaktnije.

Pomalo zalim sto sto openGL nema nesto kao .X sto koristi d3d :) al dobro sta da se radi, a o sopstvenom formatu pa hmm iskreno receno ako mi se neki od ovih formata pokaze dobar, razmisljam njega da koristim do kraja :)) jedino sto cu uraditi jeste zipovati podatke da ne zauzimam toliko prostora :)

Nemozes smisliti generalni file format. U zavisnosti od toga sta zelis da postignes
vertexi treba da imaju odredjene atribute (pos, normal, textcoord1 texcoord2,
bone index, bone weight, fog, separate color, ...). Ako pravis game, onde bi
trebalo da imas "kompajliranu" mapu u file-u, koju brzo ucitas i jos brze gurnes
u graficku karticu.

Zamisli da svaki put kada se ucitava level, engine racuna light maps, smoothing,
bone indexing...

yooyo

Pisem MMOG svemirslu simulaciju. http://www.elitesecurity.org/tema/39514 Da kada bolje razmislim u pravu si za format, trba ga srtpati u neku formu da se sto brze ucitava.

Ovde se ne slazem sa tobom, yooyo. X files podrzavaju FVF i vertex DECLove, tako da mozes da imas proizvoljne atribute za svaki mesh (tj. vertex buffer). Jedan VB moze da ti bude position, normal, tangent, drugi moze da bude samo position i texcoord. Tacnije, bilo koju C strukturu mozes da zapises u X fajl, pogledaj templateove u helpu.

Pritom X fajlove postoje u dve varijante: teskt i binarni, i jos opcionalno mogu da budu kompresovani ZLIBom (automatski, u okviru biblioteke).

Sto se tice tekstura, bolje je da one budu nezavisne od mesha: prvo, moze da se desi da vise mesheva koristi istu teksturu, drugo, zgodno je da mozes da radis operacije na teksturama a da pritom ne menjas mesheve (smanji sve teksture, pretvori u DXT format, itd.).

Nisam 100% siguran ali mislim da AB:1 bi trebalo da ima uticaja ako renderujes zicani model. Dakle AB:1 znaci da je duz koja spaja temena A i B vidljiva u zicanom modelu. U svakom slucaju treba to treba da ignorises.
E sad imam i ja jedno pitanje. Ako objekat ima samo jedan materijal(dakle nema submaterijala) kakvo je znacenje tag-a *MESH_MTLID. Obisno tu 3ds lupi neke brojeve od 0 do 6 ?! S obzirom da nema submaterijala sto inace indeksira *MESH_MTLID logicno je da je uvek 0 ili 1.

Inace cela prica o cetvorouglovima je besmislena. Bolje ti je da preradis sve modele u trouglove nego da gubis vreme na tome.

*MESH_MTLID je broj materijala koji se koristi za taj trougao. Materijal obicno podrazumeva teksturu / efekat (shader + tesktura) i parametre za osveljenje. Materijali su definisani u odvojenom delu fajla.

Znam da u X moze da ide svasta. Medjutim, posto ne koristim DX onda mi ni X file
nije koristan. Dosta dugo se bavim 3d programiranjem, tako da sada vec imam
razradjene toolove i plugine za MAX i Maya. U mojim file formatima se pored
rendering geometrije nalaze i sekundarni podaci koji se koriste od strane engine
(collision, efekti, kamere, sounds...) i to u obliku koji meni odgovara.

Kad bolje razmislim... cak je i moguce koristiti X files u OpenGL-u... Malo je
maltretiranje konvertovati matrice, ali u principu moze.


yooyo



[Ovu poruku je menjao yooyo dana 11.02.2004. u 02:33 GMT]

Ne sumnjam da tvoj format radi sve ono sto ti treba, i da to radi vrlo dobro, ali sam samo hteo da skrenem paznju na to da je izjava da nema generalnog formata problematicna.

Uostalom, ako imas neke predloge za nov fajl format, voleo bih da ih vidim, jer cu skoro poceti time da se bavim (doduse ne full-time). Sav input je dobrodosao.

To je u redu. Samo sam pitao zasto ako u fajlu postoji samo jedan materijal max izlupa brojeve uglavnom izmedju 0 i 6.

Kratko... XML.

yooyo

Samo da napomenem da ni jedan od 3 OBJ loadera koja sam skinuo nije po specifikaciji formata :))

http://www.gametutorials.com/Tutorials/opengl/OpenGL_Pg4.htm
http://www.wotsit.org/download.asp?f=objsrc

doduse ovaj je najblizi
http://jet.vr.clemson.edu/

tako da sve u svemu izgleda da cu ipak morati da budem sam svoj majstor. Nema druge flex ce morati da radi :)

Dejane, o cemu se radi, sta nedostaje tim loaderima? Postuj rezultate ovde da i ostali mogu da vide.

Postoje razlike u nacinu na koji odredjeni programi
exportuju .obj.
Recimo, u svim tim primerima sa neta stvari stoje ovako:

I ovo je OK, samo sto .obj format malko varira od
exportera do exportera. Naime, uv koordinate se mogu staviti
odmah iznad face i onda se koristi negativni index za uv koordinatu.

MilkShape exportuje .obj kao u primeru 1, a
LW kao u primeru 2. Ne znam kako Max exportuje .obj,
ali bi voleo da cujem od nekoga.
Ako je ovo problem, neka se svaki objekat provuce kroz MilkShape
i onda ce ga bez problema ucitati primer sa gamedeva.

reject zaboravio si da dodas i komponentu normale
oznacavaju se na pocetku za


isto tako face ima oblik


Pa video sam da neki od onih ne ucitava normale drugi radi samo sa trouglovima itd..

U pravu si.
Primer sa gamedeva ne importuje info o normalama,
vec ih racuna nakon importovanja. Koliko se secam
ni Milkshape ni LW ne exportuju podatke o normalama
u .obj.
Znaci kombinacija ''triplovanih'' objekata, Milshape
exportera i importera kao u gamedev-primeru bi
resila tvoj problem, mada bi bilo malo komplikovano. :)
Dal neko zna kako Max exportuje .obj?
Ako ga exportuje kao MilkShape, onda je tvojim mukama
kraj, jer koliko sam shvatio graficar radi u Maxu. Samo
treba da ''tripluje'' objekat i exportuje ga u .obj.
Ako ga exportuje drugacije, primer sa gamedeva se moze
malkice izmeniti.

Po meni, nacin na koji exportuje LW je mozda i bolji zato sto
se pri importovanju vt ne moraju nikako indexirati zato sto
ih poligoni koriste redom kojim su vt-ovi upisani u file.
Znaci prvi face koristi vt 1 2 3 redom, drugi face koristi
vt 4 5 6 redom i tako dalje, tako da se jedan trougao moze
srediti vec pri citanju vt-ova:
Evo malo razmisljanja:
1.Da bi stigao do vt-ova i f-ova program koji cita redom morao
je da procita sve v-ove i da ih negde smesti u memoriji.
2.Citanjem se nailazi na 'vt' (ovo znaci da su svi v-ovi spremni
za spajanje sa svojim vt-ovima) tako da se odma moze dodati
novi trougao, u njegove point[1].vt, point[2].vt i point[3].vt
upisati vt-ovi redom.
3.Odma posle toga nailazi se na face. I odma se mogu izcitati
i koje to v-ove koristi trougao i prebaciti te v-ove ili samo
njihov index(po zelji) u point[1 do 3].v.

Nego, sta si odlucio, samo trouglovi, trouglovi i cetvorouglovi ili
podrska za jos neku vrstu poligona?

Ovo ce vam biti interesantno...

Max File Reader:
http://sparks.discreet.com/downloads/downloadshome.cfm

exportuje MAX file u XML ifi u neku bazu preko ODBC-a

yooyo

Pa moji graficari koriste pored maxa mnogo drugih programa tako da ce verovano sve ici iz ostalih programa u mayu pa ce se iz nje exportovati u obj. Video sam i to sa negativnim referenciranjem. Medjutim tu isto tako gubis tj sam obj fajl je mnogo veci jer se mnoge tacke visestruko ponavljaju. Tako da umesto veceg alociranja citaces n puta veci fajl pa meni nekako lepse je raditi sa svim apsolutnim referencama.

Pa licno sam odlucio da podrzim i visetemene poligone. Ako maya tako generise sta da joj radim moram da ispostujem. Upozorio sam graficare da cemo mozda imati muke da objekti mozda nece izgledati identicno. Sa druge strane poceo sam u lexu da pisem parser koji ce da cita obj i da odma pravi openGL display listu.

Jeste, u pravu si, fajl jeste veci i to se verovatno
dosta primecuje kod objekata sa brdom poligona.

Pusti ti mayu i max i LW, generisu oni sve i svasta,
ali to uglavnom rade da olaksaju rad modelaru i animatoru.
Moj je savet da se ne mucis sa visetemenim poligonima.
Koriscenje poligona od vise tacaka ti samo stvara probleme,
a moze se resiti jednom komandom u modelaru pre snimanja
finalne verzije objekta. Pazi - samom hardwareu je isto dal
crto trouglove ili n-touglove, on i onako crta samo trouglove :),
a tebi je vece zezanje da pravis podrsku za n-touglove nego
da graficari tripluju objekat pre nego sto snime finalnu verziju.
U lw-u stisnes shift+t i svi poligoni postanu trouglovi, i
onda snimis objekat i tako resis sve probleme.

Takodje, uvodjenjem ovih poligona neces moci da izvedes neke
jednostavne a lepe efekte. Recimo, ako je objekat pod vodom,
on moze da malkice menja svoj oblik tako sto se sve njegove tacke
malkice pomeraju (po malim slucajnim brojevima po sve tri ose).
Ukoliko je objekat od trouglova, sve je OK i trik radi super.
Medjutim ukoliko imas poligon od x tacaka dovoljno je da par njih ode
u levo, par njih u desno i da tacke vise nisu u istoj ravni.
Sta se onda desava? Objekat malkice menja oblik, a malkice puca,
odnosno ti poligoni se nece iscrtati kako treba.
Ovaj efekat se moze primeniti i na brod koji je ispao iz hiper-svemira
pre par sekundi, a moze da se isto tako malo ''cimne'' kokpit kad te
pogode nekim oruzijem. Isto u nekom fps-u moze tako da ti se
''muti vid'' kad te pogode nekim suzavcem ili udjes u dim.

Ovo je verovatno najneoptimalniji moguci format zapisa mesha. Gomila vertexa se duplira, trosi se memorija i GPU na sve strane. Ako izaberes ovakav format, budi spreman na ogromne (2-3x) gubitke u performansama i prostoru.

Na danasnjim GPUovima, cache optimizirane index liste u opstem slucaju daju najbolje performanse.

Relja pod tom optimizacijom jel mislis na da se koristi GL_TRIANGLE_STRIP i GL_TRIANGLE_FAN

[img]
http://www.dcc.unicamp.br/~lma...603/redbook/images/Image34.gif
[/img]

E i sada prakticno pitanje kako da izoptimizujem gomilu face-ova da budu tako pogodno uneseni, tj da li cu sa kesiranom display listom nadoknaditi to sto cu ovako neka temena unositi vise puta?

Nisam mislio bas na to. Na modernim procesorima nema dobiti od stripova i fanova ako dobro organizujes vertexe. Koliko se secam OpenGLa, tu ne postoji API za optimizaciju mesheva, ali siguran sam da mozes da nabavis na netu sors za to.

U Direct3Du se to radi ovako:



Takodje, mozes da koristis MeshView alat u Direct3D SDKu koji ti omogucava da ucitas mesh, da ga optimizujes, i da ga sacuvas. Ovako optimizovani meshevi ce u opstem slucaju biti optimalno rasporedjeni za renderovanje. Zbog toga se i koriste index liste, jer u njima mozes proizvoljno da menjas raspored trouglova dok ne dobijes najbolju varijantu.

Jel zna neko mozda specifikaciju mtl formata ili ima link gde da ga nadjem(mtl je deo vezan za materijale i koristi se u konjukciji sa obj-om)

E ljudi mukama je dosao kraj :), slucajno sam naleteo na neki projekat u kome je bio loader :) a da vas ne cimam da skidate 11mb :) evo okacicu ga ovde pa ko zna mozda nekome moze da posluzi :)

Uz malu napomenu ovaj kod je pisan za openGL, pa ne znam koliko ce biti od koristi ostalima.