Osvědčené postupy skriptování vizuálů mesh pro zajištění výkonu
Přehled
Vizuální skripty nejsou ze své podstaty pomalé, ale jsou výrazně pomalejší než kód jazyka C#.
Když ve svém prostředí vytváříte vizuální skripty, je nejlepší je použít k propojení stávajících funkcí, ne pro těžké zvedání: vytváření lepidla, ne vazů. Nejjednodušším způsobem, jak zajistit, aby vaše vizuální skripty neměly vliv na celkový výkon vašeho prostředí, je zajistit, aby na prvním místě nic nedělaly.
Události skriptů s vysokou a nízkou frekvencí
Vizuální skriptování nabízí širokou škálu událostí, které můžete použít k aktivaci toků vizuálních skriptů.
Zkuste se vyhnout:
Při aktualizaci, při opravené aktualizaci, při pozdní aktualizaci a podobné. Tyto události se velmi často aktivují (často se stejnou rychlostí jako snímky vykreslování) a dokonce i v případě, že váš skript nedělá hodně, má dokonce i jeho spuštění režii, která může výrazně ovlivnit výkon vašeho prostředí, pokud se to stane na mnoha místech najednou.
Při aktivaci zůstat a při kolizi zůstat. I když jsou tyto události aktivní pouze za určitých podmínek (například když je fyzikální objekt uvnitř objemu fyzikálního triggeru nebo se dotkne spřažení), zatímco tyto podmínky jsou uvedeny, aktivují se velmi často.
U těchto událostí s vysokou frekvencí není žádná přímá náhrada. Nejsou zakázané, takže je můžete použít, pokud je to naprosto nezbytné, ale doporučujeme využít předdefinované funkce, jako je komponenta Animatoru, která může být řízena vizuálními skripty nebo restrukturalizovat logiku skriptu tak, aby byla reaktivní, nikoli aktivní – například pomocí událostí Při změně stavu.
Pokud se těmto vysokofrekvenčním událostem nemůžete vyhnout, možná budete moct snížit jejich dopad tím, že budete mít neaktivní celou komponentu skriptového počítače , když ji nepotřebujete. Jiný vizuální skript může pomocí sady skriptů | Povoleno zakázat a povolit celý graf skriptu. I když je tato akce zakázaná, neaktivuje se žádný z uzlů událostí a nemá nulové náklady za běhu.
Jedná se o mírně nebezpečné pro výkon, ale někdy je to nezbytné:
- Při vstupu do kolizí a při ukončení kolize. Za normálních okolností se tyto události aktivují pouze jednou, když se tělo fyziky dotkne slídiče, a znovu, když se přestane dotýkat. Někdy se však fyzika tělo zasekne mezi dvěma kolidátory; v takovém případě může rychle zatěžovat a aktivovat mnoho událostí při kolizi ve velmi rychlém sledu. Místo toho doporučujeme používat události triggeru .
To je v některých situacích v pořádku:
V intervalu můžete aktivovat toky skriptu v přizpůsobitelných intervalech (například jednou za sekundu) definované prostřednictvím nastavení Interval . Nastavení Zpoždění můžete použít k rozdělení provádění různých událostí intervalu, které mají stejný interval.
Uzel Časovač není událost, ale jednou pro každou dobu trvání časovače aktivuje její port Tick po dobu trvání časovače zadáním jeho počátečního portu. Pokud časovač není spuštěný, má nulové náklady za běhu.
Zkuste tyto události nepoužívat k kontrole, jestli se změnily určité proměnné, vlastnosti nebo podmínky– místo toho je lepší použít událost On State Changed k naslouchání změnám za nulových nečinných nákladů.
Vždy je to v pořádku:
Při změně stavu se aktivuje pouze v případě, že a když některý ze vstupních portů změní jejich hodnotu. U proměnných skriptů a vlastností komponent se tato funkce implementuje velmi efektivně způsobem, který bude čítat nulové náklady za běhu, pokud se nic nezmění.
Při změně stavu lze použít také ke sledování složitějších vstupů (například výsledků výpočtu), které vyžadují opětovné vyhodnocení vstupu jednou za rámec, aby bylo možné určit, jestli došlo ke změně. Tuto funkci povolíte povolením možnosti Povolit dotazování . Uživatelské rozhraní pro úpravy skriptů vás o tom informuje a upozorní vás na potenciální dopad na výkon. I tak bude stále o něco efektivnější než skriptování vlastní logiky dotazování pomocí události Při aktualizaci .
Při přidání položky slovníku a při odebrání položky slovníku fungují podobným způsobem a mají nulové náklady za běhu, dokud se nic nezmění.
Při triggeru Enter a Při ukončení aktivační události nemá žádné potenciální nebezpečí výkonu odpovídajících událostí kolizí (viz výše).