HDR, Mesh i takie tam narzekania

Znowu ktoś mi wytknie, że zaczynam kolejną notkę od usprawiedliwiania się za małą aktywność na tej stronie w ostatnim czasie. Niestety - gorący okres a uczelni i inny projekt sprawia, że nie mam za bardzo czasu na literackie wyrażanie swoich myśli. Dobre jest jednak to, że powoli (bardzo powoli) kończy mi się taki pierwsza "gorączka" w semestrze i być może uda mi się częściej coś napisać.

Nawiasem mówiąc, nie życzę nikomu pisania programu na zaliczenie (z Delphi) w taki sposób, jaki ja to wczoraj robiłem. Przez dwa tygodnie nie mogłem znaleźć błędu, który niszczył realizację polecenia liczenia wygranych w wyścigach konnych. Mniejsza o treść - po prostu jak głupi, przez cały czas szukałem błędu w procedurze obliczającej wyniki - zmieniałem, grzebałem, dodawałem, odejmowałem, wrzucałem do biblioteki DLL, wyrzucałem z niej. I co? Okazało się, że błąd leżał w wyświetlaniu w komponencie Memo... Dowiedziałem się o tym wczoraj o 21 i po poprawieniu zacząłem kreślić schemat blokowy. W momencie, kiedy rysowałem szóstą stronę A4, z pocieszającą wieścią odezwał się kolega, który poinformował mnie, że schematu do tego programu nie trzeba oddawać...

Cóż, wypadki chodzą po ludziach. Trafiający ich szlag również. Tak czy inaczej, na dwa tygodnie przed terminem uzyskałem zaliczenie z tego programu, choć jakby tak popatrzeć, wcale okropny nie jest - pod warunkiem, że bym go pisał w C++, a nie Delphi. Choć z nim też miałem do czynienia, konkretnie z Pascalem. Kiedyś. Aczkolwiek dłużej w nim dłubałem aniżeli w C++.

W każdym razie - nieważne. W planach mam też notkę poświęconą organizacji zespołu tworzącego grę przez Internet - taki plan na przyszłość. Dzisiaj jednak chciałem się zająć tym, co w ostatnim - hmmm - miesiącu (chyba) dopisałem do Yesty. A muszę przyznać, że niezbyt dużo. Zresztą z tych samych powodów, co długie przerwy pomiędzy notkami. I do tego jeden "ficzerek" został błędnie zaimplementowany, aczkolwiek po 3 tygodniach walki uznałem, że i tak nie znajdę błędu, jak go będę szukał - stanie się to na przykład przy wiązaniu butów czy innej prozaicznej czynności.

Aha - ktoś (chyba Shirou Noir - pozdrawiam) ostatnio mnie nakłaniał o opisaniu "życia uczelnianego" (oczywiście, tego naukowego, bo z towarzyskim mam mało wspólnego). Spokojnie - jeśli zbierze się dostateczni dużo materiałów, to felietonik będzie.

High Dynamic Range Rendering

Otóż, na bazie tego przykładu, udało mi się dołączyć do przestrzeni nazw CEffects efekt HDR na bazie shaderów CG (w przykładzie jest na GLSL) oraz wielu niepotrzebnych i niedziałających zmiennych typu OKTTT (O Kant Tyłka To Trzasnąć). O dziwo, sam algorytm działa w miarę poprawnie - jest widoczny efekt zwiększonego zakresu barw i potwornej jasności, co można w sumie już nazwać efektem bloom (choć tak naprawdę, mieszają mi się definicje - dla mnie bloom to odmiana HDR, która jedynie bardziej rozjaśnia jasne miejsca). Jaki jest więc problem? A taki, że tekstura (specjalnie przygotowana w formacie RGBE) niesamowicie się rozjeżdża ku górze. Co ciekawe, na te rozjechane miejsca również działa efekt HDR. Dodatkowo, nie udało mi się zmusić już "powalającego" (jeśli chodzi o sposób komplikacji) kodu do zatwierdzania więcej niż jednej tekstury HDR. Cóż - rozwiązanie przyjdzie z czasem.

Mesh, czyli siatka wierzchołków

Postanowiłem połączyć relaksujące z pożytecznym. Mianowicie, chciałem napisać coś, do czego nie będę "używał" tutoriali (jeśli chodzi o sam cel kodu) oraz wykorzystującego jakąś fajną mechanikę, której wcześniej nie próbowałem, a powinienem. I tak powstała obsługa siatki wierzchołków z użyciem mechanizmu VBO (Vertex Buffer Objects), który dosyć mocno przyspiesza renderowanie. Posługując się tą lekcją Nehe, udało mi się stworzyć klasę gromadzącą wierzchołki, tworzącego VBO (o ile to możliwe), renderującą siatką, a także umożliwiającą eksport i import z i do pliku. Dodatkowo, klasa została zaprojektowana w ten sposób, że względnie łatwe jest jej zintegrowanie z obiektami klasy CCollisions, które posłużą do ustawienia i wykrywania kolizji.

Podczas pisania HDR, naszła mnie jedna refleksja - nieprojektowany kod się mści. Owszem, od początku zamierzałem dodawać kolejne funkcjonalności na luźno, bez wielkich planów związanych z rozwojem frameworka. Odczuwam jednak już tego skutki, czym są powtarzające się inicjalizacje shaderów, brak elastyczności przy efektach itd. Oczywiście, zamierzam dalej to rozwijać (o ile będę miał na to czas), aczkolwiek z całą pewnością muszę obmyślić, czy nie da się tego przeprojektować od nowa i dzięki temu zuniwersalizować nieco cały system, aby był prostszy dla osoby pielęgnującą kod (dla użytkownika pozostanie bez zmian). Innymi słowy - w dalekiej przyszłości myślałem nad dodaniem trybu DirectX (wypada się go w końcu, cholera, nauczyć) oraz organizacją kolejnych struktur na wzór tych z darmowych silników (chociażby OGRE). Może nawet uda się framework wyprowadzić na silnik - kto wie. To jednak, jak mówię, dopiero w dalekiej przyszłości - na razie skupiam się na projektach, uczelni oraz dodawaniem kolejnej funkcjonalności do Yesty, o ile będę miał czas i pomysły.

Morał jest jednak taki, że jeśli nie musisz robić tego inaczej - projektuj chociażby szkielet aplikacji. Aż mi się zresztą głupio zrobiło na Wprowadzeniu do Informatyki i wykładzie dotyczącym Inżynierii Oprogramowania. A także z tego powodu, iż nie zaufałem od razu Doxygenowi, żeby zautomatyzować dokumentację. Cóż, człowiek uczy się na błędach, a dzięki braku wsparcia dla Doxygena zachowałem przynajmniej specyficzny styl kodowania. Ale na przyszłość radzę pamiętać o tych "wspomagaczach".

Pozdrawiam i dziękuję - SceNtriC.