![]() |
Poznámky ke tvorbě scenérií do Flight SimulatoruPopis několika problémů, se kterými jsem se setkal a musel při tvorbě do FS řešit.Nebudu tu popisovat úplné základy tvorby - je to nad moje síly, nechce se mi a je to zbytečné. Je o tom dost popsáno jinde. Ale pokusím se tu shrnout a předvést řešení několika často dost zásadních problémů při práci ve více vývojových programech. Ani nečekejte bůh ví jakou úroveň a kompletnost - co mě napadne, to tu dám.Vše se vztahuje k FS2004, k vývojovým nástrojům dostupným v té době (cca polovina roku 2005) a k aktuálním SDK od Microsoftu.
Objekty v FS mají obrácené plochyPříčina:Při vytváření objektu jste nejspíše použili funkci zrcadlení. Ač to není v GMAXu vidět, rozhodily se tím normály ploch. To se pak ve hře projeví tím, že plochy objektu, které by měly jít vidět vidět nejsou a naopak.Řešení:
MakeMDL vyhazuje chybovou hláškuProblém:Při pokusu o export scény pomocí MakeMDL vyskočí hláška, obsahující krom jiného taky řádek ".... Invalid X file ...". Jedna z příčin:Některý objekt má nějakým záhadným způsobem více vrcholů než by měl mít. Vrcholy navíc nejsou součástí žádné plochy a myší se obvykle nedají označit, jen mopomí Select All. Řešení:
Makro stromy od Petra BednářeMakro několika stromů středoevropského vzhledu je použitelné v programu Airport a tuším i ve FSSD (nevím, nepoužívám). Dají se umisťovat jednotlivně nebo jako skupinka (forest). Při jednotlivém umisťování je nutné zadat krom parametrů jako jsou rozměry a podobně také souřadnice, která oblast textury se na ten který strom vykreslí. Následuje obrázek a tabulka s parametry, které se v Airport vyplní do odpovídajících políček.
![]()
Kouzlo tohoto makra je ale ještě v něčem jiném. Krom stromků se dají takto do scény umístit jakékoliv jiné objekty/textury (v terminologii grafiků tzv. sprites). Dost dobře se tak dají do scenérie umisťovat například osoby. Zásadní problém je v tom, že použitá textura musí mít rozlišení maximálně 256x256 pixelů. Plyne to tuším z omezení kódu SCASM, který toto makro využívá.
Crashboxy a kolize s objekty i daleko od nich (GMAX)Problém:FSko detekuje kolize s vámi vytvořenými objekty třeba i 15 metrů od nich.Příčina:Je to dámo způsobem, jakým jsou reprezentována a uložena data pro kolize. Každý exportovaný model, i když je složen z více objektů, má svůj popis kolizí uložen v tzv. 8-stromu (octtree). 8-strom vzniká dělením kvádru, obalujícího model na omezený počet menších kvádrů poloviční, čtvrtinové, osminové velikosti. Kolize letounu se scenérií jsou pak počítány jako kolize s těmito ať už hodně velkými nebo malými kvádry. Právě tyto kvádry většinou nemohou přesně obalit všechny části objektu a často značně přesahují námi vytvořený objekt. A to je příčinou nechtěných kolizí ve větší vzdálenosti od objektu.Proč je to řešeno pomocí rozkladu na 8-stromy a ne jako kolize polygonu s polygonem? Důvod je asi podstatně větší rychlost výpočtu zda se koliduje nebo ne. Když máte ve scéně 200 objektů a každý by měl mít kolizní tvar složený z polygonů, tak by se CPU poněkud dost zapotilo. 8-strom:"Osmistrom" je v tomto případě datová struktura, kde každý uzel může mít svou hodnotu buď bude kolize, nebude kolize nebo ukazatel na svých 8 potomků.![]() ![]()
Část kódu souboru jes_st_boudy.asm, ve které je popsán 8-strom kolizí
001: crash_riff_start label BGLCODE
002: db 'C','R','A','S'
003: dd crash_riff_end - $ - 4
004: BGL_CRASH_START model_crash_end, 67
005: BGL_CRASH_OCTTREE crash_end_1
006: dw CRASH_FLAG_BUILDING_PLANE ; crash type
007: dw 30 ; nodes used
008: real4 50.951530,0.000004,-6.792075 ; Box x,y,z
009: real4 11.377305,9.922221,29.766663 ; Box w,h,d
010: dw 1, 8, 8, 11, 16, 21, 25, 25 ; base offset into node table
011: ; So if you take branch 2 (count from 0), you add 8 to indices you encounter on that branch
012: ; Nodes (254=empty 255=full, else an index into branch)
013: OCTTREE_NODE 0, 255, 0, 0, 0, 0, 254, 0 ; node 0
014: OCTTREE_NODE 1, 2, 3, 4, 254, 254, 5, 6 ; node 1
015: OCTTREE_NODE 254, 254, 255, 255, 254, 254, 255, 255 ; node 2
016: OCTTREE_NODE 254, 254, 255, 255, 254, 254, 254, 254 ; node 3
017: OCTTREE_NODE 254, 254, 254, 254, 255, 255, 254, 254 ; node 4
018: OCTTREE_NODE 254, 255, 254, 254, 255, 255, 254, 254 ; node 5
019: OCTTREE_NODE 255, 255, 254, 254, 255, 255, 254, 254 ; node 6
020: OCTTREE_NODE 255, 255, 255, 254, 255, 255, 254, 254 ; node 7
021: OCTTREE_NODE 254, 254, 254, 254, 254, 1, 254, 2 ; node 8
022: OCTTREE_NODE 255, 254, 255, 254, 254, 254, 254, 254 ; node 9
023: OCTTREE_NODE 255, 254, 254, 254, 254, 254, 254, 254 ; node 10
024: OCTTREE_NODE 1, 2, 254, 254, 3, 4, 254, 254 ; node 11
025: OCTTREE_NODE 255, 255, 254, 254, 255, 255, 254, 254 ; node 12
026: OCTTREE_NODE 255, 255, 254, 254, 255, 255, 254, 254 ; node 13
027: OCTTREE_NODE 255, 255, 254, 254, 255, 255, 254, 254 ; node 14
028: OCTTREE_NODE 255, 255, 254, 254, 255, 255, 254, 254 ; node 15
029: OCTTREE_NODE 254, 254, 1, 2, 254, 254, 3, 4 ; node 16
030: OCTTREE_NODE 255, 255, 254, 254, 255, 255, 255, 255 ; node 17
031: OCTTREE_NODE 255, 255, 254, 254, 255, 255, 255, 255 ; node 18
032: OCTTREE_NODE 255, 255, 255, 255, 255, 255, 254, 254 ; node 19
033: OCTTREE_NODE 255, 255, 255, 255, 255, 255, 254, 254 ; node 20
034: OCTTREE_NODE 1, 255, 255, 255, 2, 255, 3, 255 ; node 21
035: OCTTREE_NODE 255, 255, 255, 255, 254, 255, 254, 255 ; node 22
036: OCTTREE_NODE 254, 255, 254, 255, 254, 255, 254, 255 ; node 23
037: OCTTREE_NODE 255, 255, 255, 255, 255, 255, 254, 255 ; node 24
038: OCTTREE_NODE 1, 2, 254, 254, 3, 4, 254, 254 ; node 25
039: OCTTREE_NODE 255, 255, 254, 254, 254, 255, 254, 254 ; node 26
040: OCTTREE_NODE 255, 255, 254, 254, 255, 255, 254, 254 ; node 27
041: OCTTREE_NODE 254, 255, 254, 254, 254, 255, 254, 254 ; node 28
042: OCTTREE_NODE 255, 255, 254, 254, 255, 255, 254, 254 ; node 29
043: crash_end_1 label word
044: model_crash_end label word
045: BGL_RETURN
046: crash_riff_end label BGLCODE
Pokusím se trochu popsat jak to v této části kódu funguje (alespoň to co chápu). Nejprve si uvědomme, že kvádry jsou orientovány rovnoběžně s poledníky, rovnoběžkami a jsou vodorovné (za předpokladu, že v XML není uvedena nějaká rotace scény).
![]() Jak minimalizovat škody vzniklé nedostatečným rozkladem:Za prvé: Pokud mají objekty větší rovné plochy (např paneláky), rozhodně je navrhujte "rovnoběžně s osami" a případné otočení proveďte až pomocí XML souboru.Za druhé: U malých objektů, kde jsou kolize vcelku zbytečné, je vypněte. Pamatujte, že vypnout se dají pouze u celého objektu, takže pokud chcete, aby některá část existujícího objektu byla nekolizní, musíte příslušné polygony pomocí Detach oddělit. Zamotné zrušení kolizí vybraného objektu provedete v GMAXu skriptem AttachTools - viz SDK. Nebo napsáním tohoto textu do Properties vybraného objektu. <?xml version="1.0" encoding="ISO-8859-1"?><FSMakeMdlData version="9.0"><NoCrash/></FSMakeMdlData>
Za třetí: Pokud je scéna rozlehlejší (např fotbalový stadion + pár budov kolem), exportujte ji v několika částech. Samostatně vyexportujte objekty, které nebudou kolizní. Poté od sebe oddělte objekty, které spolu moc nesouvisí a jsou od sebe vzdáleny. Následující obrázek by to měl osvětlit.
![]() Za čtvrté: V souboru ASM můžete crashboxy upravit. Psát to ručně je ale trochu pekelná práce. Nějakým jednoduchým programem půjde udělat definice vlastních crashboxů. Crashboxy by taky mohly jít pěkně vytvořit přímo v GMAXu a pak si trochu pohrát se spojováním dat z více ASM souborů. Zatím jsem vypotil malý prográmek, který z ASM souboru pomůže vytvořit BGLko, ve kterém jsou viditelné crashboxy - FSBox ![]() Dávkové soubory *.BAT
Spousta programů pro tvorbu a kompilaci scenérií jsou pouze konzolové aplikace bez uživatelského rozhraní. Pracuje se s nimi pouze v příkazovém řádku formou zadání jména programu a jednoho nebo více parametrů. Často je potřeba spustit sérii programů, které si budou postupně předávat výsledky své práce. Právě tady se uplatní dávkové soubory = textové soubory s příponou BAT.
Příklad vytvor.bat souboru pro konverzi .asm na .mdl a .bgl
bglc /mdl %1.asm
bglcomp %1.xml
copy %1.bgl "c:\hry\fs2004\Addon Scenery\moje_mesto\Scenery\%1.bgl
pause
Při exportu testovací scenérie namesti z GMAX přes MakeMDL a se zaškrtnutím volby Keep Files v Options vzniknou soubory namesti.asm, namesti_0.asm a namesti.xml. V namesti.xml nastavíte souřadnice, kde bude náměstí umístěno.
Ke spuštění procesu převedení těchto souborů na soubor namesti.bgl stačí do příkazového řádku napsat vytvor namesti. Provede se tím:
resample jes.inf
del 011232010033201*.tga
del 011232010033203*.tga
del 011232010033210*.tga
del 011232010033211*.tga
del 011232010033321*.tga
del 011232010033323*.tga
del 011232010211001*.tga
abc.exe "c:\FS-sdk\0*.tga" /flip /convert="c:\FS-sdk\*.bmp"
imagetool -nogui -terrainphoto 0*.bmp
copy *.mip JES-tex\*.bmp
copy *.mip c:\hry\FS2004\Scenery\World\texture\*.bmp
del 0*.mip
Dávkové soubory vám často ušetří až desítky procent času, námahy a nervů.
Export z GMAX do *.ASM
Z GMAXu je přes MakeMDL možné exportovat přímo do formátu MDL a nebo při zaškrtnutí volby Keep Files v Options můžete ponechat mezistupeň mezi GMAXem a formátem MDL - soubory ASM. V těchto souborech je vámi vytvořená scéna (objekty) popsána na nejnižší člověkem čitelné úrovni. Znalost struktury těchtou souboru vám dá možnost editovat parametry, které by jste přímo v GMAXu těžko ovlivnili.
Texturování polygonu z Airportu
Zatím jen pár poznámek bez delšího popisu.
Vytvoří se polygon, přiřadí se mu textura. Projekt se převede do kódu SCASM. Ve vzniklém souboru SCASM se upraví závorka u odpovídajícího řádku Bitmap(.....)
Špatná AFD data (AFCAD)Jak se to projevuje:FSko při načítání nebo při přiblížení k letišti na vzdálenost asi 15 km někomu spadne, někomu ne.Příčina:Program AFCAD v AFD datech vytvořil chybu - například zdvojenou dráhu.Řešení:
Odstraněný autogen okolo GMAX objektůProblém:I ve vzdálenějším okolí objektů z GMAXu je v FSku ostraněn autogen. To znamená, že například blízko u vymodelovaného letiště by měl být les, ale v FS v něm nejsou stromy. Ty se objevují až o několik desítek až stovek metrů dále.Pravděpodobná příčina:Autogenové objekty se pravděpodobně ruší v kruhu (no, spíše v obdélníku), který má střed ve středu souřadnicového systému vašeho GMAX projektu a poloměr sahá k nejvzdálenějšímu bodu objektu vaší scény, přesněji k nevzdálenějšímu bodu objektu, který exportujete.Možné řešení:Pokud máte ve scéně některý objekt příliš vzdálen, posuňte jej do středu. Budete pak ale muset pro tento objekt zvlášť zjistit jeho souřadnice a zvlášť ho exportovat. Neznamená to ale, že výsledek bude muset mít více BGLek. Při kompilaci jednoduše všechny objekty scény v XML souboru sloučíte dohromady a vyexportujete jako jediný BGL soubor.Zde je příklad fotbalového stadionu a přilehlého školy. V prvním případě se v FSku smazaly autogenové domy do vzdálenosti cca 250 metrů od středu hřiště. Po úpravě, samostatném vyexportování a sloučení všecho v XMLku se smazaly autogenové domy jen do vzdálenosti cca 150 metrů. ![]() Export z GMAXJen krátce. Exportuje se přes utilitku MakeMDL.Exportuje se buď přímo do .MDL a .XML a potom se pomocí bglcomp vytvoří BGL. Při exportu lze v MakeMDL zvolit monost Keep Files, díky čemuž krom .MDL a .XML vzniknou ještě dva soubory .ASM. MDL je v podstatě pouze kompilát z těchto souborů ASM. Postup kompilace je zatím napsán někde výše (BAT soubor). Převody souřadnicObčas je potřeba převádět souřadnice různých souřadnicových systémů. Například S-JTSK <-> WGS-84 (ten používá FSka). Zatím mi jako dobrý nástroj připadá tento "excelovský program".Objekty, reagující na vítr a podobněTakové specialitky, jako pěkné větrné pytle, přistávací "téčka" v signálním čtverci, zahrádka u hospody, otevřená jen v létě a podobně se dají udělat pomocí editace BGLC kódu.Někdy tu možná trochu popíši, jak se to dělá. Zatím ale jen doporučím samostudium zde http://www.scenerydesign.org/forum/. Poslední aktualizace: podzim 2005 Pokud máte připomínky, nebo narazíte na chybu, prosím napište Zpět na homepage www.leteckemotory.cz |