Programujeme grafický engine V.

opengl_logo.jpg Po­čnúc tou­to čas­ťou se­riá­lu za­čne­me uvád­zať po­drob­ný ko­men­tár k prog­ra­mo­vé­mu kó­du ap­li­ká­cie En­gi­ne v1.0. Tá­to vzo­ro­vá ap­li­ká­cia nám po­slú­ži na prak­tic­kú ukáž­ku jed­né­ho z množ­stva spô­so­bov, ako nap­rog­ra­mo­vať jed­no­duc­hý gra­fic­ký en­gi­ne. Za­čne­me opi­som ob­sa­hu jed­not­li­vých sú­bo­rov so zdro­jo­vým kó­dom, pri­čom sa po­drob­ne bu­de­me ve­no­vať mo­du­lom, kto­ré sú rep­re­zen­to­va­né tý­mi­to sú­bor­mi. Po­stup­ne sa bu­de­me za­obe­rať všet­ký­mi mo­dul­mi ap­li­ká­cie, kto­ré dopl­ní­me kon­krét­ny­mi ukáž­ka­mi čas­tí zdro­jo­vé­ho kó­du.

Tou­to čas­ťou se­riá­lu te­da za­čne­me po­pri teó­rii bu­do­vať vlast­ný en­gi­ne, kto­rý sa bu­de­me sna­žiť do­viesť do po­do­by hra­teľ­nej po­čí­ta­čo­vej hry. Mno­hé z mo­du­lov bu­dú pri­tom ob­sa­ho­vať čas­ti kó­du, kto­ré sme pred­sta­vi­li v pre­doš­lom se­riá­li, čo zna­me­ná, že sa bu­de­me v maximál­nej mie­re sna­žiť o vy­uži­tie na­do­bud­nu­tých po­znat­kov.

Mo­du­ly ap­li­ká­cie En­gi­ne v1.0
Ako sme uvied­li, ap­li­ká­cia En­gi­ne v1.0 bu­de vzo­ro­vá ap­li­ká­cia, po­mo­cou kto­rej si prak­tic­ky uká­že­me, ako nap­rog­ra­mo­vať jed­no­duc­hý gra­fic­ký en­gi­ne. Zdro­jo­vý kód ap­li­ká­cie En­gi­ne v1.0 bu­de­me po­stup­ne dopĺňať o tie čas­ti, kto­rým sa bu­de­me ve­no­vať vždy v ak­tuál­nej čas­ti se­riá­lu. Ne­bu­de­me te­da vy­tvá­rať sa­mos­tat­né ap­li­ká­cie, tak ako to bo­lo v pre­doš­lom se­riá­li. Na to, aby sme moh­li s ap­li­ká­ciou En­gi­ne v1.0 pl­no­hod­not­ne pra­co­vať, mu­sí­me po­drob­ne cha­rak­te­ri­zo­vať ce­lú fi­lo­zo­fiu jej tvor­by. Ne­bu­de­me sa te­da spo­lie­hať iba na ko­men­tár k zdro­jo­vé­mu kó­du, kto­rý je umies­tne­ný v jed­not­li­vých sú­bo­roch, ale via­ce­ré fun­kcie opí­še­me aj pria­mo v týc­hto člán­koch.

Ap­li­ká­cia En­gi­ne v1.0 sa skla­dá z nas­le­du­jú­cich mo­du­lov (obr. 1):
1. En­gi­ne – zá­klad­ný mo­dul, kto­rý ob­sa­hu­je hlav­nú vy­ko­ná­va­ciu fun­kciu ap­li­ká­cie main(),
2. Inter­fa­ce – je­den z naj­dô­le­ži­tej­ších mo­du­lov, kto­ré­ho úlo­hou je in­teg­ro­vať vstu­py/vý­stu­py os­tat­ných mo­du­lov do jed­né­ho cel­ku. Ten­to mo­dul by sme moh­li naz­vať aj tzv. uz­lom (angl. hub), v kto­rom sa stre­ta­jú všet­ky in­for­má­cie spra­cú­va­né v os­tat­ných mo­du­loch ap­li­ká­cie. Mo­dul Inter­fa­ce ob­sa­hu­je aj ini­cia­li­zá­ciu OpenGL a fun­kcie na zme­nu sta­vov sta­vo­vé­ho stro­ja OpenGL.
3. Ava­tar – ne­ná­pad­ný, ale je­den z naj­dô­le­ži­tej­ších mo­du­lov ap­li­ká­cie, kto­rý má na sta­ros­ti im­ple­men­tá­ciu po­hy­bu po­zo­ro­va­te­ľa (angl. ava­ta­ra). V tom­to mo­men­te nie je veľ­mi vy­uží­va­ný, no len čo za­čne­me ho­vo­riť o fy­zi­ke, de­tek­cii ko­lí­zií, na­po­dob­ňo­va­ní rôz­nych dru­hov reál­nych po­hy­bov, neus­tá­le bu­de­me ho­vo­riť prá­ve o mo­du­le Ava­tar.
4. Bac­kend – ten­to mo­dul má na sta­ros­ti na­čí­ta­nie úda­jov zo vstup­ných sú­bo­rov. V tom­to sta­ve sú to sú­bo­ry for­má­tu 3ds, ale v bu­dúc­nos­ti to mô­žu byť (resp. ur­či­te bu­dú) ďal­šie sú­bo­ry ob­sa­hu­jú­ce in­for­má­cie o stav­be scé­ny. Mo­dul Bac­kend úz­ko spo­lup­ra­cu­je s mo­du­lom Inter­fa­ce a mo­du­lom Fron­tend, kto­rý opí­še­me v nas­le­du­jú­com bo­de.
5. Fron­tend – naj­dô­le­ži­tej­ší mo­dul ap­li­ká­cie, kto­rý ob­sa­hu­je zoz­nam všet­kých ob­jek­tov (tro­ju­hol­ní­kov) scé­ny a ta­kis­to po­le tých tro­ju­hol­ní­kov, kto­ré sú ur­če­né na vý­sled­né vy­kres­le­nie na ob­ra­zov­ke. To­to po­le sa napĺňa po­mo­cou iných mo­du­lov ap­li­ká­cie, no je to je­di­né mies­to, z kto­ré­ho sa tro­ju­hol­ní­ky v po­sled­nej fá­ze spra­co­va­nia „vy­kre­slia“ na ob­ra­zov­ku po­čí­ta­ča.
6. Octtree – mo­dul, kto­rý bu­de­me pri ďal­šom vý­vo­ji ap­li­ká­cie dopĺňať mo­dul­mi rov­na­ké­ho cha­rak­te­ru. Má na sta­ros­ti us­po­ria­da­nie vstup­ných úda­jov na­čí­ta­ných v mo­du­le Bac­kend do štruk­tú­ry, kto­rá po­slú­ži naj­mä na urýc­hle­nie a op­ti­ma­li­zá­ciu spra­co­va­nia veľ­ké­ho množ­stva vstup­ných úda­jov. Octtree im­ple­men­tu­je tzv. ok­tá­no­vý strom, kto­rým us­po­ria­da­me tro­ju­hol­ní­ky, z kto­rých je zlo­že­ný te­rén, no v pr­vých fá­zach vý­vo­ja ap­li­ká­cie bu­de­me uve­de­ný typ stro­mu po­uží­vať aj na ďal­šie úče­ly. Ok­tá­no­vý strom nes­kôr dopl­ní­me o tzv. bi­nár­ny strom (BSP), ale o tom až nes­kôr.
7. Frus­tum – ďal­ší z ne­ná­pad­ných, ale nes­mier­ne dô­le­ži­tých mo­du­lov. Je­ho úlo­hou je vý­ber tých tro­ju­hol­ní­kov scé­ny, kto­ré sa v da­nom mo­men­te nac­hád­za­jú v po­hľa­de po­zo­ro­va­te­ľa. Os­tat­né tro­ju­hol­ní­ky bu­dú z ďal­šie­ho vý­poč­to­vé­ho pro­ce­su vy­lú­če­né, čím dôj­de k urýc­hle­niu spra­co­va­nia jed­not­li­vých ob­jek­tov scé­ny.
8. 3ds – jed­no­duc­hý mo­dul, kto­rý po­zná­me z pre­doš­lé­ho se­riá­lu. Na­čí­ta­va vstup­né sú­bo­ry for­má­tu 3ds a na­čí­ta­né tro­ju­hol­ní­ky umies­tňu­je pros­tred­níc­tvom mo­du­lu Bac­kend do úda­jo­vých štruk­túr mo­du­lu Fron­tend.
9. 3d­math – ďal­ší z jed­no­du­chých mo­du­lov, ob­sa­hu­je fun­kcie po­treb­né na vy­ko­ná­va­nie rôz­nych ma­te­ma­tic­kých ope­rá­cií, bu­de­me ho po­uží­vať stá­le čas­tej­šie, ale až v nes­kor­ších fá­zach vý­vo­ja en­gi­nu.
10. Textu­re – mo­dul zod­po­ved­ný za na­čí­ta­va­nie textúr (sú­bo­rov s ob­ráz­ka­mi, kto­rý­mi sú po­kry­té jed­not­li­vé ob­jek­ty scé­ny).
11. Text – mo­dul, po­mo­cou kto­ré­ho sa vy­pi­su­jú všet­ky tex­ty zob­ra­ze­né na ob­ra­zov­ke.

engine obr1.bmp
Obr. 1 Blo­ko­vý di­ag­ram jed­not­li­vých mo­du­lov ap­li­ká­cie En­gi­ne v1.0

Opis naj­dô­le­ži­tej­ších fun­kcií
Za­čne­me opi­som fun­kcií jed­no­duch­ších mo­du­lov a po­stup­ne prej­de­me k tým zlo­ži­tej­ším. Med­zi jed­no­duc­hšie mo­du­ly pa­tria Text, Textu­re, 3d­math, 3ds a Frus­tum.

Mo­dul Text (trie­da mText, sú­bo­ry com­mon/mText.cpp, com­mon/mText.h)
V mo­du­le Text doc­hád­za k spra­co­va­niu všet­ké­ho textu, kto­rý bu­de­me zob­ra­zo­vať na ob­ra­zov­ke po­čí­ta­ča, kon­krét­ne vo vy­tvo­re­nom ok­ne OpenGL. Je sa­moz­rej­mé, že množ­stvo naj­mä in­for­mač­né­ho či po­moc­né­ho textu bu­de­me vy­pi­so­vať pria­mo do kon­zo­ly Li­nuxu (angl. con­so­le, ter­mi­nal), no ta­kis­to tre­ba, aby sme po­uží­va­te­ľo­vi umož­ni­li zís­ka­vať ur­či­té in­for­má­cie aj pria­mo v ok­ne spus­te­nej ap­li­ká­cie.
Na za­čiat­ku prá­ce s textom je po­treb­né ini­cia­li­zo­vať vý­pis textu po­mo­cou nas­le­du­jú­cej fun­kcie:
int mText::t_ini­tia­li­ze(const char *FONT_FI­LE,const un­sig­ned int W, const un­sig­ned int H)

Po ini­cia­li­zá­cii textu mô­že­me zme­niť je­ho far­bu fun­kciou:
void mText::t_co­lor(GLfloat R,GLfloat G,GLfloat B,GLfloat A)

Vý­pis textu reali­zu­je­me v troch fá­zach: 1. V pr­vej fá­ze prip­ra­ví­me OpenGL do sta­vu po­treb­né­ho na vý­pis textu (mo­di­fi­ku­je­me sta­vy sta­vo­vé­ho stro­ja OpenGL):
void mText::t_start(void)

2. V dru­hej fá­ze vy­pí­še­me je­den, resp. via­ce­ro texto­vých re­ťaz­cov na ob­ra­zov­ku:
void mText::p_text(GLfloat X,GLfloat Y,const char *STRING)
void mText::p_ftext(GLfloat X,GLfloat Y,const char *FOR­MAT,...)

3. V tre­tej fá­ze vrá­ti­me OpenGL sta­vo­vý stroj do pô­vod­né­ho sta­vu tak, aby bo­lo mož­né vy­kres­ľo­vať bež­né ob­jek­ty scé­ny:
void mText::t_end(void)

Mo­dul Textu­re (trie­da mTextu­re, sú­bo­ry com­mon/mTextu­re.cpp, com­mon/mTextu­re.h)
Ako už dáv­no vie­me, textú­ra je ob­rá­zok, kto­rým sa po­krý­va ob­jekt zob­ra­ze­ný na ob­ra­zov­ke. Tie­to ob­ráz­ky ma­jú pres­ne de­fi­no­va­ný roz­mer a for­mát. Do „pros­tre­dia“ OpenGL do­ká­že­me nah­rať textú­ry via­ce­rých dru­hov (čo sa tý­ka roz­me­rov aj for­má­tov, ale aj ur­če­nia), pri­čom tie sa uk­la­da­jú do tzv. ob­jek­tov textúr (angl. textu­re ob­jects). Mo­dul Textu­re prak­tic­ky reali­zu­je čin­nos­ti spo­je­né s po­uží­va­ním textúr.

Na­čí­ta­nie rôz­nych dru­hov textúr vy­ko­ná­va­me po­mo­cou nas­le­du­jú­cich fun­kcií:

int mTextu­re::Load2DTextu­re(GLuint ID,char *F,GLuint MO­DE)
int mTextu­re::Load1DTextu­re(GLuint ID,char *F,GLuint MO­DE)
int mTextu­re::Load­Bum­pTextu­re(GLuint ID1,GLuint ID2,char *F,GLuint MO­DE)
int mTextu­re::Load­Cu­be­Map­Textu­re(char *F1,char *F2,char *F3,
                                 char *F4,char *F5,char *F6,GLuint MO­DE)
int mTextu­re::Load­De­tail­Textu­re(char *F)
int mTextu­re::Load­Cros­shair­Textu­re(char *F)

Za ru­še­nie ne­vyu­ží­va­ných textúr je „zod­po­ved­ná“ fun­kcia:

void mTextu­re::Free­Textu­re(GLuint ID) 

Mo­dul Textu­re tiež ob­sa­hu­je jed­no­duc­hú fun­kciu, ur­če­nú na vy­kres­le­nie za­me­ria­va­cie­ho krí­ža (angl. cros­shair). Ten­to ob­jekt za­tiaľ ne­bu­de­me ni­ja­ko up­ra­vo­vať, a te­da je­ho vy­kres­le­nie mô­že­me reali­zo­vať pria­mo v mo­du­le Textu­re. V bu­dúc­nos­ti sa k ob­jek­tu za­me­ria­va­cie­ho krí­ža vrá­ti­me a uká­že­me si, ako ho mož­no po­užiť na na­vo­de­nie čo naj­ver­nej­šie­ho vzhľa­du napr. pri si­mu­lá­cii ďa­le­koh­ľa­du či za­me­ria­va­nia po­hyb­li­vých ob­jek­tov.
int mTextu­re::DrawCros­shair(void)

Mo­dul 3d­math (trie­da m3d­math, sú­bo­ry com­mon/m3d­math.cpp, com­mon/m3d­math.h)
Mo­dul 3d­math spo­me­nie­me iba ok­ra­jo­vo. Na príp­ra­ve je­ho fun­kcií bu­de­me pra­co­vať prie­bež­ne. Naj­väč­ší vplyv na úp­ra­vu toh­to mo­du­lu bu­de mať im­ple­men­tá­cia de­tek­cie ko­lí­zií, pre­to­že doň bu­de tre­ba dop­ra­co­vať množ­stvo fun­kcií reali­zu­jú­cich vý­poč­ty s vek­tor­mi. V tom­to oka­mi­hu je ne­vyh­nut­né ve­dieť, že mo­dul 3d­math ob­sa­hu­je dek­la­rá­ciu trie­dy tVe­c3 a de­fi­ní­ciu jej fun­kcií. Tá­to trie­da slú­ži na prá­cu s troj­roz­mer­ným vek­to­rom, kto­rý je a bu­de zá­kla­dom tak­mer všet­kých ma­te­ma­tic­kých ope­rá­cií vy­ko­ná­va­ných v ap­li­ká­cii:
tVe­c3

Mo­dul 3ds (trie­da m3ds, sú­bo­ry com­mon/m3ds.cpp, com­mon/m3ds.h)
Ten­to mo­dul ne­mu­sí­me zvlášť ro­zo­be­rať. Trie­du m3ds ur­či­te dob­re po­zná­me z pre­doš­lé­ho se­riá­lu, v kto­rom sme ju vy­tvo­ri­li a po­uži­li na na­čí­ta­nie sú­bo­rov for­má­tu 3ds. Naj­dô­le­ži­tej­šia fun­kcia mo­du­lu je na­čí­ta­nie ob­jek­tov zo vstup­ných sú­bo­rov for­má­tu 3ds, kto­ré reali­zu­je­me nas­le­du­jú­cou fun­kciou:
int m3ds::im­p3ds(char *fna­me)

Mo­dul Frus­tum (trie­da mFrus­tum, sú­bo­ry com­mon/mFrus­tum.cpp, com­mon/mFrus­tum.h)
Jed­no­duc­ho zne­jú­ci ná­zov mo­du­lu Frus­tum vy­tvá­ra do­jem, že ide o mo­dul, kto­ré­ho fun­kcio­na­li­ta je veľ­mi ob­med­ze­ná. Opak je však prav­da. Ten­to mo­dul mož­no bez­poc­hy­by naz­vať „sr­dcom“ op­ti­ma­li­zač­né­ho pro­ce­su vý­be­ru tro­ju­hol­ní­kov, kto­ré tre­ba spra­co­vať a nás­led­ne zob­ra­ziť na ob­ra­zov­ke. Frus­tum je an­glic­ký ná­zov pre tzv. „po­hľad“, kto­rý v rám­ci OpenGL oh­ra­ni­ču­je­me po­mo­cou šies­tich ore­zá­va­cích ro­vín (angl. clip­ping pla­ne). Tie­to ro­vi­ny sú hra­ni­ca­mi pries­to­ru, kto­rý „vi­dí“ po­zo­ro­va­teľ. Je­di­ne ob­jek­ty nac­hád­za­jú­ce sa v tom­to pries­to­re bu­dú vi­di­teľ­né na ob­ra­zov­ke a je­di­ne tie­to ob­jek­ty tre­ba spra­cú­vať. Všet­ky os­tat­né ob­jek­ty sú pre po­zo­ro­va­te­ľa ne­vi­di­teľ­né, a te­da nie je dô­vod na ich spra­co­va­nie.

Zá­kla­dom hod­no­tia­cich vý­poč­tov je fun­kcia ak­tua­li­zu­jú­ca rov­ni­ce šies­tich ore­zá­va­cích ro­vín:
void mFrus­tum::Frus­tu­mUp­da­te(void)

Z mno­hých fun­kcií na­chád­za­jú­cich sa v mo­du­le Frus­tum je v tom­to oka­mi­hu naj­dô­le­ži­tej­šia nas­le­du­jú­ca fun­kcia:

bool mFrus­tum::Cu­beIn­Frus­tum2(GLfloat X1,GLfloat X2,
                              GLfloat Y1,GLfloat Y2,
                              GLfloat Z1,GLfloat Z2)

Uve­de­ná fun­kcia vy­be­rá tie ob­jek­ty (ap­roximo­va­né koc­ka­mi), kto­ré sa as­poň čias­toč­ne nac­hád­za­jú v po­hľa­de po­zo­ro­va­te­ľa, a je­di­ne tie­to ob­jek­ty „po­sú­va“ na ďal­šie spra­co­va­nie.

Zhr­nu­tie
V tom­to člán­ku sme opí­sa­li časť mo­du­lov ap­li­ká­cie En­gi­ne v1.0. Uvied­li sme, akú úlo­hu ma­jú mo­du­ly Text, Textu­re, 3d­math, 3ds a Frus­tum. Po­kiaľ by nám in­for­má­cie z toh­to člán­ku ne­pos­ta­čo­va­li na pl­no­hod­not­né po­cho­pe­nie jed­not­li­vých fun­kcií či kon­krét­nych prí­ka­zov zdro­jo­vé­ho kó­du ap­li­ká­cie, nie je prob­lém po­cho­piť fun­kcio­na­li­tu spor­ných čas­tí kó­du pria­mo za po­mo­ci ko­men­tá­rov, kto­ré som sa usi­lo­val po­užiť vša­de tam, kde bo­lo tre­ba.

Tak­mer kaž­dý ria­dok zdro­jo­vé­ho kó­du som sa sna­žil po­drob­ne oko­men­to­vať. Kód som ďa­lej dopl­nil prí­kaz­mi za­čí­na­jú­ci­mi sa ko­men­tá­rom // IN­FO:. Tie­to za­ko­men­to­va­né prí­ka­zy som po­uží­val po­čas tvor­by prog­ra­mo­vé­ho kó­du ap­li­ká­cie, po­nec­hal som ich však na pô­vod­nom mies­te, a to hlav­ne z dô­vo­du ďal­ších tes­tov, resp. bliž­šie­ho oboz­ná­me­nia sa s fun­kcio­na­li­tou niek­to­rých dô­le­ži­tých blo­kov. V zdro­jo­vých sú­bo­roch sa na via­ce­rých mies­tach ta­kis­to nac­hád­za struč­ný opis úlo­hy, kto­rú pl­ní da­ný blok, čo by moh­lo pris­pieť k eš­te väč­šej in­for­mo­va­nos­ti o vý­zna­moch po­uži­tých al­go­rit­mov.

Na obr. 2 mô­že­me vi­dieť ak­tuál­ny gra­fic­ký vý­stup ap­li­ká­cie En­gi­ne v1.0. Všim­ni­me si údaj „po­cet tes­tov: 49“, kto­rý ho­vo­rí, koľ­ko tes­tov s ok­tá­no­vým stro­mom sa vy­ko­na­lo na vý­ber tro­ju­hol­ní­kov, kto­ré tre­ba spra­co­vať. Ďalej si mô­že­me všim­núť, že z cel­ko­vé­ho po­čtu 14 628 tro­ju­hol­ní­kov bo­lo spra­co­va­ných a zob­ra­ze­ných iba 3898 tro­ju­hol­ní­kov. To je po­čet tro­ju­hol­ní­kov, kto­ré preš­li tes­tom po­hľa­du s lis­ta­mi ok­tá­no­vé­ho stro­mu a nás­led­ne tes­tom po­hľa­du s kaž­dým jed­not­li­vým tro­ju­hol­ní­kom (Frus­tum Culling).

engine obr2.bmp
Obr. 2 Gra­fic­ký vý­stup ap­li­ká­cie En­gi­ne v1.0

Na­bu­dú­ce...
V bu­dú­cej čas­ti se­riá­lu bu­de­me po­kra­čo­vať v opi­se fun­kcio­na­li­ty mo­du­lov ap­li­ká­cie En­gi­ne v1.0. Za­me­ria­me sa na mo­du­ly Octtree, Fron­tend, Bac­kend, Ava­tar, Inter­fa­ce a En­gi­ne. Tým za­vŕši­me opis mo­du­lov ap­li­ká­cie a za­čne­me sa ve­no­vať jej zlep­šo­va­niu. Uve­die­me, kto­ré zá­klad­né vlas­tnos­ti gra­fic­kých en­gi­nov sme do­po­siaľ im­ple­men­to­va­li a kto­ré bu­de­me mu­sieť im­ple­men­to­vať v nas­le­du­jú­cich ver­ziách.

Ďal­šie čas­ti >>

Zdroj: Infoware 3/2008



Ohodnoťte článok:
   
 

24 hodín

týždeň

mesiac

Najnovšie články

Prog­ra­mu­je­me gra­fic­ký en­gi­ne XXXVII.
V tejto a takisto v nasledujúcej časti seriálu budeme riešiť synchronizáciu streľby s pohybom postavy. Pôvodne sme sa tejto oblasti venovali oddelene od blokov súvisiacich so zobrazením postavy. čítať »
 
Prog­ra­mu­je­me gra­fic­ký en­gi­ne XXXVI.
V tejto časti seriálu sa budeme venovať tomu, ako možno do grafických (herných) enginov implementovať objekty reprezentujúce rebríky (ladders). čítať »
 
Prog­ra­mu­je­me gra­fic­ký en­gi­ne XXXV.
V tejto časti seriálu podrobnejšie rozoberieme jednotlivé časti programového kódu súvisiace s implementáciou streľby. čítať »
 
Prog­ra­mu­je­me gra­fic­ký en­gi­ne XXXIV.
V tejto časti seriálu vám v stručnosti predstavíme tzv. systémy častíc (particle systems). Kvalitne navrhnutými systémami častíc dokážeme veľmi rýchlo a elegantne zvýšiť dynamiku grafických aplikácií. čítať »
 
Prog­ra­mu­je­me gra­fic­ký en­gi­ne XXXIII.
V predchádzajúcej časti seriálu sme dokončili kapitolu, v ktorej sme sa venovali simulácii fyziky. čítať »
 
Prog­ra­mu­je­me gra­fic­ký en­gi­ne XXXII.
Touto časťou seriálu ukončíme tému implementácie fyzikálnych zákonov v rámci grafických enginov. Všetky vedomosti, ktorými v tomto okamihu disponujeme čítať »
 
Prog­ra­mu­je­me gra­fic­ký en­gi­ne XXXI.
Týmto článkom sa pomaly dostávame k záveru celku, v ktorom sme sa zaoberali simuláciou fyziky. Zostáva nám opísať princíp detekcie kolízií a uviesť spôsob reakcie simulačného systému čítať »
 
Prog­ra­mu­je­me gra­fic­ký en­gi­ne XXX.
V tomto pokračovaní seriálu si doplníme teoretické vedomosti potrebné na implementáciu fyzikálnych zákonov v grafických a herných enginoch. čítať »
 
 
 
  Zdieľaj cez Facebook Zdieľaj cez Google+ Zdieľaj cez Twitter Zdieľaj cez LinkedIn Správy z RSS Správy na smartfóne Správy cez newsletter