VeÂľkĂ˝ sprievodca enginom HalfLifu - II. èasÂť Jackar [03.07.2004 : 12:50:03] 129 Tutoriál Čítaní : 6193 Priemerná známka : 1.22

Po dlhšom èase je tu ïa¾ší megalomanský èlánok. Tentokrát sa budeme hlbšie zaobera kompiláciou prvých 3 toolov. Ich funkcie sme si už prebrali v prvom dieli, tak ich už len zhrnieme a doplníme, èo ešte nebolo povedané. Prejedeme si postupne prvé tri programy (hlcsg, hlbsp, hlvis), ich nastavenia, výsledky a triky na rýchlejšie kompilovanie. Najprv by som ale chcel doporuèi všetkým èo ešte neèítali prvú èas, nech si ju najprv preštudujú, pretože sa na òu budem èasto odvoláva, pretože som tam už viaceré veci naplno vysvetlil (napr. Vis)... Tak, pustime sa do toho ! HLCSG Popis Tak najprv by som sa chcel hlboko ospravedlni za chybu, ktorú som napísal v 1. èasti. HLCSG nie je nástroj, ktorý konvertuje planárny formát na vektorový. To robí HLBSP (viz. nižšie...). Takže sa ešte raz hlboko ospravedlòujem za tento "dos brutálny omyl" o Takže èo vlastne ten HLCSG robí ? Zjednodušuje zložitý .rmf planárny formát na jednoduchý .map planárny formát. Hammer si do rmfka zapisuje všetky bloky a entity pod¾a poradia ako sme ich vytvárali, má tam aj údaje o groupoch, VisGroupoch atï atï... ¼udovo povedané "má v tom bordel" . HLCSG tieto informácie zoberie, vytriedi a usporiada ich pekne zaradom. .rmf formát má odlišné aj viaceré údaje kvôli zrýchleniu práce, napr. informácie o polohe textúry, roviny má uzavreté vertexami (èiže ko¾ko rohov má rovina, to¾ko má vertexov) a ešte mnoho iných odlišností ktoré ani nie sú moc známe (viz. poznámka)... *pozn. Možno si hovoríte, že preèo Hammer nepracuje rovno s jednoduchým formátom. Ide o rýchlos. Ak sú objekty uložené v poradí ako boli vytvorené, nie je problém aplikova krok UNDO. Nezaberá sa tak tým skoro žiadne miesto v pamäti. Ak by mal rovinu definovanú len 3 koordinátmi, musel by po každej operácii (vytvorenie nového bloku, premiestnenie starého bloku...) nanovo prepoèítava všetky bloky, pretože nemá dané ktorá rovina môže ovplivni druhú. Ak má ale roviny definované defacto vertexami, èiže aj samostatnými objektami, tak mu staèí prepoèítava len upravené objekty. A pritom je taký systém oznaèovania omnoho rýchlejsí na výpoèet... Takže Hammer používa vpodstate akýsi "pseudo-planárny" formát , ani nie vektorový, ani nie planárny... Csg ïalej zaokrúh¾uje koordináty s desatinou èiarkou. Engine nedokáže pracova s WorldMatrix (herný svet pre architektúru, WolrdBrushe) na úrovni desatiných èísel, preto už csg zaokrúhli všetky desatiné korodináty na celé èísla. Koordináty textúr a modelov sú síce long integer, ale to nechajme tak, veï na nieèom sa šetri nemuselo, že ;)... Preto keï dostane HLCSG pri triedení objektu desatiné èíslo, tak ho proste zaokrúhli na najbližšiu hodnotu. Vtedy môžu vzniknú tri prípady: Objekt je úplne v poriadku, lebo všetky jeho vertexy boli posunuté o rovnakú hodnotu, vpodstate sa blok "narovnal". Druhý prípad je ten, že posunie rohové vertexy, a objekt bude vyzera zdeformovane. A tretia najhoršia alternatíva je, že rozdelí jeden vertex na dva vertexy, takže hrana polygónu sa rozdvojí a vznikne medzera. A HLBSP to bud zoberie a potom budeme ma v mapke nepekné praskliny (niekedy aj cez celý level) alebo èo je pravdepodobnejšie, error... Csg kompiluje tzv. Hulls, èo sú vlastne sústavy rovín. 1 World Hull ktorý tvorí herný svet (roviny objektov) a 3 Clipping Hulls, prièom každý Clipping Hull obsahuje roviny iba v jednom smere, takže máme 1 Horizontálny X, 1 Horizontálny Y a 1 Vertikálny Z Cliping Hull. Clipping Hulls urèujú priechodnos objektov, teda zaruèujú že neprejdeme cez stenu a neprepadneme sa cez podlahu. V kratkosti povedané, CSG robí akúsi "kancelársku" robotu, triedi a zjednodušuje dáta aby sa s nimi v budúcnosti ¾ahšie pracovalo. Takto vyzerá definícia jedného objektu v planárnom formáte .map: { ( 8 -240 320 ) ( 56 -240 320 ) ( 56 -240 352 ) C1A1_FLR2B [ 1 0 0 0 ] [ 0 0 -1 0 ] 0 1 1 - rovina 1 ( 8 -328 352 ) ( 8 -240 352 ) ( 56 -240 352 ) C1A1_FLR2B [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1 - rovina 2 ( 56 -240 320 ) ( 8 -240 320 ) ( 8 -328 320 ) C1A1_FLR2B [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1 - ... ( 8 -328 320 ) ( 8 -240 320 ) ( 8 -240 352 ) C1A1_FLR2B [ 0 1 0 0 ] [ 0 0 -1 0 ] 0 1 1 ( 56 -240 352 ) ( 56 -240 320 ) ( 56 -328 320 ) FIFTIES_WALL12 [ 0 1 0 0 ] [ 0 0 -1 0 ] 0 1 1 ( 56 -328 320 ) ( 8 -328 320 ) ( 8 -328 352 ) C1A1_FLR2B [ 1 0 0 0 ] [ 0 0 -1 0 ] 0 1 1 } ( koordinátX koordinátY koordinátZ) ( ... ) ( ... ) ( vertex1 ) ( vertex2 ) ( vertex3 ) TEXTÚRA [ pozícia textúry v osi X ] [ pozícia textúry v osi Y ] ve¾kos textúry Všimnite si že roviny sú definované vertexami. Vpodstate to nie sú plnohodnotné vertexy, sú to iba koordináty, ale zápis vyzerá úplne ako zápis 6 polygónov... btw: Kto spraví mapu v notepade, je guru ! Parametre pre HLCSG Najprv by bolo vhodné si ozrejmi, kde sa tie nastavenia vôbec nastavujú, že ... Tak vedzte že je to pod tlaèítkom expert a po stisnutí sa vám otvorí táto tabu¾ka: klikni pre zväèšenie Nastavenia sa píšu do políèka Parametres cez pomlèku (viz. obrázok). Všestky tieto nastavenia nájdete v dokumente ktorý je v Zoner HalfLife Compile Tools> Ja som to vpodstate preložil a vysvetlil zrozumite¾nejšie (možno ). -wadinclude - príkaz, ktorý použité textúry s uvedených .wad súborov skompiluje do mapy. Za príkazom sa uvedie buï názov .wad, alebo cesta ku viacerým .wad súborom, relatívna od Hammera. Tým pádom nemusí hráè stahova .wad spolu s mapou. Taktiež sa takto zapúzdrené textúry ažšie použijú/zneužijú vo vlastnej mape (treba na to jeden nástroj, ktorý je síce free, ale nie každý ho má ;) ). Príklad: vytvoríte si v Hammeri adresár textury a tam dáte všetky neoriginálne .wad súbory ktoré budete používa. Môžu tam by aj všetky custom textúry ktoré používate, lebo HLCSG zapúzdri do .map iba tie textúry, ktoré sa použili v mape. Potom bude príkaz vyzera nasledovne: - wadinclude hammer/textury. -noclip - vynechá kompiláciu 3 Clipping hulls (viz popis HLCSG). Po vypnutí bude celý svet priechodný, teda sa hneï prepadneme cez podlahu... -onlyents - updatuje skompilovaný .bsp súbor informáciami o entitách. Ak robíme posledné zmeny v leveli a meníme už len osvetlenie, alebo setupy zložitých entity procesov (napríklad nejaký komplikovaný výah), atp. tak staèí skompilova iba entity. Nesmie sa ale niè robi s architektúrou levelu a to platí aj pre entity, tzn. nesmú sa meni textúry, pridáva nové bloky, maza staré bloky, meni rozmery. PointBased entity ako svetlá, zvuky multimanagery sa meni/maza/vytvára/... môžu. -noskyclip - vynechá sky brushe s Clipping Hull. Pri kompilovaní berie HLCSG Sky brushe ako normálne objekty, preto ich nastaví ako nepriechodné. Po vypnutí ale berie sky ako func_illusionary takže aj VIS dostane kapky... -tiny # - vymaže s mapy bloky ktoré sú tenšie ako # unitov. Používa sa hlavne pri eliminácii "vadných" objektov vzniknutých manipuláciou vertexov. Môže ale spôsobi aj ve¾ké problémy, hlavne LeafPortalError, èiže problémy s VIS -brushunion # - generuje varovania pri pretínajúcich sa brushoch (BrushOverlapping). Dobrá pomôcka pri eliminovaní pretínajúcich sa brushov. Pri pretínaní sa na # % a viac vypíše varovnú hlášku s èíslami pretínajúcich sa brushov. Vhodné hlavne pre zaèínajúcich mapperov, ktorí "radi" vytvárajú brushe cez seba skrz naskrz . Brush Overlap je nežiadúci kvôli znižovaniu výkonu HLBSP a hlavne HLVIS. Taktiež môže spôsobi rôzne visuálne artefakty v leveli (klasické preblikávanie dvoch textúr) Príklad: Máme blok s èislom 25 a blok s èíslom 56. obidve majú 256 unitov a pretínajú sa na 64 unitov, èo je 25% s celkovej dåžky kvádru. Zadáme -brushunion 20 a vypíše nám "Warning: Entity 0, Brush 26: is overlapping Entity 0, Brush 56 @ [koordináty X Y Z]". -hullifle - pri kompilácii sa použije vlastný HullFile. Toto sa používa hlavne pri vlastných modoch, ktoré upravujú štandartné ve¾kosti v HalfLife. Napríklad HalfLife Rally používa vlastný 2x zmenšený Hullfile aj všetky modely sú dvakrát zmenšené, takže si teoreticky zväèšili +-4096 unitov na mapu dvojnásobne na +-8192 èo je cca 16000 unitov na dåžku. Samozrejme že ale treba upravi aj fyziku a podobné veci, lebo ináè by všetko padalo a pohybovalo sa 2x rýchlejšie. HLBSP Popis Je to program, ktorý spracuje planárny formát .map do vektorového polygonového formátu .bsp, s ktorým vie pracova HLVIS a HLRAD. Planárny formát definuje objekty ako prieniky rovín, takže krabicu pozná ako 6 rovín umiestnených pod¾a urèitých pravidiel. Vektorový formát definuje objekty v polygónovej sieti. Každý polygón je tvorený 3 vertexmi. Polygónová sie je sústava polygónov, ktoré majú spoloèné vertexy (viz obrázok). Môže by 1.)Neuzavretá - môže definova iba rovinný objekt, napr. sprite alebo decal, vodnú hladinu, a 2.)Uzavretá - definuje 3d objekt, napr. kocka, ihlan, gu¾a... Celý systém si môžeme predstavi ako alobal ktorý je zlepený. Ak obklopouje nejaký objekt (desiatu naprílad ) tak má jeho tvar. Ak ho však roztrhneme a odbalíme, môžeme alobal rozložit na stôl a máme rovinu. V uzavretej sieti nesmie by žiaden vertex samostatný (roh alobalu...) Keï už vieme èo je to polygónová sie, tak si teraz skúste predstavi že by ste mali prepísa rovinný formát do vektorového. Aj lepší matematik by prišiel o rozum pri našich leveloch :p. Preto má HLBSP ažkú úlohu a oèas "pochybí". Väèšinou ide o problémy so súdržnosou polygónovej siete, väèšinou po manipulácii s vertexami, prípadne LEAK, èi iné potešujúce errory... HLBSP taktiež generuje VIS-leafy, ktoré slúžia VIS-u na urèovanie PVS (vidite¾nosti). Ak ste èítali prvú èas pozorne, tento odstavec môžete k¾udne preskoèi, je to vlastne iba zhrnutie. Pri kompilovaní rozdelí hlbsp level na Vis-Leafy ktoré si môžeme predstavi ako sektory na mape. Používa ich hlvis na urèovanie vidite¾nosti. Rozdelí ich buï pod¾a architektúry (prechody z chodby do miestnosti apod) alebo ich rozmiestni pravidelne po mriežke. Problém však je, že hranice medzi týmito Leafmi musia by polygónové, èiže keï sa stretávajú dve Vis-leafy uprostred miestnosti, na mieste kde ich roviny pretínajú miestnos, sa face rozdelí. Vpodstate nám to miestnos akoby "prepáli laserom" skrz naskrz. Takéto umiestòovanie je niekedy nežiadúce, lebo môže r_speeds aj zvýši. Preto sa VisLeafy vytvárajú ruène pomocou HINT blokov (bloky s texturou HINT a NULL), ktorými si môžeme nadefinova vlastné Vis-Leafy. Tutoriál èoskoro ;). Parametre pre HLBSP -leakonly - spustí kompiláciu bsp iba kvôli zisteniu èi mapa nemá LEAK (viz. errory) -subdivide # - rozdelí celý herný svet po # unitov. Kvôli umelým limitáciam enginu rozde¾uje HLBSP celý herný svet deafultne na 240 unitove stvorce. Doslova ho "nareže". Ak máme nejakú stenu ktorá má viac ako 240 unitov a nebola by nijako rozdelená pri poh¾ade cez gl_wireframe 1, tak ju BSP rozdelí po 240 unitov, takže nám vzniknú zbytoèné face-y, èo je plýtvanie polygónmi a síce r_speeds. Je to kvôli starším grafickým kartám a Softwarovom móde, lebo staršie grafiky nedokázali spracova textúru väèšiu ako 256 pixelov. A keï máme textúru natiahnutú na 512 unitovom bloku, má 512 pixelov, takže by ju karta nedokázala vyrenderova. Je to síce zaujímavé, že bežne sú textúry 256 pixelov ale subdivide je 240, ale je to jedna s mnoha nezodpovedaných otázok vývojárov HalfLifu. Tento príkaz ale dokáže toto obmedzenie obís až do maxímálneho èísla 512. Ale pozor ! Ak použijete upravenú hodnotu, mapa pri spustení v Softaworom mode zmrzne a je nutný tvrdý reštart !!! Na OpenGL to ide vpohode ale na DirectX to tiež obèas blbne. Takže si poriadne rozmyslite èi je to do vášho modu vhodné a ak sa už tak rozhodnete, tak urèite informujte hráèov o nutnosti hra v OpenGL ! Príklad: Keïže používame textúry ve¾kosti 256 pixelov, tak nastavíme -subdivide 256 a tým pádom sa nám budú textúry teoreticky "zarezáva" správne. Softwarový mod nefunguje, ale èo už -maxnodesize # - nastaví maximálnu ve¾kos VIS-Leafov, ktoré HLBSP generuje. Ako sme si povedali, hlbsp rozdelí level viacmenej pravidelne na Vis-Leafy. Rozde¾uje ich buï pod¾a architektonických rozdielov (prechod z haly na chodbu) alebo pod¾a urèitej hodnoty do mriežky. A tento príkaz dokáže nastaví najväèšiu hodnotu vzdialenotí tejto mriežky (aká najväèšia vzdialenos môže by medzi stenami VisLeafu). Pri ve¾mi vysokých èíslach bude VisLeafing nevyhovujúci (príliš ve¾ké VisLeafy) a engine bude vidie prive¾a, pri ve¾mi nízkych èíslach "rozfranforcuje" level na kopu face-ov (príliš malé VisLeafy), takže engine bude ma krásny PVS, ale èo z toho keï budú r_speeds ešte väèšie, že . Odporúèam nastavi na 512 alebo 256 spolu s príkazom subdivide, èím nám vznikne teoretická krásna harmónia... Príklad: Ale my sme nejaký lepší mapperi, preto si vytvoríme vlastné Vis-Leafy pomocou HINT blokov (tutorial hneï po tomto èlánku ), ktoré rozmiestnime inteligentne. Keïže ale hlbsp kašle na naše rozdelenie -> ak spravím väèšiu medzeru ako on uzná za vhodné, prereže mi to. Tak si nastavíme -maxnodesize 512 a bude spokojný, lebo, to myslím, musí staèi každému ;) -notjunc - nebude rozde¾ova polygónovú sie pri T-spojoch blokov. Ak sa dotýka menší blok väèšieho, ten menši ho rozdelí (viz. prvá èas). Tento príkaz zabráni takémuto chovaniu, urobí pre obidve bloky samostatné polygónové siete a nadefinuje ich ako jednu. Super vec poviete si, ale taký optimista by som zase nebol . Keïže nemáme celistvú polygónovú sie, HLRAD nám prepoèíta nesprávne osvetlenie, takže sa môže sta že tieò ten menší blok nebude vôbec vrha, prípadne bude úplne ináè nasvetlený ako má by. Takže pre finálne kompilácie niè príjemné. Ïalej to dos zaažuje HLVIS, takže o nejakom zoptimilizovaní rýchlosti sa nedá hovori. Použiva sa hlavne pri kontrolovaní urèitého úseku cez Cordon tool (bližšie info pri LEAK errore), kde sa rozhodujeme èi svetlá spravi func_wall, èi ich necha tak (keïže to vlastne simuluje upravenie všektých takých blokov na entitu bez tieòa). -noclip - ak ste zadali tento príkaz pri Csg, tak je nutné zada ho aj tu, aby nevznikly errory. -nofill - skompiluje mapu bez vytvorenia Void priestoru (viz. errory/leak). Tento príkaz odstráni Void a berie celý herný svet (kocka 8192x8192x8192) ako vnútorný hrací svet. Je to ve¾mi nevhodné, lebo VIS nedokáže správne urèi vidite¾nos v rámci levelu a RAD poèíta osvetlenie aj "vonku", takže kompilácia Vis-u a svetla trvá ve¾mi dlho. Erory pri HLBSP LEAK - Ve¾mi známy problém, hlavne pre zaèínajúcich mapperov. Pri správne postavenom leveli oddelí HLBSP vnútro levelu od vonkajšku. Môžeme si to predstavi ako vodotesnú krabièku ponorenú do vody. V krabièke je vo¾ný priestor - náš level kde sa pohybujeme a voda je Void - priestor kde niè nie je, kde sa nemôžeme dosta. Ak ale máme v leveli dieru (diera v krabièke), HLBSP nevie ako oddeli vonkajší priestor od vnútorného (krabièka sa naplnila vodou...), preto ich nerozde¾uje, vypíše LEAK a nerozdelí level na Vis-Leafy (èiže VIS ani BounceLightning nepôjde). Príklad: === LEAK in hull 0 === === LEAK in hull 1 === === LEAK in hull 2 === === LEAK in hull 3 === Náprava: Možností je nieko¾ko. 1.) Základné je pozrie si celý level v Hammeri, èi niekde nie je vidite¾ná diera, potom si zapnite flatShaded mod v hammeri a pozrite sa èi netvorí nejaká entita koniec levelu, resp. èi nevyplòuje tu dieru. HLCSG totiž entity neberie ako normálne brushe a preto musia by entity vždy uzavreté vnútri levelu. 2.) Pri zistení Leaku vygeneruje hlbsp Pointfile subor, ktorý nám napomôže pri h¾adaní leaku v HL. Spustite HalfLife (alebo mod). Dajte si konzolu a zadávajte príkazy: particles 50000 potom nahrajte vašu mapu map xxx a keï už sme v mape, zadajte pointfile. Mali vy ste teraz vidie takú bodkovanú èiaru ktorá ide cez celý level ako sa jej zachce. Entita ktorú vám tool udal pri errore je pomôcka, ktorá ukazuje kde zaèína táto èiara. Zadajte si noclip a zaènite ju sledova (tú bodkovanú èiaru). Tam kde konèí/opúša level je LEAK. Niekedy je nutné ju sledova dos dlho aby sme vôbec zistili kde je koniec ... 3.) Takto sa to NEM� robi!!! Nikdy, opakujem nikdy neopravujte leak tak, že okolo celého levelu postavíte ve¾kú krabicu (ani oblohu cez Sky)! Kompilaèné èasy sa môžu predåži až trikrát a máte ve¾kú pravdepodobnos že sa vám vytvorí nejaký iný error. O zvýšení r_speeds ani nehovorím... Toto pravidlo platí aj pre normálne mappovanie, keï robíte zložitejší level s exteriérom ale nie je ešte dokonèený a tak dáte okolo celého levelu skybox. Nerobte to. Radšej si dajte tú námahu a zatunelujte všetky otvory skyBrushom, ale zase to nepreháòajte... 4.) Je tu ešte jedná metóda. V hammeri je taká vecièka èo sa volá Cordon tool. Je to nástroj ktorý nám umožòuje skompilova iba urèitú èas levelu. Nájdete ho v hornej lište nástrojov, je to 6,7 zprava (viz. obrázok). Oznaète si ním urèitú èas levelu a pri kompilácii sa vám bude kompilova iba táto èas. Takže zaènite kompilova najprv jednu èas levelu bez VIS a RAD, s HLBSP parametrom -leakonly. Ak je v danej oblasti leak, zase si ju rozde¾te na polovicu a zase skúška. Ak to v danej polovièke nie je, je to v druhej (logicky...). Tak rovno zaèneme preh¾adáva tú druhú polovièku atï. Až po èase dostanete oblas do 512x512 unitov, skompilujte ju normálne s HLCSG a HLBSP. Potom zaènite h¾ada Leak druhou metódou (pointfile). Táto metóda je síce zdåhavá, ale je na 150% úèinná. Ponz: Dúfam že ste nezabudli že pri kompilovaní urèitého úseku tam treba premiestni aspoò jeden info_player_start... Plane with no normal - chyba spôsobená vertex manipulation (VM). Každá rovina (plane) v mape je definovaná troma bodmi. Ak majú akéko¾vek 2 body rovnakú polohu, ide o úseèku, èiže vygeneruje sa tento error. Vznikne buï pri zaokrúh¾ovaní HLCSG alebo pri chybnom kroku s vertexmi. Príklad: Entity 0, Brush 10, side 4: plane with no normal Entity 15, Brush 0, side 2: plane with no normal Náprava: Smaza celý objekt a prerobi ho nanovo, prípadne zväèši rozostupy medzi vertexami. Brush with coplanar faces - Ïa¾šia chyba spôsobená VM. Na jednej rovine objektu nemôžu leža 2 face-y. Príklad: Entity 0, Brush 15, side 5: has a coplanar face at (-586, -9, 356), texture c1a1_fiftwall2 Entity 13, Brush 0, side 1: has a coplanar face at (246, 98, -64), texture c1a1_fiftwall2 Náprava: Chyba nastane ak sa pokúsime spravi napríklad s 5 steného objektu 4 stenný (viz obrázok zo ZHLT). Opravíme to jednoducho tak, že stredný vertex posunieme úplne na okraj ku druhému a na otázku "Merge verticles ?" dáme "Yes". Brush outside wolrd - Objekt mimo svet. Ak sa dostane nejaký objekt alebo iba jeho èas mimo hraníc levelu (+- 4096 un) tak nastane tento error. �asto ho však vída, ak je nejaký brush poškodený od VM a jeden s jeho vertexov "odišiel na prechádzku" ... Ak je jeden s koordinátov 9000 tak brush je poškodený a musí by zrobený nanovo. Príklad: Entity 0, Brush 56: outside wolrd(4096): (-9000,59,98)-(9000,64,12) Náprava: Väèšinou treba spravi celý objekt nanovo, ale niekedy to sú iba zle posunuté brushe. Žiaden brush by nemal by do 64 unitov od okraja mapy. Taktiež príliš dlhé brushe to môžu obèas spôsobi, skúste ich nareza na menšie kúsky. Mixed face contents - Tento error nastane v prípade že zmiešame viaceré typy textúr na jednom bloku. Napríklad Sky textúru s normálnou, alebo Water textúru s normálnou... Taktiež unikátne textúry typu aaatriger èi origin musia ma celý blok pre seba. Príklad: Entity 0, Brush 48: mixed face contents Texture STEEL_9 and WATER6 Náprava: Staèí iba pretextúrova blok na žiadanú textúru. Typy sa nesmú mieša. Textúry v rámci typu sa mieša dajú (hoci to nevyzerá moc dobre). Typy textúr sú SLIME (láva), WATER, SKY, AAATRIGGER, ORIGIN, CLIP, SOLID (klasické textúry, vrátane poloprieh¾adných). HLVIS Popis Celý èas tu spomínam Vis-Leafy, ktoré vytvorí HLBSP. Ale naèo sú ? Vis na ich základe dokáže urèi vidite¾nos jednotlivých Vis-Leafov, takže engine nemusí renderova celý level ale iba èas v ktorej sa nachádzame (Vis-Leaf). Podrobný popis bol už v prvom dieli, takže si zopakujeme základ a ide sa ïalej. "Pri výpoètoch vyšle VIS z poèítaného Leafu mnoho myslených lúèov do priestoru (pracujeme v 3D). Lúèe ktoré sa ocitnú v ïa¾šom leafe podajú informáciu o vidite¾nosti tohoto leafu a pokraèujú ïa¾ej. Ak narazia na stenu, zanikajú a podajú informáciu že zanikli. Po zaniknutí všetkých lúèov spracuje všetky podané informácie o vidite¾nosti, uloží ich a pokraèuje na ïa¾ší leaf v rade (rada sa urèuje cez BSP-Tree). Takto spracuje všetky leafy a napokon uloží Particle Visible Set (PVS) do BSP stromu." Ïa¾ší krok je vypoèítanie LightMapy ktorá sa použije pri poèítaní BounceLightningu (odrazenému svetlu). Viac si o tom poveieme neskôr pri HLRAD. To je vlastne celá práca Vis, nakoniec ešte urèí pravidlo, aby sa všetky BackFace-y nerenderovali (face-y ktoré nikdy nemôžeme vidie, napr. zadná strana krabice atï...), ale to je už zrejme záležitos enginu... Parametre pre HLVIS -fast - Rýchla kompilácia pre skúšku osvetlenia Tento príkaz povie Vis-u aby poèítal PVS ve¾mi obšírne, takže výsledky nie sú nijako ohromujúce, väèšinou to vyzerá tak akoby PVS vôbec nepoèítal. Akurát odstráni BackFacing a prepoèíta lightning mapu pre BounceLight. Takže -fast Vis slúži hlavne na skúšobnú ukážku osvetlenia v podobe akú bude ma vo finálnej verzii. HLRAD síce vypoèíta Bounce light ale nebude nijako zvl᚝ kvalitný èi presný, naozaj ide len o preview aby sme si spravili približnú predstavu o rozložení svetla. -full - Opak fast, skompiluje PVS s najpresnejším nastavením Tento parameter sa používa výhradne pri finálnych alebo beta kompiláciach. Prikáže Vis-u aby poèítal s presnejšími výpoètami, vïaka èomu sa prepoèítajú aj niektoré errory, ktoré bránili VIS-u v kompilácii. Proces sa spomalí asi o 30%. R_speeds sa moc nezmenia, maximálne v desiatkach wpoly. Ide totiž len a len o potlaèenie situácií, kde klasické výpoèty nedokážu urèi správne hodnoty a preto vypíšu error. Erory pri HLVIS Leaf portal saw into leaf - jeden z mála errorov Vis-u. Ide o problém keï VIS nevie urèi správnu vidite¾nos leafu. Nastáva väèšinou pri hrbo¾atých podlahách a nerovných nepravidelných stenách, napríklad kaòon, údolie, ale aj kruhové námestie s fontánou... Na odstránenie väèšinou pomôže skompilova HLVIS s parametrom -full, prípadne upravi prostredie tak aby bolo viac "kockaté" a pravidelné (malo menej výstupkov a stien). Závereèná... Koneène ste sa prelúskali na koniec a ako predpokladám, tak netrpezlivo èakáte na tretiu finálnu èas, kde si rozoberieme celý HLRAD a všetky tipy na rýchlejšie kompilovanie a menšie r_speeds. Taktiež si v òom povieme ako si spravi vlastné rozdelenie levelu do Vis-Leafov pomocou HINT blokov. V tomto èlánku by ste sa mali dozvedie všetky kompilaèné parametre, bližšie informácie o kompilaèných nástrojoch a ich najèastejšie errory. Dúfam že sa vám èlánok páèil a že využijete svoje novonabudnuté znalosti èo najskôr. Mappovaniu zdar želá: JACKAR p.s.: Všetky parametre a errory platia pre kompilaèné nástroje Zoner HalfLife Compile Tools ( ZHLT ) verzie 2.5.3

BODOVANIE ČLÁNKU Boduje sa ako v škole (1- výborný, 5-zlý)         Priemerná známka : 1.22 Hlasovalo : 18

KOMENTÁRE KU ČLÁNKU Počet komentárov ku článku : 18 1. Jackar [07.07.2004-21:22] 304 Kua ludia, to nemate co povedat ??? Ako mam tvorit bez spatnej odozvy 2. Choosen [30.07.2004-11:50] 334 DobrĂ˝ èlánek. Mám pár otázek: HULLS:1)pokud vložím do mapy novĂ˝ objekt, tak zøejmì bude muset CSG znova pøepoèítat HULLS a poslat dál koordináty,Ĺľe? 2) Zpracovává hulls jen pevnĂ© objekty (neprĂąchodnĂ©) nebo i ty prĂąchodnĂ© (func ilusionary atd... - ovšem nemám na mysli sprity, svìtla atd ... ) kompilaènĂ­ pøíkazy: Kua, to sou good vìcièky hned musĂ­m nìjakĂ© prubnout (hlavnì wadinclude ) a pak zkusĂ­m v mapì udìlat nìjakou dĂ­ru a podle toho návodu ji eliminovat ... Nepochpil jsem akorát proè je tam parametr noclip .... jakĂ© má praktickĂ© vyuĹľitĂ­? 3. Jackar [30.07.2004-23:41] 335 Konecne sa dakdo pyta . Takze, Hulls su 4. 3 Spracuvaju objekty, teda VSETKO (newim ako je to ale s func_pushable... ?). Posledny clipping hull spracuva iba nepriechodne objekty. Takze func_illusionary sa nepocita... Ale ted newim presne, ze ci nahodou tie 3 clipping hulls nesu osi, ale 1 na world objekty, 1 na entity a 1 na modely...hmmm Kompilacne si poskusaj, ale s -wadinclude som mal v poslednej dobe dake problemy, kua furt pise ze .wad neexistuje... hmmm... A ten noclip je na to, ze si mozes poskladat sam clipping bloky, teda oclipujes si sam bloky... Ale pouziva sa to hlavne pri eliminacii problemov pri kompilacii (metoda postupne povypinam co sa da...) DAlsie otazky, anyone 4. Choosen [31.07.2004-08:33] 336 Jak to vypadá s RAD? Dìláš na tom? 5. Jackar [31.07.2004-12:39] 337 jj, ale nstiham Defam ze to do buduceho tyzdna stihnem... 6. thor_ [03.08.2004-20:56] 344 Najlepší èlánok na The lambda 7. Jackar [05.08.2004-20:18] 347 dik ;) 8. Kelish2 [23.10.2005-15:22] 1581 (LEAK)Hej tak som to skudil ale ale ked som dal pintfiles tak mi vypisalo could open L21.pts a ten suborik bol aj v pricinku map aj v graphs tak co tet 9. Kelish2 [23.10.2005-18:45] 1582 Uz som to zrobyl tak nic hej 10. Cheroke [24.10.2005-05:19] 1583 úžasnĂ© koneènì nìco co oslovilo i mì Ps :moĹľná bys mohl se tomuhle tĂ©matu vìnovat ještì vĂ­c a napsat knihu . ne ted vážnì moc dobrĂ©. 11. goblin [04.05.2006-07:53] 1948 neviem ci to bolo v tomto clanku alebo v sprievodca enginom hl cast 1 ale nevedel som ze prekrivanie blokov ma nejaky vplyv (na beh hry?) All I want , all I need is to see my enemy bleed! 12. Jackar [04.05.2006-20:30] 1950 Ma vplyv na kompilaciu a ciastocne aj na beh hry, kedze sa moze stat ze sa ti bloky prekryvaju aj v hre a vznika overlapping textur. A tam sa zbytocne nici fillrate kedze musi na jednu plochu mapovat zbytocne dve textury 13. Kelish2 [06.06.2006-14:41] 1965 jackar>>Konecne som si mohol precitat cely clanok a je fakt dobry.No nepochopil som par veci ale to bude asi koli tomu ze som ete necital prvu cast ete precitam.Ako velmi nevem co je to tenhint a v hameri kde je toto s hlvis to full .A tesim sa uz na tretiu cast a inac co uz na nej pracujes ci ete ne?? 14. Jackar [06.06.2006-22:19] 1966 Full VIS je to ze pocita visible strom na este vyssej urovni (vacsia presnost). To ti este viac zvysi kompilacne casy, ale zasa "malo by to" opravit poniektore VIS errory a zlepsit stavbu BSP stromu ;) 15. Kelish2 [08.06.2006-06:52] 1967 Ja som pochopil co to roby ale kde to je,je to tam ked dam F9 bo ja jak tam mam VIS je tam moznost No , Normal a Fast.. 16. Jackar [08.06.2006-12:52] 1968 To sa zadava pri Expert kompilacii, ako prikaz pre VIS ;). Rovnako ako vacsina tych prikazov co som tu popisoval. 17. Kelish2 [08.06.2006-15:46] 1969 Aha dik a tie hin bloky to co je vlastne?? 18. Kelish2 [10.06.2006-07:02] 1970 Som sa pomilil tie HINT bloky to co je vlastne??Kusa som ich nepochopil Pre pridávanie komentárov musíte byť prihlásený Pokiaľ ešte nieste zaregistrovaný, môžete tak urobiť TU