Poprawa wydajności

*Ta zawartość została przetłumaczona przy użyciu narzędzi AI (w wersji beta) i może zawierać błędy. Aby wyświetlić tę stronę w języku angielskim, kliknij tutaj.

Ta strona opisuje problemy i najlepsze praktyki dotyczące ich mitigacji.

Kalkulacja Skryptu

Drogie operacje w kodzie Lua trwają dłużej do przetwarzania i mogą więc wpływać na oceniaćklatki. Chyba, że jest wykonany równolegle, kod Lua jest wykonywany równolegle i blokuje główny wątek, aż do czasu, gdy zostanie wykonany równolegle, kod Lua jest wykonywany równolegle i blokuje główny wątek, aż do czasu, gdy zostanie wykonany równolegle.

Zwykłe problemy

  • Intensive operations on table structures - Skomplikowane operacje, takie jak serializacja, deseryzacja i głęboki klonowanie, wiążą się ze wysokim kosztem wydajności, szczególnie na dużych strukturach tabeli. To szczególnie prawdziwe, jeśli te operacje są recursive lub zaangażują powtarzanie się nad dużymi strukturami danych.

  • Wysokie wydarzenia częstotliwości - łączenie drogich operacji z wydarzeniami opartymi na ramach RunService bez ograniczania częstotliwości, co często prowadzi do niepotrzebnego zwiększenia czasu wykonania. Te wydarzenia obejmują:

Mitigacja

  • Wykonuj kod na RunService wydarzeniach oszczędnie, ograniczając użycie do przypadków, w których wysoką częstotliwość wzywania jest niezbędna (na przykład, aktualizacja kamery). Możesz wykonać większość innego kodu w innych wydarzeniach lub rzadziej w pętli.
  • Rozdzielaj duże lub drogie zadania używając task.wait() , aby rozprzestrzenić pracę na wiele okien.
  • Zidentyfikuj i zoptymalizuj niepotrzebnie drogie operacje i użyj wielowątkowości dla kosztownych zadań, które nie wymagają dostępu do modelu danych.
  • Niektóre skrypty na stronie serwera mogą skorzystać z 生成原始代码, prostego flagi, który kompiluje skrypt na kod maszynowy, a nie kod bajtowy.

Mikro profilatoryczne zakresy

ZakresPowiązana kalkulacja
RunService.PreRenderKod działający na wydarzeniu PreRender
RunService.PreSimulationKod wykonujący się na wydarzeniu krok po kroku
RunService.PostSimulationKod wykonuje się podczas wydarzenia Heartbeat
RunService.HeartbeatKod wykonuje się podczas wydarzenia Heartbeat

Dla więcej informacji o debugowaniu skryptów za pomocą MicroProfiler, zobacz debug bibliotekę, która zawiera funkcje do oznaczania kodu specyficznego i dalszego zwiększania specyfikacji, takie jak debug.profilebegin i debug.profileend. Wiele metod API wzywanych przez skrypcity ma również wł

Użycie pamięci skryptu

Leaki pamięci mogą się pojawić, gdy piszesz skrypcty, które konsumują pamięć, którą gromadarka nie może prawidłowo uwolnić, gdy nie jest już w użyciu. Leaki są szczególnie powszechne na serwerze, ponieważ mogą być nieustannie online przez wiele dni, podczas gdy sesja klienta jest znacznie krótsza.

Poniższe wartości pamięci w Konsoli Rozwoju mogą wskazać na problem, który wymaga dalszej investigacji:

  • LuaHeap - Wysoka lub rosnąca konsumpcja sugeruje przecieki pamięci.
  • InstanceCount - Spójny wzrost liczby instancji sugeruje, że niektóre instancje w twoim kodzie nie są gromadzone.
  • PlaceScriptMemory - Dostarcza skrypt poprzez rozkład użycia pamięci.

Zwykłe problemy

  • Wyłącz połączenia połączone - Silnik nigdy nie gromadzi wydarzeń połączonych z instancją i wszystkie wartości odniesione w przypisanych wartościach wezwania zwracanych. Dlatego aktywne połączenia wydarzeń i kodu w przypisanych instancji, związanych funkcji i wartości z referencją w przypisanych wartościach pamięci, są poza zakresem dla gromadzenia pamięci, nawet po zakończeniu wyd

    Chociaż wydarzenia są odłączone, gdy instancja, do której należą, zostanie usunięta, powszechny błąd jest założenie, że dotyczy to Player obiektów. Po tym, jak użyt

  • Tabelki - Wstawianie obiektów do tabel, ale nie usuwanie ich, gdy nie są już potrzebne, powoduje niepotrzebne zużycie pamięci, szczególnie dla tabel, które śledzą dane użytkownika, gdy dołączają. Na przykład poniższy kod przykładowy tworzy tabelę, dodającą informacje użytkownika za każdym razem, gdy użytkownik dołącza:

    Przykład

    local playerInfo = {}
    Players.PlayerAdded:Connect(function(player)
    playerInfo[player] = {} -- niektóre informacje
    end)

    Jeśli nie usuniesz tych wpisów, gdy nie są już wymagane, tabela nadal rośnie w rozmiarze i konsumuje więcej pamięci, gdy do sesjadołącza więcej użytkowników. Każdy kod, który przechodzi przez tę tabelę, staje się również bardziej kosztowny, gdy tabela rośnie w rozmiarze.

Mitigacja

Aby oczyścić wszystkie użyte wartości do zapobiegania wycieków pamięci:

  • Rozłącz wszystkie połączenia - Idź poprzez swoją bazę kodu upewnij się, że każde połączenie zostanie wyczyście za pomocą jednej z następujących ścieżek:

    • Rozłączanie ręcznie przy użyciu funkcji Disconnect().
    • Niszczenie instancji, do której należy wydarzenie, za pomocą funkcji Destroy().
    • Niszczenie obiektu skryptowego, do którego połączenie ma powrót.
  • Usuń obiekty i postacie gracza po opuszczeniu - Wdroż kod, aby upewnić się, że po opuszczeniu nie trwają połączenia, jak w następujązym przykładzie:

    Przykład

    Players.PlayerAdded:Connect(function(player)
    player.CharacterRemoving:Connect(function(character)
    task.defer(character.Destroy, character)
    end)
    end)
    Players.PlayerRemoving:Connect(function(player)
    task.defer(player.Destroy, player)
    end)

Kalkulacja fizyczna

Nadmierna simulacja fizyki może być główną przyczyną wydłużania czasu obliczania na klatkę ramy zarówno na serwerze, jak i na kliente.

Zwykłe problemy

  • Przeważająca częstotliwość czasu fizyki - Domyślnie stosowana jest wskaźnik częstotliwości kroków fizyki w Trybie adaptacyjnym, gdzie kroki fizyki dzieją się w zależności od złożoności mechanizmu fizyki.

    Dostępny jest również tryb stały z poprawioną dokładnością fizyki, który zmusza wszystkie zespoły fizyczne do krokowania 240 Hz (cztery razy na klatkę). To prowadzi do znacznie więcej obliczeń na każdym klatce.

  • Zbyt dużo złożoności modelowanych obiektów - Im więcej złożonych modelowanych obiektów, tym dłużej czasu trwania fizyki w każdym klatce. Często doświadczenia będą miały obiekty, które nie muszą być lub będą miały mechanizmy, które mają więcej ograniczeń i łączeń niż nie potrzebują.

  • Naderdokładne wykrywanie kolizji - Sieci części mają właściwość CollisionFidelity pozwalającą wykryć kolizję, która oferuje różne modele z różnymi poziomami wpływu na wydajność. Dokładny tryb wykrywania kolizji dla części sieci ma najwyższy koszt wydajności i dłużej trwa do wykonania.

Mitigacja

  • Zakotwiczaj części, które nie wymagają simulacji - Zakotwicz wszystkie części, które nie wymagają bycia kierowane przez fizykę, takie jak dla statycznych NPC.

  • Użyj dynamicznej fizyki krokowej - Dynamiczna krokowa fizyka dostosowuje dynamicznie szybkość obliczeń dla mechanizm fizyki, umożliwiając mniejszą częstotliwość aktualizacji w niektórych przypadkach.

  • Zredukuj złożoność mechanizmu * Gdy to możliwe, zminimalizuj liczbę ograniczeń lub łączeń fizycznych w zestawie.

    • Zmniejsz ilość kolizji samo-zderzającej się w mechanizmie, taką jak stosowanie ograniczeń lub ograniczeń niezderzania, aby zapobiec kolizji z innymi.
  • Zredukuj użycie precyzyjnej wierności kolaizji dla sieci * Dla małych lub nieobsługiwanych obiektów, w których rzadko kiedy użytkownicy zauważą różnicę, użyj kopiowania skrzyni.

    • Dla obiektów małych lub średnich użyj fidelności pudełka lub hullu, w zależności od kształtu.

    • Dla dużych i bardzo złożonych obiektów zbuduj niestandardowe kolizje za pomocą niewidocznych części, jeśli to możliwe.

    • Dla obiektów, które nie wymagają kolizji, wyłącz kolizje i użyj wierności obszarów lub hullu, ponieważ geometria kolizji nadal jest przechowywana w pamięci.

    • Możesz renderować geometrię kolizji dla celów debugowania w Studio poprzez włączenie Wierności kolizji z Opcjami wizualizacji w górnym rogu 3D-viewportu.

      Alternatywnie możesz zastosować filtr CollisionFidelity = Precise do Explorer, który pokazuje liczbę wszystkich części siatki z precyzyjną wiernością i umożliwia łatwo ich wybór.

    • Aby uzyskać wnikliwe omówienie tego, jak wybrać opcję wierności kolizji, która równoważy wymagania dotyczące Twojej precyzji i wydajności, zobacz Ustawić parametry fizyki i renderowania .

Mikro profilatoryczne zakresy

ZakresPowiązana kalkulacja
fizykaStopniOgólna kalkulacja fizyczna
krok świataRozdzielczość kroków fizyki we w każdym klatce

Użycie pamięci fizycznej

Fizyczne ruchy i wykrywanie kolizji zużywają pamięci. Części siatki mają właściwość CollisionFidelity, która określa podejście używane do oceny granic kolizji siatki.

Zwykły problem

Domyślne i precyzyjne modele wykrywania kolizji zużywają znacznie więcej pamięci niż dwa inne modele z mniejszą ilością kształtów kolizji o niskiej wierności.

Jeśli zobaczysz wysokie poziomy zużycia pamięci pod Fizyczne części, możliwe, że będziesz musiał zbadać zmniejszenie wierności kolizji obiektów w swoim doświadczeniu.

Jak zminimalizować

Aby zmniejszyć ilość pamięci używanej do celność kollizji:

  • Dla części, które nie wymagają kolizji, wyłącz ich kolizje ustawiając BasePart.CanCollide, BasePart.CanTouch i BasePart.CanQuery do 2> false2> .
  • Zmniejsz nieliniowość kolizji przy użyciu ustawienia CollisionFidelity. Box ma najniższą podaż pamięci i Default i 1> Enum.CollisionF
    • Zwykle bezpieczne jest ustawienie wielkości zderzenia dowolnej małej związanej części na Box.
    • Dla bardzo złożonych wielkich siatek można zbudować własną siatkę kolizji z mniejszymi obiektami z większą wiarygodnością kollizji.

Ludzkie

Humanoid jest klasą, która dostarcza szeroką gamę funkcjonalności dla graczy i postaci nie graczy (NPC). Mimo że jest potężny, to Humanoid przychodzi z znacznie dużym kosztem obliczeniowym.

Zwykłe problemy

  • Wszystkie człowiek noszący stan typu włączone na NPCs - Istnieje koszt wydajności dla wypatrywania niektórych HumanoidStateTypes włączonych. Wyłącz dowolne, które nie są potrzebne do Twoich NPC. Na przykład, jeśli Twój NPC nie będzie wchodzić na drzewa, to bezpiecznie mo
  • Nieustannie instancjowanie, modyfikowanie i odrodowywanie modeli z ludzkimi kształtami często * Może to być intensywne dla silnika do przetwarzania, szczególnie jeśli te modele używają połączonej odzieży . To również może być problematyczne w doświadczeniach, w których awatary często respawnują.
    • W MicroProfiler długie aktualizowane nieprawidłowe klastry tagi (ponad 4 ms) są często sygnałem, że natychmiastowa instytucja awatara/modyfikacja wywołuje nadmierne nieprawidłowe anulacje.
  • Używanie Humanoid w przypadkach, gdy nie są wymagane - Styczne NPC, które ogólnie rzecz biorąc nie mają potrzeby korzystania z klasy Humanoid .
  • Animacje do gry na dużej liczbie NPC z serwera - Animacje do gry na serwerze muszą być symulowane na serwerze i sklonowane do klienta. Może to być niepotrzebne przeciążenie.

Mitigacja

  • Odtwarzaj animacje NPC na klientach - W doświadczeniach z dużą liczbą NPCs rozważaj stworzenie Animator na klientach i uruchomienie animacji lokalnie. To zmniejsza obciążenie na serwerze i potrzebę niepotrzebnej skopiowania. Umożliwia również dodatkowe optymalizacje (takie jak tylko odtwarzanie anim
  • Użyj przyjaznych dla wydajności alternatyw dla ludzkoidów - modele NPC nie muszą koniecznie zawierać ludzkoidu.
    • Dla statycznych NPC użyj prosty AnimationController, ponieważ nie muszą się poruszać, ale tylko potrzebują odtwarzać animacje.
    • Dla ruchomych NPC, rozważ należy implementować własny kontroler ruchu i używać AnimationController dla animacji, w zależności od złożoności swoich NPC.
  • Wyłącz nieużywane stanami ludzkimi - Użyj Humanoid:SetStateEnabled() , aby włączyć tylko niezbędne stanami dla każdego ludzkiego.
  • Modele NPC basen z częstym respawningiem - Zamiast niszczyć NPC całkowicie, wysyłaj NPC do basenu nieaktywnych NPC. W ten sposób, gdy nowy NPC jest wymagany do respawnu, możesz po prostu ponownie aktywować jednego z NPC z basenu. Proces ten nazywa się pooling, co minimalizuje liczbę czasów, które znajdują się potrzebne do natychmiastowego odtwarzania.
  • Tylko wtedy, gdy użytkownicy są blisko, wtedy NPC się pojawiającego - Nie wtedy, gdy użytkownicy nie są w zasięgu, a usuń je, gdy użytkownicy opuszczą zasięg.
  • Unikaj zmian w hierarchii awatara po jej zainstalowaniu - Niektóre zmiany w hierarchii awatara mają znaczne implikacje wydajności. Dostępne są pewne optymalizacje:
    • Dla animacji proceduralnych niestandardowych nie aktualizuj JointInstance.C0 i JointInstance.C1 właściwości. Zamiast tego aktualizuj właściwość Motor6D.Transform.
    • Jeśli musisz załączyć jakiekolwiek obiekty BasePart do awatara, zrób to poza hierarchią awatara Model.

Mikro profilatoryczne zakresy

ZakresPowiązana kalkulacja
stepHumanoidKontrola i fizyka humanoidów
Animacja krokuanimacjaludzoidu i animator
aktualizujNieprawidłoweFastClustersZwiązane z inicjowaniem lub modyfikacją awatara

Renderowanie

Znaczna część czasu, którą kliент poświęca na każdą ramę, jest na renderowaniu sceny w obecnej ramie. Serwer nie robi żadnego renderowania, więc ta sekcja jest wyłącznie dla klienta.

Wywołania rysunkowe

Call draw jest zestawem instrukcji z silnika doGPU, aby renderować coś. Callowanie jest znacznie mniej wydajne. Ogólnie rzecz biorąc, imniej liczba callów proszę będzie mniej czasu kalkulacyjnego po renderowaniu klatki.

Możesz zobaczyć, ile wzywów renderowania ma miejsce obecnie z przedmiotem Render Stats > Timing w Studio. Możesz zobaczyć Render Stats w klientach, naciskając 2>Shift2> 5>F25>.

Im więcej obiektów, które muszą być rysowane w twojej scenie w określonym kadrze, tym więcej wezwywanych jest do instancji instancji na rzecz grafiki. Jnak silnik Roblox wykorzystuje proces MeshId do łączenia identycznych sieci z tę samą MeshId . W szczególności wielu sieci z tę samą 2>inst

Inne problemy związane

  • Niestandardowa gęstość obiektu - Jeśli duża liczba obiektów jest skoncentrowana z dużą gęstością, to renderowanie tego obszaru sceny wymaga więcej wezwów do rysowania. Jeśli znajdujesz, że twoja stopka kadrowa spada, gdy patrzysz na pewną część mapy, może to być dobry sygnał, że gęstość obiektu w tym obszarze jest zbyt duża.

    Przedmioty takie jak naklejki, tekstury i cząsteczki nie przetwarzają dobrze i wprowadzają dodatkowe wezwania do rysowania. Zwróć szczególną uwagę na te rodzaje przedmiotów w scenie. W szczególności zmiany właściwości do ParticleEmitters mogą mieć dramatyczny wpływ na wykonywanie.

  • Nieprawidłowe możliwości instytucji przestrzeni - Często zdarza się, że scena zawiera tę samą sieć duplikowana wiele razy, ale każda kopia sieci ma różne ID sieci lub tekstur. To zapobiega instytucji przestrzeni i może prowadzić do niepotrzebnych wezwów do rysowania.

    Powszechną przyczyną tego problemu jest to, że cały obszar jest importowany jednocześnie, a nie poszczególne zasoby są importowane do Roblox i następnie duplikowane po importowaniu, aby połączyć obszar.

  • Zbyt duża skomplikowaność obiektu - Meskie liczby wezwania rysunku nie są tak ważne, jak liczba trójkątów w scenie, ale liczba trójkątów w scenie zbyt duża jest problemem powszechnym, podobnie jak wszystkie mieszki z ustawioną właściwością MeshPart.RenderFidelity

  • Przekroczenie ilości cienia - Handling cieni jest drogim procesem, a mapy, które zawierają dużą liczbę i gęstość obiektów cienia, które castingują cienie (lub dużą liczbę i gęstość małych części wpływanych przez cienie) prawdopodobnie mają problemy z wydajnością.

  • Wysoka przejrzystość pozwala na nakładanie obiektów z częściową przejrzystością w pobliżu siebie. - Umieszczanie obiektów z częściową przejrzystością w pobliżu siebie zmusza silnik do renderowania różnych pikseli wiele razy, co może negatywnie wpłynąć na wykonywanie. Dla więcej informacji o identyfikowaniu i naprawie tego problemu, zobacz Usuwaj połączone przejrzystości.

Mitigacja

  • Instancing identical meshes and reducing the amount of unique meshes - Jeśli zapewnisz, że wszystkie identyczne meszy mają tę samą podstawową ID, silnik może rozpoznać i renderować je w jednym wywołaniu. Upewnij się, że każdy mesz na mapie zostanie tylko raz załadowany, a następnie duplikowany w Studio do
  • Odznaczanie - Odznaczanie opisuje proces eliminacji rzeczy, które nie są czynnikami w ostatecznym renderowaniu ramy. Domyślnie silnik ignoruje odznaczanie rzeczy poza polą widzenia kamer (oczyszczanie frustum) ale nie ignoruje odznaczania rzeczy zablokowanych z widzenia innych obiektów (oczyszczanie
    • Ukryj MeshPart i BasePart, które są daleko od kamery lub ustawienie.
    • Dla środowisk wewnętrznych zaimplementuj system pokoju lub portalu, który ukrywa obiekty niezajęte przez żadnych użytkowników.
  • Redukcja wierności renderowania - Ustaw wierność renderowania na Automatyczną lub Wydajność . To pozwala na zesunię siebie w kierunku mniej złożonych alternatyw, co może zmniejszyć liczbę poligonów do rysowania.
  • Wyłączanie cieniowania na odpowiednich częściach i obiektach świetlnych - Skomplikowanie cieni w scenie można zmniejszyć poprzez wyłączanie selektywnie właściwości cieniowania na obiektach świetlnych i częściach. Można to zrobić podczas edytowania czasu lub dynamicznie podczas wykonania. Niektóre przykłady:
    • Użyj właściwości BasePart.CastShadow, aby wyłączyć kastowanie cienia na małych częściach, w których cienie nie są prawdopodobne do zobaczenia. Może to być szczególnie skuteczne, gdy stosowane jest tylko do części, które są daleko od kamery użytkownika.

    • Wyłącz cienie na ruchomych obiektach, jeśli to możliwe.

    • Wyłącz Light.Shadows na instancjach światła, gdzie obiekt nie musi rzucać cieni.

    • Ogranicz zasięg i kąt instancji światła.

    • Użyj mniej instancji światła.

Mikro profilatoryczne zakresy

ZakresPowiązana kalkulacja
Przygotuj i wykonajOgólne renderowanie
Perform/Scene/計算光源PerformAktualizacja siatki światła i cieni
LightGridCPUAktualizacja siatki światła Voxel
ShadowMapSystemMapa cieni
Perform/Scena/UpdateViewPrzygotowanie do renderowania i aktualizacji cząsteczek
Wykonaj/Scenę/RenderViewRenderowanie i post-Processing

Sieci i replikacja

Sieci i replikacja opisuje proces przesyłania danych między serwerem a połączonymi klientami. Informacje są wysyłane między klientem a serwerem za każdym klatki, ale większe ilości informacji wymagają więcej czasu do wykonania.

Zwykłe problemy

  • Zbyt dużo ruchu zdalnego - Wysyłanie dużej ilości danych poprzez obiekty RemoteEvent lub RemoteFunction lub wzywanie ich bardzo często może powodować dużo czasu pracy na serwerze, przetwarzając paczki przychodzące w każdym klatkę. Częste błędy to:

    • Replikowanie danych w każdym klatku, który nie musi być replikowany.
    • Replikowanie danych na wejściu użytkownika bez żadnego mechanizmu, aby go ograniczyć.
    • Wysyłanie więcej danych niż jest to wymagane. Na przykład wysyłanie całego ekwipunku gracza, gdy kupuje on przedmiot, a nie tylko szczegóły zakupionego przedmiotu.
  • Utworzenie lub usunięcie drzew kompleksowych instancji - Gdy zmiana jest dokonana w modelu danych na serwerze, zostaje ona replikowana na połączonych klientach. Oznacza to, że tworzenie i usuwanie dużych drzew hierarchii instancji, takich jak mapy podczas uruchomienia, może być bardzo kłopotliwe.

    Zwykłym winowajcą tutaj jest złożona data animacji zapisana przez wtyczki Animation Editor w rygach. Jeśli te nie zostaną usunięte przed publikacją gry i zeskanowany model animacji jest regularnie kopiowany, duża ilość danych zostanie niepotrzebnie skopiowana.

  • Server-side TweenService - Jeśli TweenService jest używany do tweeningu serwera strony, tweened property jest replikowana do każdego klienta każdym klatkę. Nie tylko prowadzi to do tego, że tween jest nieprawidłowo, ale powoduje dużo niepotrzebnego ruchu sieci.

Mitigacja

Możesz zastosować następujące taktyki, aby zmniejszyć niepotrzebną replikację:

  • Unikaj wysyłania dużych ilości danych na raz poprzez zdarzenia zdalne . Zamiast tego wysyłaj tylko niezbędne dane w niższej częstotliwości. Na przykład, dla stanu postaci, replikuj go, gdy się zmienia, a nie każdą klatkę.
  • Chunk up complex instance trees jak mapy i ładowane w kawałkach, aby rozdzielać pracę replikując tę na wiele ram.
  • Oczyść metadane animacji , szczególnie katalog animacji rur, po zaimportowaniu.
  • Ogranicz niepotrzebną replikację instancji , szczególnie w przypadkach, gdy serwer nie musi mieć wiedzy o instancjach tworzonych. To obejmuje:
    • Efekty wizualne, takie jak eksplozja lub magiczny efekt wybuchu. Serwer musi tylko wiedzieć lokalizację, aby określić wynik, podczas gdy klienci mogą tworzyć wizualizacje lokalnie.
    • Modele widoków przedmiotów w pierwszej osobie.
    • Zmień obiekty na klientach, a nie na serwerach.

Mikro profilatoryczne zakresy

ZakresPowiązana kalkulacja
Pakiety procesuPrzetwarzanie pakietów sieciowych, takich jak wezwania wydarzeń i zmiany właściwości
Zakonfiguruj Bandycję i Uruchom nadawcówWydarzenia wychodzące odpowiednie na serwerach

Użycie pamięci zasobów

Najwyższym dostępnym dla twórców mechanizmem wpływu jest włączenie Instancja przesyłania.

reaming instancji

Instancja przetwarzania selektywnie ładowuje części modelu danych, które nie są wymagane, co może prowadzić do znacznie skróconego czasu ładowania i zwiększyć zdolność klienta do zapobiegania awariom, gdy dochodzi do niedostatecznej ilości pamięci.

Jeśli doświadczasz problemów z pamięcią i masz wyłączoną instancję, rozważaj aktualizację swojego doświadczenia, aby wspierać ją, szczególnie jeśli twoja wirtualna rzeczywistość jest duża. Instancja streamingu jest oparta na dystrybucji w przestrzeni 3D, więc większe światy naturalnie korzystają z tego bardziej.

Jeśli włączone jest przesyłanie instancji, możesz zwiększyć agresję. Na przykład, rozważ:

  • Redukowanie użycia trwałego StreamingIntegrity .
  • Redukowanie promienia przesyłania .

For more information on streaming options and their benefits, see Streaming Properties .

Inne problemy związane

  • Duplikacja zasobów - Częstym błędem jest wstawienie tego samego zasobu wiele razy, co prowadzi do różnych identyfikatorów zasobów. Może to prowadzić do tego, że ten sam treści zostanie załadowany do pamięci wiele razy.
  • Nadmierna ilość zasobów głosu - Nawet gdy zasoby nie są identyczne, są przypadki, gdy możliwości ponownego użycia tej samej zasoby i zapamiętania pamięci są przegapane.
  • Pliki audio - Pliki audio mogą być zaskakującym wnętrzeńiem zużycia pamięci, szczególnie jeśli załadasz je wszystkie na klienta naraz, a nie tylko ładowanie tego, czego potrzebujesz do części doświadczenia. Dla strategii, zobacz Czas ładowania.
  • Wysoka rozdzielczość tekstur - Konsumpcja pamięci grafiki dla tekstury jest niezwiązana z rozmiarem tekstury na dyskach, ale raczej liczbą pikseli w teksturze.
    • Na przykład 1024x1024 tekstura pikseli zużywa cztery razy pamięci graficznej 512x512 tekstury.
    • Zdjęcia wstawione na Roblox są przeszyfrowane do stałego formatu, więc nie ma korzyści pamięci z wstawiania zdjęć w modelu kolorów związanym z mniejszą ilością bajtów na piksel. Podobnie, kompresja zdjęć przed wstawieniem lub usunięciem kanału alfa z obrazów, które nie go wymagają, może zmniejs
    • Możesz zidentyfikować konsumpcję pamięci graficznej dla danej tekstury, rozszerzając kategorię Grafika w Konsoli Rozwój.

Mitigacja

  • Tylko w razie potrzeby wstawiaj zasoby - ponownie użyj tego samego ID zasobu na obiektach i upewnij się, że te same zasoby, w szczególności sieci i obrazy, nie są wysyłane ponownie wiele razy.
  • Znajdź i napraw duplikowane zasoby - Szukaj identycznych części siatki i tekstur, które są wielokrotnie wstawiane z różnymi ID.
    • Chociaż nie ma API do wykrywania podobieństw zasobów automatycznie, możesz zebrać wszystkie ID zasobów obrazu w swoim miejscu (manualnie lub przy użyciu skryptu), załadować ich i porównać je używając zewnętrznych narzędzi porównania.
    • Dla części siatki najlepszym strategia jest wziąć unikalne ID sieci i zorganizować je według rozmiaru, aby ręcznie zidentyfikować duplikaty.
    • Zamiast używać oddzielnych tekstur dla różnych kolorów, załaduj jedną teksturę i użyj właściwości SurfaceAppearance.Color, aby zastosować różne odcienie do niego.
  • Importuj zasoby w mapie osobno - Zamiast importować całą mapę na raz, importuj i odtwórz zasoby w mapie osobno i odtwórz je. Importer 3D nie wykonuje żadnej duplikacji sieci, więc jeśli importujesz dużą mapę z dużą ilością oddzielnych płytki podłogi, ka
  • Ogranicz pikseli obrazów do nie więcej niż niezbędnej ilości. Chyba, że obraz zajmuje dużą ilość miejsca fizycznego na ekranie, zwykle wymaga maksymalnie 512x512 pikseli. Większość mniejszych obrazów powinna być mniejsza niż 256x256 pikseli.
  • Użyj kart do przycięcia , aby zapewnić maksymalne odzyskiwanie tekstury w mapach 3D. Dla kroków i przykładów na temat tego, jak tworzyć karty przycięcia, zobacz tworzenie kart przycięcia .

Czas ładowania

Wiele doświadczeń implementuje niestandardowe ekrany ładowania i używa metody ContentProvider:PreloadAsync(), aby wysyłały zasoby, takie jak obrazy, dźwięki i siatki, aby zostać zeskanowanymi w tle.

Za pomocą tego podejścia możesz upewnić się, że ważne części swojego doświadczenia są w pełni załadowane bez pop-in. Jest to jednak powszechny błąd, który polega na nadużyciu tego metody, aby przedłużyć ładowanie więcej zasobów niż jest w rzeczywistości wymagane.

Przykładem złej praktyki jest ładowanie całegoWorkspace . Chociaż może to zapobiec wyskakiwaniu tekstury, to znacznie wydłuża czas ładowania.

Zamiast tego użyj ContentProvider:PreloadAsync() tylko w koniecznych sytuacjach, które obejmują:

  • Obrazy na ekranie ładowania.
  • Ważne obrazy w menu swojego doświadczenia, takie jak tła przycisków i ikonek.
  • Ważne zasoby w obszarze uruchamiania lub spawnowania.

Jeśli musisz załadować dużą liczbę zasobów, zalecamy, abyś zaznaczył przycisk Pomiń ładowanie .