Panowie, chciałem zwrócić waszą uwagę na pewną kwestię, dotyczącą LoD - mianowicie, dyskryminuje on duże rozdzielczości renderowania.
W czym jest problem? Otóż, jak wszyscy wiemy, u jednego hipotetycznego użytkownika, który korzysta z symulatora w rozdzielczości 1280x960px, dany model przechodzi z jednego LoD (Level of Detail) w drugi, kiedy odległość między kamerą a obiektem przekroczy wartości min-/maxdistance* kolejnych LoD, zajmując przy tym (model) określoną liczbę pixeli na ekranie. Natomiast u innego użytkownika, który korzysta z symulatora w rozdzielczości 2560x1920px, ten sam model, przy tej samej przejściowej odległości, będzie zajmował dwukrotnie większą ilość pixeli. Tzn. czterokrotnie większą - rozmiary (wys. i szer.) podwoją się, a jak wszyscy wiemy 2^2=4.
Teraz, zadajecie sobie waszmoście pytanie - okej, wymądrzył się za dwóch, a teraz niech powie czego chce.
Otóż, proponuję szeroko pojętą redefinicję systemu LoD MaSzyny. Rozwiązanie powyższego problemu jest dość proste, na dobrą sprawę wystarczy przeskalować podane wartości min-/max distance w zależności od używanej rozdzielczości ekranu, wcześniej przyjąwszy jakąś rozdzielczość za wyjściową (taka, której używamy przy testowaniu LoD, którego celem jest dobranie odpowiedniej bariery min-/maxdistance) - z zasady ludzie którzy używają symka w dużej rozdzielczości dysponują lepszym sprzętem, niż ci, którzy grają w mniejszej rozdzielczości, ponadto zmniejszanie rozdzielczości wyświetlania często służy zwiększaniu fps - dzięki takiemu skalowaniu ten efekt wzmógłby się dodatkowo; nie występuje natomiast żadne optyczne czy to polepszenie, czy pogorszenie grafiki albowiem wyjściowo rozdzielczość rasterowania poszczególnych trójkątów w tej samej scenie pozostaje taka sama niezależnie od rozdzielczości.
Skoro przedstawiłem proste, zarówno koncepcyjnie jak i w metodyce wdrożenia rozwiązanie - dlaczego proponuję szukanie bardziej zawiłych rozwiązań?
Pragnę w tym momencie zauważyć, że aktualny system LoD jest systemem bardzo prostym, takim, który nie bierze pod uwagę wielu czynników, natomiast nasza percepcja opiera się na dalece większej ilości owych. Weźmy na przykład prędkość względną obiektu, względem obserwatora - w rzeczywistości, przy prędkości 250km/h (inna rzecz, czy patrzymy z bocznej szyby, czy czołowiej) nie dostrzegamy wielu detali obrazu, widzimy go bowiem zbyt krótki czas.
Tu pojawia się kwestia, którą ktoś poruszał jakiś czas temu - modelując nastawnię dla niezelektryfikowanego (jeśli dobrze pamiętam), starego szlaku, po którym skład miał się poruszać z prędkością 40 czy 20km/h, zastanawiał się ten jegomość, czy wymodelować jej wnętrze i w ogólnej dyskusji tego zagadnienia dotyczącej stwierdził, że na takiej trasie warto to wnętrze wymodelować, ponieważ jadący 20km/h obserwator będzie miał czas, żeby po pierwsze dostrzec, po drugie przyjrzeć się bliżej, a po trzecie docenić detale. Analogicznie wiele obiektów przy dużej prędkości rozmywa nam się w motion blurze, nie dostrzegamy detali, a gdy jedziemy powoli, to te detale cieszą nas niezmiernie.
Innym przykładem niech będzie skład jadący równolegle z nami - wysoki poziom detali na takim wpływa bardzo pozytywnie na odbiór produktu, jakim jest symek, kto z nas, widząc inny skład, jadący równo z nami, w bocznej szybie, nie ma ochoty popatrzeć sobie nań, przyjrzeć się wszystkim detalom, których być może nie dostrzegliśmy w ujęciu statycznym - analogicznie powinien działa symulator, pozwalając nam nacieszyć się tymi smaczkami.
Proszę panów szanownych o przemyślenia w tym temacie, bardziej, lub może lepiej mniej luźne oraz ogólnie rzecz biorąc propozycje - od czego waszym zdaniem powinien uzależniony być LoD?
Apeluję też, by zastanowić się nad tematem w dwójnasób, czy może nawet rozważyć trzy punkty widzenia. Pierwszym niech będzie percepcja samego użytkownika, efekt wizualny. Drugim niech będzie wpływ na wydajność pracy. Na przytoczonych powyżej przykładach - piękny model nastawni, z wymodelowanym wnętrzem, etc, kiedy go mijamy z dużą prędkością, wyświetla się na ekranie tylko przez kilka klatek. Jaki jest więc sens po pierwsze ładować na żądanie wszystkie modele i tekstury LoD po kolei, tylko po to, by zaraz je wyrzucić, po drugie pokazywać model w detalu, którego przez prędkość właśnie nie dostrzeżemy, ergo pozytywny pływ na wydajność i fps, bo kiedy jedziemy tą samą trasę szybko, to ta sama ilość modeli musi wyświetlić się w krótszym czasie, a żeby się wyświetliły, modele muszą zostać wysłane do GPU, a zmieniając (w funkcji prędkości) LoD zmniejszamy ilość modeli do przesłania (szczególnie tych o dużej rozdzielczości siatki - obszerne i bardziej flopochłonne w renderowaniu) i tym samym odciążamy sprzęt.
Trzecim punktem widzenia niech będzie metodyka wprowadzania udoskonaleń do systemu LoD. Przytoczony na początku przykład skalowania LoD w zależności od rozdzielczości, jest bajecznie prosty - trzeba przeskalować (jak to @Ra określił - po chamsku) wartości min-/maxdistance i w sumie roboty jest dość. Bardziej zawiłe systemy, jak np. uzależnianie LoD od prędkości, są dużo bardziej skomplikowane w realizacji (pamiętajmy, że renderer nie widzi w ogóle takich rzeczy jak prędkość (chyba, że jako parametr wejściowy dla motion blura, czy innego efektu post-rastrowego) niezależnie czy względna, czy bezwzględna, fizyka zresztą też się w małym stopniu interesuje takim zagadnieniem, jak prędkość względna (chyba, że zderzają się dwa wagony i fizyka chce wiedzieć jak bardzo ma animować zderzaki), więc poza pomysłem ogólnie, potrzebny jest też pomysł na realizację zagadnienia.
* inna kwestia, że bardzo łatwo popsuć - np. podać rozbieżne wartości min-/maxdistance w kolejnych LoD
P.S. Proszę o poważne posty.
Zamykam.
adsim
