Od ponad roku testowałem który format tekstur jest najlepszy dla wydajności OMSI 2. W ramach tego eksperymentu zmieniałem używane tekstury wszystkich obiektów scenerii na mapie (w niektórych przypadkach również splinów), a następnie robiłem próbne przejazdy (oczywiście tym samym autobusem). Mapy których używałem są bardzo wymagające, więc różnice były widoczne na pierwszy rzut oka. Udało mi się przetestować wszystkie powszechnie używane formaty (BMP, DDS, JPG, PNG, TGA) i chcę się podzielić swoimi spostrzeżeniami.

Zanim zaczniemy warto wspomnieć, że pod pojęciem wydajności rozumiem dwie rzeczy - ilość fpsów oraz ilość "freezów" wraz z ich długością. Są one od siebie niezależne, co może ułatwić dobór formatu.

Ilość klatek na sekundę zależy od tego, czy dana tekstura posiada wygenerowane mipmapy. Generowanie mipmap polega na tym, że tekstura zawiera pomniejszone wersje samej siebie. Dzięki temu możemy troszkę odciążyć silnik OMSI, który w trakcie gry musi ciągle skalować wszystkie tekstury w zależności od odległości z jakiej na nie patrzymy. Z formatów które wymieniłem, to tylko BMP i DDS obsługują mipmapy, ale w przypadku DDSów trzeba zaznaczyć odpowiednią opcję przy eksporcie.

Teraz przejdźmy do zacinania się gry. Wynikają one z wczytywania się tekstur, natomiast rozmawiamy o OMSI, więc rozwiązanie problemu nie jest oczywiste. Z moich doświadczeń wynika, że najlepiej w tej kwestii radzą sobie BMP i JPG, chociaż format JPG ma inny problem do którego przejdę za chwilę. Moja teoria jest taka, że wynika to z faktu, iż OMSI ma oznaczone te formaty jako nieobsługujące przezroczystości, a w przypadku każdego innego formatu OMSI od razu zakłada, że ten będzie miał w sobie przezroczystość, bez patrzenia np. czy istnieją wpisy [matl_alpha] i zaczyna go całego skanować. Ale wróćmy do wątku formatu JPG. Jest to format mocno skompresowany, więc mimo wszystko nie wczyta się on od razu. I tutaj mamy ciekawą sytuację - OMSI nie będzie czekać aż dekompresja się skończy, tylko pozwoli aby symulacja trwała dalej, a na potrzebny czas tekstura będzie biała. Nie może to jednak trwać wiecznie, więc jeżeli po 3-5 sekundach nadal tekstura będzie biała, to symulacja znowu się zatrzyma i będzie czekać aż do końca dekompresji. Tak więc używając formatu JPG będziemy spotykać białe tekstury (a gdy jedziemy szybko, to nie zdążą zniknąć, co źle wpływa na estetykę gry), a czasami i tak nie będziemy w stanie uniknąć laga.

Łącząc obie wypowiedzi nasuwa się wniosek, że do tekstur z przezroczystością najlepszy będzie DDS, a do zwykłych BMP. Niestety jest jeden problem o którym nie wspomniałem - waga tekstury. W tej kwestii najwięcej ma do powiedzenia twórca danego obiektu. W obu formatach liczy się tylko wielkość danej tekstury i nic więcej. Nie wydaje mi się, aby był sens upychać do OMSI tekstury w nie wiadomo jak dużej rozdzielczości, a są różne sposoby aby efektywnie wykorzystać już konieczną do zajęcia przestrzeń. Oczywiście, że znajdą się od tego wyjątki - chociażby malowanie autobusu. Gdyby spróbować przekonwertować malowanie SU18 do formatu BMP, to otrzymalibyśmy teksturę o skromnej wadze 17MB. Można próbować zmniejszyć format kolorów do 8 bit, wspomagać się ditheringiem i przełknąć fakt, że tekstura nie będzie najlepszej jakości. Można również pogodzić się z losem i użyć PNG aby jak najmocniej zmniejszyć wagę tekstury. Natomiast naprawdę zachęcam do podjęcia walki - fpsy mogą podskoczyć nawet dwukrotnie, a "freezy" gry można praktycznie całkowicie wyeliminować.

Jeżeli uważacie, że coś jest nieprawdą, o czymś nie wspomniałem, lub macie własną wiedzę do dodania, to zachęcam aby się tym podzielić.

Ja wpadłem na jeszcze inny pomysł tworząc budynki do niedoszłej aktualizacji Projektu Lublin. Obserwując ile trwa kopiowanie małych plików, a ile dużych doszedłem do wniosku, że lepiej będzie stworzyć duże tekstury 4096x4096 do wielu obiektów niż kilkanaście pomniejszych teksturek. W ten sposób stworzyłem teksturę do kilkunastu unikalnych budynków. Udało mi się tak poupychać, wyskalować te tekstury że zapełniłem szczelnie całą przestrzeń. Wyglądało to tak jak na załączniku tylko 4096x4096.

Załączone pliki

Miniatury
   

Taka tekstura niestety będzie dużo ważyć, natomiast przyznaję że nie testowałem jaka jest różnica w wydajności między jedną dużą teksturą do wszystkiego, a kilkoma mniejszymi. Możliwe że takie rozwiązanie jest nawet lepsze, ale trudno mi będzie to sprawdzić.

Przy okazji zrobiłem 2 testy:

Dzięki pierwszemu potwierdziłem, że OMSI tylko raz wczytuje teksturę o danej ścieżce. Mówiąc wprost - jeżeli 10 obiektów używa tekstury z tego samego miejsca na dysku, albo w danym obiekcie tekstura jest użyta kilka razy, to OMSI i tak wczyta tą teksturę tylko jeden raz.

W drugim teście postawiłem obiekt i zmieniając format jego tekstury badałem jak zmienia się zajętość pamięci tekstur pod shift+y. Okazuje się, że formaty JPG i PNG zajmują więcej tej pamięci niż formaty BMP, DDS i TGA. Tekstury z pierwszej grupy zajmowały o 25% więcej pamięci niż te z drugiej, mimo że na dysku ważyły mniej.

Ja osobiście preferuje format .tga. Nie dość że jest znacznie lepszy optymalizacyjnie niż .jpg, .png, nie jest archaiczny jak .bmp, to jeszcze eksportuje mi sie go znacznie szybciej i sprawniej niż .dds(w dodatku nie jest on stratny jak .dds, otwieranie i eksportowanie go wiele razy nie robi mu różnicy).

---

dodatkowo .tga przy mniejszych rozdzielczościach ma benefit tego że jego kompresja potrafi bardzo zaoszczędzić na miejscu na dysku, po drugie jest formatem bezstratnym. DDS niby jest najlepszy, ale bezstratne wersje DDS zajmują dużo miejsca na dysku, bmp jest archaiczne, jpg jest absurdalne, a końcowo to na wydajność będzie wpływać więcej czynników niż format tekstur. Dodatkowo warto uzmysłowić sobie że 4096x4096 a 2048x2048 nie jest 'dwa razy większe' a cztery razy większe. Tak więc trzeba mieć też na uwadze dobór rozmiarów tekstur, a nie sam ich format, bo 1k png będzie lepsze niż 4k dds w pewnych sytuacjach.

---

A ja trochę stanę tutaj okoniem, bo przetestowałem sobie trochę i wyszło mi, że...

Że w sumie to bez znaczenia jaki format użyjecie do tekstur, bo to wpływa tylko na ilość pamięci jaką będzie potrzebować karta graficzna - a tutaj png jest najlepsze

Dla omsi na wydajność wpływają dwie rzeczy:
- ilość geometrii (trójkątów i wierzchołków - tak sprawdzałem, czy pojedyncze wierzchołki zżerają fpsy i tak, zjadają).
- ilość materiałów (nie mylić z teksturami)


A teraz kilka słów:
Ustawiłem na pustym kaflu 5000 sześcianów takich samych oteksturowanych 6-cioma różnymi formatami tej samej tekstury (po jednym materiale na kostkę):



i na moim komputerku:


wyniki wyglądają tak:

png - 96fps
dds - 96fps
dds_opt2 - 96fps
jpg - 96fps
tga - 96 fps
tga_oryg - 96fps

Czyli dokładnie to samo. Omsi o dziwo potrafi pogrupować sobie te same materiały w kopiowanych obiektach, więc suma zużycia pamięci to było waga 1 tekstury + tekstura podłogi



---
Ale ciekawie dopiero robić się zacznie.
Ta sama kostka, ta sama tekstura, ilość pamięci wykorzystanej taka sama, a fpsów: PRAWIE 2 razy mniej.


Gdzie jest haczyk?
Każda ściana ma dedykowany materiał z tą samą teksturą.
Nie jestem specjalnie ździwiony, bo to jest coś, o czym generalnie wiedziałem już wcześniej, natomiast okazuje się, że nieużywane materiały (takie, które w blenderze stworzyliśmy, ale ich nie użyliśmy) wpływają w identyczny sposób na wydajność (zmniejszają fpsy jak cholera) - uprzedzam pytania, używałem wtyczki https://github.com/space928/Blender-O3D-IO-Public, w pliku sco nie było nadmiarowych maltów, ale w pliku o3d wtyczka te nieużywane materiały zapisuje.

No i na koniec ostatni test:
Skopiowałem plik o3d (ten, co ma 1 materiał), zrobiłem drugi plik sco i podzieliłem ich rozkład na mapie na 2, żeby sprawdzić jak omsi radzi sobie z alokacją takiego samego materiału w dwóch różnych obiektach - i tutaj znowu punkt dla omsi. Identyczna liczba fpsów jak przy takim samym obiekcie.

Wniosek zatem jest taki:
To co zrobił Barcik jest najlepsze dla wydajności o ile pracujemy na tym samym materiale w blenderze.

Aczkolwiek ze swoich obserwacji muszę dodać jeden ciekawy fakt - jak OMSI chce już palić tekstury, bo coś, to w ostatniej kolejności pali ddsy, pierw pozwala się palić wszelkim tga i png.

---

Jeżeli w materiale mamy nadaną teksturę przykładowo .png a w folderze na tekstury mamy .png oraz .dds, to wczytana zostanie tekstura o rozszerzeniu .dds. Ma ona pryiorytet ponad resztę formatów.

---

Pracując nad nEdytorem postanowiłem na krótki skok w bok i zaimplementowałem kod, który merguje wierzchołki o tej samej pozycji oraz scala wszystkie materiały robiąc jeden duży atlas.

Póki co nie działa to idealnie, ale nie ma to znaczenia, bo tekstura się nałożyła, a obiekt ma dokładnie takie same parametry geometrii.

Mam tutaj taki tragicznie zoptymalizowany pod kątem omsi obiekcik jakiegoś beznadziejnego autora:
Ma on uwaga 17 materiałów, czy 17 drawcalli musi wykonać procesor (btw. jak trzeba być zdolnym, żeby z 5 tekstur zrobić 17 materiałów? ).




Ma on 76 trójkątów i 129 wierzchołków (zatem ten obiekt akurat scalenia wierzchołków nie potrzebował).

No i 5 tysięcy takich domków z 17 drawcallami w omsi wygląda tak:


5.7MB na karcie graficznej, a średnio 13 fpsów, czyli szału nie ma

No to teraz po puszczeniu przez programik, który wygenerował atlas i zmergował wszystko w jeden materiał:

(co prawda ściany są odwrócone do wewnątrz, a UV mapa to dramat, ale to bez znaczenia - przy poprawnej uvmapie byłoby podobnie).

Jak widać na kartę poszło trochę więcej MB, bo mapa atlasu najoptymalniej nie została wygenerowana, ale zamiast 13fpsów mam średnio 98 fps.

Za taki program który automatycznie optymalizuje obiekty postawiłbym piwo, a nawet i całą skrzynkę wódki.

Ogółem jestem ciekaw ile taki sposób by potrafił podnieść fpsy na niektórych mapach które znane są z tego że są ciężkie.

---