Dobrodošli, goste ( Prijava | Registracija )

 
Reply to this topicStart new topic

Mala skolica game designa, tehnike izrade 3d igrica

V
Angel_of_Dark
poruka Mar 11 2005, 00:27
Poruka #1




Grupa: VIP
Poruke: 1,463
Datum reg.: 28-January 05
Lokacija: Milano
Član broj: 162



Kao sto sam i obecao:
Skolicu zamisljam kao uporednu virtuelnu skolu kursa koji pocinjem da odrzavam od novembra, i koju cu pokusati da ispratim na ovom forumu koliko god mi vreme ( i vase interesovanje) bude dopustalo.
Ovo nije skola programiranja, iako ce biti dosta govora o principima programiranja, ali cu te price pokusati da pojednostavim sto je vise moguce. Ovo bi na prvom mestu trebala da bude skola za kreativce, od koje ce na prvom mestu moci da profitiraju 3d modelari, animatori, dizajneri vizuelnih efekata i zvuka. Popnajvise ce biti price o principima kontrolisanja medija, RT renderingu, virtuelnim karakterima, limitima hardverske i softwerske vrste, i zapravo svemu onom sto je pozeljno da jedan multimedijalni umetnik upozna da bi lako mogao da se ubaci u ambijent rastuce game industrije i interaktivnog 3D-a. Takodje, skoncentrisacu se ponajvise na first person nacin igranja, kao najzahtevniji i najkompleksniji sistem pravljenja igrice iz perspektive multimedijalnog dizajnera (pod FP nacin igranja podrazumevam u ovom slucaju i igrice iz treceg lica i simulacije, izraz koristim samo da bih naznacio da se radi o tipologiji igrica koje se najvise priblizavaju realnom pojmanju prostora i vremena)
Takodje, ovo je pravo mesto za eventualne zajednicke eksperimente i male projekte.
Problem predstavlja odakle poceti posto mi je jasno da ovde postoji dosta ljudi sa razlicitim kvalitetom znanja, a opet, zeleo bih da ovaj tekst bude pristupacan svakome. Sva pitanja i sugestije su dobrodose - voleo bih najvise da se ova skolica pretvori u jednu otvorenu diskusiju i da iz se iz nje eventualno izrode neke nove ideje.
Go to the top of the page
 
+Quote Post
Angel_of_Dark
poruka Mar 11 2005, 00:27
Poruka #2




Grupa: VIP
Poruke: 1,463
Datum reg.: 28-January 05
Lokacija: Milano
Član broj: 162



Pocecemo verovatno malo haoticno posto postoji dosta stvari koje su usko povezane a nemaju neki precizan nacin klasifikacije po vaznosti, tj. jedna je proporcionalno zavisna od druge a opet su drasticno razlicite.
Dosta puta cemo se vracati na odredjena objasnjenja, a to cu pokusati da, sto je moguce vise, povezem linkovima sa prethodnim referencama.
Vazna stvar je da prihvatite da sve sto je ovde napisano predstavlja samo jedan od nacina rada, i da cu taj nacin rada koji sam stekao kroz iskustvo pokusati da opisem. To se pogotovo odnosi na software i na 'content creation' (kreiranje sadrzaja).
Mozda cete videti kroz vreme i neke nedostojnosti u mojim iskazima, ali to morate prihvatiti kao nezaobilaznu pojavu u software industriji - tehnologije se menjaju ogromnom brzinom a sa time se menjaju i procesi njenog koristenja - ne postoji definitivna biblija game designa jer ono sto se pokazalo kao uspesno juce, moze biti totalno neuspesno sutra.
Ponavljam, ovo je jedan od nacina rada, ali u isto vreme predstavlja i sliku main stream nacina rada, svi procesi koje cete naci u game designu ce biti tu, samo pod drukcijim nazivima ili uradjeni u drukcijem softwareu. To ce biti iz vise razloga:
-preferiram da pricam o softwareu koji ja personalno poznajem najbolje a samim tim mogu na najbolji nacin da pomognem
-ovi softwarei su po mom misljenju najbolji all round softweri za game design, kako sa strane opcija, free plug-inova, tako i sa strane njihove fleksibilnosti u didaktickom radu koja ce verovatno biti jasnija tek kasnije.

Za pocetak bih voleo da definisem primarni software sa kojim ja radim:
-Za 3d content creation koristim primarno 3d studio max i SketchUp (koji se pokazao fenomenalno u ambijentu level designa)
-za 2d content (tj. teksture i sprajtove) koristim photoshop
-za programiranje i RT rendering koristim Virtools Dev, koji je verovatno najintuitivniji alat za programiranje (authoring) ikada napravljen, a fokusiran je kako na programere - tako i na kreativce. Sa druge strane Virtools je odlican i za didaktecke svrhe, jer citavo programiranje predstavlja na vizuelan nacin koji je lagan za citanje.
http://www.virtools.com/
Inace, poseduje sve sto jedan moderan engine treba da poseduje - u njemu je moguce raditi iste stvari kao i u doom3 engineu. Uz to, bilo koji materijal je moguce publikovati direktno na netu uz malu velicinu fajla.
Go to the top of the page
 
+Quote Post
Angel_of_Dark
poruka Mar 11 2005, 00:28
Poruka #3




Grupa: VIP
Poruke: 1,463
Datum reg.: 28-January 05
Lokacija: Milano
Član broj: 162



Prvo bih voleo da objasnim sta je to game engine i osnove njegovog funkcionisanja.
Cesto se desava da se u razgovoru o game engine (motoru) brkaju pojmovi kao sto su game engine, render engine i level editor.

-game engine je zapravo software koji sluzi kao pokretac nase igrice, koji sjedinjuje razne fiunkcije motora koji stoji iza onoga sto se desava u igrici. Game engine moze sadrzati motore za rendering (iscrtavanje), manipulisanje objektima, karakterima, partiklima (cesticama), animacijama, proceduralnim animaijama, optimizacijom scene, vestackom inteligencijom, simulacijom fizike, manipulisanjem zvuka.

-render engine je deo game enginea koji na sebe snosi zadatak odluke o tome sta i kako ce biti iscrtano na nasem ekranu. On sam po sebi ne iscrtava sliku, vec samo donosi vazne odliuke o tome koji su poligoni i objekti vidljivi a koji ne. Zatim te informacije prenosi takozvanom rasterizeru.

-Rasterizer: DirectX 9, Open GL, software. Sve su to vrste rasterizera koji zapravo nase podatke koji su izracunati u 3D vektorskom prostoru - transformise u 2d vektorski prostor, tj. u 2D sliku na ekranu. Rasterizer je u danasnje vreme usko povezan sa hardverom i predstavlja neizostavnu sponu izmedju game enginea i hardvera.

-level editor: Level editor je najcesce software sa GUI koji sluzi za kreiranje i skriptovanje igrice, a samim tim i za manipulisanje medija. To je deo game enginea gde cemo u pricipu provesti najvise vremena cesto i neznajuci sta se krije iza haube citavog enginea. On direktno saradjuje sa game motorom, ali kroz prijateljski interfejs. Kazem prijateljski interfejs, jer on pomaze da umetnik lakse skriptuje i kontrolise medije u okviru igrice. Dovoljno je samo pomisliti na cinjenicu da u danasnje vreme odnos programera i umetnika koji rade na igrici je 20/80 u korist umetnika.
Go to the top of the page
 
+Quote Post
Angel_of_Dark
poruka Mar 11 2005, 00:29
Poruka #4




Grupa: VIP
Poruke: 1,463
Datum reg.: 28-January 05
Lokacija: Milano
Član broj: 162



Izvinjavam se zbog pauze u pisanju, ali nisam mogao da nadjem slobodnog vremena. Nastavljamo:

Izrada igrice je izuzetno komplikovan i slozen posao. Nekada je bio slozen sa programerske strane gledista, danas postaje sve vise slozen sa 'umetnicke' strane. Kao sto sam prethodno napomenuo, vec sada je po studijima odnos 80% prema 20% u korist umetnika. Tendencija je da ce tako, ne samo ostati, nego da ce se ta razlika jos vise povecati, a neki zadaci ce sa programera preci na umetnike. U danasnje vreme u produkciji jedne igrice ucestvuje veliki broj strucnjaka raznih oblasti, a svakom novom tehnologijom broj kreatora i kompleksnost se povecava, sa rezultatom da produkcija cesto traje i po 3-4 godine. U ovakvom ambijentu jako je bitno znati dobro sta zelimo da napravimo i koji je relno nas cilj. Na ovom ispitu cesto i najveci studiji padaju (dobar (los) primer bi bila igrica 'Enter the Matrix'). Ne treba zaboraviti takodje da, posto se ipak radi o proizvodnji softwera, cesto je jako tesko predvideti sve probleme koji se mogu naci na putu u vidu bug-ova.
U planiranju se pocinje naravno od ideje - tj. od price koja ce zaokruziti nas gameplay.
Scenario je - iako se cesto u recenzijama govori o njemu - kako to lepo kaze kreator Dooma John Carmack: "Story in a game is like a story in a porn movie. It's expected to be there, but it's not that important." (prica u igri je kao prica u porno filmu - ocekuje se da postoji - ali ona zapravo nije toliko vazna). Naravno, ni to nije tako jednostavno, ali, o ovoj temi cemo pokusati da rapravljamo dosta kasnije. Ono sto je po meni najbitnije je gameplay, tj. koliko jedna igrica ovakvog tipa uspeva da nas uvuce u njen svet i atmosferu.

Jednom kada imamo pricu i znamo sta zelimo da napravimo, moramo odluciti kako to treba izvesti i to je verovatno jedna od najtezih odluka. Ovde govorim o tehnickom pristupu, tj. onome cemu cu navjise paznje posvetiti u maloj skoli game designa. Cesta greko u produkciji je ta da se neretko desava da se u startu planira na osnovu trenutne tehnologije, ili jos gore, krece se sa vec zastarelom tehnologijom ili se cilja da je igricu moguce igrati na trenutacnim konfiguracijama.
Produkcijki ciklus je suvise dugacak, i kako sam rekao, radi se cesto o godinama produkcije, a hardwer sa druge strane mnogo brze napreduje. Rezultat je da cesto po izlasku igre, tehnologija i njen vizuelni kvalitet su jako iza standarda u tog trenutka. Primera ovakvih flopova ima previse.
(uzecu jedan primer iz moje sredine: moj kolega trenutno radi na jednoj takvoj igrici za playstation 2. Prosle su 4 godine od kada su zapoceli za radom razvijajuci svoj engine. Svake godine su taj engine morali da pisu iz pocetka ili da ha nadogradjuju da bi odrzali korak sa vizuelnim kvalitetom konkurentnih igrica. Medjutim, svaka izmena takve vrste je zahtevala i izmene u artworku igrice. Zbog pogresne pocetne procene i idenja linijom manjeg otpora imajuci u vidu konkurenciju od pre 4 godine, zasli su se pred bankrotom, i pitanje je dali ce uspeti da na trziste izadju pre izlaska playstationa 3 Znaci, radi se o gresci koja se skupo placa: bolje je u startu preceniti sebe i ciljati najvise sto je moguce, nego pokusati praviti nesto sto je u startu mediokritetno).
Go to the top of the page
 
+Quote Post
Angel_of_Dark
poruka Mar 11 2005, 00:29
Poruka #5




Grupa: VIP
Poruke: 1,463
Datum reg.: 28-January 05
Lokacija: Milano
Član broj: 162



Oni koji se vec bave 3D modeliranjem, verovatno su primetili da u nekim igricama mogu videti kompleksne objekte i ambijente koji se mnogo bolje ponasaju nego sto bi se vizuelno identicni objekti napravljeni u programu za modelovanje ponasali u viewportu. Ako ste jos pokusali i renderujete, viudeli ste sigurno da su vremena visestruko sporija (na primer, pokusajte da napravite jednu sliku vizuelnog kvaliteta poput Doom3, i da istu takvu sliku izrendirate) Verovatno ste se zapitali: 'Konfiguracija je ista, ista je graficka kartica, drajveri su isti, ali sve radi 50% sporije, pa onda zbog cega?'
Odgovor cu pokusati da dam kroz sledecih nekoliko lekcija. Savetujem svima da se skoncentrisu na ove redove jer su vrlo bitni i pozeljno je znati ih i razumeti ih pre nego sto se upustite u bilo koji rad (prvenstveno kreativni deo koncept arta a zatim modelovanje).
Vraticemo se na pitanje: kako to da engine i kreatori igrice uspevaju da ubrzaju nasu scenu na efikasan nacin?
Radi se o tome da je scena organizovana na drukciji nacin nego sto bi to bilo u nekom 3D programu. Pokusacu sada samo da navedem neke nazive osnovnih tehnika, a zatim kroz sledece lekcije i da objasnim njihovo funkcionisnje podrobnije. Hierarchical Culling, BSP, Viewport clipping, LOD meshing (sa visestrukim objektima sa vise i manje detanja, progressive meshing i generacija terena sa i bez geomorphic tranzicija), primena portala iu organizovanje scene, optimizacije mesha u procesu modelovanja.

Pokusacu da napravim paralelu izmedju osnovnih pojmova u svetu renderovane 3D animacije koji je svima blizi - naspram ekvivalentnih pojmova u svetu real time interaktivne animacije.
Go to the top of the page
 
+Quote Post
Angel_of_Dark
poruka Mar 11 2005, 00:30
Poruka #6




Grupa: VIP
Poruke: 1,463
Datum reg.: 28-January 05
Lokacija: Milano
Član broj: 162



Pozabavicemo se malo geometrijom modela i kako se ona ponasa u jednoj 3d igrici.

Najbolje je da prvo izvedemo osnovne geometrijske elemente (3d entitete) jedne 3d scene. Pod osnovnim elementima podrazumevamo 3d objekte.
Svaki 3d objekat poseduje MESH
> Mesh je sastavljen od fejsova
> Svaki fejs je sastavljen (tj. definisan) sa 3 vertexa.
Zapitacete se gde su nestali edgeovi i poligoni koje mozemo manipulisati u vakom 3d programu?
U RT 3D-u poligoni i edgeovi su logicki pojmovi, tj. oni realno ne postoje, vec su samo proizvod osnovnih elemenata - fejsova i vertexa. Znaci, nasa video kartica nikada nece saznati te informacije, da se tako izrazim. Svaki poligon je predstavljen samo sa fejsovim. Znaci, poligon sa 4 vertexa = dva poligona sa po 3 vertexa koji ih opisuju, i naravno, 2 vertexa od ta tri su zajednicki.
Skoncentrisacu se na to kakve informacije sadrze ove jedinice.

Pocecemo od vertexa:
Vertex sadrzi informaciju o svojoj poziciji u 3d prostoru. Ta informacija je direktno asocirana sa njim i opisuje se sa vektorima. Vektor je skup X, Y, Z koordinata. Te koordinate su iskazane u lokalnom koordinatnom sistemu. Centar lokalnog koordinatnog sistema je definisan u samom objektu, tj. predstavljen je pivot pointom objekta.
Za vertex nije dovoljno da poseduje samo vektorske koordinate. Svaki vertex mora da poseduje jos jednu informaciju, takodje iskazanu u formi vektora, a ta informacija je njegova usmerenost, tj. normala. Znaci, vertex, iako je virtuelna tacka, gleda u odredjenom pravcu, a taj pravac je druga tacka. Njemu su takodje asocirani drugi vertexi, tj, vertexi sa kojima je povezan edgeovima. Naime, svaki vertex u meshu poseduje i svoj identifikacioni broj, a uz njega asocirane identifikcione brojeve drugih vertexa sa kojima je povezan. Ove informacije sluze da bi nas hardware (rasteriser) mogao da interpretira i rekonstruise osnovnu geometriju objekta.
Pored tih informacija, vertex moze posedovati citav niz drugih informacija (mapping coordinate, vertex color, vertex weight) koje nisu najuze vezane za geometriju, a o kojima cemo raspravljati kasnije.

Fejsovi: Ovde se stvari malo vise komplikuju. Vertexi, kao sto smo videli, su jako slicni kao vertezi u 3d modeling programu, sto kod fejsova nije slucaj.
Fejsovi zapravo sadrze jako malo informacija, tj. samo jednu informaciju, a to je vektor njihove normale. Taj vektor sluzi da bi orijentisao sam fejs, tj. da bi rekao koja je gornja strana (vidljiva strana) a koja donja. On moze biti bilo koja tacka u prostoru, i njegov utisaj moze biti samo u okviru bool-a : da ili ne. Ako je ispod tri vertexa koji cine fejs, onda taj fejs gleda na dole, ako je iznad, onda gleda na gore. Razlika sa 3d modeling programom je ta da fejsovi mogu sadrzati smoothing grupe. U RT iscrtavanju, pojam kao sto su smoothig grupe ne postoji. Za sve fejsove koji su povezani vazi pravilo da su automatski smoothovani, tj. da pripadaju istojh smoothing grupi.
Sa ovim, sto je inace jako bitno, cu se pozabaviti u sledecoj lekciji.
Go to the top of the page
 
+Quote Post
Angel_of_Dark
poruka Mar 11 2005, 00:30
Poruka #7




Grupa: VIP
Poruke: 1,463
Datum reg.: 28-January 05
Lokacija: Milano
Član broj: 162



Kao sto smo videli u prethodnoj lekciji, neke informacije se u meshu zapisuju na razlicita nacin nego u 3dmodeling programu. Osnovni razlog tome je sto svaki mesh i njegova struktura mora da bude na neki nacin 'pojednostavljena' i brza za renderovanje u realnom vremenu.
Ovde cu objasniti malo blize strukturu mesha i podataka koji se dodeljuju vertexu. Ovo ce biti samo referenca odredjenih stvari koje cemo kasnije objasniti malo potpunije:
-Vertex Position (kako smo vec rekli radi se o koordinatama u formi vektora - Vector 3D (x, y, z) iskazanih u lokalnom koordinatnom sistemu)
-Vertex Normal (Vector 3D, lokalna koordinata)
-Vertex Color (Color (r, g, b, a))
Vertex kolor je 'boja' koja se moze dodeliti vertexu. Ona se koristi za pre-kalkulaciju svetla i boje mesha i njegove eventualne transparence. Iskazana je u RGBA (komponenta A je alfa vrednost, tj. transparentnost vertexa) formatu, sa komponentama iskazanim u integerima u rasponu od 0 - 127.
-Vertex maping koordinate. (vector 2D (x, y)) Ove koordinate su iskazane sa vektorom u 2D i njihova vrednost (float) ide od 0 do 1. Ona dodeljuje odgovarajucu tacku texture svakom vertexu. Ako imamo texturu velicine 256x256 i na vertex stavimo vrednost 0.5, 0.5, na tom vertexu ce se naci tacka koja odgovara koordinati pixela 128 x 128, znaci, sam centar nase mape.
-Vertex Weight (float vrednost koja se moze dodeliti svakom vertexu, sluzi za specijalne efekte i za dodeljivanje atributa za skinovanje mesha)
-materijal (svakom vertexu moze biti dodeljen 1 materijal). Ovde nastaje problem slican problemu sa smoothing grupama:
Hardwerski renderer prepoznaje sve fejsove koji su medjusobno povezani kao automatcki smoothovane. Da bi znao da je jedna ivica ostra, on mora da razdvoji mesh, tj. da duplicira vertexe. Na taj nacin, ako imamo box sa 6 stranica i sa ostrim ivicama on, iako bi u modeling programu imao zapravo samo 8 vertexa, u nasem engineu ce imati 4x6 vertexa, sto je moramo priznati, dosta vise. Ovo je iz razloga sto na ovaj nain, engine moze da izbegne dodatno opterecenje racunajuci koje strane su ostre a koje ne, ali sa povecanjem broja vertexa. Veci broj vertexa usporava racunanje, ali ne toliko koliko bi usporilo dodatno smoothovanje, jer je moguce koristiti optim izacije u samoj kartici koja ce videti vektore na kojima se nalaze dupli vertexi, i sve njihove transformacije ubrzati racunajuci samo jednu koordinatu (koristeci vertex cache buffer ili tehnika poput vertex stripifying-a).
Isti slucaj 'razbijanja' mesha cemo imati i sa razlicitim maping koordinatama, tj. ako je jedan vertex dodeljen vecem broju fejsova a ti fejsevi poseduju razlicite maping koordinate (takozvane non-continuous mapping koordinate).
Go to the top of the page
 
+Quote Post
Angel_of_Dark
poruka Mar 11 2005, 00:31
Poruka #8




Grupa: VIP
Poruke: 1,463
Datum reg.: 28-January 05
Lokacija: Milano
Član broj: 162



Ovde mozete naci interaktivni 3d prikaz osnovnih geometrijskih elemenata o kojima smo pricali prethodno:


http://lnx.organismedia.com/oliver/skola/normals.htm



Za rotiranje koristite kursorske strelice na tastaturi + pgUp, pgDown tastere za zumiranje
Go to the top of the page
 
+Quote Post
Angel_of_Dark
poruka Mar 11 2005, 00:31
Poruka #9




Grupa: VIP
Poruke: 1,463
Datum reg.: 28-January 05
Lokacija: Milano
Član broj: 162



Videli smo kako je mesh organizovan interno (kasnije kada se budemo pozabavili texturama, vraticemo se na ovu temu) a sada cemo se pozabaviti malo organizovanjem scene, nacinom renderinga i generalnim optimizacijama.
Svaki mesh je najcesce jednostran, sto znaci da se renderuje samo njegov prednji deo, tj. stranice cije normale gledaju u pravcukamere. Sve ostale stranice se ne kalkulisu.
Sta se desava sa objektima koji se nalaze jedan ispred drugog?
Svi objekti koji se nalaza u scenu se renderuju uvek, oni postoje i svaki objekat u viewportu mora da bude izrenderovan. Cak i u slucaju da se neki objekat nalazi u iza zida, u drugoj prostoriji naceg levela, on ce prvo morati da bude izrenderovan, pa pokriven sa zidom. To interno u grafickoj kartici funkcionise slicno ovome:



Za pitanja i komentare koristite ovu temu:
Go to the top of the page
 
+Quote Post
Angel_of_Dark
poruka Mar 11 2005, 00:32
Poruka #10




Grupa: VIP
Poruke: 1,463
Datum reg.: 28-January 05
Lokacija: Milano
Član broj: 162



Posto smo videli dase sve ste se nalazi u sceni zapravo renderuje i da nasa graficka kartica ne zna sta treba da izostavi, pokusacu da objasnim neke od nacina optimizacije od strane enginea (znaci, optimizacije koje se izvode autimatski vise manje) i optimizacije koje se izvode uz nasu pomoc.
Kako jedna scena uradjena u programu za modeling biva renderovana zapravo?
Znaci, mi posedujemo model koji je uslovno receno skup koordinata i vektora u 3D prostoru. Ta ista scena treba da se predstavi zapravo u 2d prostoru koji je nas ekran. Znaci, scena se uz pomoc trigonometrijskih funkcija projektuje u odnosu na nasu kameru, i render engine odredjuje sta ce biti vidljivo a sta ne.
U ovome nam pomaze graficka kartica. Graficka kartica poseduje akceleraciju za ove funkcije. U 2d grafici znamo da se rezolucija i moc kartice mere sa maksimalnom rezolucijom o brojem boja koje se mogu raprezentovat na ekranu. Takodje, sigurno znate da ta kolicina informacija zahteva veliku obradu podataka i veliku kolicinu memorije. U 2d grafici postoje samo X i Y ose, tj. vertikalna i horizontalna rezolucija. U 3d akceleraciji postoji pojam Z ose. Ona nije realna, ali pri proracunima mora da se uzme u obzir. Za te svrhe koristimo Z-buffer. Memorija i kolicina podataka za obradu je, za razliku od 2d grafike, odredjena Horizontalna x vertikalna x Z-buffer rezolucija. Z buffer nam govori gde se odredjeni pixel nalazi u prostoru, tj. kako ce eventualno biti zamaskiran ilim maskirati ostale objekte u sceni. On nam pomaze da vizuelno predstavimo dubinu.
Z buffer ima svoje limite u rezoluciji koji uticu na preciznost scene i preklapanja objekata.
Go to the top of the page
 
+Quote Post
Angel_of_Dark
poruka Mar 11 2005, 00:32
Poruka #11




Grupa: VIP
Poruke: 1,463
Datum reg.: 28-January 05
Lokacija: Milano
Član broj: 162



3d kartice imaju preciznost Z-buffera od 16, 24 ili 32 bita. Najveca moguca preciznost je od 32 bita, sto iako se moze ciniti dovoljno, zapravo nije nikako i predstavlja veliki problem pri kalkulaciji.
Sigurno ste videli u igricama da dva fejsa koju su paralelni i potavljeni blizu jednostavno trepere, tj. probijaju jedan preko drugog proizvodeci iritirajuci efekat. Razlog je nepreciznost Z-buffera.

Vrednost z buffera = (1<<N) * ( a + b / z )


N = Broj bita preciznosti Z-buffera
a = zFar / ( zFar - zNear )
b = zFar * zNear / ( zNear - zFar )
z = rastojanje izmedju tacke gledanja i objekta

Iz ove jednacine mozemo videti da je preciznost jednaka po citavoj Zposi, tj. da je nepravilno rasporedjena. Objekti koji su vise udaljeni maju manju preciznost od objekata koji su jako blizu kameri.
U pravljenju jedne ovekve scene bitno je limitirati raspon z-bufera, tj, radi se o takozvanom Z-clippingu. Svi objekti koji su jako blizu kameri se ne uzimaju u obzir tj. bivaju iskljuceni iz renderinga. Takodje, svi objekti koji se nalaze iza odredjene udaljenosti bivaju iskljuceni iz renderinga. Ovo ne predstavlja problem pri renderovanju enterijera, ali pri renderovanju ekterijera moze biti bolno jer objekti u daljini ne mogu biti renderovani. To takodje znaci da nas svet mora imati limite, tj. ne moze se prostirati u beskonacnost.

Evo jednog primera nepravilno definisanaog Z-clippinga koji sa Z-bufferom od 16 bita pravi probleme u vidu loseg odredjivanja dubine (z-order) dok ovaj problem nije vidan kod 32 bitnog Z-buffera.

Go to the top of the page
 
+Quote Post
Angel_of_Dark
poruka Mar 16 2005, 22:47
Poruka #12




Grupa: VIP
Poruke: 1,463
Datum reg.: 28-January 05
Lokacija: Milano
Član broj: 162



Videli smo kako postoji nepreciznost u samom prikazu 3d geometrije. Ali, problem oko preciznosti nije samo u prikazu vec se ispoljava i na drugim poljima game designa.
Sve matematicke funkcije i kalkulacije transformacija se obicno izvrsavaju pomocu Float vrednosti. Ali, sta je zapravo Float vrednost?
Float vrednosti su takozvani 'brojevi sa pokretnim zarezom'. Precizno objasnjenje toga sta je Floating Point vrednost je dosta slozeno, te cu pokusati da uprostim i banalizujem stvar u svrhu toga da se lakse razume problem.
U normalnoj matematici mozemo imati brojeve svih mogucih vrednosti i broja cifara. Kod kompjutera, radi lakseg i brzeg racunanja te vrednosti moramo limitirati. To limitiranje se obavlja tako sto se za svaki broj odredi maksimalni broj decimala. Tako da mozemo imati brojeve kao recimo:
1.001
10.01,
100.1
1 001
ako broj decimala limitiramo na 4 (ovde zbog prikaza i jednostavnosti limitiramo na 4, iako se u stvarnosti moze limitirati na mnogo vise). Prakticno mozemo videti kako se samo zarez pomera,i preciznost broja se automatski smanjuje. Ako bi recimo prvom broju dodali zadnji broj iz niza: 1.001 + 1001 rezultat ne bi bio 1002.001 vec, posto je nemoguce opisati takav decimalni broj, rezultat bi bio zaokruzen na 1002. Ovo pri raznim transformacijama kod programiranja moze dovesti do jako velikih gresaka, od gresaka u motoru fizika, kalkulacija transformacija, do atrifakta u primeni vertex i pixel shadera i u najtezim slucajevima do teskih bugova.
Zbog ovoga je jako bitno pametno odrediti velicinu objekata i citavih svetova u igrici.
Go to the top of the page
 
+Quote Post
Angel_of_Dark
poruka Apr 1 2005, 02:23
Poruka #13




Grupa: VIP
Poruke: 1,463
Datum reg.: 28-January 05
Lokacija: Milano
Član broj: 162



CITAT (Djomla @ Mar 31 2005, 10:04)
Angel...hteo bih da postavim pitanje...u vezi ovog poslednjeg posta u skoli...
jel poenta bila da moramo da se pridrzavamo limita koji smo zadali...npr 4 ...ili je 4 limit... ako sam malo promasio pitanje sorry.  blink.gif
*

Nije limit 4, to je bio samo kao primer sa malo decimala da bi se problem shvatio lakse. U realnosti decimale mogu biti mnogo vece i odredjuju se u bitovima float16, float24, float32. Ali ponavljam, matematika koja stoji iza ovih brojeva je dosta kompleksnija od onoga sto sam ja objasnio i izlazi izvan potreba ovog texta. Ono sto je bitno je da su racunice u unutrasnjosti enginea donekle neprecizne.
Za one koje zanima visak informacija na ovu temu predlazem da pogledaju ovaj clanak: http://babbage.cs.qc.edu/courses/cs341/IEE...references.html
Go to the top of the page
 
+Quote Post
Angel_of_Dark
poruka Apr 1 2005, 03:17
Poruka #14




Grupa: VIP
Poruke: 1,463
Datum reg.: 28-January 05
Lokacija: Milano
Član broj: 162



PlacePozabavicemo se malo osnovnim sistemima optimizacije renderinga enterijera (zatvorenih levela) i definicijama osnovnih tehnika koje se najcesce primenjuju - portali, occlusion i hierarchicall culling tehnike ( a zatim i BSP tehnikama).
U ovom slucaju cu se skoncentrisati pre svega na objekte sa velikim povrsinama (poput zidova) koji zahtevaju veliki fillrate.
Vlada opste ubedjenje da je broj poligona osnovni razlog usporavanju renderinga. To nije sasvim tacno, bar sto se tice staticne geometrije, pogotovo sa karticama novijih generacija koje lako mogu da kontrolisu render velikog broja poligona. Kao sto smo videli, sama kartica ne zna gde se neki objekat nalazi i renderuje sve sto postoji u vidnom polju. To medjutim n ikako nije potrebno.
Uzecemo za primer jedan klasican nivo igrice, gde se igrac nalazi samo u jednoj sobi, oko njega su zidovi i samo jedna otvorena vrata. Zbog cega bi engine morao da salje citav nivo na render kada se vecina tog nivoa ne vidi?
Tu na snagu nastupaju portali.

PORTALI:
Portali su jednostavni objekti- aktivatori. Kada se u vidnom polju nadje neki portal, engine zna da u tom trenutku treba da renderuje sve objekte koji se nalaze iza njega - u suprotnom slucaju za njega ne postoje objekti koji se nalaze iza... Da bi to lakse objasnio pokusacu da objasnim pojam Place-ova (mesta).

PLACE (mesto, soba):
Logicka jedinica hijerarhijske organizacije objekata.
Svaki zatvoreni nivo je moguce organizovati na ovaj nacin. Najcesce ce nas Place biti pojedinacna soba. Znaci, u engineu se odredi da svi objekti sa zidovima pripadaju jednom skupu.
Pogledajmo ovu sliku:



Ovde su sobe podeljene na place-ove. Izmedju njih se nalaze portali (obelezeni zelenim). Portali su najcesce jednostavni meshevi koji okupiraju prostor otvora koji povezuje dva logicka mesta - vrata, prozora.
U ovom slucaju ako se nalazimo u PLACE1 bice moguce videti portal 1 i portal 2, ali treci portal koji povezuje PLACE3 i PLACE4 nije moguce videti te ce u tom slucaju citava geometrija i aktivni skriptovi koja pripada PLACE4 biti iskljucena iz renderinga.

To be continued...
Go to the top of the page
 
+Quote Post
Angel_of_Dark
poruka Apr 18 2005, 17:18
Poruka #15




Grupa: VIP
Poruke: 1,463
Datum reg.: 28-January 05
Lokacija: Milano
Član broj: 162



Izvinjavam se sto se u poslednje vreme nisam posvetio skolici, ali trenutno sam u fazi useljavanja u poslovni prostor i imam previse obaveza oko sredjivanja kompova i ostalih peripetija. Nastavice se uskoro, cim sredim one najosnovnije stvari.
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic

 



Lo-fi verzija Trenutno vreme: Monday 22. July 2019 - 02:24

Sve informacije (poruke, teme i sl.) predstavljaju stavove samo njihovih autora.
Objavljivanje informacija sa sajta u nekomercijalne svrhe moguće je samo uz navođenje URL adrese diskusije.
Za sve druge vidove distribucije potrebno je imati izričitu dozvolu administratora Dizajn Zone i/ili autora poruka.
Autorska prava za sadržaj poruke zadržava njihov autor, osim ako nije drugačije naznačeno.

powered by:Plus hosting