Chmury - jak z 2D zrobić 2.5D?

W dniu wczorajszym obiecałem, że powiem kilka słów o tym jak uzyskać takie chmury jak mi się udało. Nie są może one rewelacyjne, ale moim zdaniem i tak wyglądają całkiem nieźle. Nie są płaskie, dają pewne drobne wrażenie głębi, a jednocześnie nie są wolumetryczne.

Kluczem jak łatwo się domyśleć jest wykorzystanie 2-wymiarowego szumu Perlina, który pozwala nam na wygenerowania podstawowej struktury chmur. Oczywiście robimy to w tradycyjny sposób zgodnie z tym co napisał Ken Perlin w swojej prezentacji, czyli sumujemy pewną liczbę oktaw szumu z odpowiednimi wagami i częstotliwościami. Im więcej oktaw, tym lepiej. Przynajmniej do pewnego momentu, bo potem okazuje się, że choć wydajność zaczyna nam spadać, tak jakość obrazu w zasadzie nie ulega zmianie.

Niemniej stosowanie szumu Perlina bez jakiejkolwiek obróbki ma jedną podstawową wadę, która dla wielu zastosowań może być dyskwalifikująca - uzyskane chmury są kompletnie płaskie! Nijak oddać za ich pomocą chmur burzowych, czy ogólnie, czegokolwiek poza najdelikatniejszymi obłokami. Na dowód obrazek:

Swego czasu, aby to obejść do tekstury uzyskanej za pomocą szumu Perlina dodawałem (ale dokładnie w jaki sposób - nie pamiętam) wartości kolorów z tekstury będącej zdjęciem prawdziwej chmury, co w pewien sposób pozwalało mi symulować różne typy chmur. Nawet jakoś tam działało.

Na szczęście istnieją lepsze sposoby, które pozwalają nam także na uwzględnienie rozchodzenia się światła w chmurze, a tym samym jej oświetlenie. W rzeczywistości chmura jest skupiskiem wody w różnej postaci (od ciekłej po stałą). Promień światła przechodząc przez każdą z kropel odbija się i rozprasza pod najróżniejszymi kątami, trafia do innej kropli, odbija się, trafia do innej kropli, itd. Promieni jest dużo, kropel jest dużo, więc widać, że nie będzie się tego dało zrobić poprzez implementację stanu faktycznego. Dokonamy bardzo zgrubnego przybliżenia tego scatteringu. Spójrzmy na poniższy rysunek:

Idąc od punktu, w którym umieszczone jest Słońce w kierunku dolnego punktu na chmurze (punkt P) sprawdzamy, czy w danym momencie promień znajduje się wewnątrz chmury (oczywiście przesuwamy się w pętli o jakąś ustaloną jednostkę w każdej iteracji). Zatem nie uwzględniamy faktycznych zjawisk zachodzących w chmurze, a jedynie uwzględniamy jej gęstość w danym punkcie, co pozwala nam oszacować ile światła przejdzie dalej. Aby to uczynić sprawdzamy czy aktualna współrzędna y wektora położenia, jest większa od wartości zapisanej w teksturze wygenerowanej za pomocą szumu Perlina (ale o tym jeszcze za chwilę). Jeśli tak to dodajemy pewną wartość do aktualnej wartości oświetlenia (scatteringu). Wartość ta powinna być pomnożona przez aktualną gęstość chmury (odczytaną z tekstury) dla nieco lepszego efektu. Po dojściu do dolnego punktu promień bezpowrotnie opuszcza chmurę (w uproszczeniu), a tym samym na pewno nic nie wpłynie już na jej kolor. Po zebraniu wszystkich próbek musimy jeszcze jakoś zamienić zebrane dane o oświetleniu na rzeczywisty scattering. Ja robię to za pomocą następującej linii kodu: scattering = 1.0f / exp(scattering * 0.4f);

Jak widać takie podejście jest podobne do wielu efektów operujących na mapie wysokości. W rzeczywistości aproksymujemy w ten sposób jakąś całkę. Jeszcze jedna sprawa, aby uniknąć problemów z aliasingiem ta mapa wysokości (tekstura chmur z szumem Perlina, na której operujemy) powinna składać się tylko z kilku pierwszych oktaw. U mnie jest to 4. Ale zaraz... 4 oktawy to trochę mało i efekt będzie mierny... Zgadza się, dlatego te 4 oktawy należy np. zapisać do render targeta a po ich przetworzeniu dodać do nich pozostałe. I gotowe - do tego wystarczy dodać kolor nieba i mamy fajne chmury.

Dynamiczne chmury

Dziś skończyłem pisać dynamiczne chmury w oparciu o artykuł z Game Programming Gems 5 oraz o swoje inne z tym doświadczenia. Jutro postaram się wyjaśnić jak coś takiego osiągnąć (a da się jeszcze lepiej), dziś nie mam na to czasu. Poniżej film oraz garść screenów (więcej jak zawsze w galerii):

Pierwsze próby z HDR

Zaraz, zaraz... uważam się za człowieka mającego pojęcie o grafice komputerowej i dopiero teraz podjąłem próby wykorzystania tej powszechnej dziś techniki?! I tak, i nie. Nie, bo nie chodzi o programowanie grafiki. Tak, bo poświęciłem kilka godzin wczoraj i dziś na przygotowanie zdjęć z wykorzystaniem właśnie HDR.

O tym, że jest to możliwe pisał też jakiś czas temu Reg na swoim blogu. Pokazał on też w skrócie proces tworzenia tego zdjęcia i przedstawił darmowy programik, z którego sam skorzystałem - Qtpfsgui. Program jest bardzo fajny, pozwala na stworzenie zdjęcia HDR i jego tone-mapping do LDR w bardzo prosty i przejrzysty nawet dla laików sposób. Większość efektów da się osiągnąć zmieniając kilka wartości za pomocą pasków, ale jeśli ktoś wie, co robi ma dużo większe pole manewru - z definiowaniem swoich profili włącznie.

Aby ze zdjęcia można zrobić wersję HDR trzeba tak naprawdę przygotować serię zdjęć różniących się między sobą czasem ekspozycji i pokazujących dokładnie to samo (bez statywu praktycznie nie da razy). Później wystarczy je wczytać, trochę poczekać, od czasu do czasu coś kliknąć i otrzymać rezultat... Poniżej to co ja zrobiłem przez ten weekend:

Jak na początek chyba nieźle. Trochę miejscami przesadziłem, ale od czegoś trzeba zacząć :)

Brak refaktoringu, refaktoring, a refaktoring pusty

Natknąłem się dziś na całkiem interesującą (choć dosyć starą) notkę na pewnym blogu. Niestety teraz nie mogę ustalić jego adresu. Otóż jej autor, zwolennik agile development, wprowadził pojęcie null refactoring. Z braku lepszego odpowiednika nazwałem go właśnie tytułowym refaktoringiem pustym.

Cóż to jest za twór? Ano jest to refaktoring, który nie wprowadza żadnych zmian w kodzie. Brzmi dziwnie? W pierwszej chwili - być może tak. Ale po chwili zastanowienia nie powinno to wydawać się już aż tak głupie.

Chodzi bowiem o to, że Agile (szczególnie programowanie ekstremalne) zaleca refaktoring zawsze wtedy, gdy jest to KONIECZNE. Podkreślam słowo konieczne - nie ma potrzeby przerabiania kodu, który jest dobry. Ale co jeśli nie wiemy czy kod jest dobry i czy wymaga refaktoryzacji? Teoretycznie powinniśmy to wiedzieć zawsze, ale teoria nie często w 100% pokrywa się z praktyką. W rzeczywistości często mamy do czynienia np. z sytuacją, że mamy nieczytelny kod, ale za to niesamowicie wydajny. Z jednej strony wskazane byłoby jego przepisanie ze względu na czytelność, ale czy wydajność na tym nie ucierpi? Prawdopodobnie tak. Dlatego programiści przed dokonaniem refaktoryzacji powinni się zastanowić, czy rzeczywiście jest ona niezbędna, wziąć pod uwagę wszelkie za i przeciw (przy czym nie mogą to być rzeczy typu: "lepiej nie będę dotykać tego kodu... na razie działa", czy "nie rozumiem tego kodu i nie mam ochoty się w niego zagłębiać"). Jeśli po takim skomplikowanym procesie myślowym okaże się, że refaktoring w chwili obecnej jest zbędny, to mamy właśnie do czynienia z refaktoringiem pustym. Od kompletnego braku refaktoringu różni się on tym, że dogłębnie przeanalizowaliśmy kod pod każdym kątem i poważnie rozważaliśmy jego refaktoring.

Dla wielu osób to pewnie rzeczy oczywiste, ale dla wielu nie. Zwykle wśród programistów mamy według mnie dwa typy:

• tych, co refaktoryzują wszystko, nawet "na siłę"
• tych co nie refaktoryzują wcale swojego kodu

Pamiętajmy, więc że optymalne podejście jak zawsze leży pomiędzy dwoma skrajnościami.

Pierwsza porcja update'ów... od dawna

Już rok?!