ShaderToy po polsku — demoscena
W Listopadzie 2017 na Wydziale Fizyki i Astronomii UWr zorganizowaliśmy pierwsze wrocławskie warsztaty pisania shaderów w języku GLSL na platformie ShaderToy. Uczestnikami byli głównie studenci naszej Informatyki Stosowanej i Systemów Pomiarowych oraz Fizyki, ale mieliśmy też gości z innych uczelni, a nawet szkół ponadpodstawowych.
Wykład YouTube: https://youtu.be/zx54GIBG0Yo
Parafrazując “pisać shadery każdy może” — na odpowiednim dla siebie poziomie, używając odpowiedniej logicznychtechniki. Chcę tu pokazać, że jest to fajna zabawa i dlatego, zaraz po warsztatach postanowiłem szybko (jeszcze w emocjach, bo tak wychodzi zwykle najzgrabniej) spisać to co pamiętam i to co myślę, że warto wiedzieć na ten temat. O czym to będzie? O bardzo unikalnej technice pisania programów z użyciem kart graficznych, która pozwala na szybkie programowanie grafiki, animacji czasu rzeczywistego, a nawet prostych gier czy programów. To zupełnie nowa platforma, bardzo wyjątkowa. No i nie ma zbyt wielu materiałów w języku polskim, dlatego… 3, 2, 1… Shader!
1. Najpierw Demoscena — od 8bit do GPU
Nie da się o tej technice mówić bez kilku słów wprowadzenia do demosceny. Jest to subkultura, która na wiele lat przykuła mnie do klawiatury i monitora zabierając cenne godziny wieczorne i nocne programowanie, dopasowywanie efektów do muzyki, czyli na tworzenie programów demonstracyjnych. Każdy scenę widzi inaczej, ja widzę jako platformę, gdzie można poznać ludzi, którzy robią to samo, jeżdżą na tzw. parties (imprezy komputerowe na których przezentowane są produkcje i jest zwykle organizowany dla nich konkurs).
Za czasów, kiedy łamało się gry zapisywane na dyskietkach i taśmach, grupy które się tym zajmowały podawały do informacji namiary na siebie. Zwykle było to tzw. intro. Intra na początku były proste, ale ktoś tam dodał kolor, ktoś dodał ciekawy font i nagle rywalizacja z tego kto złamie szybciej i lepiej grę przeniosła się na pole — kto zrobi ładniejsze intro, kto pokaże więcej punktów na ekranie, kto zrobi ładniejszą muzykę…
Demoscena nie ma już dziś wiele wspólnego z łamaniem gier, to znaczy nikt z nas — zajmujących się demami, intrami, efektami graficznymi gier już nie łamie. Za to idea tworzenia “czegoś ruchomego na ekranie, działającego w czasie rzeczywistym, najlepiej z muzyką” pozostała. Spotykamy się na imprezach, które odbywają się w wielu miejscach na świecie, różnej skali, w różnym klimacie. To bardzo unikalne imprezy, raczej nie pojawiają się na nich ludzie przypadkowi. Zwykle są to ludzie którzy coś na scenie tworzą lub coś organizują — tak ująłbym definicję członka demosceny.
Pierwsze scenowe produkcje, jakie obejrzejrzeć można teraz już np. na YouTube to głównie produkcje na maszyny 8-bitowe — te teoretycznie bardzo słabe maszyny nie są takie do końca słabe, jak się okazuje można na nich uzyskać bardzo ciekawe efekty graficzne. Co więcej, do dziś istnieją grupy zajmujące się tworzeniem dem na te maszyny.
Same dema na komputery 8-bitowe to osobny temat, bo one zmieniają się do dzisiaj i dziś na przykład odkrywane są możliwości, które nie były w oficjalnych specyfikacjach.. Ale my przejdźmy dalej, bo zmierzamy ku shaderom, a to jeszcze daleko. Kolejne były maszyny 16 i 32-bitowe i tzw. królowa demosceny (pozwolę sobie na to wtrącenie, jako historycznie tzw. amigowiec)- Amiga.
Amiga
Amiga to komputer wyjątkowy. Wyprzedziła ona swoją erę o lata świetlne. Była zbudowana w specyficzny sposób, bo oprócz procesora zawierała na płycie głównej specjalizowane układy odpowiadające za dźwięk czy grafikę, które osobno wykonywały masę pracy nie obciążając jednostki głównej. Brzmi znajomo? I właśnie to wykorzystała scena, a wykorzystała do cna, tworząc dla niej początkowo dema, które bezlitośnie korzystały z własności tych układów dodatkowych. Ileż było sztuczek, oszustw czy skrótów w dziejach sceny, które umożliwiały działanie efektów w ramce — czyli szybciej od tego jak odświeżany był na niej obraz (wtedy demo było płynne).
Wszystko “popsuła” jednak popularność procedur typu Chunky2planar, czyli możliwość tworzenia grafiki tak jak to się dzieje na komputerach typu PC — za pomocą prostego stawiania pikseli do bufora karty graficznej. Dlaczego o tym piszę? Bo ten moment zmienił bardzo tzw. główny nurt sceny, która przeniosła się z pisania pod specyficzny sprzęt na pisanie z użyciem odpowiednich algorytmów i technik. To wszystko rozmyte granice, wszystko nadal współgra i współistnieje, ale jednak — takie są fakty. Dema na Amigę przestały używać copperlisty i blittera (związane z układami specjalizowanymi o których pisałem), a zaczęły czerpać bardziej z algorytmów prezentowanych w artykułach z Siggraph lub przynajmniej z podręczników grafiki komputerowej (sceny 3d, teksturowanie, oświetlenie).
PC
Równolegle na scenie zaczyna się era szybkiego rozwoju sceny PC. Dla mnie na przykład naturalnym krokiem było opuszczenie dość słabej Amigi i przejście dalej na tę platformę, która pozwala realizować podobne rzeczy, ale w większej skali. PC to nie jest to demoscenowa platforma marzeń, ale rozszerza ona znacznie (dla niektórych na scenie za bardzo!) wachlarz możliwości. Dema na PC też przeszły transformacje — od tzw. renderingu software’owego, gdzie cały potok graficzny był programowany od zera, przez dema oparte o OpenGL/DirectX, aż po dzień dzisiejszy.
Klasycznie dema na PC powstawały w oparciu o wszelkiej maści API graficzne. Programy ciniowania (Shadery) służyły tu do modyfikacji elementów potoku graficznego i zmianę zarówno własności wierzchołków jak i pikseli obrazu.
I wtedy.. szybki rozwój kart graficznych i procesorów GPU spowodował, że na scenie zainteresowano się (trudno mi tu wskazywać kto był pierwszy, zresztą to nie ma znaczenia) opisem scen i grafiki z użyciem programów cieniowania. A to dlatego, że te algorytmy wymagają powtórzenia tych samych operacji wiele razy dla każdego piksela obrazu z osobna. Prym od wielu lat wiedzie tu Inigo Quilez (iq/rgba), który zaangażował się bardzo zarówno w promocję jak i rozwój tych metod. I tak rozpoczyna się, Drogi Czytelniku, nasza przygoda z shaderami.
Celem naszym jest wygenerowanie sceny: rysunku 2d, 3d lub animacji z użyciem programu cieniowania.
Shadery, a Commodore Vic-20
Pominę tu standardowy wstęp przechodząc od razu do rzeczy. Nic tak nie uczy, bowiem, jak praktyka i dobry przykład “Hello World”.
Odwiedź zatem, Szanowny Czytelniku, stronę ShaderToy.com, kliknij “new” po prawej stronie na górze (w ten sposób utworzyłeś właśnie nowy projekt) i voilà — mamy to, nasz (albo bardziej ich :-) ) pierwszy program cieniowania, który wygląda tak:
void mainImage( out vec4 fragColor, in vec2 fragCoord )
{
vec2 uv = fragCoord.xy / iResolution.xy;
fragColor = vec4(uv,0.5+0.5*sin(iTime),1.0);
}Jest to program, który jest uruchamiany na każdym pikselu tekstury nałożonej na dwa trójkąty wypełniające cały ekran na który patrzymy (miniaturka jest w ShaderToy umieszczona po lewej stronie). Ten przykładowy kod generuje animację zmieniających się w czasie kolorów, czyli coś takiego jak pokazane obok.
Są to po prostu uzależnione od czasu gradienty wszystkich trzech składowych kolorów i kod, który je generuje normalnie zająłby trochę więcej (otwarcie ekranu, przygotowanie danych i zmiennych, pętle po pikselach, rysowanie, zwolnienie zasobów, obsługa myszy i dekoracji okna, wyjście z programu). To co mnie osobiście urzeka w omawianym narzędziu (i mowa tu nie tylko o http://shadertoy.com, ale też jego odmianach np. http://glslsandbox.com) to zdjęcie z programisty (czyli ze mnie ze mnie ze mnie) obowiązku tworzenia całej otoczki związanej z programowaniem, która zwykle zajmuje najwięcej czasu, jest narażona na najwięcej błędów i sprawia trudności początkującym, którzy zwykle nie rozumieją jak istotna i fundamentalna jest to część — konfiguracja środowiska pracy. Początkujący powinien mieć dostarczoną platformę “tu, teraz i za darmo”, a nie siedzieć nad konfiguracją, ładować biblioteki czy bawić się podstawami linuxa w konsoli. Kiedyś (przepraszam za dygresję, ale wydaje mi się to ważne) taką rolę spełniały komputery 8-bit, które zamiast systemu operacyjnego (albo lepiej równolegle do niego) posiadały interpreter języka BASIC. Mówię tu o komputerach, które znam najlepiej czyli moim pierwszym — najbardziej mi bliskim — Commodore Vic-20 oraz drugim (tego już nie miałem, potem przyszła Amiga) — Commodore C-64. Ten interpreter to była potrzeba chwili, ale ja się tak nauczyłem programowania (bo kolega — Sebastian-pozdrawiam!) przyniósł mi w 8 klasie podstawówki program na kartce i powiedział, żebym go sobie wpisał tam i na koniec dopisał “Run”. Nie pamiętam tego programu (może czyta to Sebastian, albo jest na sali lekarz czy hipnotyzer potrafiący wydobyć ze mnie tą informację), ale spróbuję coś napisać podobnego. Zachęcam Cię, drogi czytelniku, do przepisania go sobie na jakimś emulatorze. Możesz użyć tego samego komputera co ja (tzn. Vic-20) kontaktując się ze mną (bo mam taki jeden i nawet działa:) albo… używając owoczesnej technologii JavaScript wchodząc na stronę emulatora https://www.mdawson.net/vic20chrome/vic20.php
Ciekawy jestem jak potoczyłyby się moje losy gdyby za mojego dzieciństwa był internet, albo trafiłaby do mnie ta książka “A_Beginners_Guide_to_Real_Programming_Discover_your_VIC-20” — polecam znaleźć pdf w sieci. Pytanie jest stąd, że moje zainteresowanie programowaniem wynikało początkowo z braku materiałów i wiedzy. Gdybym miał tą książkę, może właśnie byłoby to złe? To taka dygresja, ale chyba istotna. Nie zarzucajmy początkujących materiałami, nie dawajmy na siłę przepisów i recept, bo chyba nie o to chodzi żeby komuś łopatą włożyć coś do głowy, a o to by zaciekawić i zainspirować…
No dobrze, ale co ma wspólnego ShaderToy.com z Vic-20? Otóż jedno i drugie narzędzie daje coś niezwykle cennego dla początkujących programistów — skonfigurowane środowisko pracy, gdzie po wpisaniu kilku prostych instrukcji jesteśmy w stanie zobaczyć efekt naszej pracy. Zatem, Moi Drodzy, uruchamiamy www.shadertoy.com w przeglądarce i zanurzamy się w świecie shaderów.
Maciej Matyka
http://panoramix.ift.uni.wroc.pl/~maq/eng/
http://www.ift.uni.wroc.pl/~maq/
http://www.youtube.com/user/maqflp/
W przygotowaniu jest część 2. tego tekstu pt “ShaderToy po polsku — pierwsze starcie” traktująca o trzech podstawowych technikach w programowaniu shaderów. Nie ukrywam, że powstanie ona szybciej, jeśli będzie jakiś feedback z tego tekstu. Zatem czytajcie, piszcie (maciej.matyka@gmail.com), komentujcie.
Organizatorami pierwszego wrocławskiego warsztatu programowania w ShaderToy.com, który odbył się 25–26. Listopada 2017 roku na Wydziale Fizyki i Astronomii UWr był Wydział Fizyki i Astronomii (M. Matyka, J. Poła), Wrocław ACM Siggraph Chapter (F. Mendelez) i Wrocław Khronos Chapter (Ł. Piwowar). Wykłady z warsztatów możesz obejrzeć w wersji youtube: https://youtu.be/zx54GIBG0Yo
