[Wątek został napisany tylko w celach edukacyjnych, proszę o jego nie usuwanie. Jeśli znajduje się w złym dziale to proszę o przeniesienie w odpowiedni]

Witam.
Wiele osób krzyczy, że w grach ma po 60 FPS a w td2 ma ledwo 20
Powstało wiele "teorii" dlaczego tak się dzieję, ja przedstawię i raz na zawszę wyjaśnię przyczynę


Zacznijmy od tego, że TD2 wykorzystuje potencjał GPU w znikomym stopniu - wiele mocy obliczeniowej jest marnowane
By znaleźć przyczynę małej ilości FPS obniżmy ustawienia Graficzne do minimum...
W moim przypadku, klatkaż zwiększył się ok 5-10 FPS co jest bardzo słabym wynikiem.

By zrozumieć dlaczego tak się dzieje ustawmy mnożnik LOD na 0.


Już na starcie widać na czym polega problem...


Po ustawieniu mnożnika na 0 odległość rysowania jest przemnażana przez 0 (logiczne :p) czego efektem powinno być zniknięcie wszystkich obiektów.
Fakt część obiektów znika np. wysięgniki czy podkłady, lecz reszta obiektów jest rysowana na całej długości scenerii co po przemnożeniu przez ilość obecnych wierzchołków modeli daje ogromną liczbę
Skybox (możliwe że przypadkowo) jest nieudolną próbą zasłonięcia tego że te obiekty są wyświetlane na całej długości (lub znikają w bardzo dużej odległosci)
Ilość obiektów które procesor musi przetwarzać przekłada się na znacznie wyższe użycie CPU w stosunku do niskiego użycia GPU co potwierdza fakt że można mieć dobrą grafikę a mieć i tak 20FPS
(tak jest w moim przypadku)

Druga przyczyna (też istotna) jest to renderowanie obiektów które są niewidoczne
By to sprawdzić sprawdźmy użycie GPU oraz CPU gdy patrzymy się w różnych kierunkach:

Najpierw spójrzmy stronę kierunku jazdy by zebrać dane kontrolne...


Następnie spójrzmy w bok gdzie statystycznie jest mniej obiektów, niż w kierunku jazdy


Jak widać użycie CPU oraz GPU się nie zmieniło (lub spadło nieznacznie) mimo iż widzimy znacząco mniej obiektów

By się upewnić zobaczmy co się stanie jak będziemy patrzeć w niebo gdzie nie widzimy na ekranie żadnych obiektów


Jak widać mimo iż nie widzimy obiektów to CPU oraz GPU jest także w pełni obciążone...

Dla porównania zobaczmy jak to wygląda w innym symulatorze w tym przypadku trainz.
Screen w kierunku jazdy:


Screen z boku:


W tym przypadku widać znaczny spadek użycia CPU i GPU
Wywnioskować z tego możemy, że w TD2 obiekty są renderowane nawet jak na nie nie patrzymy
Co powoduje ogromny spadek wydajności bo zamiast renderować tylko tego co widzimy (kąt widzenia dla którego powinny zostać wyrenderowane obiekty to średnio 150st.)
Przez to GPU oraz CPU musi wykonać średnio 2X więcej obliczeń niż tego potrzebujemy

Teraz nasuwa się pytanie dlaczego do dzisiaj nikt przy tym nie usiadł i tego nie poprawił
Poprawienie tych dwóch problemów wymaga ogromnego nakładu pracy, w przykładzie pierwszym wymaga to zmiany odległości rysowania dla każdego obiektu jaki mamy w grze
W drugim przykładzie na ten moment nie ma rozwiązania, w obecnej sytuacji zastosowanie skryptu który by blokował renderowanie niewidocznych obiektów (przy obecnej konstrukcji programu) jest niemożliwe do zrealizowania.

Cytuj

Zacznijmy od tego, że TD2 wykorzystuje potencjał GPU w znikomym stopniu
To prawda. I to chyba jedyne słuszne zdanie w całym tym temacie.

Od początku - nie wszyscy wiedzą jak działa proces renderowania grafiki, zatem zacznijmy od wyjaśnienia.
Otóż, w cały proces renderowania jednej klatki zaczyna się od określenia tego, które elementy mają być widoczne na ekranie.
Sprawdzane są poziomy LOD dla obiektów, czy obiekt w ogóle mieści się w kącie widzenia kamery i to jak daleko od kamery znajduje się obiekt.
Następnie siatki obiektów muszą być przesłane z CPU do GPU, jedna po drugiej - jest to złożony protokół komunikacyjny, ale dla uproszczenia zobrazujmy

CPU: Hej karto graficzna, mam dla Ciebie siatkę obiektu!
GPU: No dawaj!
C: No to podaję wierzchołki ... ... ... ... ... ... ... ... ... ... ... ... ... ...
C: Koniec transmisji
G: Koniec transmisji, przesłano n wierzchołków!

I tak z każdym obiektem. Współczesne karty graficzne są bardzo szybkie obliczeniowo, można robić na nich skomplikowane obliczenia w ułamkach sekund, ale - wąskim gardłem jest prędkość transmisji danych. Jeśli chcecie na karcie graficznej policzyć wynik "1 + 2 = ?" licząc, że GPU zrobi to szybciej, to będziecie zdziwieni. Zanim karta graficzna otrzyma dane i zaalokuje na nie pamięć, zwykły procesor policzy to 100 razy. Tak! Karty graficzne świetnie obliczają złożone wektory, macierze, ale pod warunkiem, że są to duuuuuże i skomplikowane obliczenia, bo transfer danych na kartę trwa na tyle długo, że w przypadkach prostych działań zwykłe CPU sprawdza się o wiele wydajniej.
Podsumowując: Transmisja CPU -> GPU to wąskie gardło.

Cytuj

By znaleźć przyczynę małej ilości FPS obniżmy ustawienia Graficzne do minimum...
W moim przypadku, klatkaż zwiększył się ok 5-10 FPS co jest bardzo słabym wynikiem.
Już na starcie widać na czym polega problem...
Po ustawieniu mnożnika na 0 odległość rysowania jest przemnażana przez 0 (logiczne :p) czego efektem powinno być zniknięcie wszystkich obiektów.
Fakt część obiektów znika np. wysięgniki czy podkłady, lecz reszta obiektów jest rysowana na całej długości scenerii co po przemnożeniu przez ilość obecnych wierzchołków modeli daje ogromną liczbę

LOD to nie jest odległość rysowania tylko Level Of Details - poziom szczegółowości. Niektóre obiekty nie muszą pokazywać wszystkich swoich szczegółów z dużej odległości, bo po prostu ludzkie oko i tak ich nie zauważy, dlatego posiadają zdefiniowany LOD. Zmniejszając LOD Bias zmniejszasz mnożnik tej odległości. Jeśli autor ustawił, że króliczek ma mieć wyraźnie widoczne uszka z 50 metrów, a Ty ustawiasz LOD Bias = 0.5, to uszka będą widoczne dopiero z 25 metrów.

Jeśli liczysz, że ustawiając LOD na zero znikniesz całą scenę, to jesteś w ogromnym błędzie.

Cytuj

Skybox (możliwe że przypadkowo) jest nieudolną próbą zasłonięcia tego że te obiekty są wyświetlane na całej długości (lub znikają w bardzo dużej odległosci)

Początek tego tematu zapowiadał rzetelne i poparte dowodami argumenty. Niestety, szerzysz na forum kolejną herezję.
Już u podstaw grafiki 3D, gdy powstawała pierwsza wersja openGLa, kamera pozwalała zdefiniować dwie płaszczyzny odcinania - bliską i daleką.
Są to dwie odległości przed którą i za którą nie widzisz żadnych obiektów. Zanim znowu napiszesz coś równie durnego, otwórz edytor, wznieś się na lekką wysokość i zobaczysz, że daleka płaszczyzna odcinania kamery schowa przed Tobą te obiekty, które są za nią. A niech stracę, zrobię to za Ciebie...


Jak widać na powyższym screenie, SkyBox nie odcina żadnych obiektów, odcięcie następuje wcześniej.


Cytuj

Wywnioskować z tego możemy, że w TD2 obiekty są renderowane nawet jak na nie nie patrzymy
Co powoduje ogromny spadek wydajności bo zamiast renderować tylko tego co widzimy (kąt widzenia dla którego powinny zostać wyrenderowane obiekty to średnio 150st.)
Przez to GPU oraz CPU musi wykonać średnio 2X więcej obliczeń niż tego potrzebujemy

Kolejna bzdura, jakich wiele tutaj na forum. Zaczniemy od źródła, czyli dokumentacji Unity: https://docs.unity3d.com/Manual/class-Camera.html
Note that the near and far clip planes together with the planes defined by the field of view of the camera describe what is popularly known as the camera frustum. Unity ensures that when rendering your objects those which are completely outside of this frustum are not displayed. This is called Frustum Culling.

Sprawdźmy jeszcze tą teorię w praktyce. Niestety, w badaniu wydajności gier nie używa się menadżera zadań, a trochę konkretniejszych narzędzi (kliknij, by powiększyć):



Nie wiem jak u Ciebie, ale u mnie czas poświęcony na renderowanie graficzne sceny spadł z 12ms do 1.5ms.
A u Ciebie nie...
Cytuj

Jak widać użycie CPU oraz GPU się nie zmieniło (lub spadło nieznacznie) mimo iż widzimy znacząco mniej obiektów

... porównanie danych na zasadzie - tu jest 1/2 a tu 1/3 wykresu nie jest miarodajne.

I teraz - zauważ - że ilość obiektów widocznych na scenie nie podniosła znacząco wydajności, zatem problemem nie jest ich ilość ani ich skomplikowanie.
I tu dochodzimy do sedna sprawy. Przez team TD2 przewijało się wiele osób. Niektórzy z nich byli profesjonalistami w tym co robią, niektórzy uczyli się dopiero programowania, a jeszcze inny poklikali trochę w edytor i znudziło im się to. Taka mieszanka spowodowała, że w TD2 jest obecnie wiele różnych szkół dodawania obiektów czy skryptów - każdy robił to tak jak uważał za słuszne - i dzisiejszym tego efektem jest wąskie gardło. To procesor nie nadąża wysyłać informacji o obiektach do wyrenderowania na scenie. Jak jednak pokazałeś powyżej - ilość tych obiektów nie wpływa znacząco na wydajność CPU. Zatem? Zatem powodem jest sposób ich transmisji. Współczesne karty graficzne oferują wiele technik, które pozwalają lepiej zarządzać przepływem danych z CPU do GPU. przykładem jest np. Vertex Buffer Object, Instancing. Dodatkowo po stronie CPU można wykorzystywać narzędzia takie jak Object Pooling, Mesh Baking, Light Baking.

Aha, ostatnio były problemy i pomówienia, że skora coś tam kiedyś pracował nad czymś, a później ekipa go wyrzuciła i wykorzystała jego robotę. No to pokażmy od kiedy pracujemy nad optymalizacją, żeby nie było niedomówień i teorii, że skora chciał dobrze, a cała reszta specjalnie psuje tedeka... I pokażmy efekty. W sumie, to zepsułeś niespodziankę dla użytkowników...



I optymalizacja: bez obiektów i renderingu: z 32 na 42 fpsy:


I później z optymalizacją procesu renderowania - 60:


Prace w Parzęczewie:


Prace na Helu:
Tak, materiały nagrywa się z ręki, telefonem, żeby nie zakłócać pracy CPU procesem nagrywania filmu i zachować miarodajność pomiaru
W przeciwieństwie do uruchomienia TD2 i Trainza na raz...

Oczywiście, fpsy mierzone w Unity są lekko zaniżone, bo sam edytor jest dość obciążającym procesem. A jak to wygląda w finalnym exe?


Oczywiście to nie tak, że w nowej wersji będziecie mieć 120 fpsów na każdej scenerii. Pokazałem tylko jakie są możliwości.
Optymalizacja procesu renderowania to dość czasochłonny proces. Jest to działanie poprzez szukanie dziury w całym, badanie renderowanego obrazu klatka po klatce, obiekt po obiekcie:



Cytuj

W drugim przykładzie na ten moment nie ma rozwiązania, w obecnej sytuacji zastosowanie skryptu który by blokował renderowanie niewidocznych obiektów (przy obecnej konstrukcji programu) jest niemożliwe do zrealizowania.

Nie ma rzeczy niemożliwych do zrealizowania. Jednakże, to rozwiązanie jest całkowicie zbędne. Jak wykazano powyżej, nie ilość obiektów i ich skomplikowanie są problemem, a sposób ich renderowania. I nad optymalizacją tego problemu pracujemy od początku roku. Miło, że chcesz zwrócić uwagę na problem, ale podpierasz się przy tym niepoprawnymi pomiarami i błędnymi argumentami. Później takie teorie krążą po forum i mamy całą armię specjalistów w każdej dziedzinie, bo usłyszeli oni to czy tamto.

Zaufajcie nam i dajcie troszkę czasu

Z powodu małego chochlika musiałem ręcznie przywrócić posty dlatego przy każdym widnieje adnotacja:

Kod: [Zaznacz]

Ostatnia zmiana: Dzisiaj o 22:xx:xx wysłana przez uetam


No to niezły chochlik mnie prześladuje :p

odsyłam do mojego postu na ten temat:
https://td2.info.pl/dyskusje/jak-podniesc-ilosc-fpsow-nie-wymieniajac-starego-komputera-na-nowy/msg51228/#msg51228