My @daydreamsagents budujemy narzędzia, które umożliwią powstawanie firm o wartości miliarda dolarów bez pracowników.

Jesteś starszym inżynierem ds. Three.js i wydajności gier. Już zbudowałeś mentalny model działania katalogu gier (struktura, podział, renderowanie). Twoim nowym zadaniem jest znalezienie i zaproponowanie konkretnych optymalizacji. Główne cele •Zmniejszenie użycia CPU i obciążenia GPU. •Zmniejszenie zmienności czasu klatek (mniej zacięć). •Minimalizacja użycia pamięci i problemów z GC. •Uczynienie procesu podziału + renderowania jak najbardziej wydajnym i skalowalnym. Zakładaj, że ta gra musi ostatecznie wspierać: •Duże eksplorowane mapy (wiele kawałków). •Wiele aktywnych jednostek/struktur. •Dziesiątki jednoczesnych graczy. ⸻ Co powinieneś przeanalizować 1.Pętla renderowania i aktualizacje stanu •Znajdź główną pętlę renderowania (animate(), pętla gry lub cykl renderowania React). •Szukaj: •Pracy wykonywanej w każdej klatce, która mogłaby być grupowana, ograniczana lub przenoszona z gorącej ścieżki. •Drożych obliczeń lub alokacji wewnątrz pętli (np. tworzenie nowych wektorów, tablic lub obiektów). •Redundantnych aktualizacji (np. ustawianie uniformów/pozycji/materiałów w każdej klatce, gdy się nie zmieniają). 2.Podział i widoczność •Zbadaj, jak określane są widoczne kawałki na podstawie pozycji kamery/gracza. •Szukaj: •Niewydajnych skanów wszystkich kawałków w każdej klatce. •Powtarzających się obliczeń widoczności, które mogłyby być buforowane lub aktualizowane tylko przy ruchu. •Jakichkolwiek wzorców N² (np. sprawdzanie każdego kawałka w porównaniu do każdej jednostki w każdej klatce). •Zaproponuj ulepszenia, takie jak: •Indeksowanie przestrzenne (siatki, mapy kluczone według współrzędnych). •Aktualizowanie widoczności tylko wtedy, gdy kamera przekracza granice kawałków. •Wstępne obliczanie relacji sąsiednich. 3.Zarządzanie siatkami i obiektami •Zbadaj, jak siatki są tworzone/usuwane, gdy kawałki są ładowane/odładowywane. •Szukaj: •Częstego tworzenia/usuwania geometrii/materiałów (przeciążanie GPU). •Niepotrzebnych oddzielnych siatek zamiast instancjonowania lub scalonej geometrii. •Obiektów pozostawionych w scenie lub nieusuniętych (wycieki pamięci). •Rozważ: •Użycie InstancedMesh dla powtarzających się struktur, gdzie to możliwe. •Użycie pul geometrii/materiałów lub ponowne użycie instancji siatek. •Grupowanie obiektów per-kawałek pod grupami kawałków dla szybszego dodawania/usuwania. 4.Wywołania rysowania i materiały •Policz i rozważ: •Liczbę używanych materiałów. •Liczbę wywołań rysowania na klatkę (szczególnie na kawałek). •Zidentyfikuj: •Możliwości łączenia materiałów lub tekstur (sprite'y/atlasy). •Miejsca, w których wiele podobnych siatek mogłoby być grupowanych. •Zaproponuj: •Atlasy tekstur dla terenu/struktur. •Wzorce ponownego użycia materiałów zamiast tworzenia materiałów dla każdego obiektu. 5.Culling, LOD i szczegóły •Sprawdź, jakie culling istnieje: •Ustawienia culling frustum. •Ręczne culling dla dalekich kawałków/jednostek. •Zidentyfikuj: •Siatki o wysokiej liczbie wielokątów renderowane, nawet gdy są małe na ekranie. •Kosztowne shadery używane dla obiektów poza ekranem lub małych obiektów. •Zaproponuj: •Prosty LOD (siatki o niskiej rozdzielczości lub impostory dla odległych obiektów). •Agresywne culling dla obiektów poza ekranem lub usuwanie na podstawie odległości. •Wyłączenie cieni lub kosztownych efektów na dalekich kawałkach. 6.Garbage Collection i alokacje •Szukaj: •Tworzenia tymczasowych obiektów w gorących ścieżkach (wektory, macierze, tablice). •Rozprzestrzenienia, mapowania/filterowania/redukcji w wewnętrznych pętlach. •Zaproponuj: •Ponowne użycie tymczasowych wektorów/macierzy. •Wstępne alokowanie buforów/tablic używanych w każdej klatce. •Zastąpienie wzorców funkcyjnych pętlami imperatywnymi tam, gdzie to odpowiednie w gorącym kodzie. 7.Integracja z React / R3F (jeśli dotyczy) •Jeśli używasz React / React Three Fiber: •Zidentyfikuj komponenty, które renderują się zbyt często. •Szukaj ciężkich obliczeń w funkcjach renderujących React lub hookach. •Zaproponuj: •Memoizację propsów i selektorów. •Przeniesienie ciężkiej logiki z komponentów React do systemów/usług. •Użycie stabilnych referencji, aby uniknąć niepotrzebnych rekonsolidacji. 8.Profilowanie i pomiar •Zaproponuj, jak mierzyć te optymalizacje: •Prosta nakładka FPS/czasu klatki. •Tryby debugowania, które logują liczbę kawałków, liczbę jednostek, szacunkowe wywołania rysowania. •Flagi do przełączania funkcji (cienie, post-process, LOD), aby porównać wpływ. •Zaproponuj minimalną listę kontrolną profilowania, którą zespół może regularnie używać. ⸻ Wyniki Przygotuj strukturalny raport optymalizacji: 1.Ryzyka wydajnościowe •Lista punktów dotyczących najbardziej niepokojących wzorców, które znalazłeś, uporządkowanych według oczekiwanego wpływu. 2.Konkretne rekomendacje optymalizacji •Dla każdej rekomendacji: •Co zmienić (plik(i), funkcja(e), odpowiedzialność). •Dlaczego to pomaga (CPU, GPU, pamięć, GC, sieć itp.). •Przybliżony oczekiwany wpływ (wysoki/średni/niski). 3.Ulepszenia specyficzne dla podziału/renderowania •Sugestie tylko dla: •Logiki widoczności kawałków. •Wydajności ładowania/odładowania kawałków. •Cyklu życia siatki/geometrii/materiału dla kawałków. 4.Plan optymalizacji krok po kroku •Plan 3–5 kroków: •Krok 1: „Niskie ryzyko, wysoki wpływ” szybkie wygrane. •Krok 2: Refaktoryzacje (np. wprowadzenie instancjonowania lub puli). •Krok 3+: Zmiany strukturalne (np. nowy indeks kawałków, system LOD). Pytania / Założenia •Wymień wszelkie założenia, które musiałeś poczynić. •Wskaź miejsca, w których potrzebny jest większy kontekst (np. ograniczenia projektowe gry), aby wybrać najlepsze kompromisy optymalizacyjne. Twoim celem nie jest tylko mikro-optymalizacja, ale zapewnienie, że gra może komfortowo skalować się w miarę wzrostu mapy i liczby graczy, przy jednoczesnym utrzymaniu kodu w łatwej do zarządzania formie.

Moim tajnym punktem odniesienia dla tych modeli jest doprowadzenie ich do optymalizacji niesamowicie dużego świata gry w threejs 5.2 właśnie znalazło kilka zysków, których nie znalazł Opus.