Popis 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é plochy (GMAX)
MakeMDL vyhazuje chybovou hlášku (GMAX)
Makro stromy od Petra Bednáře (Airport)
Crashboxy a kolize s objekty i daleko od nich (GMAX)
Dávkové soubory *.BAT
Export z GMAX do *.ASM
Texturování polygonu z Airportu
Špatná AFD data (AFCAD)
Odstraněný autogen okolo GMAX objektů
Export z GMAX
Převody souřadnic
Objekty, reagující na vítr a podobně
Objekty v FS mají obrácené plochy
Příč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í:
Vyberte objekt, u kterého se problém vyskytuje
Pokud možno, přesuňte těžiště objektu (pivot) na střed objektu
Zrcadlete (mirror) objekt podle osy X
Aplikujte na objekt modifikátor Edit Mesh
Označte všechny plochy objektu
V liště s nástroji podržte levé tlačítko myši na ikoně Scale a vyberte Non-Uniform Scale. Klikněte znova pravým na tuto ikonu
Otevře se okno pro zadání změn velikost objektu. Do políčka Offset X zadejte -100%.
Objekt by měl být nyní na své původní pozici a měl by mít obrácené normály. Teď už jen aplikujte modifikátor Normal a flipněte normály.
Pokud objekt teď exportujete a vyzkoušíte v FS, měly by už být jeho plochy orientovány správně.
MakeMDL vyhazuje chybovou hlášku
Problé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í:
Vyberte objekt, u kterého se problém vyskytuje. Naleznete jej třeba metodou pokusu omylu nebo to provedete pro všechny objekty.
Pomocí modifikátoru Edit Mesh myší vyberte všechny polygony objektu a zvolte Detach do nového objektu.
Vznikne vám nový objekt, pojmenovaný třeba Mesh01. Původní objekt už není viditelný, ale stále obsahuje ty záhdné vrcholy (vertexy). Starý objekt teď můžete smazat.
Exportujte přes MakeMDL.
Makro stromy od Petra Bednáře
Makro 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.
listnaté vf_tree1.bmp
číslo
x size
y size
x offset
y offset
1
64
255
0
0
2
64
127
64
0
3
128
127
128
0
4
64
127
64
128
5
64
127
128
128
6
64
82
192
128
7
64
45
192
211
jehličnaté vf_tree2.bmp
číslo
x size
y size
x offset
y offset
1
64
255
0
0
2
64
255
64
0
3
64
127
128
128
4
64
128
192
128
5
64
127
128
0
6
64
127
192
0
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ů.
8-strom vzniká přibližně tak, že se exportované objekty pokud možno obalí co nejmenším kvádrem. Ne vždy tomu tak je.
První dělení proběhne vždy a zjišťuje se, zda 8 vzniklých kvádrů se bude považovat za kolizní, nekolizní nebo zda se bude některý z nich muset dělit na dalších 8. Pokud nejde o exportování krabice, tak se obvykle dále dělí. Zjistí se jestli každá jednotlivá část (kvádr) bude kolidovat, nebude nebo se bude dále dělit. Dělí se tak dlouho, dokud nějaký mechanismus při exportu neuzná za vhodné, že je třeba skončit (může být i dosaženo maxima kvádrů).
Na obrázku je vidět jak takové dělení postupuje a postupně se označují kolizní a nekolizní kvádry. Čtvrtý obrázek je v tomto případě konečný a jde vidět, které kvádry jsou jak označeny. Žlutě jsou označeny některé oblasti, ve kterým není žádný objekt, ale přesto jsou kolizní - to právě způsobuje problémy s "building crash" i daleko od budov v FSku.
Část kódu souboru jes_st_boudy.asm, ve které je popsán 8-strom kolizí
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).
Řádek 007 - počet uzlů v seznamu
Řádek 008 - souřadnice levého, spodního (osa kolmá na zemský povrch), dolního rohu oblasti vzhledem k souřadnicovému středu projektu.
Řádek 009 - velikost oblasti (kvádru) - šířka (osa X), výška, délka (osa Y)
Řádek 010 - základní offsety prvních osmi kvádrů. Příklad: dw 1 (na uzel 1), 8 (na uzel 8), 8, 11, 16, 21, 25, 25. Uzly jdou popořadě tak jak na následujícím obrázku
Řádek 013 až 042 - samotné definice uzlů. Za OCTTREE_NODE vždy následuje 8 čísel. 254 znamená, že tento kvádr nebude kolizní a dále se nedělí. 255 znamená, že kvádr kolizní bude a dále se nebude dělit. Jakékoliv jiné číslo je offset, ukazující na řádek s rozkladem daného kvádru na 8 dalších.
Offsety fungují následovně. Na řádku 14 je poslední hodnota 6 - znamená to, že tento kvádr se bude rozkládat na kvádry popsané na uzlu 6+1=7 (v ukázce řádek číslo 20). Proč +1? Protože se tyto kvádry nacházely v první osmině základního kvádru a na řádku 10, začínajícím "dw" je na prvním místě uvedeno číslo 1.
Pokud to stále není zřejmé, zkuste si tento příklad projít a určitě pochopíte.
Zde je řádek 10 a 13 u sebe. Všimněte si, že offsety v prvním řádku na pozici 2 a 7 vlastně nejsou ani tak offsety, jako spíše bezvýznamné číslo. To proto, že na druhém řádku jsou tyto pozice označeny jako kolizní (255) a nekolizní (254) a offset pro další rozklad není nutný.
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.
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.
Červený obdélník obsahuje všechny objekty. Ty byly při prvních pokusech s touto scenérií exportovány najednou. Crashboxy samozřejmě nemohly tak dobře sednout a výsledkem byly nechtěné kolize krom jiného i na místech vyznačených červenými fleky nebo žádné kolize na místech, kde by se hodily. Scénu jsem rozdělil na 5 částí (označeny žlutě) a objekty bez kolizí (neoznačeny). Vetšina špatných kolizí se napravila až na kolize mezi budovami vlevo dole. Tam by bylo potřeba další dělení.
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
Zde je vidět v praxi jak crashboxy vypadají a že přesně nekopírují hranice objektu.
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
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:
Převedení souborů *.asm na namesti.mdl
Převedení namesti.mdl na namesti.bgl
Překopírování namesti.bgl na zvolenou cestu
Čeká na stisk klávesy
Dávkové soubory se také neuvěřitelně osvědčí při tvorbě ortofotomap. Zde je příklad bez podrobnějšího popisu.
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(.....)
druhá a čtvrtá souřadnice se použije pro přesné umístění
hodnoty jsou 0 - 255
druhá souřadnice je horizontální osa - čím víc tím víc do prava
čtvrtá souřadnice je vertikální osa - čím víc tím výš
Š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í:
Výsledný BGL soubor dekompilovat pomocí programu bglxml
Opravit chybu (například právě ta zdvojená dráha)
Zpětně zkompilovat pomocí programu bglcomp
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 GMAX
Jen 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řadnic
Obč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
8-strom vzniká přibližně tak, že se exportované objekty pokud možno obalí co nejmenším kvádrem. Ne vždy tomu tak je.
První dělení proběhne vždy a zjišťuje se, zda 8 vzniklých kvádrů se bude považovat za kolizní, nekolizní nebo zda se bude některý z nich muset dělit na dalších 8. Pokud nejde o exportování krabice, tak se obvykle dále dělí. Zjistí se jestli každá jednotlivá část (kvádr) bude kolidovat, nebude nebo se bude dále dělit. Dělí se tak dlouho, dokud nějaký mechanismus při exportu neuzná za vhodné, že je třeba skončit (může být i dosaženo maxima kvádrů).
Na obrázku je vidět jak takové dělení postupuje a postupně se označují kolizní a nekolizní kvádry. Čtvrtý obrázek je v tomto případě konečný a jde vidět, které kvádry jsou jak označeny. Žlutě jsou označeny některé oblasti, ve kterým není žádný objekt, ale přesto jsou kolizní - to právě způsobuje problémy s "building crash" i daleko od budov v FSku.
Červený obdélník obsahuje všechny objekty. Ty byly při prvních pokusech s touto scenérií exportovány najednou. Crashboxy samozřejmě nemohly tak dobře sednout a výsledkem byly nechtěné kolize krom jiného i na místech vyznačených červenými fleky nebo žádné kolize na místech, kde by se hodily. Scénu jsem rozdělil na 5 částí (označeny žlutě) a objekty bez kolizí (neoznačeny). Vetšina špatných kolizí se napravila až na kolize mezi budovami vlevo dole. Tam by bylo potřeba další dělení.
