FORUM PTT -

POMOC 2D - Wydajność tekstur/polygonów
Qń - 26-12-2012, 14:43
:
@Cameron: No niestety ale przy 9 teksturach i ponad 700kB grafiki to "zamordowałeś wydajność". Szczególnie, że skoro nie stosujesz klonowania, to można było wszystkie główne tekstury skleić w jedną. Przykładowo skleiłem tekstury:

Jedyne co musiałem minimalnie zmniejszyć to tekstura komina (tak, żeby weszła w trójkąt obok dachu. Inne tekstury mają rozmiar identyczny jak w oryginale. Zamiast tego czarnego kwadratu 16x16 pikseli, który jest typowym mordercą wydajności użyłbym małego fragmentu tekstury głównej nad trójkątem dachu przybudówki (przy jednolitej teksturze nie widać rozciągnięcia). Wszystko zawiera się w rozmiarze 512x512. Do tego pojawiło się więcej miejsca (można rozsunąć tekstury, a w modelu ograniczyć liczbę polygonów), widać że część tekstur ma niespasowany odcień. Sumaryczna waga tekstur jest taka sama ale ilość mniejsza o 8. Tutaj jest potężny zysk na wydajności.
Pomyśl nad tym.
McDreamy - 26-12-2012, 16:03
:
Nigdy nie opanowałem sztuki takiego teksturowania, zawsze wszystko jechałem z pojedynczych tekstur. Wybierałem ścianę, "m" > "new" > "standard" > ...

Ale chętnie się nauczę.
kilanziom - 26-12-2012, 16:05
:
A ja będę w opozycji, bo ostatnio zaczynacie być strasznie nachalni z tymi opowieściami o wydajności mniejszej ilości dużych tekstur. To jest uzależnione od kilku czynników i sprawdzałem to na paru komputerach, wnioski mam bardzo niejednoznaczne.

1). Mała ilość dużych tekstur jest wydajna tylko przy bardzo potężnej karcie graficznej typu 1024mb grafiki wzwyż. Przy mniejszych ilościach na dużych mapach wyraźnie zauważalne są irytujące czknięcia przy wczytywaniu modeli zbudowanych metodą 'duże tekstury', zwłaszcza tabor (tu ciepłe pozdrowienia dla modelu SP42, który jest w stanie sam bez pomocy wagonów wykończyć grywalnosć dużej mapy). Ponieważ nie ma zasady, że wszyscy mają super karty graficzne, należy się z tym faktem liczyć. Czka albo grafika albo silnik JET kiedy ma do czynienia z dużym plikiem i go rysuje.

2). Nawet bardzo wielkie ilości polygonów nie są dla silnika JET czymś znamiennym, bez względu na kartę graficzną. Na dużych mapach bez problemu wczytują się różne modele (nawet zgrupowane) o wysokim polycouncie. Przykładem niech będą samoloty (przeciętnie 8-9 tysięcy trójkątów) albo parowozy. Parowozy miewają od 20 do 220 tysięcy polygonów, ale czkać zaczynają te, w których autor dał duże tekstury (bez znaczenia czy luzem czy zgrupowane - duże czkają). Jeżeli jedna dodatkowa tekstura to w przełożeniu z kb na poly ~ +500 poly, to prawdę mówiąc nie zauważyłem specjalnych skoków przy takich dodatkach na dużej mapie, natomiast jak już wspominałem - czkają te, gdzie są wielkie tekstur, które musi w pewnej chwili łyknąć karta via silnik.

3). Wygoda robienia. W ostatnim czasie wiele rzeczy opracowywałem sumując większą ilość tekstur na jednej i rozprowadzając je na modelach (np. model wału kardana, który cały siedzi na 1 tex). Z perspektywy wygody modelarskiej jest to ~2-3 krotnie bardziej czasochłonne i wymagające dużo dokładniejszego spasowania tekstur niż klasyczne modelowanie z mapowaniem metodą UWV Map. Z perspektywy dużego zapotrzebowania na modele i nie wielkiej ilości czynnych modelarzy (dla mnie) prędkośc wykonania dodatku i wygoda jego wykonania są sprawą kluczową. W tej chwili stosując metodę grupowania tekstur jestem ~50% mniej wydajnym twórcą niż wcześniej przy znikomych zyskach wydajności jakie obserwuję na swoich mapach na kilku komputerach - o ile jakiejkolwiek.

Mój pogląd to czysta praktyka, więc z góry oświadczam, żeby nie przekonywać mnie tym co napisał Auran. Jestem praktykiem, teorie mnie nie interesują. Praktyka wskazuje, że temat mapowania i ilości tekstur vs. ilości poly nie jest jednoznaczny i w dużej mierze zależy od konfiguracji komputera i preferencji modelarza.

Namawiam zatem do dystansu w tych sprawach.
drstrach - 26-12-2012, 16:34
:
Tak Kilan, tylko nie zauważasz jednej zasadniczej kwestii. Duża ilość plików to zabójstwo dla procesora i dysku. Przypomnę, że to wszystko trzeba w końcu wczytać z dysku (czyli najlepszym rozwiązaniem jest SSD) i rozpakować (dobry procesor). Im więcej plików, tym gorzej, tym lepsze powinny być te dwa składniki. Rozumiem wygodę ale niestety jest ona nieefektywna, przynajmniej jeśli te wszystkie modele nie korzystają z jednej tekstury (taki sposób był dostępny w TRS2004 i jest od TS2009 w Mesh_Library). Niestety, nie ma nic za darmo.

Tak na boku tej dyskusji pozwolę sobie na dygresję.
Zauważyłem ostatnio, że największą bolączką Trainz-a jest właśnie jego sukces, czyli duża ilość twórców tworząca dużą ilość model. Niestety z punktu widzenia wydajności gry jest to zabójstwo. Jeśli na mapie nie zastosuje się kilku modeli na krzyż, wyrzucając całą resztę na śmietnik, to nie istnieje taki sprzęt, który byłby w stanie to uciągnąć. Niestety Trainz nie daje możliwości korzystania z ogólnej biblioteki tekstur (np. biblioteki okien) i wszystko trzeba po kawałku robić samemu, co jest raczej mało efektywne.
Qń - 26-12-2012, 21:16
:
@Kilan:
Ad.1 Tutaj nie Przedstawiasz żadnych dowodów. Bo Mówisz "duże tekstury", a to nie jest to samo co "mała liczba tekstur". To, że silnik TRS ma problemy z grafiką to wszyscy wiemy. Dlatego należy modelować oszczędnie, nikt nie namawia do stosowania wielkich rozmiarowo tekstur. Tylko na logikę dlaczego większa liczba mniejszych tekstur miałaby zmniejszyć obciążenie karty graficznej? Przecież na pewno jest jakiś koszt wczytania 1kB grafiki na danym sprzęcie, niezależny od rozmiaru pliku. Do tego dochodzi koszt wczytania kolejnego pliku, niezależny od jego wielkości. I to wszystko jest logiczne, bo przecież wiadomo, że każda następna mapa oznacza konieczność wykonania przez komputer dodatkowych operacji logicznych (pobranie z dysku, odczytanie itd.). Ja wierzę w tym względzie Auranowi, bo to oni dysponują wiedzą na temat Jet Engine (czyli kodem źródłowym). Ty natomiast podajesz jakieś zupełnie absurdalne przykłady w stylu SP42. Tak, ten model może wykończyć słabszą kartę graficzną, tylko co to ma wspólnego z niewielką liczbą tekstur? Bo tekstur w SP42 jest ponad 40!, do tego całość waży prawie 12MB. Zestawiając to wszystko razem wychodzi oczywiście bomba wydajnościowa. Tylko to jest antyprzykład modelarstwa w ogóle, a nie jakiś konkretny dowód. Poza tym, ja bardzo nieufnie podchodzę do stwierdzeń typu "czka", bo z poziomu użytkownika często trudno znaleźć obiektywną przyczynę takiego stan rzeczy (najlepszy przykład to te nieszczęsne długie odcinki prostych torów bez punktów środkowych, które mulą stację chociaż wokół nie ma nic niewydajnego).
Tutaj sprawa ma się nieco inaczej. Na naszej scenie od dłuższego czasu zapanowała polityka "zwiększania wydajności", rzecz jak najbardziej chwalebna i potrzebna. Tylko do tej pory wszyscy skupili się na jednym aspekcie tego zagadnienia czyli wielkości plików grafiki. I to już jest niebezpieczne, bo prowadzi do fałszywych wniosków, gdzie zamienia się zbiorczą mapę tga na dwie mniejsze żeby zaoszczędzić te 30kB, kiedy w trosce o wydajność należałoby zrobić coś zupełnie odwrotnego. Robi się sytuacja podobna do unijnej walki z ociepleniem klimatu, która prowadzi do zupełnie irracjonalnych działań i nie przynosi żadnych efektów. Dlatego trzeba o tym trąbić, mówić, powtarzać, tak żeby podejmować świadome modelarskie wybory. Nie jest to żaden dogmat, krucjata itp. Po prostu tylko mając pełny obraz sytuacji można wprowadzić skuteczne działania. Inaczej kolejne wymiany dodatków, zwiększanie wydajności itd. są od razu skazane na niepowodzenie.
Nie łudźmy się, nie zobaczy się gołym okiem wzrostu wydajności domku który zamiast na 4 teksturach będzie siedział na jednej. Natomiast jeżeli globalnie zmniejszymy liczbę tekstur na mapie (czyli np. ze średnio 5 per dodatek na 3) to możliwe, że coś drgnie. Ja przynajmniej przyjmuję do wiadomości to co w tym względzie mówi do nas Auran.

Ad.2 Co do liczby polygonów to pełna zgoda. Na wydajność wpływają w dużo mniejszym stopniu niż grafika. Chociaż z drugiej strony większość obiektów u nas stosowanych ma bardzo umiarkowaną liczbę polygonów więc trudno powiedzieć co by było gdyby do mapy pakować np. niemieckie żurawie wodne 20000+. Poza tym odczucie płynności w TRS raczej nie jest psute przez jeden niewydajny model. To byłoby za proste. Na to składa się przecież wiele obiektów, wpływ ma też ich różnorodność w danym miejscu. Znowu łatwo się czymś fałszywie zasugerować.
Tutaj znowu przywołana jest teoria "dużych tekstur". Teoria nie mówiąca nic o liczbie plików. To że dodatek jest na jednej teksturze wcale nie oznacza, że będzie ona wielka (u mnie przynajmniej dodatki o mapach 512x512 albo 512x1024 nie czkają, a to jest już wielkość którą można spokojnie oteksturować skomplikowane i duże obiekty). Karta via silnik tak samo musi łyknąć 1Mb grafiki w 10 plikach jak i w 1 pliku, cudów nie ma.

Ad.3 Jestem w stanie uwierzyć, że obiekt na oddzielnych teksturach robi się wygodniej. To prawda. Tylko oznacza pogodzenie się z utratą wydajności. O ile jest to wybór świadomy to OK. Ja bym jednak namawiał, do wydajności bo nasza scena za dużo w tej dziedzinie osiągnęła żeby się teraz cofnąć. W przypadku obiektów scenery, gdzie tworzenie w GMaxie zajmuje stosunkowo niewiele czasu wydaje się to być proste do zrobienia. Osobiście wolę poświęcić te pół godziny więcej na dodatek i ograniczyć liczbę tekstur niż produkować kolejny model wieloteksturowy. I żeby nie było wątpliwości. Ja nie namawiam do wpychania wszystkiego na siłę na jedną teksturę! Po pierwsze proponuję ograniczać małe tekstury (takie jak rynny, kominy, kwadraty 16x16 pikseli itp.). Tutaj jest największe pole do optymalizacji i nie są to zabiegi uciążliwe). A jeżeli globalnie (ważny aspekt całej sprawy) uda się zejść ze średnią liczbą tekstur na dodatek o 20% to już będzie osiągnięcie. Jeżeli dodatek ma mieć dla wygody 2-3 tekstury (bo np. jest klonowanie albo tak nam się rozmiary ułożyły) to przecież nic się nie stanie. Zamiast tego walczmy z przyzwyczajeniami robienia dodatków które mają 200kB grafiki i 15 tekstur, bo one psują wydajność zamiast ją poprawiać.
Podobnie jest z taborem. To nie ma być festiwal "upchaj wszystko na jednym". Natomiast wywalanie każdej pierdoły do oddzielnego pliku jest działaniem biegunowo różnym od poprawiania wydajności. Przez samo zgrupowanie niektórych drobiazgów (tarcze zderzakowe + tuleje + elementy sprzęgów powietrznych, sprzęg śrubowy + ogrzewczy, różne elementy wnętrza razem) można znacząco ograniczyć liczbę map, a jednocześnie zachować pewną uniwersalność pozwalającą przenosić znormalizowane elementy do kolejnych modeli. Tutaj jest milion rozwiązań pośrednich i każde w jakimś stopniu poprawia wydajność!
Poza tym zdradzę wam pewien "sekret firmowy". W przypadku taboru przyjęcie jako wysokość tekstury pudła 128 pikseli automatycznie powoduje nieczytelność opisów na nim zrobionych (żadne wyostrzanie nie pomoże, zawsze będzie lipa). Zwiększenie wysokości do 256 pikseli to automatyczne bardzo duże zwiększenie wagi modelu. Natomiast jeżeli za wysokość ściany przyjmiemy ok.200 pikseli, to jakoś opisów bardzo wyraźnie wzrasta, a waga grafiki tylko troszkę. Jest jeden warunek. Trzeba robić tekstury skomasowane i dobrze wykorzystać te pozostałe 56 pikseli tekstury głównej (na różne detale których w taborze nie brakuje). Popróbujcie, na prawdę warto!

Ad.4
Przykro się to czyta. Bo to taka deklaracja "Ja wiem lepiej i żadne nowe metody mnie nie interesują". Przykre, bo wypowiedziane z ust które kiedyś wniosły ogrom nowości do polskiego i nie tylko polskiego TRSa. A teraz traszna "konserwa" z Ciebie wyszła.

Namawiam zatem do bliższego przyjrzenia się tej sprawie.
drstrach - 26-12-2012, 22:01
:
Qń ładnie to wszystko ująłeś, ja nie dałem rady, chyba za bardzo się odmóżdżyłem w te święta :-)

Wracając do dyskusji, IMO niezłym sposobem zwiększenia wydajności byłoby przerzucenie obiektów powtarzalnych do osobnych siatek i wczytywanie tych siatek do modeli jako dodatków typu mesh. Aż prosi się żeby takiej rzeczy dokonać przy sprzęgach, czy buforach. IMO taki ruch powinien dość mocno ograniczyć ilość tekstur na modelach taboru. BTW sprawdziłem to rozwiązanie w przypadku cieni pod wagonami. Dzięki przerzuceniu ich do osobnej biblioteki i dystrybucji po różnych wagonach, takie cienie wczytują się dużo szybciej niż pozostałe tekstury wagonów. Dochodzi do takich kuriozów, że zanim wczyta się sam wagon już mam wczytany cień, który został wykorzystany już w modelu stojącym na mapie.
Kudłaty - 26-12-2012, 22:26
:
Cytat:
Wracając do dyskusji, IMO niezłym sposobem zwiększenia wydajności byłoby przerzucenie obiektów powtarzalnych do osobnych siatek i wczytywanie tych siatek do modeli jako dodatków typu mesh


Niewątpliwie masz rację, Strachu - takie rozwiązanie pewnie sprawdziło by się w przypadku taboru. Tylko co z modelami, które już istnieją? Taka operacja wymagała by ponownego wydania kilkuset modeli. Z punktu widzenia "tfurcy" - masakra, ja bym się na coś takiego nie pisał, nigdy w życiu.

Tak sobie myślę - czy nie było by dobrym rozwiązaniem stworzyć normę czy zbiór norm dotyczących wielkości i ilości tekstur obowiązujących w dodatkach?

Wiecie o co chodzi - ustalamy twardo, np. że w dodatkach typu ogrodzenia tex ma mieć max. 128x128px, w domach parterowych 512x256px lub 256x256px, td, itp...

Ja na przykład moje ostatnie magazyny z Kompleksu warsztatowego zrobiłem na teksturach 256x512px. Takie założenie bardzo ułatwiało mi pracę, wiedziałem, że mam konkretne wytyczne (co prawda tylko w mojej głowie) ale efekty IMO są bardzo dobrze - magazyny na mapce śmigają aż miło i można ich ustawiać mnóstwo bez strat na jakości.
drstrach - 26-12-2012, 22:36
:
Qdaty napisał/a:
Niewątpliwie masz rację, Strachu - takie rozwiązanie pewnie sprawdziło by się w przypadku taboru. Tylko co z modelami, które już istnieją? Taka operacja wymagała by ponownego wydania kilkuset modeli. Z punktu widzenia "tfurcy" - masakra, ja bym się na coś takiego nie pisał, nigdy w życiu.

A czy ja pisałem, że trzeba bebeszyć modele już istniejące? Nie wydaje mi się.

Qdaty napisał/a:
Tak sobie myślę - czy nie było by dobrym rozwiązaniem stworzyć normę czy zbiór norm dotyczących wielkości i ilości tekstur obowiązujących w dodatkach?

Nie da się, i to nie dlatego, że scenę tworzy grupa indywidualistów, tylko w większości przypadków zastosowane rozwiązania zależą od modelu i materiału jaki do tworzenia się wykorzystuje.