Spřátelené weby
další odkazy

Poznámky ke tvorbě scenérií do Flight Simulatoru

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.

1. Objekty v FS mají obrácené plochy (GMAX)
2. MakeMDL vyhazuje chybovou hlášku (GMAX)
3. Makro stromy od Petra Bednáře (Airport)
4. Crashboxy a kolize s objekty i daleko od nich (GMAX)
5. Dávkové soubory *.BAT
6. Export z GMAX do *.ASM
7. Texturování polygonu z Airportu
8. Špatná AFD data (AFCAD)
9. Odstraněný autogen okolo GMAX objektů
10. Export z GMAX
11. Převody souřadnic
12. 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í:

1. Vyberte objekt, u kterého se problém vyskytuje
2. Pokud možno, přesuňte těžiště objektu (pivot) na střed objektu
3. Zrcadlete (mirror) objekt podle osy X
4. Aplikujte na objekt modifikátor Edit Mesh
5. Označte všechny plochy objektu
6. 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
7. Otevře se okno pro zadání změn velikost objektu. Do políčka Offset X zadejte -100%.
8. 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í:

1. Vyberte objekt, u kterého se problém vyskytuje. Naleznete jej třeba metodou pokusu omylu nebo to provedete pro všechny objekty.
2. Pomocí modifikátoru Edit Mesh myší vyberte všechny polygony objektu a zvolte Detach do nového objektu.
3. 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.
4. Exportujte přes MakeMDL.

Makro stromy od Petra Bednáře

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. 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).

1. Řádek 007 - počet uzlů v seznamu
2. Řá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.
3. Řádek 009 - velikost oblasti (kvádru) - šířka (osa X), výška, délka (osa Y)
4. Řá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

5. Řá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ý.
   dw 1, 8, 8, 11, 16, 21, 25, 25 OCTTREE_NODE 0, 255, 0, 0, 0, 0, 254, 0

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

Pokud máte připomínky, nebo narazíte na chybu, prosím napište

Zpět na homepage www.leteckemotory.cz

© Zdeněk Kussior

Přístupů od 24. 4. 2002