Praca silnikowa delikatnie wre

W końcu! Przepraszam, że tak długo trzeba było czekać na nową notkę. Wbrew pozorom, nie zapomniałem o tym miejscu w sieci – po prostu poprzedni semestr na uczelni był niesamowicie intensywny (chyba najtrudniejszy ze wszystkich, jakie dotąd miały miejsce), ale szczęśliwie udało mi się na nim skupić i mieć wszystko za sobą. Co prawda, to półrocze też na łatwe się nie zapowiada, ale istnieje szansa, że będę miał więcej ciekawych materiałów, o których mógłbym parę rzeczy napisać. Nie chcę już obiecywać (sami (nie) widzieliście co się działo), ale nie chcę, abyście myśleli, że zostawiam blogowanie. Także proszę mnie nie usuwać z czytników kanałów RSS czy innych zakładek.

Przy okazji – nadal trwają prace nad tłumaczeniem Wielkiego Mistrza na angielski. Idzie to powoli, ale co jakiś czas ktoś coś przetłumaczy, a inni się cieszą. Przypomnę może linka:

Tutaj można tłumaczyć Wielkiego Mistrza

I jeszcze raz zapraszam do dzielenia się z nami swoim czasem i umiejętnościami językowymi. Być może dzięki Wam Wielki Mistrz zostanie zauważony poza granicami naszego kraju.

Z innych ciekawostek – jak stosunkowo niedawno się dowiedziałem, na naszej uczelni działa nieformalne koło naukowe dotyczące gier komputerowych. Miejmy nadzieję, że wkrótce ruszą spotkania i zostanie dokończona procedura formalizacji organizacji. Jeżeli będę mógł Wam przekazać więcej informacji, z chęcią to zrobię w osobnej notce. Profil naszego koła (to znaczy tak – zacząłem chodzić na spotkania stosunkowo później, z powodu uprzedniej niewiedzy o istnieniu tej inicjatywy), jak nietrudno się domyślić, obejmuje wszystko, co jest związane z grami komputerowymi. Także nie jest to tylko grafika komputerowa, ale także fizyka, sztuczna inteligencja, komunikacja sieciowa, ale także takie sprawy jak organizacja pracy zespołu developerskiego, architektury gry (i generalnie większość rzeczy, które można podpiąć pod inżynierię oprogramowania), a myślę, że czasami będziemy też zahaczać o promocję czy ogólnie sprawy nieinformatyczne. Przynajmniej tak to sobie wyobrażam – koło dopiero się rozkręca. Warto też nadmienić, że jeśli ktoś po prostu chce zaprezentować swój powstający (lub też ukończony) projekt, to także jest mile widziany. Jak mówię jednak – więcej informacji postaram się dostarczyć wkrótce. No, może trochę później.

To, na czym chciałbym się skupić w tej notce (aczkolwiek nie będę się też jakoś długo skupiał, bo jeszcze jest to w fazie abstrakcji [a przynajmniej proporcje tego fragmentu nie będą znacznie większe od poprzedniego (znowu zakopuję się z nawiasami)]), to projekt, który troszkę już został zapomniany, także przeze mnie. Jednak cały czas istnieje i od czasu do czasu myślę, co w nim zrobić. Niestety, z powodu natłoku zajęć na uczelni przez ostatnie pół roku praktycznie nic się w nim nie działo, ale ponieważ przez parę pierwszych tygodni tego półrocza nie mam wielu rzeczy do roboty, toteż (poważnie się to pisze razem?) mogę sobie pofantazjować naukowo. O czym mówię? O silniku graficznym Scav.

Te osoby, które mnie znają, wiedzą, że z elementów graficznych interesują mnie (choć niestety czasami tylko koncepcyjne) obiekty naturalne sceny. Mówiąc bardziej po ludzku – wszelkiego rodzaju rendering trawy, wody, nieba, drzewek, trolli. Nie mam na tym polu dużych dokonań, gdyż nie jestem na tyle zaawansowany i umotywowany, aby wszystkiego próbować, ale swego czasu poczyniłem pewne kroki w wyświetlaniu trawy. Pamiętacie? Na devblogu artykuł też oczywiście się pojawił (właściwie to najpierw się tutaj pojawił) i został w nim opisany sposób generacji, wyświetlania i animacji trawy, który został z kolei oparty na przeróżnych źródłach dostępnych w Internecie, które zostały tam wymienione (w tym zwłaszcza na silniku Regedita (pozdrawiam)). Co prawda, moja trawa wygląda bardziej jak pole marchewek, ale jakoś to jednak działało i niektórym się nawet podobało. Ponieważ właśnie elementy trawiaste jakoś najbardziej mnie intrygują, postanowiłem kontynuować implementację silnika Scav właśnie w tym kierunku. Co prawda, pominąłem wiele innych bardziej potrzebnych rzeczy (na przykład to, aby aplikacje w Scavie jakoś w ogóle rozsądnie działały), ale wolę pisać coś, co mi się podoba, gdyż jest wtedy nieco większa szansa na ukończenie tej partii kodu. A przy okazji można sobie dywagować o tym na blogu czy właśnie kole naukowym.

Poprzednie podejście opierało się na tym, iż każda kępka była reprezentowana za pomocą trzech skrzyżowanych czworokątów, które zostały obłożone teksturą z kanałem alfa i tak przygotowane kępki kołysały się na wietrze przy dźwiękach rock and rolla wygrywanych przez shadera. Jak to wyglądało, możecie tam ujrzeć na screenach, ale chciałbym się skupić na tym, co było złe w tym podejściu. Pomijając fakt, iż sama koncepcja była w miarę prosta w implementacji, to:

• wyglądało to brzydko i nierealistyczne – jak już mówiłem, kojarzy mi się z polem marchewek (i to takich niesmacznych)
• shader obsługiwał tylko animację, ale już nie oświetlenie i współgranie z resztą terenu, choć to akurat była po części wina samej (de)konstrukcji frameworka Yesta
• teren wyglądał bardzo regularnie i były zbyt duże odległości pomiędzy poszczególnymi kępkami
• wygląd kępki mocno zależał od użytej tekstury – tę wadę można zatuszować poprawieniem poprzednich punktów (zagęszczeniem kępek, zastosowanie oświetlenia, zrandomizowaniem (mimo że to angielskojęzyczna kalka, to tutaj bardziej pasuje) ułożenia kępek), to warto by było wprowadzić jakiś poziom szczegółowości i część trawy oprzeć nie na kępkach, ale na pojedynczych źdźbłach
• generacja trawy była bardzo długa i można iść zrobić sobie herbatę, której tej trawa w dodatku sama nie robiła. Skandal

Generalnie jest dość dużo aspektów do poprawy. Zatem niedawno zabrałem się do wstępnego projektu nowej implementacji, która byłaby rozszerzeniem klasy CStaticMesh i jedno pole marchew… trawiaste byłoby traktowane jako jeden osobny mesh, na który składają się wierzchołki tworzące źdźbła czy kępki. Co prawda, przy wstępnym podejściu do kodu okazało się, że znowu konstrukcja silnika stoi nam na drodze, ale część już udało się zrefaktoryzować, część na to czeka, a część “umownie” ominąć (np. poziomy szczegółowości to osobne materiały – dziwne, ale myślę, że zadziała. O ile nie zapomnę, o co mi chodziło). Dla każdej kępki będą generowane trzy reprezentacje – (1) quady składające się na poszczególne źdźbła, (2) trzy skrzyżowane quady tak jak poprzednio, (3) jeden quad zwrócony w kierunku obserwatora – natomiast decyzja, który poziom będzie wyświetlany, będzie zależał od odległości od oka kamery. Ponadto postanowiłem przyłożyć się do algorytmu rozmieszczania kępek i dać większą możliwość ich zagęszczania, aczkolwiek tutaj właśnie są pewne problemy natury matematycznej, z którymi jednak mam nadzieję, że sobie poradzę (i znajdę na to czas). Trudno będzie natomiast wypracować szybkość generowania i wyświetlania tej trawy przy takich założeniach – to również pozostaje kwestią wewnętrznych dyskusji w mojej głowie.

Ale być może będziecie mieli jakieś własne przemyślenia lub też gotowe rozwiązania, które już na pierwszy rzut oka wydają się znacznie lepsze od moich zamysłów? Tak czy inaczej, jak zwykle, zapraszam do komentowania i krytykowania w komentarzach.

Pozdrawiam i dziękuję za cierpliwość - SceNtriC