ČLÁNKY O TVORBĚ MAP A MODIFIKACÍ DO POČÍTAČOVÝCH HER
Zde najdete přehled všech vydaných článků, které přibližují tvorbu modifikací z pohledu samotných vývojářů, jejich rady, rozhovory, reportáže, apod. Celkem je v této sekci 64 článků.Jak správně dělat mapy ve Valve Hammer Editoru
Rubrika: Half Life 1
Návod je určen pro editor Valve Hammer Editor.
Hry Half-Life, CounterStrike 1.6
Cenné rady a zkušenosti pro správnou tvorbu map ve V.H.E.
poslední aktualizace 17-6-2010
O co vlastně jde?
Rychlost mapy je závislá na počtu objektů, které engine v daný moment zobrazuje. Čím více jich musí zobrazit, tím pomalejší bude fps (frames per second čili obrázků za sekundu). Na zjištění fps existuje příkaz, který napíšete do konzole: r_speeds 1. Tento příkaz způsobí, že v horním levém rohu pojedou čísla fps a tak zjistíte jak je mapa rychlá.
Někteří jedinci sice dokáží určit fps pouhým okem, ale je nás skutečně málo.
Takže pokud je fps v některých momentech skutečně nízké (kolem 15 - 10 fps, chvílemi i méně), znamená to následující:
1. Máte obrovskou mapu a engine zobrazuje děsně velký počet
objektů.
2. Mapu máte sice obrovskou, ale správně provedenou a přesto engine zobrazuje děsně
velký počet objektů.
3. Máte pomalý počítač.
Odpovědi jsou následující.
Bodu 1 není pomoci, musí se překopat celá mapa. Viz informace níže.
Bodu 2 pomoci je, zřejmě byla provedena kompilace na fast-VIS ve Worldcraftu, nebo
počet objektů je i přes správnost mapy příliš velký.
Bodu 3 je pomoci, spraví to lepší konfigurace PC.
Konfigurace nastavení před
kompilací.
Nastavení 1: CSG-normal,
BSP-normal, VIS-no, RAD-no
Nastavení 2: CSG-normal,
BSP-normal, VIS-fast, RAD-normal
Nastavení 3: CSG-normal,
BSP-normal, VIS-normal, RAD-normal (extra)
N2: rychlá kompilace mapy, tato možnost je sice rychlá a dostačující ale pro vydání konečného BSP je nevhodná, protože nemá VIS zkompilovaný na urychlení fps. V praxi to znamená, že engine vykresluje i předměty co nejsou vidět.
N3: toto nastavení už je správné pro konečnou kompilaci mapy, engine při VIS na normal nevykresluje zbytečné objekty a mapa se poměrně zrychlí oproti N2. Nastavení RAD na extra má tuším vliv na kvalitu osvětlení, ale nejsem si jistý.
Nastavení N3 je nejvíce časově náročné na kompilaci, s pomalejším PC musíte počítat i s několika hodinami kompilace.
Poznámka: Pro zjištění vykreslování zbytečných objektů a procesorově náročných objektů je vhodný příkaz gl_wireframe 2. Když máte mapu zkompilovanou na fast VIS, bude engine vykreslovat hodně zbytečných objektů, kdežto na normal VIS bude vidět podstatné zrychlení a vykreslování jen takových objektů, které budou v nejbližší době vidět. viz poznámky níže.
Důležité poznámky ke správnému sestavování map:
1. Dodržování S koridorů.
2. Dělené podlahy a stěny po spodní úroveň podlahy.
3. Některé předměty 1bod nad podlahou a func_wall.
4. Celá mapa v duté krychli.
5. Omezení detailů u velkoprostorových map.
6. Správná formace textur.
7. Správná tvorba oblouků.
8. Fenomén info_node.
1. Dodržování S koridorů
S koridory jsou v podstatě chodby, nebo zábrany určené k urychlení mapy - k tomu
aby engine zbytečně nevykresloval objekty v dálce, které ani hráč nesleduje.
Způsobí vlastně plánovaný předěl mezi dvěma velkými prostory - které např.
samostatně běží docela hladce, ale společně měly hodně malý fps.
Obrázek S koridoru:
Obrázek 2S (omega) koridoru:
Vysvětlení pro chápavější:
Zelená přerušovaná čára odděluje plochy, které zpracovává program VIS. Z každé
plochy, kterou koridor dělí, jsou vidět jen ty objekty, které se nachází
v přilehlé sousední ploše. Znamená to, že pokud se nacházím v ploše I. engine
vykresluje objekty umístěné na ploše I. a II., objekty na jiných plochách
nevykresluje. Ještě jednou pro upřesnění: když se nacházím na ploše IV. jsou
vykreslovány objekty z plochy IV.(na které se nacházím), III. a V. - sousední
plochy.
Těm méně chápavým stačí vědět jen to, jak koridory dělat.
2. Dělené podlahy a stěny po spodní úroveň podlahy
Hlavní předpokad správné funkce kompilátoru VIS je dělat stěny až po spodní
úroveň podlahy a na vrchní úroveň stropu.
Obrázek přiblíží:
Čili jak lze z obrázku správně pochopit, strop a podlahu dělejte raději mezi
stěnami.
Dělené podlahy jsou také jedním z předpokladů správné funkce VIS, ale díky tomu,
že vytvoříme stěny až pod úroveň podlahy se tato skutečnost realizuje už v
důsledku té první.
3. Některé předměty 1bod nad podlahou
Například krabice, bedny, tyče, židle, stoly, koše, květináče, tabulky a spoustu
podobných drobných věcí je vhodné nedávat přesně k zemi, ale 1 bod nad podlahu.
Jak Jirka_KT vysvětluje, ulehčí to počítání v engine. Mám na to malou ukázku.
(čím víc wpoly, tím pomalejší mapa)
Vytvořil jsem prázdnou mapu - dutou krychli s jedním světlem. Měla 94 wpoly.
Přidal jsem asi 11 beden těsně k podlaze - mapa měla 245 wpoly.
Všechny bedny jsem zvednul 1 bod od podlahy - mapa měla 176 wpoly.
Ze všech beden jsem udělal entity func_wall - mapa měla 162 wpoly.
Z toho plyne podstatné poučení - zbytečné předměty zvednout o jeden bod nad podlahu
a případně je změnit na func_wall. Dále z toho plyne, že by bylo vhodné udělat ze
všech objektů func_wall, ale to je trochu omyl, protože func_wall si engine nahrává
do nějakého buferu, který je omezen počtem zobrazovaných objektů typu func_wall,
takže pokud byste měli v jedné místnosti mnoho func_wall, některé by začaly mizet.
Pokud se přece jen problém objeví, nejspíše je způsoben kompilací pomocí bodu 1,
kdy engine vykresluje všechny objekty a proto se všechny najednou nevejdou do bufferu.
4. LEAK LEAK LEAK - celá mapa v duté krychli???
Určitě každý měl jeden podstatný problém a to s dírami v mapě. Hráč
uzavřený v mapě nesmí vidět ven - do černého prostoru, jinak se při kompilaci
někdy setkáme s neúspěchem. Jako nejlepší řešení vidím dodržovat body 1. a 2.
tohoto článku. Pokud se objeví přece jen nějaký LEAK,
zkuste přes celou mapu (jak doporučuje Mixer) udělat plnou krychli, a postupně
zmenšovat a průběžně kompilovat. Tam, kde se následně objeví LEAK
ve výpisu kompilace, tak někde v těch naposledy odkrytých místech bude problém. To
je ta složitější, zato však doporučenější varianta. Druhou variantou je nouzová
varianta - umístění celé mapy do jedné velké duté krychle - u venkovních map s
texturou "sky" (oblohy), bez oblohy třeba texturu "black". Pozor,
krychle nesmí být moc velká, měla by přesně obepínat celou mapu a neměla by do ní
nijak zasahovat. Protože čím větší krychle, tím pomaleji by se mapa kompilovala.
Druhá nevýhoda u druhé možnosti je ta, že mapa je pak špatně prosvětlená, a
někdy se stává že světlo proniká i tam kde by nemělo.
Upozornění: V kontaktu s volným prostorem okolo mapy musí být pouze čísté brushe,
čili žádné jiné func_wall, ani žádné entity se nesmí nacházet mimo mapu, jinak
bude LEAK pořád naskakovat. Taky si dejte pozor, abyste
neměli moc brushů zaseklých do sebe - to taky dělá občas neplechu.
5. Omezení detailů u velkoprostorových
map
Existují mapy které musí být opravdu velké, a tak je nutné u nich omezit detaily
- to znamená že se do takových prostor nebudou vkládat zbytečně předměty, které
nemají žádné opodstatnění se v dané lokalitě nacházet. S tímto souvisí i bod 6.
Dále se v Map Properties dá nastavit položka Max viewable distance, kde se zadává
vzdálenost, která má být v engine vidět - prostě kterou engine renderuje a zobrazuje
na monitoru. Pokud si nastavíte hodnotu 1024, určitě poznáte, že je velmi malá
(vhodná akorát pro nějaké bludiště). Hodnota 4096 je standardní a rozumná pro
normální mapy, 8192 používejte pro prostorné mapy. Lze používat určitě až do
16384. Doporučoval bych používat násobky 1024. (proč, to nevím, ale někde jsem se
to dočetl). Takže čím větší číslo - tím dál bude engine vykreslovat mapu,
a tím bude samozřejmě pomalejší - i když zde rozdíl rychlostí není až tolik
znatelný jak u správného nastavení kompilace.
6. Správná formace textur
Také je potřeba promyslet, zda do mapy vkládat obrovské textury 256*256, místo
jedné 128*128, kterou roztáhneme na požadovaných 256*256 - samozřejmě na úkor
kvality - ale důsledek je zvýšení rychlosti (podle Jirky_KT).
Mé zkušenosti praví, že když mám dlouhou chodbu s texturou 128*128, roztáhnu ji
raději do šířky na 128*256.
Dále je nesmysl zmenšovat velké textury do malých - třeba 128*128 na 32*32 - kvalita
je sice pěkná, ale je to na úkor zpomalení. O zvětšování malých textur na
obrovské ani nepíšu, protože to co z toho vznikne je hnusná mazanice.
Max_map_miptex - občas se tato chybová hláška objeví v
kompilaci, a začne nabíhat nepřeberné množství čísel. To má také souvislost s
texturami. Pokud máme mnoho objektů s texturami zvětšenými např 10x a více,
ušetří se určitě trochu paměti, ale maximálně zvětšujte textury 3-6x,
jinak to bude občas dělat problémy. Zmenšené textury - třeba na 0.05 původní
velikosti - to je taky špatně. Poslední problém co má za následek chybu max_map_miptex, a který se mi podařilo zjistit, je počet
použitých textur v mapě. Pokud pořád nemůžete najít problém s formací textur,
zkuste - a to možná i před hledáním problémů, odstranit některé velké textury -
čili zmenšit počet použitých textur v mapě - a náhle to pojede v pohodě.
7.Správná tvorba oblouků
Pokud vytvoříme například studnu, nebo skruž pomocí dvou objektů, z nichž
jedním menším vytvoříme díru (carve) v tom větším, je to postup špatný. Už
jsem se setkal s mnoha mapami kde bylo tímto postupem vytvořeno mnoho kulatých věcí.
Například
- Toto je
velice špatně!!!!
Nejlépe s ohledem na engine a fps se oblouky a skruže dělají přes funkci ARCH. Pomocí ARCH lze dosáhnout
téměř čehokoliv :o)
Další záležitost je vnitřní oblouk např. u nosníku stěny:
Tato verze je nejmírnější k enginu hry, tak to tak dělejte.
8. Fenomén info_node
Toto je jedna z nekonečných otázek, co je info node.
Odpověď vám dá tahle stránka.
Dodržujte architektonické prvky, nedělejte všechno hranaté. Hranaté věci patří minulosti (i když engine HL bohužel nic jiného neumí). Nejlepší kombinace je vhodná architektura a dobré textury. Více o architektuře přinesu v další aktualizaci tohoto souboru. 10. Skriptovací sekvence
Více o skriptování přinesu v další aktualizaci tohoto souboru.
Z VLASTNÍCH
ZKUŠENOSTÍ A NA PODNĚTY JIRKY_KT A OSTATNÍCH NADŠENCŮ SESTAVIL: P2K
Přezdívka/nick: | |
Text příspěvku: (pouze holý text) | Napiš cifrou deset: |