Prohlášení
Byl jsem seznámen s tím, že na mou bakalářskou práci se plně vztahuje zákon č. 121/2000 Sb.
o právu autorském, zejména §60 - školní dílo.
Beru na vědomí, že Technická univerzita v Liberci (TUL) nezasahuje do mých autorských práv užitím mé bakalářské práce pro vnitřní potřebu TUL.
Užiji-li bakalářskou práci nebo poskytnu-li licenci k jejímu využití, jsem si vědom povinnosti informovat o této skutečnosti TUL; v tomto případě má TUL právo ode mne považovat úhradu nákladů, které vynaložila na vytvoření díla, až do jejich skutečné výše.
Bakalářskou práci jsem vypracoval samostatně s použitím uvedené literatury a na základě konzultací s vedoucím bakalářské práce a konzultantem.
Datum 25.3. 2013 Podpis
Abstrakt
Aurora je aplikace pro PC (Win x86, x64), zaměřující se na co nejvěrnější simulaci a vizualizaci pohybu těles v planetárních systémech. Aplikace je schopná simulovat a vizualizovat nejenom náš planetární systém (sluneční soustavu), ale i přibližně dalších 12 000, doposud objevených planetárních systémů, které jsou veřejně dostupné díky laboratoři obyvatelnosti exoplanet, sídlící pod záštitou University of Puerto Rico – Arecibo. Aurora je rovněž schopna, díky interním algoritmům, vygenerovat kompletně náhodný planetární systém (dle řádných pravidel) a díky tomu značně protestovat simulační a vizualizační schopnosti. Mezi simulační schopnosti pak hlavně patří schopnost simulovat pohyb planet okolo hvězdy, měsíců okolo planet, menších objektů (např. komet) v systémech, ale i také udržování informací o obyvatelné zóně, která určuje obyvatelnost objektů v daném systému. Simulace je založena na analytickém řešení pohybu tělesa okolo centrálního tělesa na stabilních orbitálních drahách. Mezi vizualizační schopnosti můžeme zmínit věrnou grafickou reprezentaci jednotlivých těles v systémech, např. planety s odpovídajícím povrchem, případnou vrstvou mraků a atmosférou, odpovídající parametrům dané planety.
Aurora je napsaná v jazyce C# a je napojená na herní engine Unity3D, který se stará primárně o vizualizaci simulace a také poskytuje čisté a přehledné uživatelské rozhraní, pomocí kterého je možné využívat rozmanité možnosti této aplikace. Aplikace je určena primárně pro vzdělávací účely, kde by měla posloužit jako zdroj informací okolo výzkumu, hledání tzv. exoplanet, ale také objasňuje základy nebeské mechaniky. Její editační schopnosti dovolují experimentovat se všemi dostupnými parametry těles a umožňuje tedy vytvořit situace, které uživatel požaduje.
Abstract
Aurora is a PC (Win x86, x64) application, focusing on a very authentic simulation and visualization of planetary systems. It is able to simulate and visualize not only our Solar System, but also approximately twelve thousand already discovered planetary systems, whose data are available for public use by courtesy of Planetary Habitability Laboratory at University of Puerto Rico - Arecibo. Thanks to its internal algorithms, Aurora is also capable of generating completely random planetary systems (based on correct rules) to properly test its simulation and visualization capabilities. The main task of the simulation is to determine location of moving objects such as planets around their stars, moons around planets and even smaller objects like comets. The simulation is based on an analytic solution of body movement round the central body on stable orbital path. Another core component is the habitable zone information, which is used to define habitability of objects within a planetary system. As from the visualization point of view there are really detailed planet shaders, which directly correspond to the planet's characteristic (clouds, atmosphere, habitability, etc.).
Aurora is written in C# language and is connected to the Unity3D game engine, which is primarily used for the visualization, but as well for the clean graphical user interface, creating perfect environment to fully use the Aurora's functionalities. The application is supposed to be for an educational use, where it should serve as a source of information about the exoplanet research and celestial mechanics. The main advantages in this direction are its edit capabilities, which allow the user to experiment with all the available parameters in order to create diverse situations.
Obsah
1 Úvod...13
2 Analýza problematiky...14
2.1 Potřebné parametry k simulaci a vizualizaci...14
2.2 Charakteristika těles...14
2.2.1 Hvězda...14
2.2.2 Planety a měsíce...18
2.2.3 Charakteristika keplerovské orbity...21
2.3 Charakteristiky pro vizualizaci...25
2.4 Generování náhodných planetárních systémů...25
2.5 Načítání reálných dat o exoplanetách...26
3 Řešení problematiky...27
3.1 Použité programovací jazyky a software...27
3.2 Cílové platformy...27
3.3 Rozdělení problému do dvou hlavních projektových částí...28
3.3.1 Aurora (Aurora.dll) (jmenný prostor Aurora)...28
3.3.2 AuroraVE (Unity3D) (jmenný prostor AuroraVE)...28
4 Objektová reprezentace (jmenný prostor Aurora, dll)...28
4.1 Návrh objektové reprezentace systémů a diagram tříd...28
4.2 Popis všech částí a jejich funkcí v Aurora.dll...29
4.2.1 Základní poznámky...29
4.2.2 Dynamické třídy...29
4.2.3 Statické třídy...37
5 Simulační a vizualizační část (jmenný prostor AuroraVE, Unity3D)...39
5.1 Spojení s Aurora.dll...39
5.2 Jmenné prostředí AuroraVE...39
5.3 Herní objekty (GameObject)...39
5.3.1 Hlavní herní objekty...39
5.3.2 Vedlejší herní objekty ...40
5.4 Scény (Scenes)...41
5.5 Proces využití orbitálních charakteristik a charakteristik těles v simulaci a vizualizaci...41
5.5.1 Inicializace...42
5.5.2 Za běhu...42
5.6 Řešení problémů spojených se simulací...43
5.6.1 Technické řešení pro práci s módy „SystemView“ a „CloseView“...44
5.6.2 Kontrola správnosti simulace...45
5.7 Struktura dat v projektu...45
5.8 Modely...46
5.9 Shadery...47
5.10 Materiály...47
5.11 Textury...48
5.11.1 Přiřazování textur v kódu...48
5.12 Grafické uživatelské rozhraní...49
5.12.1 Třída „OverviewCam“...49
5.12.2 Třída „AuroraVE_mainmenu“...50
5.13 Grafické prvky uživatelského rozhraní...51
5.13.1 2D texty a ikony (aurora.igui.icon, aurora.igui.text)...51
5.13.2 3D texty (aurora.igui.dtext)...51
5.13.3 Kreslení čar...52
5.13.4 Vizualizace orbit...52
5.13.5 Vizualizace hranic obyvatelné zóny...52
5.14 Zapojení Multisample Anti-Aliasing (MSAA)...53
5.15 Změna rozlišení aplikace...53
5.16 Ukazatel snímků za sekundu...53
5.17 Ovládání aplikace...53
6 Závěr...54
6.1 Současnost...54
6.2 Budoucnost...54
Seznam ilustrací
Ilustrace 1: Před / Po (Porovnání prvotní verze s prakticky finální verzí vizualizace)...13Ilustrace 2: Hertzsprung-Russellův diagram [2]...14
Ilustrace 3: Vliv hodnoty excentricity na povahu orbity [9]...22
Ilustrace 4: Základní parametry, definující velikost a tvar orbity [10]...22
Ilustrace 5: Pokročilé parametry, definující polohu orbity [11]...23
Ilustrace 6: Zjednodušená struktura jmenného prostoru Aurora...29
Ilustrace 7: Ukázka celkového pohledu na systém ("SystemView")...44
Ilustrace 8: Ukázka detailního pohledu na těleso ("CloseView")...44
Ilustrace 9: Prohlížeč planet a jednotlivých jejich měsíců...49
Ilustrace 10: Editace parametrů hvězdy...50
Ilustrace 11: Sekce editace parametrů tělesa...50
Ilustrace 12: Hlavní menu aplikace...51
Ilustrace 13: Vizualizace obyvatelné zóny...52
Seznam tabulek
Tabulka 1: Intervaly parametrů pro jednotlivé typy podporovaných hvězd...15Tabulka 2: Intervaly parametrů pro jednotlivé velikosti těles...19
Tabulka 3: Závislost teplotně-obyvatelnostní třídy na hodnotě HZD...20
Tabulka 4: Intervaly počtu měsíců na každou velikostní třídu, které generátor využívá...26
Tabulka 5: Seznam využívaných konstant včetně aktuálně použitích hodnot...38
Seznam symbolů, zkratek a termínů
Orbita – oběžná dráha
GUI – Graphic User Interface – Grafické uživatelské rozhraní
NASA – National Aeronautics and Space Administration – Národní úřad pro letectví a kosmonautiku
PHL – Planetary Habitability Laboratory – Laboratoř planetární obyvatelnosti, sídlící pod záštitou univerzity v Portoriku v Arecibu
solární systém – v použití se slovem „náš“ se vztahuje na naši sluneční soustavu, jinak může popisovat obecný systém, stejně jako pojem „planetární systém“
HZD – Habitable Zone Distance – relativní vzdálenost od středu obyvatelné zóny AU – Astronomical Unit – astronomická jednotka
AU – Sun Unit – jednotka Slunce – používá se při výpočtu hmotností či poloměrů těles EU – Earth Unit – jednotka Země – používá se při výpočtu hmotností či poloměrů těles JD – Julian Date – juliánské datum
ESO – European Southern Observatory – Evropská jižní observatoř
1 Úvod
Když jsem před dvěma roky dostal na cvičení z předmětu „Vývoj aplikací pro Windows“
zadání, které spočívalo v jednoduchém vykreslení pohybu planetky okolo slunce s využitím základních metod kreslení na formuláře, asi bych nevěřil, že se z takové aplikace vyvine to, o čem tato práce pojednává. Už v jednoduchém formulářovém prvku jsem implementoval základy výpočtů, opírajících se o Keplerovy zákony, pohybu planety okolo hvězdy. Následoval jednoduchý objektový návrh a také další studie problematiky okolo exoplanet. Když jsem si pár měsíců poté uvědomil, že by z tohoto projektu klidně mohlo být zajímavé téma pro bakalářskou práci, neváhal jsem a zkusil jsem zadání rozšířit ještě o další solidní body.
Cílem této práce je vytvořit aplikaci, schopnou simulovat a vizualizovat nejrůznější planetární systémy, ať už reálné (náš či doposud nalezené), tak i fiktivní (procedurální). Výběr vizualizačního enginu nakonec vyhrál Unity3D se svou přístupností ve volně dostupné verzi, s vlastním vývojovým prostředím, podporou C# (jazyk, ve kterém jsem doposud projekt psal) a velkou komunitou, ve které člověk vždy najde pomoc.
Inspiraci jsem si vzal z programu, vytvořený NASA (rovněž v Unity3D), „Eyes on the Solar system“ [17], který posloužil i později, například při kontrole správné simulace.
Ilustrace 1: Před / Po (Porovnání prvotní verze s prakticky finální verzí vizualizace)
2 Analýza problematiky
2.1 Potřebné parametry k simulaci a vizualizaci
Je nutné si prvotně stanovit, co přesně bude simulace a vizualizace řešit a co už ne. Bez této prvotní analýzy se následující kroky neobejdou.
1) Aplikace bude reprezentovat systémy s jednou hvězdou.
2) Aplikace bude reprezentovat tělesa jako planety a jejich měsíce.
3) Aplikace bude rozhodovat o obyvatelnosti jednotlivých těles v daném systému.
4) Aplikace bude řešit pohyb těles (planet a měsíců) na stabilních, eliptických drahách a tento pohyb bude založený na analytickém řešení pohybu tělesa okolo centrálního tělesa (pohyb nebude ovlivněn gravitačními silami více těles v daném systému).
5) Aplikace bude řešit vzhled těles na základě jejich parametrů.
Velkou pomocí zde byla teorie, zpracovaná dle PHL, podle které bylo možné jednoduše navrhnout parametry tak, aby byla aplikace schopná reprezentovat různorodé planetární systémy s jakýmikoliv tělesy.
2.2 Charakteristika těles 2.2.1 Hvězda
Hvězda je nejdůležitější součást každého planetárního systému, protože bez ní by asi těžko planetární systém existoval. Stojí při zrodu planet a je odpovědná za dodávku tepelné a světelné energie pro všechna tělesa v planetárním systému.
Ačkoliv nejsou zcela vzácné případy tzv. binárních systémů (dvojhvězdných), simulace v současné verzi řeší pouze planetární systémy s jednou hvězdou (aplikace je na takový případ nicméně připravena a v budoucnu se problém bude řešit).
Pasivní parametry Spektrální třída
Hardvardská spektrální třída [1] rozděluje nejčastější typy hvězd do jasných kategorií.
Existuje sedm hlavních spektrálních tříd, které simulace řeší a počítá s nimi.
Jsou to (od největších a nejžhavějších) O (~0,00003%) – B (0,13%) – A (0,6%) – F (3%) – G (7,6%) – K (12,1%) – M (76,45%). Procentuální výskyt hvězd v našem okolí s těmito jednotlivými spektrálními třídami je velmi dobře odražen v křivce hvězd hlavní posloupnosti v tzv. Hertzsprung-Russellovu diagramu (název odvozen od autorů Ejnara Hertzsprunga a
Ilustrace 2: Hertzsprung-Russellův diagram [2]
Henryho Norrise Russella).
Barva
Každá hvězda má určité zabarvení. Počínaje nejslabšími M hvězdami, které jsou zbarveny do červena, přes hvězdy jako Slunce (G), které jsou laděny žlutou barvou, až po gigantické O hvězdy, které jsou praticky bílé.
Simulace tento údaj přebírá jako barvu ve formátu RGB.
Věk
Simulace zachycuje všechny hvězdy v jejich středním věku a neřeší postupný další vývoj (mluvíme zde o milionech let, na které algoritmy, které pracují s časem, ani nejsou připraveny).
Tento údaj simulace zpracovává jako desetinné číslo, vyjádřující stáří hvězdy v milionech let.
Hmotnost
Tento údaj simulace zpracovává jako desetinné číslo v jednotkách hmotnosti Slunce (1 odpovídá hmotnosti Slunce). Pro reálnou hodnotu se tento údaj musí vynásobit hmotností Slunce, která se rovná přibližně 1,98855 × 1030 kg.
Poloměr
Tento údaj simulace zpracovává jako desetinné číslo v jednotkách poloměru Slunce (1 odpovídá poloměru Slunce). Pro reálnou hodnotu se tento údaj musí vynásobit poloměrem Slunce, který se rovná přibližně 6,955 × 108 metrů.
Zářivý výkon
Je výkon, který vyzařuje daná hvězda do okolí. Výkon Slunce je přibližně 3,827 × 1026 W a z této hodnoty se následovně odvodí i výkon ostatních hvězd.
Tento údaj simulace zpracovává jako desetinné číslo v jednotkách zářivého výkonu Slunce (1 odpovídá zářivému výkonu Slunce).
Povrchová teplota
Tento údaj simulace zpracovává jako desetinné číslo v jednotkách stupňů Kelvina.
Následující tabulka ukazuje intervaly výše zmíněných parametrů pro každou podporovanou spektrální třídu. Tyto intervaly jsou rovněž využité při náhodném generování. Hodnoty pocházejí z [1].
Tabulka 1: Intervaly parametrů pro jednotlivé typy podporovaných hvězd Spektrální třída
O B A F G K M
Barva {R,G,B} {154, 175, 255} {202, 215, 255} {248, 247, 255} {248, 247, 255} {255, 242, 161} {255, 242, 161} {255, 242, 161}
Střední věk
(mil.let) (0,650; 11) (900; 1 400) (1 400; 2 750) (1 400; 4 125) (1 400; 4 125) (5 000; 7 526) (6 550; 12 000) Hmotnost (SU) (16; 30) (2,1; 16,0) (1,4; 2,1) (1,04; 1,4) (0,8; 1,04) (0,45; 0,8) (0,16; 0,45) Poloměr (SU) (6,6; 8,0) (1,8; 6,6) (1,4; 1,8) (1,15; 1,40) (0,96; 1,15) (0,70; 0,96) (0,50; 0,70) Zářivý výkon
(SU)
(30 000; 40
000) (25; 30 000) (5; 25) (1,5; 5) (0,6; 1,5) (0,08; 0,6) (0,56; 0,79)
Povrchová teplota (K)
(33 000; 50 000)
(10 000; 33
000) (7 500; 10 000) (6 000; 7 500) (5 200; 6 000) (3 700; 5 200) (1 500; 3 700)
Standartní gravitační parametr
Standartní gravitační parametr je veličina, která udává měřítko síly gravitační přitažlivosti určitého přirozeného tělesa. Značí se řeckým písmenem µ.
µ=GM
G je univerzální gravitační konstanta (G = (6,6742 ± 0,0010) × 10-11 m3 kg-1 s-2).
M je hmotnost daného tělesa v kg.
Výsledek je v m3s-2. Standartní gravitační parametr je v tomto případě simulací využit na výpočet doby oběhu tělesa (planety), které orbituje okolo dané hvězdy.
Obyvatelná zóna Popis obyvatelné zóny
Obyvatelná zóna [4] je oblast okolo dané hvězdy, kde by mohl za určitých podmínek na tělesech (planety, měsíce) existovat život tak, jak jej známe. Je to oblast, ve které tělesa přijímají takové množství sluneční energie, které povrch nepřehřívá a ani ho nenechává extrémně chladným. Obyvatelná zóna je velmi populárním tématem astronomů v posledních pár letech.
S neustálým zdokonalováním pozorovacích technik a instrumentů (např. vesmírná observatoř Kepler) se prohlubují znalosti lidstva o této problematice a objevují se tisíce tzv. exoplanet (extrasolární planety planety mimo naši sluneční soustavu (náš solární systém)).
Je to relativně jednoduchý systém, který řeší pomocí logiky ano / ne potenciální obyvatelnost těles uvnitř této zóny.
Metody pro objevování těles (planet) v okolí vzdálených hvězd
Existuje několik metod na objevování exoplanet [5], zde jsou uvedeny nejznámější a nejpoužívanější:
Dopplerova spektroskopie (Doppler spectroscopy)
Hvězdy se nepatrně pohybují díky gravitačním vlivům okolních planet, tato metoda je schopná tyto nepatrné pohyby zachytit díky Dopplerovu jevu. Tato metoda byla zatím v hledání nejúspěšnější a je schopna objevit masivní planety okolo hvězd. Detekce planet, které nejsou v těsné blízkosti hvězdy, je s touto metodou složitější a vyžaduje i roky sledování. Tato metoda se často používá jako potvrzení objevu planety při použití tranzitní metody.
Přechodová metoda (Transit)
Tato metoda je založená na sledování poklesů světelnosti dané hvězdy, tj. moment, kdy planeta přechází přes pozorovanou hvězdu ze strany pozorovatele. Tato metoda je schopná objevit jen planety, které mají orbity vyrovnané v úhlu, ze kterého je pozorovatel sleduje a také jsou u ní problémy s potvrzováním nálezů, které se často musí vyřešit aplikací jiné metody. Tato metoda je využívána vesmírnou observatoří Kepler.
Gravitační mikročočkování (Gravitational microlensing)
Tato metoda využívá gravitačního pole jedné hvězdy jako čočku, která zesiluje světlo hvězdy v pozadí (potřebuje tedy dvě hvězdy – většinou se používá k objevování planet ve směru k centru galaxie díky vyšší přítomnosti hvězd v pozadí). Pokud je v systému, kde gravitační pole hvězdy slouží jako čočka, planeta s gravitačním polem, do zesílení se zapojuje také a ovlivňuje sílu celkového zesílení světla hvězdy v pozadí.
Přímé pozorování (Direct imaging)
Planety jsou povětšinou velmi slabými zdroji světla a většinou se ztrácejí ve světle hvězdy, nicméně je možné v určitých případech se současnou technikou objevovat gigantické planety (spíše větší než Jupiter) i pomocí přímého pozorování.
Existují i další metody, které například využívají faktu, že hvězda v systému je ve skutečnosti pulsar (neutronová hvězda, která vysílá pravidelné rádiové signály) a nebo se například měří přesné pozice hvězdy na obloze a zkoumá se, jak moc je ovlivňována potenciálními planetami orbita hvězdy okolo těžiště celého systému.
Velikost a pozice zóny
Velikost a pozice zóny [6] se odvíjí od typu hvězdy. Nicméně obyvatelná zóna má vždy dvě hranice (vnitřní – ri a vnější – ro). Vnitřní hranice je hranice mezi příliš horkou a obyvatelnou, vnější je pak mezi obyvatelnou a chladnou zónou. Tyto hranice se mohou lišit dle aplikovaného modelu pro výpočet – druh modelu pak odpovídá síle skleníkového efektu, který určuje, jak moc je planeta sama o sobě schopná držet střední teplotu. Systémy tedy můžou mít planety, které jsou již velmi horké za planetami, které mají silný skleníkový efekt a jsou stále schopny podporovat život tak, jak jej známe.
ri=[ris−ai(Teff−Ts)−bi(Teff−Ts)2]
√
L ro=[ros−ao(Teff−Ts)−bo(Teff−Ts)2]√
L ris je vnitřní limit daného modelu síly skleníkového efektu ros je vnější limit daného modelu síly skleníkového efektu Teff je povrchová teplota dané hvězdyTs je rovna 5700 K
L je zářivý výkon v jednotkách zářivého výkonu slunce ai, bi, ao, bo jsou konstanty
Řešení obyvatelnosti těles uvnitř zóny
Pokud jsou známé hranice [7] pro zadaný model skleníkového efektu, je možné použít výpočet hodnoty HZD, která rozšiřuje základní ano / ne logiku do více vrstev tím, že svou hodnotou vyjádří relativní vzdálenost od středu obyvatelné zóny (HZD = 0).
HZD=2r−r0−ri r0−ri
r je vzdálenost tělesa od hvězdy v AU (astronomická jednotka) ro vnější hranice obyvatelné zóny
ri vnitřní hranice obyvatelné zóny
Výsledek HZD je v jednotkách HZU (pozor, není to skutečná vzdálenost).
Zde se aplikuje následovné:
Jestliže je HZD < -1, pak se dané těleso nachází v příliš horké zóně (Hot zone).
Jestliže je HZD > 1, pak se dané těleso nachází v příliš chladné zóně (Cold zone).
Jestliže je HZD mezi -1 a 1, pak se těleso nachází v obyvatelné zóně (Warm) a mohlo by podporovat život tak, jak jej známe.
HZD mezi -1 a 1 nám pak napovídá, v jaké části obyvatelné zóny se těleso nachází a dle této hodnoty je tedy možné určit jeho přesnější charakteristiky (více v kapitole 2.2.2 – „Třída
obyvatelnosti“).
Pozn.: Hodnota HZD se počítá až ve fázi vytvoření tělesa a doplnění potřebných informací pro výpočet této hodnoty.
Přítomnost obyvatelné zóny
Tento parametr je nutný v případě extrémních případů hvězd (spektrální třídy O a B), u kterých nejsou zatím výpočty obyvatelných zón funkční (poskytují nekompatibilní hodnoty).
Tento parametr simulace přebírá jako jednoduché ano / ne pro existenci obyvatelné zóny okolo dané hvězdy.
Aktivní parametry Pozice
V současné verzi je hvězda definovaná jako střed systému a simulace její pozici nadále neřeší, ačkoliv v reálných situacích dochází k nepatrnému pohybu (po orbitě okolo těžiště) díky vlivům okolních planet (jedna z reálných metod k objevování exoplanet se právě zakládá na tomto pohybu). To se ale v dalších verzích změní, hlavně díky implementaci vícehvězdných systémů.
Pozice se nicméně mění i nyní, ale pouze vizuální (o tom ale později (5.6), v simulaci je stále ve středu daného systému).
2.2.2 Planety a měsíce
Pasivní parametryPozice v systému
Je celočíselná informace, kterou simulace považuje jako pozici planety v planetárním systému či v lokálním systému měsíců pozici měsíce okolo planety.
Třída velikosti
Určuje slovně velikostní třídu planety nebo měsíce.
Simulace přijímá 7 typů (od nejmenší po největší):
– Asteroidan (planety, měsíce) – Mercurian (planety, měsíce) – SubTerran (planety)
– Terran (planety) – SuperTerran (planety) – Neptunian (planety) – Jovian (planety)
Třída velikosti je klíčová pro simulaci daného tělesa a odráží se v mnoha dalších parametrech (hmotnost, poloměr, přítomnost atmosféry,..).
Třída složení
Určuje, z jakých základních látek je planeta nebo měsíc složen. Každá třída velikosti má přiřazený určitý kompoziční typ podle své velikosti.
Simulace přijímá 4 typy:
– rocky-iron (Asteroidan, Mercurian, SubTerran, Terran, SuperTerran) – rocky-water (Asteroidan, Mercurian, SubTerran, Terran, SuperTerran)
– water-gas (Neptunian) – gas (Jovian)
Větší tělesa jsou plynná, menší tělesa jsou pevná.
Třída atmosféry
S velikostí se odvíjí mohutnost atmosféry, zatímco menší tělesa nejsou schopna si udržet atmosféru, gigantické planety jsou zase jen prakticky tvořeny atmosférou.
Simulace přijímá 3 typy:
– no-atmosphere (těleso nemá atmosféru, například díky malé velikosti) – metals-rich (atmosféra s prvky, které mají atomové číslo vyšší nežli hélium) – hydrogen-rich (atmosféra plynných planet)
Hmotnost
Tento údaj simulace zpracovává jako desetinné číslo v jednotkách hmotnosti Země (1 odpovídá hmotnosti Země). Pro reálnou hodnotu se tento údaj musí vynásobit hmotností Země, která se rovná přibližně 5,9722 × 1024 kg.
Poloměr
Tento údaj simulace zpracovává jako desetinné číslo v jednotkách poloměru Země (1 odpovídá poloměru Země). Pro reálnou hodnotu se tento údaj musí vynásobit poloměrem Země, který se rovná přibližně 6 378 000 metrů.
Následující tabulka ukazuje hodnoty výše zmíněných parametrů pro každou podporovanou velikostní třídu tělesa. Tyto hodnoty jsou taktéž využívány při náhodném generování těchto parametrů. Hodnoty pocházejí z [8].
Tabulka 2: Intervaly parametrů pro jednotlivé velikosti těles Třída velikosti
Asteroidan Mercurian SubTerran Terran SuperTerran Neptunian Jovian Třída složení rocky-iron,
rocky-water
rocky-iron, rocky-water
rocky-iron, rocky-water
rocky-iron, rocky-water
rocky-iron,
rocky-water water-gas, gas gas
Třída
atmosféry no-atmosphere no-atmosphere,
metals-rich metals-rich metals-rich metals-rich hydrogen-rich hydrogen-rich
Hmotnost (EU) (0,000001;
0,00001) (0,00001; 0,1) (0,1; 0,5) (0,5; 2) (2,0; 10) (10,0; 50) (50,0; 5000)
Poloměr (EU) (0,01; 0,03) (0,03; 0,7) (0,5; 1,2) (0,8; 1,9) (1,3; 3,3) (2,1; 5,7) (3,5; 27)
Síla skleníkového efektu
Tento parametr je nutný k výpočtu velikosti obyvatelné zóny, zmíněné výše (2.2.1 – „Obyvatelná zóna“). Udává sílu skleníkového efektu (pokud je přítomen) v atmosféře daného tělesa.
Na základě výpočtů k obyvatelné zóně [7] zde existují 3 základní modely (None – 0%, Medium – 50% a Strong – 100% pokrytí oblaky). Každé těleso pro simulaci má vybraný určitý model a dle toho se následovně zjistí hranice obyvatelné zóny a hodnota HZD, která určí, jak je dané těleso obyvatelné.
Teplotní třída
Teplotní třída je vázána na výpočet HZD (2.2.1 – „Obyvatelná zóna“ > „Řešení obyvatelnosti těles uvnitř zóny“ ). Zde existují tři varianty, které simulace přijímá:
– Hot (příliš horká zóna), kde pro těleso je HZD < -1 – Warm (obyvatelná zóna), kde HZD je mezi -1 a 1 – Cold (příliš chladná zóna), kde pro těleso je HZD > 1 Teplotně-obyvatelnostní třída
Teplotně-obyvatelnostní třída popisuje těleso dle potenciálních teplotních podmínek na jeho povrchu. Tento parametr se také váže na hodnotu HZD.
– non-habitable - planeta / měsíc je neobyvatelný – hyperthermoplanet - velmi horký povrch (> 100°C) – thermoplanet - horký povrch
– mesoplanet - planeta má velmi blízko teplotním charakteristikám Zemi / je Země (střední teplota, 0-50°C)
– psychroplanet - chladný povrch
– hypopsychroplanet - velmi chladný povrch (< -50°C) S těmito možnými variantami simulace pracuje následovně:
Tabulka 3: Závislost teplotně-obyvatelnostní třídy na hodnotě HZD
HZD (Habitable Zone Distance) [HZU, (Habitable Zone Unit)]
< -1,0 >= -1,0 & < -0,75 >= -0,75 & < -0,25 >= -0,25 & <= 0,25 <= 0,25 & > 0,55 <= 1,0 & > 0,75 > 1,0
non-habitable hyperthermoplanet thermoplanet mesoplanet psychroplanet hypopsychroplanet non-habitable
Standartní gravitační parametr
Význam je stejný jako u gravitačního parametru hvězdy vyjma nahrazení hmotnosti hvězdy za hmotnost planety. Tento parametr pak slouží k výpočtu orbitálních period těles, obíhajících danou planetu.
Rektascenze a deklinace severního pólu planety
Jsou parametry, které ve sférických souřadnicích udávájí směr (rotační osu), mířící k severní pólu planety.
Rotační perioda
Je parametr, který udává, za jak dlouho (ve dnech) se těleso otočí okolo své rotační osy.
Simulace tento parametr přijímá jako desetinné číslo s jednotkou dnů. Pokud bude hodnota 0, rotace bude synchronní (stejná jako orbitální perioda tělesa).
Počet a seznam měsíců
Tento parametr se týká pouze planet a slouží k udržování informací o počtu měsíců a jejich seznamu.
Aktivní parametry
Převzaté z charakteristik orbit (2.2.3).
Měsíce mají velmi podobné parametry jako planety, nicméně výběr v některých parametrech je menší (aby to vskutku odpovídalo tělesu měsíce). Za zmínku asi stojí, že pro měsíce simulace potřebuje vědět, okolo jaké planety orbituje, kolikátý je v pořadí a že pro jeho orbitu je vlastně hvězda ve skutečnosti planeta s určitým gravitační parametrem.
2.2.3 Charakteristika keplerovské orbity
První Keplerův zákon říká, že planety obíhají kolem Slunce po eliptických drahách, v jejichž jednom společném ohnisku je Slunce. Z toho lze odvodit, že značné množství parametrů pro keplerovskou orbitu se bude týkat definice elipsy jako takové.
Pasivní parametry Základní rovina systému
Za základní rovinu systému simulace považuje rovinu kolmou k severnímu pólu hvězdy, který v každém simulovaném systému směřuje vždy přesně nahoru (90° deklinace, 0° rektascenze).
Apoapsida (A)
Je bod, ve kterém je dané těleso nejdále od ohniska (například hvězdy).
A=a (1+e )
Simulace přebírá tento parametr jako desetinné číslo v jednotkách AU.
Periapsida (P)
Je bod, ve kterém je dané těleso nejblíže k ohnisku (například ke hvězdě).
A=a (1−e )
Simulace přebírá tento parametr jako desetinné číslo v jednotkách AU.
Hlavní poloosa (a)
Hlavní poloosa je hlavní poloosa orbitální elipsy. Je to vzdálenost od geometrického středu elipsy do bodu Apoapsidy či Periasidy.
Simulace přebírá tento parametr jako desetinné číslo v jednotkách AU.
Vedlejší poloosa (b)
Vedlejší poloosa je malá poloosa orbitální elipsy. Je to vzdálenost od geometrického středu elipsy do bodu equinoxu (jarní nebo podzimní bod).
b=a
√
(1−e2)Simulace přebírá tento parametr jako desetinné číslo v jednotkách AU.
Excentricita (e)
Je parametr orbity, který vyjadřuje míru její kruhovosti.
Simulace přebírá tento parametr jako desetinné číslo pouze v intervalu (0; 1).
Simulace nepodporuje hodnotu excentricity 0, protože ideální kruhová orbita neexistuje a rovněž nepodporuje hodnotu excentricity rovno 1 (parabolická orbita) či větší 1 (hyperbolická orbita).
Na ilustraci 3 můžete nahlédnout na vliv hodnoty excentricity na povahu dráhy.
Na ilustraci 4 je pak vyobrazená kompletní orbitální dráha se všemi (již zmíněnými výše) základními parametry.
a je hlavní poloosa b je vedlejší poloosa e je excentricita A je Apoapsida P je Periapsida
Refereční směr ( )♈
Je výsledek vektorového součinu dvou vektorů v rovině, kde směřuje severní pól tělesa.
Ilustrace 4: Základní parametry, definující velikost a tvar orbity [10]
Ilustrace 3: Vliv hodnoty excentricity na povahu orbity [9]
Výsledný vektor pak směřuje k bodu equinoxu.
Simulace tento parametr přijímá jako trojrozměrný vektor.
Délka vzestupného uzlu (Ω)
Je to úhel od referenčního směru k vzestupnému uzlu orbity.
Simulace přebírá tento parametr jako desetinné číslo ve stupních.
Inklinace (i)
Je to úhel, udávající sklon dráhy od základní roviny systému.
Simulace přebírá tento parametr jako desetinné číslo ve stupních.
Argument periapsidy (ω)
Je to úhel od vzestupného uzlu k periapsidě dané orbity.
Simulace přebírá tento parametr jako desetinné číslo ve stupních.
Ilustrace 5 zobrazuje všechny pokročilé parametry, definující polohu orbitální dráhy.
Doba oběhu
Udává dobu oběhu tělesa (v sekundách) po své elipticté dráze. Doba oběhu je nutná k výpočtům přesného času dalšího průchodu periapsidem.
T =2 π
√
(aµ3)a je hlavní poloosa v jednotkách AU
µ je standartní gravitační parametr hmotnějšího tělesa
Hmotnější těleso ze vztahu – pro planety je to hvězda, pro měsíce je to pak planeta.
Ilustrace 5: Pokročilé parametry, definující polohu orbity [11]
Aktivní parametry
Čas průchodu periapsidem
Tato hodnota patří mezi nejdůležitější informaci pro správnou funkci simulace pohybu na keplerovské orbitě. Simulace musí vědět, kdy planeta tímto bodem prošla a kdy bude další průchod, aby mohla korektně spočítat pozici tělesa na orbitální dráze v daném lokálním čase.
Součástí tohoto času je i odpovídající datum a toto vše se následovně převádí na juliánské datum (jedno velké číslo), se kterým pracují výpočty, popsané níže.
Převod na juliánské datum se provádí pomocí těchto kroků [12]:
1) Předpokládejme, že máme informaci o datu a čase (d.y, d.m, d.d, d.h, d.m, d.s)
2) pokud jsou d.m větší než 2, odečteme od nich 3, pokud ne, přičteme k nim 9 a od d.y odečteme 1
3) následně vypočítáme 3 meziproměnné:
c = d.y / 100;
ya = d.y - 100 * c;
j = (146097 * c) / 4 + (1461 * ya) / 4 + (153 * d.m + 2) / 5 + d.d + 1721119;
(dělení jsou celočíselná)
4) finální juliánské datum (JD) získáme pomocí
JD = j + ((d.h - 12) / 24.0) + (d.m / 1440.0) + (d.s / 86400.0);
(zde jsou dělení už v reálných číslech) Pozice (x,y)
Výpočet 2D koordinátů [30] pozice tělesa na jeho orbitě probíhá tímto způsobem:
1) Vypočítá se střední denní pohyb pomocí:
mM =2 π op op je doba oběhu tělesa ve dnech
2) Vypočítá se střední anomálie pomocí:
mA=mM (t−T0) mM je střední denní pohyb (1)
t aktuální čas, převedený do JD
T0 poslední čas průchodu periapsidou, převedený do JD 3) Vypočítá se excentrická anomálie pomocí Keplerovy rovnice:
eA=mA+e sin (E0) mA je střední anomálie (2)
e je excentricita
E0 je střední anomálie (2)
4) Vypočítá se kosinus a sinus pravé anomálie pomocí:
cos(v )= cos(eA)−e 1−e cos(eA)
sin(v)=
√
1−e2sin (eA)1−e cos(eA) eA je excentrická anomálie (3)
e je excentricita
5) Vypočítá se vzdálenost tělesa od ohniska (r) pomocí:
r =a∗((1−e)(e+cos(v )) e cos(v )+1 ) a je hlavní poloosa
e je excentricita
cos(v) je kosinus pravé anomálie (4) 6) Vypočítají se souřadnice x a y pomocí:
x=r cos(v ) y=r sin (v ) r je vzdálenost tělesa od ohniska (5)
cos(v), sin(v) je kosinus a sinus pravé anomálie (4)
Anomálie značí úhly, přičemž nejdůležitějším úhlem je pak pravá anomálie, která vyznačuje úhel mezi spojnicí tělesa a hvězdy a úsečkou k periapsidě. Excentrická anomálie značí úhel, který svírá spojnice z geometrického středu elipsy do bodu, kde by planeta byla, kdyby její orbita byla kruhová, s úsečkou k periapsidě. Střední anomálie je pak obdobný úhel jako excentrická anomálie až na to, že zde by spojnice z geometrického středu elipsy (kružnice) spojovala bod na kružnici, ve kterém by planeta byla, kdyby měla konstantní rychlost pohybu se stejnou dobou oběhu, jako má na elipse.
2.3 Charakteristiky pro vizualizaci
Vizualizace těží převážně z prvků potřebných pro simulaci. Nicméně se samozřejmě dají shrnout informace, které jsou klíčové pro finální vizualizaci jednotlivých těles v planetárním systému:
– Nejdůležitějším parametrem je pozice, která udává pozici tělesa v 3D prostoru.
– Poloměr tělesa, který se pak promítá do velikosti modelu.
– Velikostní a obyvatelnostní parametr tělesa, který se promítá do použité textury.
– Informace o přítomnosti atmosféry a síle skleníkového efektu rovněž ovlivňují finální vzhled tělesa.
Popis těchto parametrů / charakteristik je víc než povrchový, pro podrobnější detaily o realizaci vizualizace nahlédněte do sekce s řešením (5.5).
2.4 Generování náhodných planetárních systémů
Ze zadání vyplývá, že aplikace by měla být schopna reprezentovat a simulovat uživatelem definované systémy, náš solární systém, ale také i náhodně generované systémy.
Generátor musí před generováním vědět jaké hodnoty a v jakých mezích se má pro dané těleso pohybovat. Tyto intervaly byly již většinou stanoveny při analýze parametrů /
charakteristik jednotlivých základních těles (hvězda, planeta, měsíc).
Generátor by neměl generovat nesmyslné případy (zde ale nemohu zaručit, že generovaný systém bude vždy v takovém stavu, ve kterém by mohl existovat i v reálné situaci), proto bylo zavedeno pár hlavních pravidel:
Generátor musí začít s generováním hvězdy, protože na hvězde závisí celý planetární systém.
Typ generované hvězdy se odvíjí od míry přítomnosti typů hvězd v okolí naší planety (viz.
procentuální výskyt v 2.2.1 – „Spektrální třída“).
Po vygenerování náhodné hvězdy nastává další důležitá část, kde generátor musí začít s generováním jednotlivých planet. Zde se řídí dle vygenerované velikosti a dle toho náležitě rozhoduje o vzdálenostech mezi jednotlivými planetami (např. plynoví obři budou mít daleko více prostoru okolo sebe než menší planety).
Po vygenerování planety generátor musí taky zastavit a dle velikosti současné planety rozhodnout, zda je možné, aby okolo této planety existovaly měsíce. Simulace by se měla primárně zaobírat pouze důležitějšími a výraznějšími měsíci (protože hlavně pak plynoví obři se svou dominatní pozicí v systému mohou přitahovat miliony těles a to je jen těžko simulovatelné).
Tabulka 4: Intervaly počtu měsíců na každou velikostní třídu, které generátor využívá
Asteroidan Mercurian SubTerran Terran SuperTerran Neptunian Jovian
Počet měsíců 0 (0; 2) (0; 2) (0; 4) (1; 5) (5; 15) (10; 22)
Tabulka ukazuje pouze minima a maxima. Samotný generovací algoritmus pracuje s rozdílnějšími podintervaly a druhy šancí, přičemž např. u třídy Mercurian je sice interval 0 až 2, nicméně v drtivé většině je tento počet vždy 0.
Pro více informací o postupech při generování nahlédněte do přílohy číslo 3 či do sekce 4.2.3 – „Aurora.staticRMethods“.
2.5 Načítání reálných dat o exoplanetách
Další velmi významnou funkcí aplikace je schopnost zpracovávat doposud zvěřejněná data o nálezech exoplanet (více v 2.2.1 – „Obyvatelná zóna“). Tyto informace jsou spravovány laboratoří planetární obyvatelnosti (PHL), sídlící pod záštitou univerzity v Portoriku v Arecibu [28]. Laboratoř se stará o komplexní katalog exoplanet a výzkum spojený s exoplanetami (teorie okolo obyvatelné zóny). Jejich databází neustále aktualizuje dle jejich nejnovějších poznatků a celkově se snaží přiblížit cíli, který snad každý lovec exoplanet chce dosáhnout - najít exoplanetu, která bude mít prakticky identické charakteristiky jako naše Země.
Tato data jsou veřejně dostupná a je povolené je využívat pro účely výzkumu a vizualizace.
Data obsahují exoplanety, které byly doposud objeveny nejrůznějšími metodami z nejrůznějších míst na Zemi (observatoře), ale také i mimo Zemi (družice Kepler).
Na těchto datech byla provedena analýza, zda obsahují dostatečně mnoho parametrů, které umožní simulaci a vizualizaci. K dispozici jsou 4 hlavní databáze, přičemž analýzou dat prošly pouze 3 (ve čtvrté – nepotvrzené exoplanety – bylo až příliš chybějích informací). Je nutné ještě dodat, že současné metody, použité k získávání těchto dat, neumožňují zisk úplně všech informací o daných tělesech a tím pádem mohou vypadat ve výsledné vizualizaci „méně zajímavě“ než např. náhodně vygenerovaný systém. Toto se hlavně projevuje u pokročilých parametrů orbitálních drah, které jsou nulové (aplikace je sice umí dogenerovat, ale finální rozhodnutí bylo nechat je nulové).
Podporované databáze tedy jsou:
1) Potvrzené exoplanety (soubor phl_hec_all_confirmed.csv), 677 planetárních systémů alespoň s 1 nebo více exoplanetami
2) NASA Kepler kandidáti (soubor phl_hec_all_kepler.csv), 2 013 planetárních systémů alespoň s 1 nebo více exoplanetami
3) NASA Kepler TCE (soubor phl_hec_all_tce.csv), 9 550 planetárních systémů alespoň s 1 nebo více exoplanemati
Data jsou aktuální k únoru 2013.
S těmito funkcemi je aplikace schopná reprezentovat 12 240 objevených systémů, náš solární systém a pak skoro nekonečný počet náhodných planetárních systémů.
3 Řešení problematiky
3.1 Použité programovací jazyky a software
Ze zadání vyplývá, že pro tvorbu samotného jádra by mělo být využito jazyka C#, pro simulační a vizualizační jádro by pak mělo být využito herního enginu Unity3D (http://unity3d.com/). Unity3D je herní engine s vlastním vývojovým prostředím a je vyvíjený společností Unity Technologies. Je k dispozici veřejnosti ve dvou verzích – free a pro (placená).
Pro vývoj této aplikace byla zvolena verze free, která sice nedisponuje některými pokročilými grafickými efekty a rovněž neumožňuje kompilace pro mobilní platformy (iOS, Android) nebo také konzole. Nicméně je zadarmo a její funkce pro tuto aplikaci jsou nanejvýše dostačující. Pro vývoj a kompilaci byla použita nejnovější veřejná verze, v době finalizace to byla Unity 4.1.
Jádro, odpovědné za reprezentaci a správu dat o planetárních systémech, bylo napsáno v jazyce C# a za pomoci vývojového prostředí Visual Studio 2008.
Simulační a vizualizační jádro bylo pak napsáno rovněž v jazyce C# a díky skvělé podpoře externích aplikací na psaní skriptů pro Unity bylo také napsáno ve Visual Studio 2008.
Pro účely vizualizace bylo také použito jazyku ShaderLab, který je základním skriptovacím jazykem pro tvorbu shaderů v Unity3D. Ten se použil na některé modifikace existujících či přidání nových shaderů, použitých pro finální vizualizaci.
Mezi klíčovými externími programy je pak třeba zmínit program pro tvorbu 3D modelů pro vizualizaci – Blender a také pro tvorbu a úpravy textur – Photoshop.
3.2 Cílové platformy
Ačkoliv Unity3D podporuje multiplatformní kompilaci projektů, díky volné licenci jsou zde povoleny pouze možnosti kompilace pro internetové prohlížeče (vyžaduje nainstalovaný doplněk unity player) a pak standalone pro Win/Mac OS/Linux.
Díky relativní komplexnosti a velikosti dat, které aplikace nabyla (i s Unity3D komprimací se velikost pohybuje okolo 2GB), bylo nutné ustoupit od plánů plně podporovat funkci aplikace v internetovém prohlížeči.
Ve finálních kompilacích Aurora existuje ve dvou variantách - Lite a Full.
– Lite verze (odlehčená verze) běží uvnitř internetového prohlížeče a nabízí limitované funkce, soustředěné pouze pro simulaci našeho solárního systému (značně se redukovala velikost potřebných dat pro vizualizaci – provozuschopné v internetovém prohlížeči díky malé velikosti stahovaných souborů – přibližně 30MB).
– Full verze (plná verze) je samostatná aplikace, která podporuje platformu Windows (x86 či x64) a nabízí všechny funkce (tato verze je standardně zkomprimovaná pomocí programu 7z a spustitelná verze zabírá na disku přibližně 2GB).
3.3 Rozdělení problému do dvou hlavních projektových částí
V průběhu realizace aplikace a testování funkčnosti enginu Unity3D začalo být patrné, jakým způsobem budou rozloženy funkce jednotlivých částí aplikace. Objektová reprezentace, která byla vytvořena v jazyce C#, musela být napojena (hlavně co se týče výkonových a funkčních důvodů) na Unity3D engine pomocí knihovny dll. Díky podpoře jazyka C# není problém pro Unity3D tuto knihovnu využívat, jak při vývoji, tak v ostré verzi.
3.3.1 Aurora (Aurora.dll) (jmenný prostor Aurora)
ObsahObsahuje třídy, které jsou schopny vyjádřit planetární systémy, a také doplňkové funkce (např. načítání ze souborů, ukládání systémů, konstanty,..).
Funkce
Vyjadřuje a spravuje data o planetárním systému a jeho tělesech. V odpovídajících objektech jsou také ukládány dynamické atributy pro simulaci. Stará se o přesun všech důležitých reprezentačních parametrů do souboru (aby bylo možné opětovně načítat) a také je odpovědná za načítání veřejných databází exoplanet.
3.3.2 AuroraVE (Unity3D) (jmenný prostor AuroraVE)
ObsahObsahuje třídy, které jsou (v naprosté většině) odvozeny z Unity3D MonoBehaviour třídy a
„nalepené“ na herní objekty v enginu (hvězdy, planety, měsíce,..), které se následovně instancují dle vstupního planetárního systému.
Funkce
Spravuje herní objekty a převážnou část simulace a vizualizace pohybu. Řídí rychlost simulace, aktuální čas. Instancuje důležité herní objekty (planety,..) a jejich funkční doplňky (atmosféra, oblaka,..). Dynamicky přiřazuje materiály s patřičnými shadery a texturami. Stará se o vykreslení grafického uživatelského rozhraní a spravuje uživatelské vstupy.
4 Objektová reprezentace (jmenný prostor Aurora, dll)
4.1 Návrh objektové reprezentace systémů a diagram tříd
Reprezentace planetárního systému si přímo žádá o využití objektového programování. Návrh objektů probíhal v několika fázích. V prvotní fázi se vytvořily základní objekty pro systém, pro hvězdy, pro planety a měsíce. V průběhu vývoje se pak začaly jednotlivé části již vytvořených tříd oddělovat, aby došlo k větší centralizaci kódu a omezila se celkem zbytečná redundance.
Tento krok například postihl parametry pro keplerovskou orbitu (třída Aurora.KeplerianOrbit),
popis tělesa (Aurora.celestialType) či také parametry hvězdy
(Aurora.celestialTypes.starType). V průběhu vývoje se využívaly nejrůznější metody, na kterých bylo závislých více tříd najednou. Řešením tohoto problému bylo vytvoření tříd Aurora.staticMethods a Aurora.staticRMethods (R = Random – metody zaměřující se na generování).
Samotný detailní diagram tříd pak najdete v příloze 1.
4.2 Popis všech částí a jejich funkcí v Aurora.dll 4.2.1 Základní poznámky
Vstupy od uživatele či vstupní parametry tříd počítají obvykle se stupni, které se automaticky převádí pomocí Aurora.staticMethods.degress2radians metody, a v interních výpočtech se pak pracuje pouze v radiánech.
Metody get a set (pro navrácení a nastavení atributů tříd) byly vytvořeny jen tam, kde to bylo vyžadováno v kódu a některé get a set metody rovněž podporují více možností (např. navrácení v radiánech či stupních, v hodinách či sekundách,..).
4.2.2 Dynamické třídy
Aurora.solarSystemJe veřejná třída, jejíž konstruktor je úplně první kód, který se při obvyklém postupu volá. Tato třída ukládá informace o planetárním systému. Interní proměnné obsahují odkazy seznamy objektů planet (Aurora.Planet) a hvězd (Aurora.Star). Zde by bylo vhodné říct, že současná verze aplikace podporuje pouze systém s jednou hvězdou, nicméně již nyní, jak stavba objektů, tak např. i práce s xml formátem, pro ukládání dat o systému (4.2.3 – „Aurora.DataMethods“), počítají se systémy, které mohou mít více hvězd.
Pro tuto třídu existuje několik konstruktorů. Hlavním je konstruktor (#1), který je určen pro kompletní nagenerování planetárního systému, včetně jeho názvu, který se v tomto případě řídí dle vygenerovaného názvu hvězdy. Další dva jsou přetížené, prvním přetíženým je konstruktor (#2), který přijímá uživatelsky definovaný název systému a uživatelsky definovanou třídu hvězdy a druhým přetíženým pak je konstruktor (#3), který je prakticky stejný jako druhý
Ilustrace 6: Zjednodušená struktura jmenného prostoru Aurora
přetížený, akorát místo třídy hvězdy přijímá seznam hvězd (datový typ List<Aurora.Star>).
#1 pro kompletně náhodný planetární systém public solarSystem()
#2 pro uživatelsky definované jméno a hvězdu
public solarSystem(string starSystemName, Aurora.Star star) [string] starSystemName – název systému
[Aurora.Star] star – předvytvořená třída hvězdy
#3 pro uživatelsky definované jméno a více hvězd
public solarSystem(string starSystemName, List<Aurora.Star> stars) [string] starSystemName – název systému
[List<Aurora.Star>] stars – předvytvořený seznam hvězd
Pokud se bude jednat o případ konstruktoru #1, pak se po inicializaci konstruktoru rovněž spustí interní metoda zvaná planetInit, která se stará o postupnou tvorbu tříd Aurora.Planet pro jednotlivé planety a o následné přidání do interního seznamu. Počet planet odpovídá předem inicializovanému počtu planet, který je vygenerován pomocí metody Aurora.staticRMethods.generatePlanetCount.
Třída má vytvořené metody get a set pro své privátní členské proměnné, mimo jiné i get a set metody pro planety v interním seznamu, který je datového typu List<Aurora.Planet>. Objekty planet v tomto seznamu se udržují seřazené dle vzdálenosti od hvězdy a po jakémkoliv přidání (použití metody addPlanet, addPlanets, setPlanet, removePlanet) se aplikuje na tento seznam jednoduché bublinkové řazení, které zkontroluje hlavní poloosy jednotlivých planet a dle tohoto parametru je v seznamu seřadí.
Třída taktéž disponuje metodou, která se stará o automatické debugování údajů do jednoduchého textového souboru. Tato debug metoda je v současné verzi prozatím stále zapnutá a všechny debug soubory najdete ve složce debug vedle hlavního spustitelného exe souboru.
Také třída díky funkci ukládání dat o planetárním systému na pevný disk udržuje aktuální informaci o aktuálním čase simulace. Jedná se o veřejnou proměnnou localTime, která je datového typu DateTime. Tento parametr aktualizuje samozřejmě až simulace, nicméně při startu a tvorbě třídy je použit čas DateTime.UtcNow.
Aurora.Star
Je veřejná třída, jejíž konstruktor je volán ihned po vytvoření samotné třídy Aurora.solarSystem. Je to nejdůležitější třída, která svými parametry, určuje povahu celého planetárního systému. Stavba třídy se odvíjela z počáteční analýzy parametrů a následujících programátorských potřeb.
Slouží pro uchovávání základních informací, jako je například jméno hvězdy, informace o typu (třída Aurora.celestialTypes.starType – obsahuje i všechny přesné parametry hvězdy) a také i informace o obyvatelné zóně.
Tato třída disponuje jedním hlavním konstruktorem (#1), který je určen pro kompletní nagenerování hvězdy a automatickou inicializaci jejích parametrů.
Dále zde ale existují i dva další přetížené konstruktory – první je konstruktor (#2), určený pro podobnou činnost jako první, nicméně s výjimkou použití uživatelsky definovaného názvu
hvězdy. V generovaných systémech je jméno hvězdy celkem klíčové, jelikož se dle toho poté řídí názvy těles v systému. Vygenerované planety se automaticky pojmenují <název hvězdy>
<pořadí, vyjádřené římskou číslicí>. Vygenerované měsíce pak budou mít formát <název hvězdy> <pořadí planety, vyjádřené římskou číslicí> – Moon <pořadí měsíce, vyjádřené arabskou číslicí>.
Druhým přetíženým konstruktorem (#3) je konstruktor, určený pro manuální inicializaci dané hvězdy.
#1 pro kompletně náhodnou hvězdu public Star()
#2 pro uživatelsky pojmenovanou náhodnou hvězdu public Star(string starName)
[string] název hvězdy
#3 pro uživatelsky definovanou hvězdu
public Star(string starName, double distanceFromEarth, string spectralClass, double starLumi, double starTemp, double starMass, double starRadius, double starAge)
[string] starName – název hvězdy
[double] distanceFromEarth – Vzdálenost od Země – (v jedn. parsec – 0 pokud fiktivní) [string] spectralClass – spektrální třída hvězdy (O – B – A – F – G – K – M)
[double] starLumi – luminosita hvězdy (jednotky luminosity Slunce) [double] starTemp – povrchová teplota hvězdy (Kelvin)
[double] starMass – hmotnost hvězdy (jednotky hmotnosti Slunce) [double] starRadius – poloměr hvězdy (jednotky poloměru Slunce)
[double] starAge – střední věk hvězdy (miliony let)
V každém konstruktoru se po převzetí všech parametrů a vytvoření interní třídy typu Aurora.celestialTypes.starType spočítá standartní gravitační parametr.
Spustí se také interní metoda s názvem hzInit. Tato interní metoda má za úkol inicializovat parametry obyvatelné zóny (2.2.2 – „Obyvatelná zóna“) okolo této hvězdy. hzInit prvně zkontroluje spektrální třídy hvězdy a pokud zjistí, že je typu O nebo B, automaticky přestane obyvatelnou zónu počítat (více informací v 2.2.1 – „Obyvatelná zóna“) a nastaví veřejný parametr datového typu bool habZonePresent (na ano / ne přítomnost obyvatelné zóny) na false.
Pokud spektrální třída bude vyhovovat, atribut habZonePresent se nastaví na true a metoda hzInit bude pokračovat na inicializaci základních hranic obyvatelné zóny.
Hranice obyvatelné zóny se ale mohou lišit dle použitého modelu síly skleníkového efektu na daném tělese a může tedy značně změnit teplotní charakteristiku daného tělesa. Proto základní hranice, vypočítané metodou hzInit, nejsou až tak určující a daleko důležitější je pak použití metody calculateHZD (výpočet hodnoty HZD) v kombinaci s getHabZoneInnerOffset (návrat vnitřní hranice obyvatelné zóny s daným modelem skleníkového efektu) a getHabZoneOuterOffset (návrat vnější hranice obyvatelné zóny s daným modelem skleníkového efektu).
Aurora.celestialTypes.starType
Je veřejná třída, která je využívána k centralizaci parametrů souvisejících s hvězdou. Tato třída se automaticky instacuje při tvorbě třídy Aurora.Star z parametrů, které jsou předány v daném konstruktoru nebo z automaticky generovaných, které jsou získány z interních metod.
Třída Aurora.celestialTypes.starType obsahuje parametry jako:
– spectralClass – spektrální třída – starMass – hmotnost hvězdy – starRadius – poloměr hvězdy
– starLumi – luminosita hvězdy (zářivý výkon) – starTemp – povrchová teplota hvězdy
– starColor – typická barva hvězdy – hydrogenLines – úroveň zásob vodíku – starAge – střední věk dané hvězdy
V této třídě existují dva typy konstruktorů, jeden je opět pro manuální předání a nastavení parametrů a druhý je pro automatické generování. Automatické generování parametrů se provádí dle interních generovacích metod, které se většinou pojí s nejdůležitějším parametrem hvězdy – spektrální třídou.
Pro každou hvězdu se spektrální třída vygeneruje ještě mimo tuto třídu pomocí Aurora.staticRMethods.generateStarSpectralClass, aby mohla pracovat přímo s danou spektrální třídou.
Aurora.Planet
Je veřejná třída, která je využívána pro reprezentaci tělesa s charakteristikami, které jsou podobné planetám. Tato třída má jeden nepřetížený (#1) a přetížený (#2) konstruktor.
#1 je určen pro tvorbu náhodné planety
public Planet(Aurora.solarSystem planetOrigin, int planetPos)
[Aurora.solarSystem] planetOrigin – již zmíněný odkaz na planetární systém, ve kterém se tato planeta nachází
[int] planetPos – uchovává pozici planety v systému
#2 je určen pro tvorbu uživatelsky definované planety
– tento konstruktor obsahuje značné množství parametrů, které jsou nutné pro tvorbu uživatelsky definovaného objektu (nebudou zde proto vypsány)
Pro konstruktor #1 platí takový postup:
– Nastaví interní ukazatel generatedPlanet na hodnotu true (protože se jedná o generovanou planetu).
– Asociuje tuto třídu planety s třídou Aurora.solarSystem a poté také převezme pořadové číslo planety.
– Vytvoří název planety pomocí <názvu hvězdy> <pořadí, převedeného na římskou číslici>.
– Inicializuje další privátní členské proměnné, jako je například směr severního pólu
ve sférických souřadnicích.
– Vygeneruje se náhodná třída Aurora.celestialType, která udává základní charakteristiky planety (velikost, složení,..).
– Spočítá dosavadní počet planet v asociované třídě Aurora.solarSystem a získá třídu Aurora.Planet poslední generované planety, pokud bude tato planeta první, použije se namísto hodnota null v následujícím kroku.
– Získaná třída typu Aurora.Planet se následně využije pro generování současné délky
hlavní poloosy. Při tomto kroku se využije metody
Aurora.staticRMethods.generateDistPlanets, která v závislosti na velikost předchozí planety nageneruje hodnotu vzdálenosti ze 4 možností malá-normální, malá-extrémní, velká-normální, velká-extrémní ("malé" vzdálenosti mají větší prioritu při generování).
Nutno dodat, že i slovo malé pro tyto vzdálenosti může být matoucí, jelikož tato metoda pracuje s velikostmi jednotlivých planet a jestliže například bude předchozí planeta plynový gigant a následná planeta velikosti planety Merkur, bude výstup z této metody i při "malé-normální" vzdálenosti celkem velké číslo, protože tato metoda respektuje dominantní pozice jednotlivých planet v systému a počítá s tím, že menší tělesa, které budou blíže, se mohou stát oběťmi (měsíci) velkých planet.
– Po získání pravé vzdálenosti od hvězdy se provede modifikace třídy Aurora.celestialType pomocí funkce staticMethods.modifyCelestialType, tato modifikace je nutná, protože Aurora.celestialType ukládá i obyvatelnostní a teplotní třídy, které jsou plně závislé na vzdálenosti od hvězdy.
– Na řadu přichází standartní gravitační parametr pro tuto planetu (později použit pro výpočet orbitálních period měsíců).
– S již známou vzdáleností (= hlavní poloosou planety) se může vytvořit i třída typu Aurora.KeplerianOrbit (4.2.2 – „Aurora.KeplerianOrbit“) pro tuto planetu.
– Konečně přijdou na řadu také inicializace aktivních atributů pro simulaci (poslední čas průchodu periapsidou a další průchod periapsidou), v případě konstruktoru #1 platí, že se vygeneruje čas průchodu náhodně mezi lokálním časem, zapsaným při startu tvorby třídy Aurora.solarSystem, a lokálním časem + spočítanou orbitální periodu. Po získání tohoto průchodu se ještě k tomuto času přičte doba orbitální periody a získá se tím také čas dalšího průchodu této planety periapsidou. Obě tyto veřejné proměnné (perihelionDT, nextPerihelionDT) pak aktivně využívá simulace a poslední průchodu periapsidou (perihelionDT) je rovněž nutné uložit, pokud je třeba simulaci později obnovit.
– Třída planety má také na starosti asociaci objektů měsíců (třídy typu Aurora.Moon, uložené v interním seznamu datového typu List<Aurora.Moon>), inicializaci měsíců spustí pomocí interní metody moonInit, která funguje obdobně, jako když se v Aurora.solarSystem přidávají nové planety do daného interního seznamu. Před samotným přidáním měsíců ale tato metoda ještě spustí metodu moonCount, která vrátí náhodný počet měsíců, který závisí na velikosti této planety. Může se klidně stát, že vrátí nulu a pak se ani žádný měsíc nepřidá. Více informací o počtech měsíců zde (2.4).
Pro konstruktor #2 je postup obdobný jako u konstruktoru #1, je ale důležité připomenout:
– Hodnoty se převezmou z parametrů konstruktoru.
– Aurora.celestialType a Aurora.KeplerianOrbit se manuálně vytvoří.
– Manuální tvorba planety také ovlivňuje obsah simulačních proměnných o průchodu periapsidou.
