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).

---