Plynulost X-Plane ovlivňuje hlavně počet trojúhelníků a vrcholů v síti DSF (paměť grafické karty a doba načtení dlaždice) a u vegetace počet instancí (plocha × hustota). Každá úprava, která síť zahušťuje (vložení DEM, rozřezání sítě ortofotem B, vložené hrany, srovnání letiště), DSF zvětší.
Odhad výkonu ve Studiu
DSF › Přehled › Načíst statistiky – pod statistikami je Odhad výkonu v X-Plane: kategorie OK / Pozor / Hodně, odhad paměti grafické karty pro geometrii a doby načtení DSF.
V editoru ukazují náhledy úprav (vložení DEM, zjednodušení, Terén a voda včetně úpravy Vrcholy sítě, Pláže a ortofoto B) Dopad úpravy na výkon: počty před → po a změnu kategorie.
Editor › Kontrola – pod problémy je Odhad zátěže overlaye v X-Plane pro entity projektu (z uložené verze i neuložených změn): objekty, polygony (fasády a délka stěn, lesy a jejich plocha, potahy, linie, autogen), autogen (.ags / .agb s plochou a body .agp – X-Plane z nich rozvine další budovy, cena na kus změřená není), silnice a jejich délka, výjimky. U každého řádku je změna v % proti podkladové DSF projektu. Stromy (instance) = plocha × hustota / SPACING² z .for v knihovně X-Plane (u výplně čárou obvod / SPACING, u bodů strom na bod), s podílem proti změřeným referenčním dlaždicím +50+015; lesy bez známého SPACING se nezapočtou. Výjimky ubírají obsah podkladu – úspora se nepočítá. MB ani sekundy se bez změřeného zdroje neuvádějí.
Odhad je hrubý a opírá se o změřené dlaždice: DSF s 20,6 mil. trojúhelníků běžela v X-Plane plynule (ještě OK), DSF se 71,6 mil. trojúhelníků a 70,1 mil. vrcholů se načítala 195 s a přetekla paměť grafické karty (Hodně). Mezi tím je Pozor. U objektů a polygonů změřená cena na kus neexistuje, proto se ukazuje jen změna v procentech. Rozbalovací část Odkud čísla jsou (hrubý odhad) u každého odhadu vypíše zdroje.
Doporučení
Velké oblasti patří do generátoru. Studio je na místní úpravy. Jedna operace vložení DEM zpracuje nejvýš 100 km² (nad 40 km² Studio upozorní); pro větší území nebo když by přibyly miliony bodů je lepší dát data (DEM, OSM, ortofoto) do generátoru scenérie, např. RenderFarm, a dlaždici přegenerovat – generátor hlídá rozpočet bodů a správně zpracuje silnice, letiště a břehy.
Tolerance místo maxima. U vložení DEM a srovnání stačí obvykle svislá chyba kolem 0,2 m; menší tolerance přidá mnoho bodů s malým viditelným přínosem.
Přechody TRNS. Volba „zahodit“ u vložení DEM a zjednodušení výrazně ubere překryvové trojúhelníky (ortofoto B je pod fotkou odebírá samo); vzhled přechodu textur se tím ale mění – zkontrolujte v X-Plane.
Zjednodušení pomůže na moři a rovných plochách; body jen kvůli hranicím textur jdou ubrat jen málo.
Ortofoto: ZL volte podle skutečného rozlišení zdroje (Studio ho navrhne). Každá vyšší úroveň ZL je asi čtyřikrát víc dat. Drapované ortofoto (varianta A) se při testu načítalo na trojúhelník několikrát pomaleji než síť.
Hustotu ověřte v DSF › Hustota a detektorem vad (vějíře).
Výkon samotného Studia
Čtení hlavičky a statistiky celé DSF trvá i u 2GB souboru sekundy. 3D okno čte jen pooly v okně (do 0,05°).
Mezipaměť oken terénu DSF (složka dsf_okna v cache): rejstřík příkazů DSF, spočítaná okna terénu a mřížka dálky se ukládají na disk. Po novém spuštění Studia nebo při návratu kamery na stejné místo se nepočítají znovu: první okno nového místa ve 2GB DSF se ukáže asi za 1–2 s místo 4–11 s a už spočítané okno asi za 5–15 ms místo 0,3–1 s. Úplně první otevření nové nebo přepsané DSF se nezrychlí, naopak trvá o chvilku déle (mezipaměť se teprve plní a ukládá na disk). Když RenderFarm (nebo jiný program) DSF přepíše, Studio to pozná podle velikosti a času změny souboru, starou mezipaměť té DSF smaže a spočítá okna znovu. Složka má vlastní strop 5 GB (nejdéle nepoužité soubory se mažou samy); kolik zabírá, ukazuje Nastavení › Pracovní složka (výstupy a cache). Smazat ji můžete kdykoli (Studio neběží nebo nic nenačítá) – jen se pak okna znovu spočítají.
Souběžné načítání terénu: okna terénu, která ještě nejsou v mezipaměti, počítají pomocné procesy Studia – až 4 najednou, když běží RenderFarm nebo je málo volné paměti, jen 2 – a editor si o ně říká souběžně. Skok kamery na nové místo (9 oken) se tak ve 2GB DSF načte asi dvakrát rychleji než po jednom, např. za 1,7 s místo 3,6 s; první skok po spuštění Studia, kdy procesy teprve nabíhají, trvá asi 3–5 s. Procesy se spustí až s prvním oknem, které je potřeba spočítat (to se mezitím spočítá hned, bez čekání na ně), a po 10 minutách nečinnosti samy skončí. Každý drží v paměti rejstřík otevřené DSF (u 2GB DSF asi 80–190 MB, po 2 minutách nečinnosti ho uvolní), dohromady je to při práci asi 0,5–1,5 GB paměti navíc (2GB DSF Mauricia asi 0,5 GB, hustší DSF +50+015 asi 1,1–1,4 GB). Když se procesy nespustí nebo některý spadne, Studio spočítá okna bez nich (pomaleji) a zapíše to do logu – nic nemusíte dělat.
Těžké úlohy (detektor vad celé dlaždice, hustota, zápisy velkých DSF, předvýpočty) běží na pozadí a čekají, dokud běží RenderFarm nebo je volné paměti méně než minimum z Nastavení (výchozí 3 GB).
Detektor vad a hustota běží po blocích s pamětí do ~1 GB i u 2GB DSF; detektor celé velké dlaždice trvá desítky minut a přerušená úloha pokračuje od posledního bloku.
Editor načítá okno do 0,05° celé; větší okno po kouscích kolem kamery, 2–4 kousky souběžně.
Velký projekt (celá dlaždice) se otevírá po částech: nejdřív hlava projektu, pak entity a jejich původ po částech. Části čtou, rozebírají a připravují datová vlákna na pozadí (Web Worker; entity a jejich původ souběžně); editor od nich dostává entity a původ po malých dávkách (2 000 najednou) a mezi dávkami zůstává ovladatelný. Datové vlákno zároveň připraví pomocné sloupce projektu (druh, první bod, kousek okna a rejstřík id), takže editor po otevření už nerozděluje entity do kousků okna sám: u Mauricia (477 tisíc entit) to trvá 10–30 ms místo 0,5–0,9 s, u zkušebního trojnásobku Mauricia (1,43 milionu entit) 20–30 ms místo 1,4–2,7 s. Nejdelší zaseknutí prohlížeče do prvního obrazu kleslo u Mauricia z 0,35–0,5 s na 0,07–0,16 s a u trojnásobku z 0,55–0,6 s na 0,1–0,15 s, v prvních 15 s po otevření u Mauricia z 0,9–1,1 s na 0,55–0,65 s a u trojnásobku z 1,7–2,1 s na 0,65–0,95 s (zbytek je hlavně úklid paměti prohlížeče a stavba 3D scény). Zbývající nejdelší zaseknutí do prvního obrazu, asi 0,1 s, je u trojnásobku jednorázové zvětšení slovníku původu entit (1,43 milionu položek – prohlížeč ho při zvětšení přeskládá najednou), u Mauricia sestavení projektu a první vykreslení. Doba do prvního obrazu je u Mauricia stejná (3,5–4,3 s), u trojnásobku kratší (asi 9 s místo 9–13 s). Otevře se i projekt nad 1,1 milionu entit (víc než 512 MB dat), který se dřív neotevřel vůbec. Když se datové vlákno nespustí, editor čte projekt po částech sám jako dřív.
Počet entit projektu nemá strop (dřív 2 000 000). Když je projekt na volnou paměť velký, ukáže 3D okno žlutý pruh Velký projekt s odhadem: jádro (Kontrola a export čtou projekt celý) potřebuje asi 2,9 kB RAM na entitu, editor v prohlížeči asi 576 B na entitu a prohlížeč mu dá nejvýš asi 4 GB. Nic se neblokuje; Skrýt pruh schová do dalšího otevření projektu – dřív se vrátí, jen když projekt naroste aspoň o desetinu (velký import nebo převzetí). Náhled importu a dialog převzetí varují už předem.
Úpravy ve velkém projektu přepočítají v 3D okně jen změněné entity: úprava, přidání, smazání, Zpět i Znovu posunou rozdělení entit do kousků okna jen o změny (u Mauricia asi 5 ms místo 120–200 ms na krok), Uložit a průběžný koncept sestaví změny bez procházení celého projektu (dřív až asi 0,1–0,25 s po přidání nebo smazání) a tažení entity mění jen kousek okna, ve kterém leží (dřív se při každém pohybu myši znovu rozdělovaly všechny entity, asi 0,1 s). Seznam v Přehledu, minimapa, počty ve Vlastnostech projektu, seznamy výjimek a vyrovnání terénu a hledání entity podle id se po změně také jen posunou o změněné entity (pomocné sloupce projektu v typovaných polích – u Mauricia asi 17–20 MB, u trojnásobku asi 56–66 MB; paměť prohlížeče po otevření je stejná jako dřív). I smazání stovek rozházených entit najednou (výběr obdélníkem a Delete) a jeho Zpět posune Přehled jen o změněné entity: 250 entit u Mauricia asi 1 ms místo 16–24 ms, u trojnásobku asi 3–5 ms místo 80 ms. Velký výběr (Ctrl+A) si editor navíc pamatuje po pomocných sloupcích: vybrané entity pro panel vybraných a úchyty se po prvním použití čtou u Mauricia asi za 3–8 ms místo 30–47 ms (u trojnásobku asi 10–25 ms místo 100–125 ms) a Ctrl+klik nebo smazání části takového výběru trvá asi 0,3–0,45 s místo 0,55–0,85 s (u trojnásobku 0,8–1,4 s místo 1,7–2,5 s). Datová část úpravy jedné entity tak u Mauricia trvá asi 1 ms místo asi 20–25 ms (u trojnásobku asi 3 ms místo 23 ms); zbytek doby úpravy je kreslení změněné části 3D scény.
Potažený polygon (.pol) editor ořízne podle trojúhelníků načtené sítě terénu, aby ležel na terénu jako v X-Plane: nad hustou sítí (RenderFarm, Ortho4XP) má proto víc trojúhelníků. U velmi velkého polygonu (přes ~400 tisíc prověřených trojúhelníků sítě) a tam, kde síť ještě není načtená, se potah dělí jako dřív.
Lesy a fasády blízko kamery kreslí editor bez samostatné součásti na každou entitu: plochy, obrysy a fasády se zapisují do sloučených vrstev po úsecích (změna jedné entity přepíše jen svůj úsek, ne celou buňku), rozmístění stromů i triangulace plochy lesa běží ve vlákně na pozadí (výšky plochy se doplní po kouscích, lesy se k rozmístění zadávají po dávkách od kamery – i po otevření velkého projektu) a fasády se staví hromadně, po dávkách od kamery. Nejvíc stojí počet stromů ve scéně: stromy se kreslí jen do LOD lesa z .for (tráva 2 km) a v celé scéně nejvýš Strop stromů ve scéně (výchozí 250 000, vzdálenější lesy se ředí víc; u Mauricia s LOD 2,5 km dřív přes 1,5 milionu stromů); Věrná hustota kreslí v kruhu kolem kamery všechny stromy (300 m, u hustého lesa a trávy menší; až asi 40 tisíc instancí na les – strop jde změnit v Nastavení › Výkon, 10 000–300 000), na slabší grafice strop snižte nebo věrnou hustotu vypněte (štítek stromy 1 : N pak ukáže větší ředění). Stávající scenérie ve 3D kreslí do LOD navíc silnice, potahy s texturou, linie a rozložený bodový autogen .agp stejně jako projekt – v hustém městě (okno 0,1°) jsou to tisíce prvků; pomůže kratší LOD nebo vypnutá volba 3D modely. Úprava projektu (posun, smazání, Zpět) vrstvu nepřestavuje: entity jen pro čtení zůstanou tytéž, „už v projektu“ se přepočítá jen v okolí změněných entit a obrysy se na terén potáhnou jen jednou (Mauricius, okno 0,1° u Port Louis: commit se Stávající scenérií ve 3D asi 0,6 s místo 1,8–2,1 s, bez vrstvy asi 0,5 s; měřeno v prohlížeči bez grafické karty).
Každý model objektu (.obj) editor načte jen jednou: všechny jeho výskyty ve scéně (objekty projektu, objekty fasád, složený autogen i Stávající scenérie) sdílí jednu síť, texturu a materiály v grafické kartě. Model zmizí z paměti asi 15 s poté, co ho přestane kreslit poslední výskyt (po krátkém posunu kamery se tak nenačítá znovu).
Objekty se kreslí jednou vrstvou instancí pro celou scénu: každý díl modelu je jedno volání grafické karty bez ohledu na počet výskytů (dřív zvlášť v každém kousku okna). Do vzdálenosti LOD jsou všechny objekty modely (dřív se nad rozpočtem 3 mil. trojúhelníků kreslily i blízké domy jen jako tečky), za ní body (objekty autogenu a fasád nic). Přesnou mez LOD drží grafická karta; editor po zastavení kamery jen přehodí objekty, které mez přešly (objekt, který při rychlém přiblížení vjede do LOD, je do té doby bodem). Výskyty mimo obraz a za LOD grafická karta zahodí hned na začátku, bez výpočtu jejich vrcholů. Úprava jednoho objektu přepíše jen jeho záznam ve vrstvě. Na slabé grafické kartě pomůže menší LOD, nebo Rozpočet trojúhelníků objektů (výchozí vypnutý): modely pak jen nejbližší objekty, dokud se vejdou do rozpočtu, dál body (objekty autogenu a fasád nic).
Cache roste a Studio z ní samo maže jen mazatelné dlaždice mapy (podle Stropu) a nejdéle nepoužitá okna terénu DSF (vlastní strop 5 GB). Do koše… v Historii místo neuvolní – koš je složka dsf_upravy\_kos v cache na stejném disku a Studio ho nevysypává. Místo uvolníte ručně v Průzkumníku: smažte koš a exporty (editor_export) a ortofota (orto), které už nepoužíváte, viz Disk se plní.
Text vychází z manuálu RF Studia (F1 › Manuál, verze 0.11.2-beta). Dotazy a zkušenosti pište sem do vlákna.
Co stojí výkon v X-Plane
Plynulost X-Plane ovlivňuje hlavně počet trojúhelníků a vrcholů v síti DSF (paměť grafické karty a doba načtení dlaždice) a u vegetace počet instancí (plocha × hustota). Každá úprava, která síť zahušťuje (vložení DEM, rozřezání sítě ortofotem B, vložené hrany, srovnání letiště), DSF zvětší.
Odhad výkonu ve Studiu
.ags/.agbs plochou a body.agp– X-Plane z nich rozvine další budovy, cena na kus změřená není), silnice a jejich délka, výjimky. U každého řádku je změna v % proti podkladové DSF projektu. Stromy (instance) = plocha × hustota / SPACING² z.forv knihovně X-Plane (u výplně čárou obvod / SPACING, u bodů strom na bod), s podílem proti změřeným referenčním dlaždicím +50+015; lesy bez známého SPACING se nezapočtou. Výjimky ubírají obsah podkladu – úspora se nepočítá. MB ani sekundy se bez změřeného zdroje neuvádějí.Odhad je hrubý a opírá se o změřené dlaždice: DSF s 20,6 mil. trojúhelníků běžela v X-Plane plynule (ještě OK), DSF se 71,6 mil. trojúhelníků a 70,1 mil. vrcholů se načítala 195 s a přetekla paměť grafické karty (Hodně). Mezi tím je Pozor. U objektů a polygonů změřená cena na kus neexistuje, proto se ukazuje jen změna v procentech. Rozbalovací část Odkud čísla jsou (hrubý odhad) u každého odhadu vypíše zdroje.
Doporučení
Výkon samotného Studia
dsf_oknav cache): rejstřík příkazů DSF, spočítaná okna terénu a mřížka dálky se ukládají na disk. Po novém spuštění Studia nebo při návratu kamery na stejné místo se nepočítají znovu: první okno nového místa ve 2GB DSF se ukáže asi za 1–2 s místo 4–11 s a už spočítané okno asi za 5–15 ms místo 0,3–1 s. Úplně první otevření nové nebo přepsané DSF se nezrychlí, naopak trvá o chvilku déle (mezipaměť se teprve plní a ukládá na disk). Když RenderFarm (nebo jiný program) DSF přepíše, Studio to pozná podle velikosti a času změny souboru, starou mezipaměť té DSF smaže a spočítá okna znovu. Složka má vlastní strop 5 GB (nejdéle nepoužité soubory se mažou samy); kolik zabírá, ukazuje Nastavení › Pracovní složka (výstupy a cache). Smazat ji můžete kdykoli (Studio neběží nebo nic nenačítá) – jen se pak okna znovu spočítají..pol) editor ořízne podle trojúhelníků načtené sítě terénu, aby ležel na terénu jako v X-Plane: nad hustou sítí (RenderFarm, Ortho4XP) má proto víc trojúhelníků. U velmi velkého polygonu (přes ~400 tisíc prověřených trojúhelníků sítě) a tam, kde síť ještě není načtená, se potah dělí jako dřív..for(tráva 2 km) a v celé scéně nejvýš Strop stromů ve scéně (výchozí 250 000, vzdálenější lesy se ředí víc; u Mauricia s LOD 2,5 km dřív přes 1,5 milionu stromů); Věrná hustota kreslí v kruhu kolem kamery všechny stromy (300 m, u hustého lesa a trávy menší; až asi 40 tisíc instancí na les – strop jde změnit v Nastavení › Výkon, 10 000–300 000), na slabší grafice strop snižte nebo věrnou hustotu vypněte (štítek stromy 1 : N pak ukáže větší ředění). Stávající scenérie ve 3D kreslí do LOD navíc silnice, potahy s texturou, linie a rozložený bodový autogen.agpstejně jako projekt – v hustém městě (okno 0,1°) jsou to tisíce prvků; pomůže kratší LOD nebo vypnutá volba 3D modely. Úprava projektu (posun, smazání, Zpět) vrstvu nepřestavuje: entity jen pro čtení zůstanou tytéž, „už v projektu“ se přepočítá jen v okolí změněných entit a obrysy se na terén potáhnou jen jednou (Mauricius, okno 0,1° u Port Louis: commit se Stávající scenérií ve 3D asi 0,6 s místo 1,8–2,1 s, bez vrstvy asi 0,5 s; měřeno v prohlížeči bez grafické karty)..obj) editor načte jen jednou: všechny jeho výskyty ve scéně (objekty projektu, objekty fasád, složený autogen i Stávající scenérie) sdílí jednu síť, texturu a materiály v grafické kartě. Model zmizí z paměti asi 15 s poté, co ho přestane kreslit poslední výskyt (po krátkém posunu kamery se tak nenačítá znovu).dsf_upravy\_kosv cache na stejném disku a Studio ho nevysypává. Místo uvolníte ručně v Průzkumníku: smažte koš a exporty (editor_export) a ortofota (orto), které už nepoužíváte, viz Disk se plní.Text vychází z manuálu RF Studia (F1 › Manuál, verze 0.11.2-beta). Dotazy a zkušenosti pište sem do vlákna.