Graficzny edytor cieniowania

Transkrypt

1 Politechnika Warszawska Wydział Elektroniki i Technik Informacyjnych Instytut Systemów Elektronicznych Praca dyplomowa magisterska Graficzny edytor cieniowania Shading Editor Kamil Trzciński Nr albumu: Promotor: prof. nzw. dr hab. inż. Przemysław Rokita Warszawa, 2012

2

3 Graficzny edytor cieniowania Streszczenie Celem niniejszej pracy magisterskiej jest zaprezentowanie rozwiązania umożliwiającego automatyczną generację kodów programów cieniujących przy zastosowaniu metodologii WYSIWYG z wykorzystaniem Graficznego edytora cieniowania. W pierwszym rozdziale przedstawiona jest ewolucja grafiki komputerowej czasu rzeczywistego. Drugi rozdział opisuje podstawowe zagadnienia teoretyczne, a trzeci zastosowanie programowalnego potoku renderingu. Rozdział czwarty przedstawia Graficzny edytor cieniowania oraz główne algorytmy używane w aplikacji. W piątym rozdziale opisany został projekt dema technologicznego, w szóstym rozdziale omówione zostały wyniki testów aplikacji. Ostatni rozdział podsumowuje prace nad projektem. Shading Editor Abstract The main objective of this thesis is to show solution for the automatic shader program generation using the WYSIWYG methodology for, so called, Shading Editor. The first chapter presents evolution of the real-time computer graphics. In the second chapter the theory basics related to this work are described. The third chapter describes A Shader Approach to rendering methods. Chapter Four presents Shading Editor and defines main algorithms used in the project, with the following chapter revealing project s architectural information. The sixth chapter presents detailed test results. In the final chapter the entire project described in this thesis is summarized.

4

5 Życiorys Urodziłem się 20 grudnia 1986 roku w Pułtusku. W roku 1999 ukończyłem Szkołę Podstawową w Pułtusku i rozpocząłem naukę w gimnazjum. Następnie podjąłem naukę w Liceum Ogólnokształcącym im. Piotra Skargi w Pułtusku, które ukończyłem zdając egzamin maturalny w 2005 roku. Naukę na studiach dziennych Wydziału Elektroniki i Technik Informacyjnych Politechniki Warszawskiej rozpocząłem w lutym 2006 roku. Obecnie pracuje jako architekt aplikacji oraz administrator systemów. Głównym obszarem moich zainteresowań są: systemy embedded (ARM i MIPS), SymbianOS, ios, Window Phone, Android, przetwarzanie i wizualizacja grafiki 3D z wykorzystaniem OpenGL i DirectX.

6

7 Spis treści 1 Rozwój grafiki komputerowej 13 2 Programowanie grafiki komputerowej Rasteryzacja API graficzne DirectX OpenGL Modele oświetlenia Model Blinna-Phonga Rodzaje świateł Metody oświetlania sceny Cieniowanie wprost Odłożone cieniowanie Mapy cieni Programy cieniujące Cieniowanie Modele programów cieniujących Metody zarządzania efektami Pliki FX Uber Shaders Dynamic Shader Linking Narzędzia wspomagające tworzenie kodu Narzędzia wspomagające optymalizację NV PerfHUD NV Parallel Nsight Graficzny edytor cieniowania Koncepcja działania Przestrzeń robocza Budowa bloku

8 4.1.3 Diagram przepływu Architektura systemu Opis programu cieniującego Opis materiału Generacja programu cieniującego Zasada działania Kontekst Przetwarzanie bloków Unikatowość zmiennych Wyznaczanie wypadkowego koloru Kod programu cieniującego Wartości stałe Obsługiwane bloki funkcyjne Funkcje matematyczne Parametryczne Stałe Efekty Obsługa potoków renderingu Przypadek testowy Cieniowanie wprost Odłożone cieniowanie Mapy cieni Demo technologiczne ayuine2c Technologia Budowa Testy poprawności i jakości wykonania Opis testów Wizualizacja 3D Wpływ jakości na szybkość renderingu Tryb automatyczny Podsumowanie 101 Bibliografia 102 A Język HLSL 105 B Zawartość płyty DVD 113 8

9 C Uruchomienie środowiska testowego 115 C.1 Wymagania C.2 Obsługa C.3 Profile konfiguracyjne D Wygenerowane kody programów cieniujących 121 D.1 Cieniowanie wprost D.2 Odłożone cieniowanie D.2.1 Faza geometrii D.2.2 Faza oświetlenia D.3 Mapa cieni

10 10

11 Wstęp Motorem rozwoju współczesnej technologii informatycznej, powszechnie znanej jako informatyki, jest rozwój przemysłu. Pociąga on za sobą konieczność wprowadzania coraz to nowszych i lepszych produktów w celu wyeliminowania konkurencji. Jedną z gałęzi technologii informacyjnej jest grafika komputerowa. Coraz większy rynek gier oraz filmów wymusza większą innowacyjność w tym segmencie. Innowacyjność ta ma bezpośrednie przełożenie na coraz bardziej wyrafinowane techniki generowania obrazu. Można powiedzieć, że jest to dziedzina najbardziej efektywna, ma największy wpływ na odbiór finalnego produktu. Przykładem jest wyświetlany w ostatnim czasie na ekranach kin film Avatar jeden z pierwszych filmów w całości nakręcony z wykorzystaniem technologii 3D. Zestawienie wizualizacji gier i filmów sprzed 5 lat z obecnymi super produkcjami, to jak porównanie poczciwego Poloneza do nowego modelu Ferrari. Coraz większe możliwości dzisiejszych procesorów i kart graficznych motywują do szukania jeszcze lepszych algorytmów, przybliżających jakość wirtualnego świata do świata rzeczywistego. Przełomowym momentem, w tym procesie, było wprowadzenie programów cieniujących. Programy cieniujące to specjalne aplikacje pisane dla karty graficznej, uruchamiane dla każdego wierzchołka i piksela wyświetlanego na ekranie monitora. Pozwalają one uwzględnić działanie różnych efektów oddziaływujących na każdy punkt wirtualnego świata, począwszy od efektów atmosferycznych, tj.: mgła, po efekty oświetlenia, tj.: latarnie miejskie, światła reflektorów samochodowych, skończywszy na prawach fizyki. Tak duże możliwości oraz niskopoziomowa architektura programów cieniujących znacząco utrudniła, a wręcz uniemożliwiła ich przygotowanie przez grafików 2D/3D. Wymusiło to na programistach przygotowanie narzędzi, które wypełnią lukę pomiędzy wysokopoziomową wizualizacją a ich opisem niskopoziomowym. Celem niniejszej pracy magisterskiej jest przedstawienie rozwiązania, które pozwoli przy pomocy graficznych narzędzi przygotować opis niskopoziomowych programów cieniujących na potrzeby wizualizacji scen. Taka potrzeba wynika z: uproszczenia - w celu umożliwienia użytkownikom (np. grafikom) pełniejsze uczestnictwo w procesie przygotowania wizualizacji, np. różnych typów materiałów lub modeli oświetlenia, 11

12 automatyzacji - w celu ujednolicenia mechanizmów opisu programu cieniujących dla potrzeb różnych typów i metod wizualizacji, np.: cieniowanie wprost, odłożone cieniowanie, przyspieszenia - w celu optymalizacji wizualizacji pod kątem określonego sprzętu: PC, konsole i urządzenia mobilne, walidacji - w celu zapewnienia mechanizmów warunkujących poprawność wykorzystywanych kodów programów cieniujących Strukturę i przepływ wiedzy w niniejszej pracy magisterskiej najlepiej przedstawia poniższy diagram. Pierwszy rozdział ma na celu zapoznanie z historią grafiki komputerowej w kontekście wizualizacji czasu rzeczywistego. Następnie zostaną przedstawione najistotniejsze mechanizmy wykorzystywane przy renderingu grafiki trójwymiarowej z wykorzystaniem rasteryzacji. Rozdział trzeci opisuje ideę działania oraz potencjalne problemy z wykorzystaniem programowalnego potoku renderingu. Czwarty rozdział przedstawia Graficzny edytor cieniowania - narzędzie do wspomagania procesu przygotowania programów cieniujących. W rozdziale piątym omówiona została architektura dema przygotowanego na potrzeby niniejszej pracy magisterskiej, a w szóstym opisany został test poprawności i jakości wykonania. Rozdział 1. Rozwój grafiki komputerowej Wstęp Rozdział 2. Programowanie grafiki komputerowej Rozdział 3. Programy cieniujące Dodatek A. Język HLSL Rozdział 4. Graficzny edytor cieniowania Dodatek B. Zawartość płyty DVD Dodatek C. Uruchomienie środowiska testowego Rozdział 5. Demo technologiczne ayuine2c Rozdział 6. Testy poprawności i jakości wykonania Podsumowanie 12

13 Rozdział 1 Rozwój grafiki komputerowej Grafika komputerowa to dziedzina informatyki zajmująca się wykorzystaniem technik komputerowych do celów wizualizacji artystycznej oraz wizualizacji rzeczywistości. Bardzo często grafika komputerowa jest kojarzona z urządzeniem wspomagającym jej generowanie - kartą graficzną, odpowiedzialna za renderowanie grafiki oraz jej konwersję na sygnał zrozumiały dla wyświetlacza. Rysunek 1.1: Obrazek z gry California Games na Commodore C64. Historia kart graficznych sięga wczesnych lat 80-tych ubiegłego wieku. Pierwsze karty graficzne potrafiły jedynie wyświetlać znaki alfabetu łacińskiego ze zdefiniowanego w pamięci generatora znaków, tzw. trybu tekstowego. W późniejszym okresie pojawiły się układy, wykonujące tzw. operacje BitBLT 1, pozwalające na nałożenie na siebie 2 różnych bitmap w postaci rastrowej. W roku 1985 światło dzienne ujrzał układ zawierający sprzętową akcelerację operacji takich jak BitBLT, rysowanie kształtów (tzw. duszków) czy wypełnianie kolorem. Pozwoliło to na stworzenie pierwszych graficznych gier dwuwymiarowych. 1 Bit Block Transfer 13

14 Początki Wraz z nadejściem systemu operacyjnego Microsoft Windows 3.0 wzrosło zapotrzebowanie na przetwarzanie grafiki rastrowej dużej rozdzielczości. Duża popularność systemu zaowocowała powstaniem interfejsu GDI 2 odpowiedzialnego za programowanie operacji związanych z grafiką. Rysunek 1.2: Obrazek z gry Wolfenstein stworzonej przez idsoftware w 1992 roku Krótko po tym powstały pierwsze akceleratory 2D wyprodukowane przez firmę S3. Wydarzenie to zapoczątkowało erę graficznych akceleratorów grafiki. Do roku 1995 wszystkie karty graficzne posiadały taką funkcjonalność. Późniejsze lata to dalszy rozwój grafiki, kart graficznych, interfejsów programistycznych. To czas powstawania pierwszych wersji biblioteki DirectDraw 3 oraz rozbudowa funkcjonalności biblioteki GDI. Akceleracja 3D Dużym przełomem było wprowadzenie w 1996 roku chipsetu Voodoo Graphics przez firmę 3dfx. Był on dodatkową kartą rozszerzeń, która jako pierwsza na świecie pełniła funkcję akceleratora grafiki 3D. Jednakże do poprawnej pracy wymagała obecności karty graficznej odpowiedzialnej za grafikę 2D. W tym czasie, na szeroką skalę, zaczęto stosować dedykowane biblioteki umożliwiające tworzenie trójwymiarowych wizualizacji: OpenGL 4 i Direct3D 5. O ile pierwsza z nich była i jest dostępna na dowolnej platformie, o tyle DirectX był i jest ograniczony tylko do platform opartych o systemu Windows (PC, Xbox, Windows Mobile, Windows Phone). Krótko po akceleratorze 2 Graphics Device Interface, komponent odpowiedzialny za przedstawianie obiektów graficznych i przesyłanie ich do urządzeń wyjściowych, tj. monitory i drukarki 3 Interfejs służący do wyświetlania grafiki 2D 4 Open Graphics Library, specyfikacja uniwersalnego API do generowania grafiki 5 Komponent, część biblioteki DirectX firmy Microsoft, odpowiedzialny za grafikę trójwymiarową 14

15 Voodoo firma 3dfx wypuściła następną wersję: VooDoo 2. VooDoo 2 było rozwinięciem technologii znanej z VooDoo, aczkolwiek kilka modyfikacji pozwoliło firmie zwiększyć wydajność następcy około trzykrotnie, pomimo teoretycznie niezbyt rewolucyjnych zmian. Konkurencja szybko otrząsnęła się z ciosu jakim było VooDoo, powoli zaczynając nawiązywać walkę z gigantem - zwłaszcza NVidia z Riva 128/ZX. Od 3Dfx oczekiwano więc prawdziwej bomby - firma sprostała oczekiwaniom. VooDoo 2 otrzymał drugi układ TMU 6, a także usprawnioną komunikację z bazową kartą graficzną 2D. Ponad dwukrotnie wyższa ogólna wydajność od poprzednika, oraz prawie czterokrotnie wyższa wydajność w grach wykorzystujących multitexturing, uczyniły z VooDoo 2 jedną z najszybszych kart graficznych tego okresu. Rysunek 1.3: Porównanie jakości grafiki w grze Quake (po lewej stronie grafika renderowana przez CPU, po prawej akcelerowana przez kartę graficzną) Rysunek 1.4: Karta graficzna oparta o V Diamond Monster 3D II Możliwości VooDoo 2: Procesor: Voodoo Graphics (SST-2 a.k.a. V2-1000) Interfejs: PCI 6 Texture Mapping Unit 15

16 Pamięć: 8-12 MB EDO DRAM Taktowanie rdzenia: MHz Taktowanie pamięci: 110 MHz Przepustowość pamięci: 2.1 GB/sec Prędkość wypełniania pikseli: 90 MPixels/sec Jednostki teksturujące: 2 Proces wykonania: 350 nm Ilość tranzystorów: RAMDAC: 130 MHz W tym czasie pojawiły się też pierwsze akceleratory firmy NVidia (układy RIVA TNT, RIVA TNT2) czy ATI (układy Rage). Były to karty posiadające układ odpowiedzialny za akcelerację grafiki 2D i 3D na jednej karcie rozszerzeń. T&L Koniec ubiegłego wieku to w dalszym ciągu dynamiczny rozwój kart graficznych. Zwiększanie szybkości procesorów CPU, ulepszanie procesów produkcji, udoskonalanie bibliotek DirectX oraz OpenGL. To okres, w którym, większe wymagania co do jakości generowanej grafiki wymuszają na producentach wprowadzanie, na bieżąco coraz szybszych układów. Pewnym przełomem było udostępnienie przez Microsoft biblioteki Direct3D 7.0, która wprowadziła sprzętowe wsparcie dla T&L, będących fundamentem późniejszego konfigurowalnego potoku renderingu. Jednostka T&L zdejmowała z programisty i CPU konieczność wyliczania współrzędnych wielokątów względem kamery, a następnie obliczanie wypadkowego koloru pikseli należących do tych wielokątów, przy jednoczesnym uwzględnieniu umiejscowienia źródeł światła. Wszystkie obliczenia były wykonywane przez układ karty graficznej. Mniej więcej od tego momentu akceleratory graficzne zaczęły być nazywane GPU 7. Nadal nie można jednak procesorów z tego pokolenia (układy GeForce 256/2, ATI Radeon 7500) uważać za w pełni programowalne. Królami tej epoki są gry Quake 3 Arena oraz Unreal Tournament, które wprowadzały gracza w pełni w dynamiczny świat. Jako jedne z nielicznych obsługiwały nową technologię: T&L. Programowalny potok renderingu Kolejna generacja wprowadza pierwsze zalążki możliwości programowania potoku renderingu. Pierwszą kartą graficzną, oferującą cieniowanie wierzchołków oraz pikseli 7 Graphics Processing Unit, procesor graficzny, główna jednostka obliczeniowa znajdującą się w kartach graficznych 16

17 Rysunek 1.5: Obrazek z gry Quake 3 Arena. Gra obsługiwała m.in.: mapy oświetlenia, efekty wolumetryczne, dynamiczne oświetlenie, antyaliasing była NVIDIA GeForce 3. Karta ta udostępniała możliwość napisania krótkiego programu pozwalającego na rzutowanie współrzędnych wierzchołka z przestrzeni 3D do dwuwymiarowych współrzędnych ekranu, wyliczenie wypadkowego koloru wierzchołka czy zmodyfikowanie współrzędnych tekstury przekazywanych do rasteryzera. Obliczenia te były przeprowadzane przez specjalne jednostki cieniujące zw. Vertex i Pixel Shaderem. Wersja programu była oznaczona numerem 1.0 i była zgodna ze specyfikacją Direct3D 8.0. Programowanie przy wykorzystaniu tego zestawu instrukcji było trudne i mocno ograniczone głównie z powodu małej ilości instrukcji, braku możliwości wykonywania skoków warunkowych oraz konieczności pisania programów w asemblerze czyli języku natywnym GPU. Mimo tych ograniczeń pozwalało to na pełną programowalność a nie konfigurowalność tak jak było to dotychczas. Dalszy rozwój kart graficznych to powstanie nowych bibliotek oraz rozwój jednostek cieniujących umożliwiających pisanie programów cieniujących. Wprowadzenie biblioteki DirectX 8.1 pozwala na wykorzystanie Shader Model 1.4, który rozszerza możliwości programów cieniujących o możliwość tworzenia lepszych efektów oświetlenia oraz wizualizacji efektów wody, mgły i nieba. W tym okresie powstają pierwsze dema przyszłych gier prezentujące wykorzystanie technik dynamicznego oświetlenia i cieniowania scen trójwymiarowych. Kolejna wersja biblioteki DirectX oznaczona 9.0 przynosi powstanie wysokopoziomowych języków programowania, tj. HLSL 8 (od Microsoftu) oraz CG 9 (od NVidii). Wraz z możliwością pisania programów cieniujących, składnią przypominającą język C znika dużo ograniczeń poprzednich wersji. Następuje znaczne wydłużenie limitu instrukcji logicznych, arytmetycznych oraz tekstur. Pojawia się możliwość pisania programów wykorzystujących pętle oraz instrukcje warunkowe. A biblioteka DirectX 9.0c do dnia dzisiejszego jest najczęściej stosowanym interfejsem 8 High Level Shading Language [13], [22] 9 C for graphics [17] 17

18 Rysunek 1.6: Obrazek z gry Doom 3. Gra w całości bazowała na dynamicznym oświetleniu i cieniach. Do płynnego działania wymagała najnowszych akceleratorów graficznych. graficznym. Zaimplementowany w niej Shader Model 3.0 praktycznie nie ma ograniczeń na długość programów cieniujących (programy są na tyle długie, że wystarczają do znacznej większości aktualnych zastosowań). Cieniowanie geometrii Rewolucja przychodzi wraz z wprowadzeniem Shader Model biblioteki udostępnionej wraz z wypuszczeniem DirectX Najważniejsza zmianą jest wprowadzenie tzw. Geometry Shaders czyli jednostek pozwalających na przetwarzanie geometrii. Wcześniejsze wersje shaderów umożliwiały przetwarzanie wierzchołków oraz pikseli, natomiast nie pozwalały na modyfikację siatki obiektów. Wprowadzenie Geometry Shaders umożliwiło dodawanie lub usuwanie całych trójkątów z potoku renderingu. Karty graficzne tej generacji (GeForce 8 i 9) nie mają sobie równych pod względem wydajności, dodatkowo udostępniając GPU do obliczeń niezwiązanych z przetwarzaniem grafiki tzw. GPGPU 10. Autorskie oprogramowanie umożliwiające wykorzystanie procesorów strumieniowych zamontowanych w kartach graficznych o nazwie CUDA 11 szybko zdobyło popularność szczególnie w zastosowaniach matematycznych czy kryptografii, gdzie procesory ogólnego przeznaczenia nie są najszybsze. 10 General-Purpose computation on Graphics Processing Units [11] 11 Compute Unified Device Architecture [15] 18

19 Rysunek 1.7: Obrazek z gry Crysis. Porównanie świata rzeczywistego ze światem wirtualnym. Jedną z pierwszych gier obsługujących nowe możliwości kart graficznych była gra Crysis. Do chwili obecnej jej silnik graficzny jest jednym z najładniejszych i najbardziej wymagających pod względem wydajności. Najnowsza historia Wprowadzenie DirectX 11 i Shader Model 5.0 oprócz wymuszenia obsługi sprzętowych efektów teselacji (rys. 1.8) oraz wprowadzenia Compute Shader 12 (odpowiednik CUDA) nie jest tak rewolucyjne jak wprowadzenie programowalnych jednostek cieniowania czy możliwości cieniowania geometrii. Jest to bardziej ewolucja technologii, niż rewolucja. Jednakże, postęp w jakości grafiki jest widoczny, a wizualizacje coraz wierniej odwzorowują świat rzeczywisty. Przyszłość Nikt nie jest w stanie przewidzieć jak rozwinie się technologia związana z grafiką komputerową. Wydajność układów graficznych rośnie zdecydowanie

20 Rysunek 1.8: Wpływ teselacji na wynikowy obraz (po lewej bez teselacji, po prawej z włączoną teselacją). Źródło: Unigine. Rysunek 1.9: Obrazek z dema technologicznego Heaven firmy Unigine wykorzystujący DirectX 11. szybciej niż procesorów CPU. Dzieje się tak głównie za sprawą sposobu potokowego wyświetlania obrazu, którego proces może być łatwo zrównoleglony. Większość aktualnie wykorzystywanych wizualizacji opiera się na technice rasteryzacji. Inne metody, mimo lepszych rezultatów wizualnych nie są powszechnie stosowane. Jedną z takich technik jest ray tracing. Mimo tego, że jest w stanie zapewnić znacznie lepszą jakość generowanego obrazu, matematycznie jest metodą zbyt skomplikowaną jak na możliwości współczesnych kart graficznych. Innym problemem jest fakt, że obecnie dostępne karty graficzne tworzone były z myślą o generowaniu obrazu rastrowego, pod który są silnie zoptymalizowane. Generowanie obrazu metodą ray tracingu (naśladującego naturalne zachowanie światła w przestrzeni), wymagałoby nie tylko implementacji dedykowanych funkcji w sprzęcie, ale również nowych, specjalistycznych bibliotek graficznych. To z kolei wymusiłoby na twórcach oprogramowania zmiany w procesie wytwarzania aplikacji. 20

21 Rozdział 2 Programowanie grafiki komputerowej Wraz z rozwojem techniki powstały różnorodne metody wizualizacji scen trójwymiarowych, które w różnym stopniu odwzorowują oczekiwaną reprezentację wirtualnego świata. Tworzenie nowych innowacyjnych produktów wymaga opanowania umiejętności przewidywania przyszłości. Sukces rynkowy nowych produktów (w tym gier) w dużej mierze zależy od tego, jakie pierwsze wrażenie zrobią na odbiorcy. W przypadku gier komputerowych na pierwszym planie zdecydowanie jest grafika. Coraz nowsze komputery i konsole z coraz nowszymi kartami graficznymi i procesorami pozwalają na wyśrubowanie wrażeń wizualnych do wcześniej nie znanych poziomów. Zmusza to twórców do tworzenia nowych technik generowania obrazu, które będą dawały jeszcze lepsze rezultaty. Technikami wizualizacji, renderowaniem i renderingiem (ang. rendering) nazywamy proces analizy modelu sceny oraz generowania na jego podstawie dwuwymiarowego obrazu lub animacji. Ponieważ animację możemy rozumieć jako ciąg następujących po sobie statycznych obrazów, rendering oznacza tworzenie pojedynczej klatki obrazu. 2.1 Rasteryzacja Rasteryzacja [23], [6], [7] jest to przekształcenie trójwymiarowego świata na dwuwymiarowy obraz złożony z pikseli, do wyświetlania których przystosowane są dzisiejsze monitory. Grafika rastrowa przedstawiona jest za pomocą regularnej siatki punktów (pikseli), z których każdy ma przyporządkowany kolor. Istnieją różne techniki pozwalające na optymalizację tej operacji, jednak podstawowa idea jest podobna we wszystkich. W przestrzeni ustawiana jest wirtualna kamera zdefiniowany zostaje punkt widoku (ang. view point) oraz kierunek patrzenia. Przed nią, w prostej linii, umieszczona zostaje płaszczyzna, na której rejestrowany będzie obraz macierz projekcji będąca siatką pikseli. Rzutowanie następuje wzdłuż prostej wspólnej dla punktu widoku, renderowanej bryły oraz jednego piksela macierzy projekcji. Z uwagi na poziom skomplikowania dzisiejszej grafiki istnieje konieczność wykorzystania akceleratorów 21

22 graficznych, które są zoptymalizowane do generowania wizualizacji. Szczegóły sprzętu oraz zastosowane rozwiązania są tajemnicą każdej z firm produkujących karty graficzne, takich jak Intel, nvidia lub AMD/ATI, jednak znany jest ogólny abstrakcyjny model potoku graficznego (ang. graphics pipeline). Potokiem graficznym nazywamy cały proces generowania grafiki, w trakcie którego z wejściowych danych numerycznych (pozycje wierzchołków, tekstury, źródła światła, materiały) powstaje obraz na ekranie monitora. Model sceny Local Space World Space View Space Clipping Backface Culling Projection Lighting Homogenous Divide Viewport Transform Rasterization Wynikowy obraz Rysunek 2.1: Stały (nieprogramowalny) potok renderingu lub proces rasteryzacji. Potok renderingu przedstawiony na rys. 2.1 prezentuje kolejne procesy zachodzące przy zamianie modelu sceny na wynikowy obraz. Cechą charakterystyczną potoku jest jego kaskadowość wyniki pracy jednego poziomu, stają się danymi wejściowymi kolejnego etapu. Na początku przetwarzane są wierzchołki. Dla każdego wierzchołka ustalane jest miejsce w odniesieniu do wirtualnego punktu widoku, obliczane oświetlenie oraz dane niezbędne do korzystania ze współrzędnych UV dla tekstur. Elementy są szeregowane tak, aby można było wyeliminować poligony, których użytkownik nie może zobaczyć, ze względu na to, że znajdują się poza polem widzenia. Są za daleko lub za blisko. Kolejnym krokiem jest rasteryzacja, czyli zamiana trójwymiarowych obiektów na piksele. Dalsza obróbka pikseli może polegać na nadaniu im odpowiedniego koloru, będącego skutkiem oświetlenia, przezroczystości lub dodatkowych efektów, ostatecznie barwy wynikającej z tekstury. Ostatnim krokiem przed wyświetleniem jest nałożenie filtrów i inna obróbka dwuwymiarowego już obrazu. Poszczególne elementy nieprogramowalnego potoku realizują następujące funkcje: Local Space - Przestrzeń lokalna jest to system koordynatów, w którym obiekt został 22

23 wymodelowany. Cechuje go to, że wszystkie wierzchołki są w bliskim sąsiedztwie, a środek tego modelu znajduje się w punkcie (0,0,0). World Space - Przestrzeń świata jest to system koordynatów określających wzajemne położenie różnych modeli w świecie. Ma to na celu geolokalizowanie obiektów w świecie. View Space - Jest to operacja transformująca przestrzeń świata do przestrzeni widoku, czyli pozycji względnej w stosunku do obserwatora. Przyjmuje się pozycję kamery jako centrum sceny, inaczej mówiąc transformuje się tak wszystkie wierzchołki, aby obserwator znajdował się w punkcie (0,0,0). Ma to na celu głównie uproszczenie wszystkich późniejszych operacji matematycznych, w których mogą wystąpić potencjalnie błędy numeryczne. Lighting - Jest to operacja wyznaczenia intensywności oddziaływania światła na konkretny fragment sceny. Polega ona na przypisaniu każdemu wierzchołkowi i pikselowi koloru na podstawie odległości od wszystkich źródeł światła w świecie. Projection Transform - Jest to operacja zamiany pozycji wszystkich wierzchołków na współrzędne X i Y należące do [-1,1] oraz Z należące do [0,1]. Gdzie Z oznacza głębię. Backface Culling - Proces usunięcia trójkątów nieskierowanych w kierunku obserwatora. Pozwala to na zlikwidowanie niewidocznych trójkątów, tym samym przyspieszenie renderingu. Clipping - Proces przycinania trójkątów do przestrzeni widoku. Viewport Transform - Proces zamiany współrzędnych X i Y tzw. znormalizowanych koordynatów z zakresu [-1,1] na wielkość wynikowego obrazu w pikselach. Rasterization - Finałowy proces zamieniający przetransformowane i przycięte trójkąty modelu 3D na ich reprezentację na obrazie 2D. Każdy piksel należący do takiego dwuwymiarowego trójkąta jest cieniowany a wypadkowy kolor zapisywany do wynikowego obrazu. 2.2 API graficzne Dzisiejsze karty graficzne mogą być programowane przy pomocy różnych interfejsów graficznych. Dwa najpopularniejsze i konkurencyjne to OpenGL i DirectX. OpenGL jest uniwersalnym API do generowania grafiki dostępnym na prawie wszystkich platformach. DirectX jest własnościowym produktem firmy Microsoft ograniczonym tylko do platformy Windows i systemów zależnych. Firmy produkujące silniki graficzne, aby zapewnić współpracę ze wszystkimi urządzeniami zmuszone są tak przygotować kod, aby był w stanie działać z każdym z nich. Każdy z interfejsów posiada wiele różnych wersji: inne wersje dla komputerów PC, inne dla urządzeń mobilnych i jeszcze inne dla konsol. Pokrótce postaram się przedstawić idee, stojące za każdym z nich. 23

24 2.2.1 DirectX DirectX to zestaw funkcji API wspomagających generowanie grafiki (dwu- i trójwymiarowej), dźwięku oraz innych zadań związanych zwykle z grami i innymi aplikacjami multimedialnymi. Najczęściej jest wykorzystywany do obsługi grafiki w grach komputerowych. Używany jest również do pisania programów do specyficznych zadań z wykorzystaniem np. grafiki trójwymiarowej (np. symulacja komputerowa). DirectX jest produktem firmy Microsoft, dostępnym tylko na platformę Windows oraz konsolę Xbox. Obecnie dostępna jest wersja DirectX 11, która została wprowadzona wraz z premierą systemu operacyjnego Microsoft Windows 7. Biblioteka ta jest rozszerzeniem funkcjonalności biblioteki DirectX 10. Jedenasta wersja umożliwia obsługę GPGPU poprzez wprowadzenie ComputeShaders oraz obsługę teselacji. Warto w tym miejscu dodać, że starsza wersja DirectX 9.0c jest wciąż bardzo szeroko stosowana w dużej ilości produktów jako główny interfejs graficzny. Zakres funkcjonalności dostępny w tej bibliotece w większości przypadków jest wystarczający do realizacji większości efektów. Nowe biblioteki zwiększają programowalność potoku renderingu. Możliwe jest pisanie programów cieniujących wierzchołki, cieniujących geometrię oraz cieniujących piksele. Schemat implementacji najlepiej przedstawia rysunek 2.2. Elementy programowalnego potoku renderingu Input Assembler (IA) - Jednostka odpowiedzialna za translację komend sterownika systemowego na dane potoku renderingu. W tym procesie następuje zamiana podstawowych operacji, np.: wyświetlanie trójkątów na operacje GPU. Vertex Shader (VS) - Programowalna jednostka cieniująca wierzchołki. Program cieniujący napisany dla tej jednostki jest uruchamiany raz na każdym przetwarzanym wierzchołku. Ma on za zadanie transformację położenia wierzchołka z wirtualnej przestrzeni 3D na współrzędne ekranu względem obserwatora. W ten sposób można wpływać na wynikowy kształt figury powodując ruch lub deformacje. Geometry Shader (GS) - Programowalna jednostka cieniująca geometrię, pozwalająca na modyfikację siatki wierzchołków. Program cieniujący ma możliwość proceduralnego dodawania lub usuwania wierzchołków z siatki trójkątów. Przykładowym zastosowaniem może być teselacja, czyli dodanie objętościowych detali do istniejącej siatki trójkątów. Operacja taka wykonywana na procesorze jest zbyt kosztowna obliczeniowo oraz powoduje zbyt duży narzut na wykorzystanie pamięci. Takich ograniczeń nie ma jeśli wszystkie obliczenia są wykonywane w potoku renderingu przez przystosowaną do tego jednostkę cieniującą i bezpośrednio jej wyniki przekazywane są do procesu rasteryzacji. Użycie jednostki cieniowania geometrycznego jest opcjonalne. Jej brak skutkuje przekazaniem siatki 24

25 Rendering Pamięć GPU Komendy API/ Drivera Modyfikacja danych Index Buffer Input Assembler (IA) x8 x1 Vertex Buffer Vertex Shader (VS) Sampler Constant x16 Texture Geometry Shader (GS) Sampler Constant x16 Texture Stream Output (SO) x1 or x4 Stream Buffer Clip + Project + Setup + Early Z + Rasterize (RS) Pixel Shader (PS) Sampler Constant x16 Texture Output Merger (OM) x1 x8 Depth/Stencil Render Target Wynikowy obraz Rysunek 2.2: Potok renderingu w bibliotece DirectX 10/11. Opracowano na podstawie [18], [14] 25

26 wierzchołków bez modyfikacji do procesu rasteryzacji. Clip + Project + Setup + Early Z + Rasterize (RS) - Zbiór funkcji przystosowujących siatkę trójkątów do procesu rasteryzacji. Zadaniem tej jednostki jest kolejno: wykluczenie z procesu trójkątów nieskierowanych do obserwatora, przycięcie trójkątów do płaszczyzn widoku oraz przypisanie wartości współrzędnych fragmentów wielokątów w przestrzeni do współrzędnych w buforze lub teksturze. Pixel Shader (PS) - Programowalna jednostka pozwalająca na wyliczenie koloru pikseli. Na wejściu programu są parametry cieniowania pobrane z rasteryzatora, który wypełnia wielokąty przesyłane z potoku graficznego. Cieniowanie pikseli umożliwia nakładanie na fakturę obiektu zaawansowanych efektów oświetlenia, map cieni lub map wypukłości. Wprowadzenie możliwości programowania procesu wyliczania koloru pikseli umożliwiło stworzenie realistycznych wizualizacji świata generowanych w czasie rzeczywistym. Output Merger (OM) - Ostatni krok procesu wyświetlania. Tutaj budowane, przechowywane i łączone są obrazy przeznaczone do wyświetlania na podstawie wypadkowych wartości kolorów przekazanych z jednostki cieniującej piksele. Tak skonstruowany potok renderingu pozwala na pełną elastyczność, która zapewnia kompatybilność z wcześniej napisanym kodem. O ile nowa karta graficzna obsługuje wykorzystany w produkcie interfejs graficzny, o tyle możliwe jest uruchomienie go na nowym sprzęcie. Możliwe jest przygotowanie bardziej innowacyjnych rozwiązań w krótszym czasie - nie trzeba przystosowywać każdego kodu do danej karty graficznej. Jest to zapewnione przez wykorzystanie obsługiwanego API graficznego. Dużym udogodnieniem jest sposobność pominięcia niektórych etapów. Wtedy karta graficzna wykorzystuje domyślne działanie danej jednostki. Najczęściej jest to przekazywanie danych z wejścia na wyjście z pominięciem dodatkowych obliczeń. Na szczególną uwagę zasługuje informacja, że każdy element programowalnego potoku renderingu działa niezależnie od jego innych elementów. Karta graficzna zbudowana jest z wielu małych specjalizowanych procesorów, które wykonują powierzone jej zadanie. Dlatego, mimo tego że procesory te są wolne, to fakt, że karta graficzna w jednym momencie potrafi wyliczać jednocześnie 1000 próbek oświetlenia pozwala na uzyskanie w pełni dynamicznego i płynnego obrazu OpenGL OpenGL (ang. Open Graphics Library) [4], [10] jest to specyfikacja uniwersalnego API do generowania grafiki. Zestaw funkcji składa się z 250 podstawowych wywołań, umożliwiających budowanie złożonych trójwymiarowych scen z podstawowych 26

27 figur geometrycznych. OpenGL wykorzystywany jest często przez gry komputerowe i wygaszacze ekranu, spełnia rolę analogiczną jak konkurencyjny Direct3D (część DirectX) w systemie Windows firmy Microsoft. Również programy do przedstawiania wyników badań naukowych, CAD, oraz wirtualnej rzeczywistości używają OpenGL. Idea działania w najnowszych wersjach OpenGL jest bardzo podobna do tej zaprezentowanej przy okazji omawiania DirectX 10. Różnica jest w API. Interfejs biblioteki OpenGL jest interfejsem niskopoziomowym, wykorzystującym programowanie strukturalne, gdzie interfejs dla biblioteki DirectX opiera się o wykorzystanie interfejsów pełniących rolę obiektów, umożliwiających dostęp do konkretnych metod. OpenGL został zaprojektowany w taki sposób, aby producenci sprzętu graficznego mogli rozszerzać jego funkcjonalność poprzez własne rozszerzenia [16]. Rozszerzenia takie dystrybuowane są poprzez publikację zarówno sterowników obsługujących dane funkcje, jak również plików nagłówkowych z definicjami tychże, aby z funkcji tych mogli skorzystać programiści piszący oprogramowanie używające OpenGL. Funkcje lub stałe występujące w rozszerzeniach oznaczane są skrótami przyporządkowanymi poszczególnym producentom (np. funkcje firmy NVIDIA oznaczane są skrótem NV). Jeśli funkcja jest używana przez więcej niż jednego producenta, oznaczana jest skrótem EXT, a w przypadku, gdy zostanie oficjalnie zaakceptowana przez Architectural Review Board, staje się ona rozszerzeniem standardowym i otrzymuje oznaczenie ARB. Później, rozszerzenie może się stać oficjalnie częścią standardu OpenGL, w kolejnej jego wersji. 2.3 Modele oświetlenia Podstawą wizualizacji scen trójwymiarowych na płaskiej powierzchni jest oddanie efektu perspektywy. Jest to decydujące w dostrzeżeniu głębi renderowanego obrazu. Równie istotny jest sposób oświetlenia i cieniowania obiektów. Metod obliczania oświetlenia jest wiele. Pokrótce przedstawię najpopularniejsze równania matematyczne i metody wykorzystywane przy symulacji oświetlenia Model Blinna-Phonga Najczęściej stosowaną metodą jest model oświetlenia Blinna-Phonga, będący rozwinięciem oryginalnego modelu przedłożonego przez Phonga w 1973 roku [1] [3]. Phong zaproponował model, w którym powierzchnia obiektu jest pokryta bardzo cienką przezroczystą warstwą, na której zachodzi odbicie zwierciadlane, tzn. światło nie zmienia swojej barwy. Natomiast na powierzchni znajdującej się pod tą warstwą, następuje odbicie rozproszone, które zabarwia światło na kolor przypisany do obiektu. W świecie rzeczywistym takimi właściwościami cechują się np. błyszczące plastyki czy powierzchnie 27

28 pomalowane bezbarwnym lakierem. Model Phonga można opisać następującym wzorem: I = k a I a + k d I d + k s I s (2.1) Rysunek 2.3: Model Phonga. N - wektor normalny, L - promień światła, R - promień odbity, V - kierunek do obserwatora. Źródło: Wikipedia I a I d I s Natężenie światła docierające do obserwatora składa się z: - Natężenie światła otoczenia, inaczej kolor otoczenia (ang. ambient), które jest stałe. - Natężenie światła rozproszonego, inaczej kolor rozproszenia (ang. diffuse) obliczone na podstawie modelu Lamberta: I d = I i cos(β), gdzie I i to natężenie światła padającego. - Natężenie światła odbijanego zwierciadlanie, inaczej kolor odbicia (ang. specular) obliczane z prostej zależności: I s = I i f(β) cos n α, gdzie I r to natężenie światła odbitego, które może dodatkowo zależeć od kąta β. Rysunek 2.4: Model Phonga. Efekt działania każdego czynniku na wypadkowy obraz. Źródło: Wikipedia Każdy z czynników może dodatkowo być przemnożony o wartość z przedziału [0,1]. Służy to modyfikacji wypadkowego koloru w celu osiągnięcia określonego efektu. Często wzór wzbogaca się o współczynnik tłumienia atmosferycznego (np. gdy wyliczamy natężenie dla źródła o ograniczonym zasięgu). Wynika to z faktu malenia natężenia światła wraz z odległością. Tłumieniu podlega natężenie światła rozproszonego i odbitego. Natężenie światła otoczenia przyjmuje się jako wartość stałą. Dość często współczynniki te są przechowywane jako kolor wierzchołków lub tekstura przypisana do obiektu. 28

29 Przy użyciu odpowiedniego pokolorowania obiektów symuluje się rozpraszanie na różnych typach powierzchni. Przedstawiony model jest jednym z najprostszych i najszerzej stosowanych, zapewnia rezultaty wizualne Rodzaje świateł Światło w projektowaniu grafiki 3D to niezwykle ważne zagadnienie [23] [3]. Od wyboru i ustawienia świateł zależy charakter całej sceny. W zależności od pożądanego efektu dobieramy różne kolory, natężenie i kąt padania światła. W grafice 3D możemy wyróżnić kilka rodzajów świateł: punktowe, stożkowe z celem, kierunkowe z celem, światło wolumetryczne, możemy też użyć systemu nasłonecznienia. Z uwagi na to, że symulacja rzeczywistego modelu oświetlenia jest kosztowna obliczeniowo zrodziła się konieczność klasyfikacji podstawowych rodzajów świateł na potrzeby grafiki komputerowej. Modele te starają się możliwie najwierniej przedstawić zachowanie się światła w różnych sytuacjach, a przy okazji są one zoptymalizowane do pracy w czasie rzeczywistym. Wyróżniamy następujące modele podstawowe: Ambient Light Inaczej nazywane światłem otoczenia. Światło o niezmiennej jasności i kolorze, które oświetla każdy obiekt na scenie równomiernie. Ten model jest swego rodzaju oszustwem w grafice komputerowej. W rzeczywistym świecie rzadko mamy do czynienia z miejscami, do których nie dociera żadne światło. Z uwagi na to, że nawet obiekty, które znajdują się w cieniu są w pewnym sensie oświetlone przez światło odbite, zrodziła się potrzeba symulacji takiego zachowania. Oczywiście dostępne są algorytmy globalnego oświetlenia, które pozwalają na całkiem przyzwoite odwzorowanie takiego zachowania, jednakże zjawiska te są dość złożone i bardzo często efekt ten zastępuje się właśnie tzw. ambientem. Point Light Inaczej nazywane światłem punktowym. Światło, które emituje promienie z pojedynczego punktu (podobnie jak żarówka). Jasność takiego światła jest zależna od odległości źródła od obiektu oraz oświetlanej powierzchni zgodnie ze wzorem: gdzie: I s I = I s (N L) d2 oznacza intensywność źródła, d odległość między źródłem a obiektem, N wektor normalny płaszczyzny a L wektor padania światła. Oprócz odległości wpływ na intensywność świecenia może mieć kierunek padania promienia względem wektora normalnego płaszczyzny. 29

30 Rysunek 2.5: Światło punktowe na przykładzie Unity3D. Directional Light Inaczej nazywane światłem kierunkowym. Światło, którego promienie pochodzą z tego samego kierunku (są równoległe). Tego typu źródło może obrazować, np. promienie pochodzące z odległego słońca (odległość między źródłem a obiektem przybliża się jako nieskończoność). Wpływ na wypadkową intensywność ma kierunek padania promienia względem wektora normalnego płaszczyzny. Jasność takiego światła jest zależna od odległości źródła od oświetlanej powierzchni zgodnie ze wzorem: I = I s (N L) Rysunek 2.6: Światło kierunkowe na przykładzie Unity3D. Spot Light Inaczej nazywane światłem reflektorowym. Światło, którego promienie symulują stożek światła z latarki lub lampy. Oprócz wcześniej wymienionych parametrów światła 30

31 reflektorowe wymagają podania kąta rozwarcia stożka światła oraz parametru opisującego zanik światła w zależności od kąta wewnątrz stożka. Jasność takiego światła jest zależna od odległości źródła od oświetlanej powierzchni zgodnie ze wzorem: I = I s (N L) (L D) gdzie: D oznacza wektor kierunkowy stożka Rysunek 2.7: Światło kierunkowe na przykładzie Unity3D. Global Illumination Innym rodzajem oświetlenia jest globalna iluminacja. Polega ona na tym, że obiekty w scenie oświetlane są zarówno przez źródło światła, jak i przez światło odbite od innych przedmiotów w scenie (w oświetleniu lokalnym obiekty oświetlane są wyłącznie bezpośrednio przez źródło światła). Pozwala to osiągnąć większy stopień realizmu kosztem mocy obliczeniowej. Globalna iluminacja wykorzystywana jest w takich technikach renderowania jak mapowanie fotonowe, radiosity. Obecnie stosuje się różne przybliżenia, pozwalające symulować efekt działania globalnej iluminacji. Takimi algorytmami są: Radiosity [8], Spherical Harmonics [5] [26], Screen-Space Ambient Occlussion. 2.4 Metody oświetlania sceny Znajomość algorytmów i rodzajów oświetlenia musi zostać odpowiednio wykorzystana. Istnieją dwie wiodące metody cieniowania, różniące się podejściem do mechanizmów nakładania oświetlenia. 31

32 Rysunek 2.8: Algorytm Global Illumination - Radiosity Cieniowanie wprost Cieniowanie wprost (ang. Forward rendering lub Forward Shading) [23] jest to metoda dosyć często określana jako standardowe podejście do problemu rysowania świateł przy wizualizacji scen trójwymiarowych. Jest to jedna z najbardziej rozpowszechnionych i szeroko wykorzystywanych metod w grach i aplikacjach czasu rzeczywistego. W ramach tej metody powszechnie stosowane są dwa podejścia do problemu rysowania świateł: Rysowanie świateł wieloprzebiegowo Algorytm oczekuje rysowania obiektów geometrycznych tyle razy ile świateł na nią wpływa. Każdy kolejny przebieg modyfikuje obraz, uwzględniając wpływ kolejnego źródła światła. Mimo niewątpliwych zalet, tj.: prostota wykorzystania, krótkie programy cieniujące, duża konfigurowalność parametrów materiału oraz oświetlenia, możliwość przygotowania różnych programów cieniujących do różnorodnych materiałów i różnych modeli oświetlenia, metoda ta ma jedną bardzo dużą wadę - małą wydajność. Wynika to z konieczności rysowania geometrii oddzielnie dla każdego źródła światła. Dlatego bardzo często wizualizowane są tylko punkty oświetlenia, znajdujące się w najbliższym sąsiedztwie od obserwatora. Co ma bezpośredni wpływ na szczegółowość i jakość generowanego obrazu. Rysowanie wielu świateł jednocześnie Jest to podejście podobne do poprzedniego, ale wykorzystujące pojedynczy przebieg wizualizacji do rysowania jak największej liczby świateł. W tym celu najczęściej przygotowuje się odmienne wersje programów cieniujących dla różnych ilości świateł. 32

33 Start Przygotowanie modelu sceny N Wyliczenie parametrów oświetlenia, ustawienie źródła światła Koniec Dodatkowe efekty Tak Czy to wszystkie zródła światła? Rysuj obiekty na które oddziaływuje źródło światła Rysunek 2.9: Algorytm rysowania wieloprzebiegowego. Niektóre zalety z tego powodu stają się wadami. Skutkuje to znacznym wydłużeniem programów cieniujących - może wystąpić problem niedostatecznej ilości dostępnych instrukcji w starszych modelach cieniowania (przed Shader Model 4.0). Kolejno, dużo większym skomplikowaniem kodu programów cieniujących, z czego wynika większy problem z obsługą różnych typów materiałów i modeli oświetlenia. A w przypadku programów cieniujących, nie obsługujących dynamicznych pętli i instrukcji warunkowych koniecznością przechodzenia przez wszystkie instrukcje programu, czyli gorszą wydajnością. Problem ten jest szczególnie widoczny w przypadku obsługi wielu małych świateł. Tym terminem określane są światła, mające mały wpływ na wynikowy obraz. Pojawia się problem implementacji algorytmu wyznaczania grup świateł, wyboru geometrii, na którą oddziaływają oraz optymalizacji ich wpływu na wynikowy obraz (tzw. test nożyczkowy, ang. scissor test). N Start Przygotowanie modelu sceny Wyliczenie parametrów oświetlenia, ustawienie źródła światła Czy to wszystkie zródła światła? Koniec Dodatkowe efekty Rysuj obiekty na które oddziaływują wszystkie źródła światła Tak Rysunek 2.10: Algorytm rysowania wielu świateł jednocześnie. 33

34 2.4.2 Odłożone cieniowanie Odłożone cieniowanie (ang. Deferred Shading lub Deferred Rendering) [24] [21] [19] [?] jest od niedawna stosowaną techniką cieniowania scen trójwymiarowych (pomimo tego, że propozycja takiego rozwiązania padła już w 1988 roku). W odróżnieniu od cieniowania wprost odłożone cieniowanie polega na wykorzystaniu buforów pośrednich, do których renderowana jest geometria. Nałożenie oświetlenia następuje w drugiej fazie, ale już bez konieczności ponownego rysowania geometrii tylko poprzez wykorzystanie buforów pośrednich, w których zapisane są wszystkie informacje o budowie sceny oraz właściwościach materiałów. Zachodzi to w sposób podobny do tradycyjnego rysowania na ekranie, bufory te najczęściej mają postać tekstur o wymiarach równych wymiarom okna renderowania. Do tych buforów nie są jednak zapisywane pocieniowane piksele, lecz piksele z informacjami niezbędnymi do wyliczenia parametrów oświetlenia, tj.: pozycja, wektor normalny, kolor rozproszenia i odbicia materiału. Samo cieniowanie na podstawie parametrów materiału odbywa się dopiero w kolejnych etapach. Stąd nazwa odłożone cieniowanie. Przy czym warto dodać, że powstało kilka wariacji metody odłożonego cieniowania. Najpopularniejsze z nich, to: Deferred Lighting Inaczej nazywane odłożone oświetlenie. Jest to najbardziej rozpowszechniona metoda działająca w oparciu o odłożone cieniowanie. Wyróżniamy w niej dwie fazy: fazę geometrii oraz fazę oświetlenia. W fazie geometrii wszystkie obiekty są rysowane do specjalnego bufora, w którym zapisane są informacje geometryczne tak jak zostało to opisane we wstępie. Natomiast w drugiej fazie na podstawie parametrów buforów geometrycznych następuje wyliczenie wypadkowego koloru. Warto dodać, że nakładanie świateł następuje już w przestrzeni ekranu tylko na podstawie parametrów buforów geometrycznych. Rysunek 2.11: Deferred Lighting: bufory geometryczne. Od lewej: kolor rozproszenia, bufor głębokości, wektory normalne. 34

35 Rysunek 2.12: Deferred Lighting: wynikowy obraz wygenerowany na podstawie buforów geometrycznych. Light pre-pass Inaczej uprzednie oświetlenie [9]. Jest to stosunkowo młoda metoda, wprowadzająca pewne zmiany do oryginalnego algorytmu. W pierwszym etapie do bufora rozmiaru ekranu zapisywane są informacje potrzebne do oświetlenia sceny. Takimi informacjami są pozycja fragmentu w przestrzeni sceny oraz normalna do fragmentu. Takie przygotowanie przypomina etap geometrii stosowany w deferred shadingu, ale w tym wypadku nie zapisujemy informacji o materiałach, czy innych właściwościach pikseli potrzebnych do stworzenia obrazu końcowego. Tu interesuje nas tylko komplet danych wymaganych do obliczenia oświetlenia. W drugim etapie do odpowiedniego bufora zapisywane jest oświetlenie. Kolejne światła zapisywane są jako bryły z shaderem obliczającym oświetlenie na podstawie danych zbuforowanych w poprzednim etapie. W ostatnim etapie wykorzystywany jest bufor głębokości zapisany podczas przygotowania. Dzięki temu uzyskana zostaje minimalna nadmiarowość rysowania pikseli obrazu. Rysunek 2.13: Algorytm Light pre-pass. Od lewej etap 1, 2 i 3. Inferred Lighting Trzecią ostatnią opisywaną wariacją oryginalnego algorytmu jest oświetlenie wnioskowane [20] [23]. Metoda ta podobna jest do poprzedniej. Ma ona tą przewagę, że pozwala na generowanie buforów z rozdzielczością znacznie niższą, niż wynikowa 35

36 rozdzielczość obrazu. Umożliwia to na zwiększenie ilości świateł oraz obiektów na scenie przy tej samej szybkości Mapy cieni Mapy cienia [25] (ang. Shadow Maps) są obecnie bardzo popularną metodą renderowania cieni w interaktywnych aplikacjach graficznych. Szybkość działania, wsparcie sprzętowe oraz stosunkowo łatwa możliwość wdrożenia tej techniki do silnika graficznego sprawia, że nie powinno się przeoczyć tej metody podczas prac nad systemem renderingu. Technika ta została omówiona już w roku 1978 przez Lance Williams a, a następnie z powodzeniem implementowana na przykład w środowisku RenderMan lub filmie ToyStory. Jedno z podejść do wyznaczania cienia polega na wykorzystaniu dedykowanej mapy cienia, czyli tekstury, która przechowuje informacje o fragmentach, które są widoczne z punktu widzenia światła. Konieczność tworzenia mapy cieni wynika z faktu, że dla każdego światła cień jest unikatowy. Nie można zatem wygenerować cieni na podstawie informacji dostępnych przy wykorzystaniu cieniowania wprost lub odłożonego cieniowania. Idea działania mapy cieni polega na renderingu do tekstury danych o geometrii widocznej z miejsca oddziaływania światła. Zarówno kolor, faktura materiału i inne parametry wizualne nie są tutaj potrzebne, nic nie wniosą do wykonywania testu. Na podstawie mapy cienia przy nakładaniu oświetlenia na wypadkowy obraz jesteśmy w stanie sprawdzić na podstawie odległości, czy aktualnie wyświetlany wierzchołek jest w cieniu, czy nie. Zazwyczaj wykorzystuje się jeden lub dwa parametry zapisane w mapie cienia potrzebne do jego wyznacznia: depth - odległość piksela obiektu od punktu oddziaływania światła. Na podstawie tej wartości w punkcie wyliczania oddziaływania światła można sprawdzić, czy obiekt jest w cieniu (czyli dalej niż odległość zapisana w mapie cienia), czy jest oświetlony (czyli tyle samo lub bliżej niż odległość zapisana w mapie cienia). depth2 - odległość do kwadratu. Wykorzystana jest w algorytmie Variance Shadow Mapping do wyliczenia informacji o rozkładzie odległości dla każdego piksela. Rysunek 2.14: Variance Shadow Mapping. Po lewej mapa cienia, po prawej wypadkowy obraz 36

37 Rozdział 3 Programy cieniujące Rozdział ma na celu zapoznanie z zastosowaniem programów cieniujących. Opisuje różne typy oraz wersje tych programów, uwzględniając ich miejsca w potoku renderingu, ograniczenia oraz możliwości. Rozdział prezentuje również różnorodne podejścia do tworzenia programów cieniujących. Przedstawia podstawowe problemy, z którymi styka się programista lub grafik w przygotowaniu pisania programów cieniujących. W dalszej części rozdziału opisuje narzędzia wykorzystywane przy testowaniu i optymalizacji programów cieniujących w kontekście wizualizacji scen trójwymiarowych. 3.1 Cieniowanie Shader w grafice komputerowej to krótki program komputerowy, często napisany w specjalnym języku (shader language [7] [6] [13] [17]). Opisuje on właściwości pikseli oraz wierzchołków. Technologia ta zastąpiła stosowaną wcześniej jednostkę T&L. Ten krótki program komputerowy pozwala na wizualizację znacznie bardziej skomplikowanych modeli oświetlenia i materiału na obiekcie niż standardowo dostępne w środowisku graficznym. Pełna konfigurowalność potoku renderingu wprowadza nowe wymagania obliczeniowe, dużo wyższe niż kilka lat temu. Za cenę wyższych wymagań otrzymujemy dużo relastyczniejszy obraz generowany komputerowo, który może być tworzony w czasie rzeczywistym. Wykorzystanie cieniowania umożliwia uwzględnienie wielu wcześniej niedostępnych dla kart graficznych efektów, które w znaczący sposób podnoszą realizm scen 3D: refrakcji oraz odbić lustrzanych oświetlenia HDR map wypukłości zaawansowanych efektów cieniowania (occlusion) innych efektów tj. rozmycie obrazu, zaszumienie, zmiana kolorów, itp. Pierwsze karty graficzne posiadały jedynie dwie jednostki cieniujące: 37

38 Vertex Shader oraz Pixel Shader. Obliczenia programów cieniujących napisanych dla tych jednostek, były realizowane przez specjalizowane wydzielone obszary procesora karty graficznej. Wraz z rozwojem technologii powstał 3 typ: Geometry Shader. Wprowadzenie tego shadera wraz z biblioteką DirectX10 wymusiło unifikację całego procesu cieniowania. Mimo, że jednostki cieniujące realizują inne funkcje, ich programy są wyliczane w innych momentach potoku renderingu, to w najnowszych kartach graficznych są one zaimplementowane jako tzw. jednolite jednostki obliczeniowe. Jednolite jednostki obliczeniowe są przydzielane do pracy jako dana jednostka cieniująca dynamicznie w zależności od potrzeb. Pozwala to na maksymalizację wykorzystania wszystkich dostępnych jednostek, a co za tym idzie przyspieszenia procesu renderingu. Technologia ta została nazwana dla kart ATI jako Stream Processors a przez nvidię jako Unified Shaders. Podział na 3 jednostki cieniujące obowiązuje dla obu popularnych interfejsów graficznych Direct3D i OpenGL: Vertex Shader - Jest to jednostka cieniująca wierzchołki. Dosyć często inaczej określa się ją jako: cieniowanie wierzchołkowe. Program cieniujący napisany dla tej jednostki jest uruchamiany raz na każdym przetwarzanym wierzchołku. Ma on za zadanie transformację położenia wierzchołka z wirtualnej przestrzeni 3D na współrzędne ekranu względem obserwatora. Pewnym ograniczeniem cieniowania wierzchołkowego jest możliwość operowania tylko na danych explicite określonych, tj.: położenie, kolor, koordynaty tekstu, wektor normalny. Program cieniujący nie ma możliwości tworzenia nowych wierzchołków, tylko transformację jego parametrów. Geometry Shader - Jest to jednostka pozwalająca na modyfikację siatki wierzchołków. Często określa się ją jako: cieniowanie geometryczne. Program cieniujący ma możliwość proceduralnego dodawania lub usuwania wierzchołków z siatki trójkątów. Przykładowym zastosowaniem może być teselacja, czyli dodanie objętościowych detali do istniejącej siatki trójkątów. Operacja taka wykonywana na procesorze jest zbyt kosztowna obliczeniowo oraz powoduje zbyt duży narzut na wykorzystanie pamięci. Takich ograniczeń nie ma jeśli wszystkie obliczenia są wykonywane w potoku renderingu przez przystosowaną do tego jednostkę cieniującą i bezpośrednio jej wyniki przekazywane są dalej do procesu rasteryzacji. Użycie jednostki cieniowania geometrycznego jest opcjonalne. Jego brak skutkuje przekazaniem siatki wierzchołków bez modyfikacji do procesu rasteryzacji. Pixel Shader - Jest to jednostka pozwalająca na programowe wyliczenie koloru pikseli. Innym dosyć powszechnie używanym określeniem jest termin: cieniowanie pikseli. Na wejściu programu są parametry cieniowania pobrane z rasteryzatora, który wypełnia wielokąty przesyłane z potoku graficznego. Cieniowanie pikseli umożliwia nakładanie na fakturę obiektu zaawansowanych efektów oświetlenia, map cieni lub map wypukłości. Wprowadzenie możliwości programowania procesu 38

39 wyliczania koloru pikseli umożliwiło stworzenie realistycznych wizualizacji świata generowanych w czasie rzeczywistym. Gwałtowny rozwój technik programowania procesu przetwarzania obrazu 3D pozwolił w ostatnich latach na powstanie oddzielnej gałęzi programowania: przetwarzanie równoległe. Czyli wykorzystania współczesnych kart graficznych, które notabene są szybsze od współcześnie produkowanych procesorów ogólnego przeznaczenia. Współczesne karty graficzne zbudowane są z kilkuset (a nawet tysięcy) specjalizowanych procesorów zaprojektowanych do przetwarzania równoległego. Dlatego, bardzo często GPU używane są nie tylko do obliczeń graficznych, ale także do obliczeń naukowych. Programy cieniujące można pisać w wielu różnych językach programowania (inaczej nazywanych językami cieniowania). Pierwsze programy cieniujące pisano w assemblerze. Miało to na celu osiągnięcie jak najwyższej wydajności przy bardzo ograniczonych zasobach. Równolegle powstawały języki cieniowania wysokiego poziomu. W większości składnią przypominają język C. Współczesne najczęściej używane języki są to: HLSL - Zdecydowanie najpopularniejszy współcześnie używany język cieniowania. HLSL [13] jest własnościowym językiem zaprojektowanym przez Microsoft na potrzeby DirectX. W tym języku można pisać programy dla jednostek cieniujących wierzchołki, piksele oraz geometrię (dostępne dopiero od DirectX10). Programy napisane w tym języku, skompilowane przez kompilator dostarczony z DirectX SDK mogą być uruchamiane tylko na kompatybilnych z DirectX systemach operacyjnych. Zaliczają się do nich: Windows, Xbox 360 oraz Windows Phone. Cg - Jest to język [17] tworzony równolegle z HLSL w kooperacji z Microsoft przez firmę nvidia. Składnia jest identyczna jak w przypadku HLSL. Biblioteka nvidii jest wieloplatformowa, kompatybilna z szerokim spektrum urządzeń. W tym z systemami Linux i Embedded. Największym plusem Cg jest to, że kompilator stanie generować kod maszynowy dla DirectX oraz OpenGL. Pozwala to na napisanie praktycznie w pełni wieloplatformowych programów cieniujących działających na różnych platformach, różnych urządzeniach oraz różnych systemach operacyjnych. GLSL - Jest to język [10] zaprojektowany dla biblioteki OpenGL i zatwierdzony przez komitet standaryzacyjny ARB. Język ten jest niekompatybilny z wcześniej wymienionymi, wymusza na programiście napisanie nowego kodu programów cieniujących. Wymienione wyżej 3 języki cieniowania są zdecydowanie najpopularniejsze. Do dyspozycji programisty jest ich dużo więcej. Jednak pozostałe są produktami niszowymi, pisanymi głównie na potrzeby konkretnych aplikacji. Takimi produktami są m.in.: RSL (RenderMan Shading Language), VEX (Vector Expression) czy OSL (Open 39

40 Shading Language). Do znacznej większości typowych zastosowań wykorzystanie jednego z 3 jest najlepszym możliwym rozwiązaniem, zapewniającym dużą kompatybilność z różnymi systemami operacyjnymi, platformami deweloperskimi czy interfejsami graficznymi. 3.2 Modele programów cieniujących Pierwsze wersje programów cieniujących zostały zaprezentowane na przełomie roku 2000 wraz z wprowadzeniem DirectX 8.0 i Shader Model 1.0. W chwili obecnej najnowszy Shader Model oznaczony jest numerem 5.0. W tabeli 3.1 przedstawiono wersje API z obsługą programów cieniujących. Natomiast w tabeli 3.2 i 3.3 przedstawiono ograniczenia programistyczne dla różnych modeli. Wersja DirectX Wersja OpenGL Shader Model Pixel Shader Vertex Shader Geometry Shader Compute Shader a a 2.a 2.x 9.0b b 2.b 2.x 9.0c brak jednoznacznej wersji, w tym czasie wykorzystywano rozszerzenia 2 wprowadzono GLSL Tablica 3.1: Wersje programów cieniujących Shader Model 1.0 Był pierwszym modelem cieniowania zaimplementowanym w ramach biblioteki DirectX 8.0 i 8.1. Przedstawiał on koncepcję programowalnych potoków renderingu, wprowadzając cieniowanie wierzchołków i pikseli. Wprowadzał on możliwość implementacji stosunkowo zaawansowanych efektów cieniujących wierzchołki (vs.1.1 umożliwiał wykorzystanie maksymalnie 128 instrukcji) oraz prostych efektów cieniujących piksele. W tym okresie powstały pierwsze implementacje efektów Dot3 Diffuse/Specular Bump Mapping - metod generowania oświetlenia rozproszonego oraz odbijającego opartego o model Phonga-Blinna z wykorzystaniem mapy wypukłości. Wykorzystywano 40

41 SM 1.x SM 2.0 SM 3.0 SM 4.0 SM 5.0 Instrukcje Stałe Zmienne Wejścia Obsługa tekstur Rozmiar tekstur 2D 2048x x8192 Pochodne Kontrola przepływu statyczna statyczna dynamiczna dynamiczna Tablica 3.2: Ograniczenia programów cieniujących wierzchołki. w tym celu mapę wektorów normalnych, teksturę, która miała jako kolor zapisany wektor normalny w przestrzeni płaszczyzny (ang. tangent space). Shader Model 2.0 Był to kolejny model cieniowania dodany wraz z wprowadzeniem na rynek biblioteki DirectX 9.0. Znacząco rozbudowywał możliwości wersji 1.0, pozwalając na pisanie znacznie dłuższych programów cieniujących wierzchołki (256 instrukcji) oraz cieniujących piksele (dla ps.2.0 były to 32 instrukcje teksturowe oraz 64 arytmetycznych). Pozwoliło to na zaimplementowanie jeszcze lepszych modeli oświetlenia z obsługą wygładzania krawędzi cieni. Wraz z większym wykorzystaniem 2.0 nastąpił skokowy wzrost jakości generowanej grafiki. Shader Model 3.0 Był to ostatni model cieniowania dostępny w ramach biblioteki DirectX 9.0c oraz na systemy Windows XP. Główna zmiana w stosunku do 2.0 to określenie w API minimalnej ilości obsługiwanych instrukcji (512 dla programów cieniujących piksele i wierzchołki). Na chwilę obecną jest to jeden z częściej wykorzystywanych modeli cieniowania z racji dużego przywiązania developerów do bardzo dobrej i wydajnej biblioteki DirectX 9.0c oraz obsługi we wszystkich kartach graficznych obecnie dostępnych na rynku. Możliwości tego modelu do chwili obecnej nie są w pełni wykorzystane. Potwierdza to chociażby jakość grafiki w grze Crysis 2, która w pierwszej wersji była dostępna tylko dla DirectX 9.0c. 41

42 SM 1.x SM 2.0 SM 3.0 SM 4.0 SM 5.0 Instrukcje Stałe Zmienne Wejścia Obsługa MRT Obsługa tekstur Rozmiar tekstur 2D 2048x x x x8192 Pochodne Kontrola przepływu statyczna statyczna dynamiczna dynamiczna Shader Model 4.0 Tablica 3.3: Ograniczenia programów cieniujących piksele. Model cieniowania 4.0 (Shader Model 4.0) zaimplementowany w DirectX 10 jest znacznie bardzie elastyczny niż jego poprzednik Shader Model 3.0 z DX 9. Największą zmianą w stosunku do poprzedniej wersji było wprowadzenie Geometry Shaders. Programiści, przy pisaniu programów shaderowych, mają do dyspozycji znacznie więcej rejestrów. Liczba rejestrów stałych wzrosła z 256 do Liczba rejestrów tymczasowych wzrosła zaś z 32 do Zwiększono też rozmiar obsługiwanych tekstur. Zwiększona została również liczba obiektów, które mogą być jednocześnie renderowane techniką MRT (multiple render targets). Dotychczas można było nakładać tekstury na cztery obiekty, teraz tych obiektów może być osiem. Wprowadzono też tablice tekstur (texture arrays) mieszczące do 512 pojedynczych bitmap. Shader Model 5.0 DirectX 11 wprowadza nowy model cieniowania, Shader Model 5.0. Największą innowacją w nim jest to, że używa on pojęć obiektowych i umożliwia wykonywanie obliczeń podwójnej precyzji, co zwiększy dokładność renderingu. Po raz pierwszy pojawia się wykorzystanie Compute Shaders, czyli programów cieniujących wykorzystywanych do przetwarzania równoległego. Inne nowo wprowadzone kluczowe funkcje SM 5.0 dotyczą wymiany danych między wątkami. Wprowadzono w nim bogaty zestaw wyrażeń pierwotnych, do których można się dostać w sposób losowy (co przydaje się przy losowym generowaniu sceny) oraz zestaw instrukcji odpowiedzialnych za sterowanie strumieniowymi operacjami wejścia-wyjścia. Funkcje te umożliwiają szybsze i prostsze zaimplementowanie wykorzystywanych przy generowaniu scen 3D 42

43 technik oraz efektów wprowadzanych na etapie postprocessingu, a także pozwalają używać nowych technik, które zostaną zaimplementowane w sprzęcie zgodnym z DirectX Metody zarządzania efektami Podstawowym problemem każdego programisty piszącego programy cieniujące jest zarządzanie ich bazą. Wraz z rozbudową systemu wykorzystującego shadery musi powstawać coraz więcej ich typów przystosowanych do coraz bardziej specjalizowanych wizualizacji. Takimi wymaganiami są m.in.: Obsługa interfejsów graficznych: DirectX9, DirectX10/11, OpenGL, OpenGL ES Obsługa różnych wersji programów cieniujących: Shader Model 2.0/3.0, Shader Model 4.0/5.0, GLSL Obsługa różnych typów powierzchni: trawa, niebo, skóra, woda, metal Obsługa różnych modeli oświetlenia: bezkierunkowe, lambertowskie, model phonga Obsługa różnych modeli cieniowania: stałe, gouarauda, phonga Obsługa odkształceń: mapy wypukłości, parallax mapping, relief mapping Obsługa poziomów szczegółowości: zmniejszanie ilości detali wraz z oddalaniem obiektu od obserwatora Te i inne nie wymienione wymagania wymuszają konieczność zaprojektowania i zaprogramowania odpowiedniego potoku renderingu. Wiąże się to z koniecznością przygotowania jednego lub wielu programów cieniujących oddzielnie dla jednostek cieniujących wierzchołki, cieniujących geometrię (w przypadku API DirectX10/11) oraz cieniujących piksele. Przeanalizujmy przykładową sytuację. Założeniem jest, że każdy analizowany parametr/model jest niezależny - wymaga oddzielnego programu cieniującego wierzchołki, piksele. W naszym przykładzie mamy system wizualizacji domu. Tabela 3.4 przedstawia zestawienie obsługiwanych przez nasz system modeli cieniowania. Jasno widać, że ilość różnych kombinacji programów cieniujących wierzchołki i piksele jest bardzo duża. Oczywiście ten wynik jest trochę przesadzony, bo w rzeczywistości wykorzystywanych par będzie dużo mniej, ale pokazuje istotę problemu. Jak efektywnie zarządzać takim zasobem, aby móc w miarę sprawnie wprowadzać poprawki wydajnościowe oraz dodawać nowe obsługiwane modele? Jest to problem na tyle powszechny, że powstało wiele metod oraz narzędzi, które ułatwiają parametryzowanie programów cieniujących. Takie najpopularniejsze z nich, to: Ubershader, Efekty FX, Dynamic Shader Linkage, AMD Advanced Shading Language Interface. Postaram się przybliżyć oraz przedstawić ich zalety i wady. 43

44 Typ Obsługiwane modele Ilość programów cieniujących wierzchołki Ilość programów cieniujących piksele Interfejs graficzny DirectX9, OpenGL 2 2 Wizualizowane metal, woda, niebo, 4 4 powierzchnie drewno Oświetlenie bezkierunkowe, 3 3 phong, phong-blinn Cieniowanie bez cieni, prosta mapa 3 3 cieni, wygładzona mapa cieni Odkształcenia bez odkształceń, 1 3 mapa wypukłości, parallax mapping Poziomy wysoka, średnia, niska 1 3 szczegółowości Ilość kombinacji Tablica 3.4: Metody zarządzania efektami - przykład Pliki FX Pliki efektów FX są, jednym z wielu podejść do problemu zarządzania shaderami. Efekty pozwalają programiście na określenie w ramach jednego kodu różnych techniki ich wyświetlania - parametryzacji - poziomu szczegółowości. Efekty mogą zawierać różne techniki renderowania (może to być np. kod programów cieniujących), które mogą być następnie wybierane programowo w momencie wizualizacji konkretnego obiektu. Efekty FX jest to rozwiązanie wchodzące w skład Microsoft DirectX SDK. Podobna funkcjonalność jest dostępna w ramach środowiska Cg od nvidii. SDK udostępnia zestaw interfejsów, które pozwalają w łatwy sposób kompilować efekty z plików tekstowych, manipulować ich parametrami, czy ustawiać w potoku renderingu. Wykorzystanie plików z efektami jest prostym i szybkim sposobem na zarządzanie sporą ilością shaderów w ramach jednej aplikacji. Udostępniony system jest kompletnym rozwiązaniem, które zdejmuje z programisty konieczność ręcznej kompilacji, zarządzania oraz konfiguracji shaderów. Bardzo często pliki efektów są wykorzystywane w aplikacjach pisanych na szybko, gdzie wydajność renderingu a sprawność jego uruchomienia jest kluczowe. Przykładem takich aplikacji są wszelkie prace konkursowe, bardzo często też programy prezentujące implementację jakiejś określonej techniki. 44

45 Plik zawierający opis efektu podzielony jest zazwyczaj na trzy główne sekcje: Deklaracje zmiennych Deklaracje zmiennych są to wartości, które mogą zostać ustawione programowo (z poziomu aplikacji C++) a potem użyte w wykorzystanej technice. W celu deklaracji zmiennej należy określić jej typ oraz identyfikator (unikalna nazwa). Następnie można przypisać wartość w zależności od celu wykorzystania zmiennej, zdefiniowanych danych użytkownika czy wartości początkowej. Każda zadeklarowana zmienna może zostać odczytana i zmodyfikowana programowo z poziomu aplikacji C++. Interfejs ID3DXEffect udostępnia odpowiednie funkcje, tj.: SetTexture, SetMatrix, SetVector. Przykładowe zmienne: tekstury, macierz świata, parametry oświetlenia. Techniki i przejścia Najciekawszą własnością plików z efektami są tzw. techniki. W jednym pliku może być zdefiniowanych wiele różnych technik, które realizują różne efekty (celowo zostało wykorzystane to słowo). Efekt w kontekście realizacji złożonej funkcji wizualizacji, np.: kolorowania, oświetlania, cieniowania. Dodatkowo przewidziano, że pewne techniki mogą wymagać wieloprzebiegowego renderingu. Dlatego w ramach jednej techniki może być zdefiniowane wiele przejść. Każde przejście ma możliwość zmiany ustawień renderera: ustawienia buforu głębokości, ustawienia teksturowania, ustawić programy cieniujące. Przykładowy plik z efektem definiuje dwie techniki: FirstTechnique i SecondTechnique. W ramach FirstTechnique zdefiniowane jest jedno przejście P0, które ustawia oświetlenie per-vertex oraz włączą test głębokości. SecondTechnique wykonywane jest dwu przebiegowo. Pierwszy przebieg zmienia parametry filtrowania tekstury, natomiast drugi przebieg ustawia program cieniujący wierzchołki. Funkcje Na samym końcu są zdefiniowane funkcje napisane w HLSL. Funkcje mogą być wykonane w ramach techniki. Taka funkcja jest kompilowana do kodu maszynowego, który następnie jest używany jako program cieniujący w ramach wykorzystanej techniki. Tym sposobem programista ma możliwość definicji i parametryzacji w plikach efektów programów cieniujących wierzchołki, geometrię i piksele Uber Shaders Popularnym rozwiązaniem problemu dużej ilości kombinacji programów cieniujących jest wykorzystanie tzw. Uber Shaders. Jest to określenie używane do jednego dużego ciągłego programu cieniującego, który zawiera wszystkie możliwe efekty. Jednakże każdy 45

46 technique FirstTechnique { pass P0 { Lighting = true; // włącz oświetlenie z jednostki T&L ZEnable = true; // włącz test głębokości } } technique SecondTechnique { pass P0 { // ustaw filtrowanie tekstur na liniowe MinFilter[0] = Linear; } pass P1 { // przypisz do jednostki cieniowania wierzchołków // funkcję HLSL o nazwie OurShaderName VertexShader = compile vs_1_1 OurShaderName(); } } Program 3.1: Przykładowy plik z efektem z tych efektów jest włączalny. Aplikacja kompilująca lub uruchamiająca taki program ma możliwość aktywacji pewnych jego ściśle określonych funkcji z pominięciem pozostałych. Włączanie efektów można zrealizować na kilka różnych sposobów: Użycie parametrów programu cieniującego. Parametry takie są ustawianie przed uruchomieniem programu na karcie graficznej. Jednak takie podejście w większości przypadków skutkuje dużymi stratami wydajności. Wyłączone funkcje nadal są wyliczane. Wykorzystanie instrukcji warunkowych programów cieniujących. Najnowsze API graficzne umożliwiają wykorzystanie statycznych instrukcji warunkowych. Pozwala to na pominięcie fragmentów programu wyłączonych z obliczeń. Dużym problemem jest fakt, że wykorzystanie jednego ciągłego programu jest problematyczne z punktu widzenia optymalizacji kodu maszynowego - efekt nieoptymalny kodu programu cieniującego. W przypadku starszych modeli cieniowania problemem też może okazać się ograniczona ilość instrukcji programów cieniujących. Wykorzystanie dyrektyw preprocesora do wyłączenia niewykorzystanych funkcji. Umożliwia to wielokrotną kompilację jednego kodu programu za każdym razem z innymi ustawieniami preprocesora. Każda kombinacja ustawień ma przygotowany skompilowany i zoptymalizowany program cieniujący. 46

47 Największym problemem Uber Shaders jest konieczność przygotowania jednego dużego programu cieniującego. Taki program musi zawierać wszystkie obsługiwane techniki wizualizacji. Każda z technik musi być konfigurowalna (co najmniej włączalna/wyłączalna). Problem pojawia się, gdy trzeba dodać nową technikę, poprawić błędy w starej lub dokonać optymalizacji. Po pewnym czasie powstaje tzw. spaghetti code, czyli skomplikowany i trudny do zrozumienia kod źródłowy programu. Co nie jest do końca uważane za dobrą praktykę programistyczną Dynamic Shader Linking Jest to stosunkowo nowa funkcjonalność dostępna od Shader Model 5.0 [12]. Po raz pierwszy została przedstawiona wraz z prezentacją biblioteki Direct3D 11. Nowy system udostępnia programiście możliwość wykorzystania metod programowania obiektowego w ramach przygotowania programów cieniujących w języku HLSL. Mechanizm dynamicznego dołączania rozdziela kody programów cieniujących wykorzystując do tego celu interfejsy oraz wirtualne funkcje i pozwala aplikacji na wybór fragmentów kodu cieniującego przy wizualizacji obiektu. W programach pisanych z wykorzystaniem Dynamic Shader Linkage wykorzystane są dwa powszechnie stosowane obiektowe wzorce projektowe: Interfejsy Interfejs jest abstrakcyjną implementacją klasy. Wykorzystanie instancji interfejsu pozwala programowi cieniującemu na wykonanie metody bez znajomości, która jej implementacja zostanie wykonana. Kod programu cieniującego musi zdefiniować jedną lub więcej do każdego dostępnego interfejsu. interface ibaselight { float3 IlluminateAmbient(float3 vnormal); float3 IlluminateDiffuse(float3 vnormal); float3 IlluminateSpecular(float3 vnormal, int specularpower ); }; Program 3.2: Interfejsy w Shader Model 5.0 Klasy Klasa podobnie jak w innych językach obiektowych jest kontenerem grupującym zmienne i metody. Klasa może dziedziczyć z co najwyżej jednej klasy, ale z więcej niż jednego interfejsu. Klasa musi implementować wszystkie metody dziedziczonych interfejsów, inaczej taka klasa nie może zostać wykorzystana jako instancja obiektu. 47

48 class cambientlight : ibaselight { float3 m_vlightcolor; bool m_benable; float3 IlluminateAmbient(float3 vnormal); float3 IlluminateDiffuse(float3 vnormal); float3 IlluminateSpecular(float3 vnormal, int specularpower ); }; Program 3.3: Klasy w Shader Model 5.0 Na pewno możliwość wykorzystania metod programowania obiektowego w programach cieniujacych jest dużym ułatwieniem dla programistów. Jednakże takie ograniczenie, jakim jest kompatybilność z najnowszą biblioteką Direct3D 11 dyskwalifikuje wykorzystanie tej metody do szerokich zastosowań. 3.4 Narzędzia wspomagające tworzenie kodu Tworzenie i optymalizacja dzisiejszych programów cieniujących to trudne zadanie. Powstała więc konieczność stworzenia narzędzi, które w pewnym stopniu automatycznie będą mogły znaleźć, już na etapie pisania kodu programów, potencjalne newralgiczne miejsca. Tworzeniem i rozwijaniem narzędzi zajmują się głównie dwie firmy - wiodące na rynku kart graficznych: AMD oraz nvidia. Podstawowe wymagania stawiane takim narzędziom, to: Zintegrowane środowisko programistyczne dla języków cieniowania. Integracja ze środowiskiem developerskim (np. Visual Studio). Obsługa różnych interfejsów graficznych, języków cieniowania. Możliwość symulacji całego potoku renderingu, bez konieczności tworzenia kodu: C++, C#, itp. Możliwość uruchomienia symulacji na docelowym urządzeniu, np.: Xbox, iphone, itp. Duża biblioteka przykładowych efektów, modeli, tekstur. Narzędzia analizy wydajności programu cieniującego w kontekście różnych architektur i modeli kart graficznych. Możliwość oskryptowania działania aplikacji. Zdecydowanie najlepszym i spełniającym najwięcej postawionych powyżej wymagań jest FX Composer firmy nvidia. FX Composer, to zintegrowane środowisko programistyczne do tworzenia shaderów, pozwalające na szybkie tworzenie efektów wizualnych w czasie rzeczywistym. Może być wykorzystywane do tworzenia shaderów 48

49 dla HLSL oraz Cg DirectX i OpenGL. Aplikacja posiada bogatą zintegrowaną bibliotekę shaderów, narzędzie do analizy ShaderPerf, obsługę animacji, skryptów, efektów i kreatorów projektów. Najciekawsze, niewymienione w wymaganiach możliwości to: Obsługa interfejsów graficznych: Direct9/10/11/Xbox/Xbox360, OpenGL. Obsługa języków cieniowania: HLSL, Collada FX Cg, CgFX. Obsługa debugowania programów cieniujących. Obsługa systemu cząsteczek (ang. Particle Systems). Możliwość zdalnego testowania programów cieniujących (przez TCP/IP). Bogata biblioteka przygotowanych efektów - możliwość szybkiej adaptacji do własnych potrzeb. Rozbudowany edytor kodu: gotowe wstawki, zwijanie sekcji, automatyczne podpowiedzi. Rozbudowany system materiałów. Rozbudowany system sceny: zarządzanie modelami, światłami, kamerami. Obsługa importu modeli z.3ds,.fbx,.dae,.x i.obj. Obsługa animacji szkieletowej. Rozbudowana analiza wydajności programów cieniujących: porównywanie wydajności dla różnych architektur/model kart graficznych, wyliczenia przepustowości programów cieniujących, wykorzystania rejestrów, instrukcji, zagnieżdżeń. Rysunek 3.1: Okno programy FXComposer

50 Te oraz inne możliwości czynią z tego programu idealne narzędzie do weryfikacji poprawności napisanych programów. 3.5 Narzędzia wspomagające optymalizację Wstępną optymalizację programów cieniujących uzyskujemy przygotowując programy cieniujące w odpowiednich narzędziach programistycznych. Bardzo często uruchomienie takiego programu we własnej aplikacji daje zupełnie odmienne rezultaty, niż te w środowisku programistycznym. Bardzo często okazuje się, że ograniczona wydajność naszych programów cieniujących wynika z innych elementów potoku renderingu, niż sam kod programu cieniującego. Zdarza się, że wykorzystanie konkretnej metody lub zbioru metod skutkuje przyblokowaniem potoku renderingu, np. przy filtrowaniu tekstur. Z pomocą przychodzą wyspecjalizowane programy wspomagające optymalizację potoku renderingu NV PerfHUD NVIDIA PerfHUD jest rozbudowanym środowiskiem do analizy aplikacji Direct3D w czasie rzeczywistym. Do poprawnej pracy wymaga instalacji dedykowanego sterownika dla karty graficznej, obsługiwane są tylko karty graficzne firmy NVidia. Aplikacja ta jest szeroko stosowana w przemyśle gier wideo do optymalizacji kodu potoku renderingu. Rysunek 3.2: Okno programu PerfHUD Najciekawsze możliwości, to: 50

51 Obsługa interfejsów graficznych: Direct9/10. Obsługa aplikacji 32 i 64 bitowych. Obsługa aplikacji natywnych i zarządzalnych. Możliwość zapisu renderowanej ramki do pliku celem późniejszej analizy. Osługa API Direct3D: możliwość podejrzenia listy wywołań, prezentacją zależności między kolejnymi wywołaniami, możliwością ustawienia breakpointów na zdarzenia. Okno The Performance Dashboard z dostępem do ponad 50 różnych wskaźników obciążenia dla Direct3D i GPU. Okno The Frame Debugger z obsługa podglądu tekstur (2D, 3D, map cieni, celów renderingu) i podglądem stanów renderingu. Okno The Frame Profiler narzędzie do przeprowadzenia zautomatyzowanej analizy wydajnościowej renderowanej ramki. Pozwala na podgląd kosztów wykonania każdej operacji, wyliczenia shaderów i obserwację ich wpływu na wypadkową szybkość renderowania obrazu. Rysunek 3.3: PerfHUD: Graf prezentujący obciążenie jednostek cieniujących. Rysunek 3.4: PerfHUD: The Frame Profiler 51

52 3.5.2 NV Parallel Nsight Jest następcą znakomitego programu NV PerfHUD. NV Parallel Nsight dodaje możliwość integracji obliczeń GPGPU w środowisku Microsoft Visual Studio. Umożliwia zbudowanie, debugowanie, profilowanie i śledzenie aplikacji wykorzystywanych do obliczeń równoległych oraz aplikacji graficznych pisanych z wykorzystaniem CUDA C/C++, OpenCL, DirectComputer, Direct3D i OpenGL. Podstawowe funkcje środowiska, to: Zintegrowane środowisko do obsługi obliczeń równoległych. Zintegrowane środowisko do śledzenia aplikacji i systemu operacyjnego w celu wykrycia tzw. wąskich gardeł, czyli funkcji programistycznych szczególnie wpływających negatywnie na wydajność. Zintegrowane środowisko do debugowania aplikacji graficznych. Zintegrowane środowisko do profilowania aplikacji graficznych. Rysunek 3.5: Parallel Nsight: Obsługa Cuda. Podgląd wykorzystania procesorów strumieniowych. Rysunek 3.6: Parallel Nsight: Obsługa grafiki. Debugger programów cieniujących. 52

53 Rozdział 4 Graficzny edytor cieniowania Propozycją obejścia przedstawionych w poprzednim rozdziale problemów jest Graficzny edytor cieniowania, będący przedmiotem niniejszej pracy magisterskiej, wchodzący w skład podsystemu: MaterialSystem. Celem powstania graficznego edytora cieniowania jest zautomatyzowanie procesu generacji kodu programów cieniujących. Tak jak zostało to przedstawione przy okazji omawiania metod zarządzania efektami, wraz ze wzrostem ilości obsługiwanych modeli ilość możliwych kombinacji programów cieniujących wzrasta wykładniczo. Przedstawione w poprzednim rozdziale metody są głównie rozwiązaniami programistycznymi - wymuszają znajomość specjalizowanego języka cieniowania. W związku z tym wykluczony zostaje udział przy modelowaniu nowych typów efektów osób nie umiejących programować, np. grafików. Opisane w tym rozdziale rozwiązanie omija to twarde ograniczenie poprzez ubranie funkcji i efektów normalnie wykonywanych programistycznie w postać graficznych bloków, które łączone są w wizualną strukturę nazwaną diagramem przepływu. Efektem działania systemu jest kod programu cieniującego - oddzielnie dla każdej jednostki cieniującej kompatybilny ze środowiskiem uruchomieniowym aplikacji (np. DirectX). Rozdział ten szczegółowo opisuje jego mechanikę, wykorzystane struktury danych oraz ich właściwości. Prezentuje mechanizmy wykorzystane w procesie przygotowania, generacji oraz kompilacji kodu programów cieniujących. 4.1 Koncepcja działania Koncepcja działania graficznego edytora cieniowania polega na wykorzystaniu różnych typów bloków, które definiują diagram przepływu. Każdy blok posiada określoną ilość wejść i wyjść, które można łączyć z wyjściami i wejściami innych bloków. Każdy blok realizuje ściśle określoną funkcję na podstawie parametrów oraz danych wejściowych i przekazuje jej wynik na wyjście. Na podstawie wzajemnych połączeń generowany jest kod programów cieniujących wierzchołki i piksele, który następnie jest kompilowany i wgrywany do pamięci karty graficznej. 53

54 Aplikacja wykorzystująca MaterialSystem jest kluczowym modułem projektu silnika graficznego ayuine2c. Odpowiedzialny jest on za generację programów cieniujących dla określonego interfejsu graficznego oraz określonego typu potoku renderingu. Aktualna implementacja obsługuje jedynie DirectX9. Mimo, iż może się to wydawać dużym ograniczeniem w rzeczywistości tak nie jest. Wynika to z faktu, że od początku przy projektowaniu całego systemu brano pod uwagę wykorzystanie innych interfejsów graficznych. Zrezygnowano z implementacji innych API dlatego, że nie podniosłyby one znacząco wartości projektu a jedynie wydłużyłyby czas programowania Przestrzeń robocza Przestrzeń robocza jest to obszar pracy osoby tworzącej program cieniujący. Zasada jego działania opiera się na umieszczaniu bloków oraz łączeniu ich w celu realizacji bardziej skomplikowanych funkcji. Edycja wymusza przestrzeganie paru poniższych zasad: Po lewej stronie znajdują się bloki wejściowe. Po prawej stronie znajduje się dokładnie jeden blok wyjściowy. Wejścia bloków zawsze znajdują się po jego lewej stronie. Wyjścia bloków zawsze znajdują się po jego prawej stronie. Jedno wyjście może być podłączone do wielu wejść. Jedno wejście może być podłączone tylko do jednego wyjścia. Połączenia między blokami nie mogą tworzyć zapętleń. Okna przestrzeni roboczej Przykładowy wygląd przestrzeni roboczej został przedstawiony na rys Jego strukturę można opisać następująco: 1. Pasek narzędzi - Umożliwia dostęp do komend odczytu, zapisu, odznaczenia i usunięcia. Dodatkowo udostępnia możliwość wyboru metody renderingu: FS - cieniowanie wprost LIT - cieniowanie wprost bez faktury DS - odłożone cieniowanie HDR - efekty HDR 2. Przestrzeń edycyjna - Umożliwia zaznaczanie, przesuwanie, dodawanie oraz łączenie bloków. 3. Ekran właściwości - Pokazuje właściwości aktualnie zaznaczonych bloków. 4. Lista bloków - Pokazuje listę wszystkich dostępnych bloków możliwych do umieszczenia w programie. Metodą przeciągnij i upuść są one dodawane do programu. 54

55 5. Ekran podglądu - Pokazuje podgląd aktualnego shadera oświetlenia lub materiałowego. 6. Ekran logów - Pokazuje informacje generatora. Rysunek 4.1: Przestrzeń robocza Proces tworzenia programu cieniującego 1. Wybranie z listy bloków funkcji i umieszczeniu ich w przestrzeni edycyjnej. 2. Połączenie bloków według następującej zasady: wyjście przeciągamy do wejścia. 3. Ustawienie parametrów każdego z bloków. 4. Sprawdzenie działania programu cieniującego. 5. Naniesienie poprawek Budowa bloku Każdy blok realizuje jedną ściśle określoną funkcję. W programie może być wiele bloków realizujących te same funkcje o ile ich wyjścia są podłączone do innych wejść. Wygląd każdego bloku jest ustandaryzowany i prezentuje następujące informacje: 1. Nazwa lub typ bloku 2. Wejścia bloku 3. Wizualizacja danych 55

56 4. Wyjścia bloku Rysunek 4.2: Wizualizacja bloku Diagram przepływu W celu zaznajomienia czytelnika ze schematem działania systemu posłużę się przykładowym diagramem zdefiniowanym na rys Diagram składa się z 4 różnych bloków. Każdy z nich realizuje inną funkcję, przyjmuje inne parametry wejściowe oraz inne wartości zwraca na wyjście. Kluczowym z punktu widzenia tego diagramu jest blok wysunięty najbardziej na prawo Output::Solid. Definiuje on punkt końcowy fragmentu programu cieniującego zdefiniowanego przez prezentowany diagram przepływu. Opis poszczególnych bloków oraz realizowanych funkcji wygląda następująco: diffusetexture - Bloczek parametryzuje program cieniujący. Dodaje on możliwość określenia samplowanej tekstury. Stream::TexCoords - Bloczek pobiera z parametrów wierzchołka koordynaty tekstury. Texturing::Sampler - Bloczek sampluje teksturę w określonym koordynatami miejscu przekazuje kolor RGBA na wyjście. Przyjmuje i zwraca on następujące parametry: [Sampler] - Uchwyt do tekstury. [Coords] - Koordynaty tekstury. [Color] - Wyjście: zwraca kolor RGB w miejscu samplowania. [Alpha] - Wyjście: zwraca przezroczystość w miejscu samplowania. Output::Solid - Bloczek definiuje koniec diagramu przepływu. Przyjmuje on dwa parametry: [Color] - Kolor zwracany przez program cieniujący. [Alpha] - Przezroczystość zwracana przez program cieniujący. Opisany schemat jest jednym z najprostszych programów. Implementuje on najprostszy typ materiału z jedną teksturą oraz koordynatami pobieranymi z parametrów wierzchołka. 4.2 Architektura systemu MaterialSystem jest to nazwa określająca grupę komponentów realizujących podobne funkcje, tworzące jedną spójną całość. Architektura systemu wraz z zależnościami została przedstawiona na rysunku 4.3. Strukturę systemu można podzielić na trzy części: 56

57 Opis programu cieniującego - Jest to grupa struktur przechowująca informacje o programie cieniującym zdefiniowanym przez diagram przepływu. Przechowuje ona listę bloków, ich parametry oraz połączenia między nimi. Opis materiału - Jest to grupa struktur przechowująca informacje o parametrach materiału. Podstawowym parametrem opisu materiału jest wybrany shader opisujący program cieniujący. Opis ponadto może zawierać wartości parametryzujące program cieniujący, tj.: tekstury, kolor, ustawienia cieniowania. Generacja programu cieniującego - Jest to grupa struktur, która na podstawie określonych parametrów kompilacji oraz określonego programu cieniującego generuje tekstowy kod programu cieniującego, który następnie może zostać skompilowany i wgrany do pamięci karty graficznej. Opis programu cieniującego Diagram przepływu Blok wejściowy Link Blok funkcyjny Link Blok wyjściowy Shader Parametry shadera Materiał Opis materiału Parametry kompilacji Kompilator Tekstowy kod shadera Generacja programu cieniującego Rysunek 4.3: Architektura MaterialSystem 57

58 4.2.1 Opis programu cieniującego Strukturą opisującą program cieniujący jest Shader. W projekcie wykorzystywanych jest wiele różnych typów shaderów, które są używane z różnymi typami obiektów. Rys. 4.4 przedstawia hierarchię klasy Shader. W implementacji systemu podzielono shadery na dwa typy: shader materiałowy - Shadery dziedziczące po klasie GeneralShader, które wyliczają parametry materiału (powierzchni). Takimi parametrami są: kolor otoczenia (ang. ambient), kolor rozproszenia (ang. diffuse), kolor emisji (ang. emissive), kolor odbicia (ang. specular), przezroczystość (ang. opacity), wektor normalny (ang. normal), itp. shader oświetlenia - Shadery zdefiniowane przez klasę LightShader, które wyliczają wpływ oświetlenia na wynikowy kolor. Implementując ten shader można uzyskać: oświetlenie phong-blinn, światło rysunkowe (ang. cartoon lighting), mapy cieniu, światła kierunkowe, światła pulsujące lub latarki. Shader LightShader GeneralShader MaterialShader TerrainShader SkyShader Rysunek 4.4: Hierachia klasy Shader Każdy shader jest definiowany oddzielnie. Designer tworzy shader materiałowy, a następnie shader oświetlenia. Każdy typ jest przypisywany do odpowiedniego obiektu: do obiektów geometrycznych shader materiałowy, a do świateł shader oświetlenia. Silnik graficzny automatycznie na podstawie tych dwóch typów programów i wybranego potoku renderingu generuje kod programów cieniujących. Takie podejście pozwala na logiczne rozdzielenie funkcjonalności: w shaderze materiałowym definiujemy wyliczanie parametrów materiałów, w shaderze oświetlenia definiujemy zachowanie się wybranego modelu oświetlenia. Pozwala to na uproszczenie diagramów i możliwość wprowadzenia automatycznej obsługi zaawansowanych potoków renderingu, tj. deferred shading. Klasa Shader Jest to klasa abstrakcyjna, która jest specjalizowana przez określony typ shadera: materiałowy lub oświetlenia. Struktura shadera przechowuje informacje o liście bloków, 58

59 o liście zmiennych oraz o połączeniach między blokami. Lista implementowanych funkcji: addblock() - Metoda dodająca nowy blok do listy bloków. removeblock() - Metoda usuwająca blok z listy bloków. blockcount() - Metoda zwracająca ilość bloków. block(i) - Metoda zwracająca i-ty blok. contains(nazwa) - Metoda zwracająca informację o istnieniu zmiennej o określonej nazwie. get(name) - Metoda zwracająca wartość zmiennej o określonej nazwie. constmaxoffset() - Metoda zwracająca maksymalną ilość slotów dla stałych programu. samplermaxcount() - Metoda zwracająca maksymalną ilość slotów dla tekstur programu. vertextype() - Metoda zwracająca oczekiwany typ wierzchołka dla danego typu programu. Shader +addblock(wartość block : QSharedPointer<ShaderBlock>) : bool +removeblock(wartość index : unsigned) : bool +blockcount() : unsigned +block(wartość index : unsigned) : QSharedPointer<ShaderBlock> +contains(wartość name : const QByteArray &) : bool +get(wartość name : const QByteArray &) : QVariant +constoffset() : unsigned +constmaxcount() : unsigned +sampleroffset() : unsigned +samplermaxcount() : unsigned +vertextype() : Types Rysunek 4.5: Opis klasy Shader Połączenia Każde wejście i wyjście bloku ma zdefiniowany typ danych. Wejście bloku oczekuje pewnego typu danych, a wyjście zwraca dane o określonym typie. O ile jest to możliwe przeprowadzana jest automatyczna konwersja z typu wyjściowego na typ wejściowy. System nie pozwala na przypisanie do wejścia bloku niekompatybilnego (niekonwertowalnego) typu danych z wyjścia. Na rys. 4.1 przedstawiono obsługiwane typy danych a na rys. 4.2 macierz konwersji. Blok funkcyjny Jest to grupa bloków realizujących ściśle wyspecjalizowane funkcje. Bloki funkcyjne można podzielić na następujące kategorie: 59

60 Nazwa typu Opis Parametry Ilość float liczba X 1 float2 wektor dwuargumentowy X,Y 2 float3 wektor trójargumentowy X,Y,Z 3 euler kąty eulera w radianach Yaw,Pitch,Roll 3 float4 wektor czteroargumentowy X,Y,Z,W 4 color parametry koloru od 0 do 1 R,G,B,A 4 matrix macierz 4x4 M11,..,M44 16 sampler uchwyt do jednostki S 1 filtrującej tekstury Tablica 4.1: Obsługiwane typy danych float float2 float3 euler float4 color matrix sampler float float2 float3 euler float4 color matrix sampler Tablica 4.2: Macierz konwersji typów: kolumny typ wyjściowy, wiersze typ wejściowy matematyczne - bloki implementujące określone zdefiniowane funkcje, tj.: normalizację, zamianę współrzędnych sferycznych. parametryczne - bloki pozwalające na parametryzację programu cieniującego, np. pozwalają na zdefiniowanie koloru lub tekstury. stałe - bloki przekazują aktualne parametry przetwarzanej klatki, np.: czas rysowania klatki. efekty - bloki realizujące określone typy efektów, np.: cieniowanie, efekty wypukłości, poziomy szczegółowości. Blok wejściowy i wyjściowy Są to specjalne typy bloków używane w shaderach materiałowych i shaderach oświetlenia. Blok wyjściowy pozwala na przekazanie wszystkich parametrów materiału do fazy oświetlenia, a blok wejściowy na użycie ich w fazie oświetlenia. Para bloków wyjściowy-wejściowy jest wirtualnym połączeniem pozwalającym na przesłanie 60

61 wszystkich parametrów materiału pomiędzy fazą materiałową a fazą oświetlenia. Jest to istotne, gdyż system dopuszcza możliwość przekazywania parametrów między różnymi fazami generowania geometrii. Przykładem może być użycie potoku renderingu, wykorzystującego odroczone cieniowanie (ang. deferred shading). W potoku tym, istnieje podział na fazę materiałową (inaczej fazę geometrii) oraz na fazę oświetlenia. Parametry przekazywane są poprzez specjalny bufor pośredni tzw. G-bufor. Są to specjalne tekstury, do których są pakowane parametry materiałów, które są następnie rozpakowywane w fazie oświetlenia. Mechanizm rozdziału shaderów na materiałowe i oświetlenia, pozwala na dowolne pakowanie danych przy ich przesyłaniu. Kod programu cieniującego może być jednolity: zawierający shader materiałowy oraz shader oświetlenia lub dwufazowy: shader materiałowy zapisuje dane do buforów pośrednich. Natomiast shader oświetlenia odczytuje z buforów pośrednich parametry geometryczne. Klasa ShaderBlock Jest to klasa abstrakcyjna, która jest specjalizowana przez określony typ bloku. Struktura bloku przechowuje informacje o liście połączeń, o ustawieniach oraz o wartościach domyślnych zmiennych definiowanych przez blok. Implementacja wymaga obsługi następujących metod: inputlink(i) - Metoda zwracająca opis i-tego wejścia bloku: oczekiwany typ danych oraz nazwę. inputcount() - Metoda zwracająca ilość wejść bloku. outputlink(i) - Metoda zwracająca opis i-tego wyjścia bloku: zwracany typ danych oraz nazwę. outputcount() - Metoda zwracająca ilość wyjść bloku. connect(j-wyjście, i) - Metoda przypisująca j-te wyjście innego bloku do i-tego wejścia. Sprawdzana jest poprawność typów. unlink(blok) - Metoda usuwająca wszystkie dowiązania do określonego bloku. blockmaxcount() - Metoda zwracająca maksymalną ilość bloków danego typu, które mogą być umieszczone w jednym shaderze. inputvarname(kompilator,i) - Metoda zwracająca nazwę zmiennej i-tego wejścia bloku w kontekście kompilatora. Wartość zmiennej jest przekonwertowana do typu oczekiwanego wejścia. W przypadku, gdy do wejścia nie jest przypisane żadne wyjście zwracana jest wartość domyślna dla oczekiwanego typu. outputvarname(kompilator,i) - Metoda zwracająca nazwę zmiennej i-tego wyjścia w kontekście kompilatora. 61

62 ShaderBlock +inputlink(wartość index : unsigned) : Link +inputcount() : unsigned +outputlink(wartość index : unsigned) : Link +outputcount() : unsigned +connect(wartość other : OutputLink, wartość selected : Link) : bool +unlink(wartość block : const QSharedPointer<ShaderBlock>&) : unsigned +blockmaxcount() : unsigned #inputvarname(wartość compiler : MaterialShaderCompiler &, wartość index : unsigned) : QString #outputvarname(wartość compiler : MaterialShaderCompiler &, wartość output : unsigned) : QString Opis materiału Rysunek 4.6: Diagram UML klasy ShaderBlock Opis materiału przechowywany jest w klasie Material, która rozszerza funkcjonalność klasy ShaderState. ShaderState jest strukturą opisującą stan shadera. Przechowuje on uchwyt na wskaźnik Shader oraz listę wartości dla zmienionych zmiennych. Opis materiału oprócz, zmiennych mających wpływ na wygląd graficzny obiektu, przechowuje zmienne, mające wpływ na symulację fizyczną. W przyszłości będą to jeszcze dźwięki lub np. dialogi. Parametry materiału pozwalają przy wizualizacji na szybkie grupowanie obiektów w celu przyspieszenia renderingu według następujących kryteriów, tj.: shader, tekstury, ustawienia przezroczystości, ustawienia oświetlenia, materiały. Material ShaderState +opaque() : OpaqueMode +shadows() : bool +collidable() : bool +staticfriction() : float +dynamicfriction() : float +elasticity() : float +softness() : float +contains(wartość name : const QByteArray &) : bool +get(wartość name : const QByteArray &) : QVariant +set(wartość name : const QByteArray &, wartość value : const QVariant &) +values() : ShaderValues +materialshader() : const QSharedPointer<Shader>& +setmaterialshader(wartość materialshader : const QSharedPointer<Shader>&) Rysunek 4.7: Opis klasy Material Klasa Material udostępnia następujące metody: contains(nazwa) - Metoda zwracająca informację o istnieniu zmiennej o określonej nazwie. get(name) - Metoda zwracająca wartość zmiennej o określonej nazwie. set(name, wartość) - Metoda ustawia wartość zmiennej o określonej nazwie. values() - Metoda zwraca listę wszystkich zmiennych oraz ich wartości. materialshader() - Metoda zwraca ustawiony shader. opaque() - Metoda zwraca ustawienia przezroczystości. Dostępne są następujące tryby: Opaque - bez przezroczystości AlphaTest - wykorzystuje test kanału alfa. Pozwala określić, czy obiekt jest przezroczysty 62

63 czy nie. Efekt słaby wizualnie, ale bez większego wpływu na szybkość wizualizacji. Sort - pełna przezroczystość. Wymaga sortowania obiektów względem odległości od obserwatora oraz wyświetlania ich od tyłu (od najdalszego do najbliższego). Efekt pozwalający na wizualizację obiektów półprzezroczystych, ale mający duży wpływ na szybkość wizualizacji. Wynika to z konieczności wyłączenia części optymalizacji grupujących obiekty. staticfriction() - parametr fizyczny, statyczny współczynnik tarcia. dynamicfriction() - parametr fizyczny, dynamiczny współczynnik tarcia. elasticity() - parametr fizyczny, elastyczność powierzchni wykorzystywana przy symulacji tkanin. softness() - parametr fizyczny, gładkość powierzchni, wykorzystywana przy symulacji tkanin. 4.3 Generacja programu cieniującego Generacja programu cieniującego opiera się o wykorzystanie propagacji wstecznej. Podstawowe założenia: 1. Każdy program posiada oczekiwany typ wierzchołka. Pozostałe parametry wierzchołka o ile są niedostępne, są automatycznie generowane z dostępnych. 2. Każdy program posiada wartość określającą oczekiwany poziom szczegółowości. Wyróżniamy 3 poziomy szczegółowości: niska, średnia i wysoka. 3. Każdy Shader posiada blok wyjściowy. Jeden Shader musi posiadać dokładnie jeden blok wyjściowy. 4. Każde wyjście każdego bloku jest wyliczane tylko raz. Generator przechowuje listę wyliczonych zmiennych w ramach danego kontekstu kompilacji. 5. Generacja kodu programu cieniującego jest wykonywana od tyłu. Przechodząc z bloku wyjściowego przez wejścia do bloków funkcyjnych, ale tylko tych faktycznie wymaganych. 6. Każdy wygenerowany kod programu cieniującego ma przypisany kontekst kompilacji. Strukturę opisującą położenie zmiennych oraz tekstur potrzebnych do ustawienia wartości w potoku renderingu. 7. Generator kodu programu cieniującego automatycznie przygotowuje kod programu cieniującego wierzchołki i cieniującego piksele. 8. Generator automatycznie przekazuje wymagane parametry z programów cieniujących wierzchołki do programów cieniujących piksele. 63

64 4.3.1 Zasada działania Proces generacji kodu programu cieniującego zaprezentowany został na rys Idea generacji polega na wykorzystaniu bloku wyjściowego do wyciągnięcia z diagramu przepływu interesujących informacji, a następnie takim ich przetworzeniu, aby powstał wypadkowy kolor programu cieniującego piksele. Kod programu cieniującego wierzchołki jest tworzony równolegle i jest kompatybilny z programem cieniującym piksele. Kolejność generacji kodu programu cieniującego zapewniona jest poprzez wykorzystanie kontekstu generacji. W strukturze tej przechowywane są m.in. informacje o odwiedzonych wyjściach bloków. Utworzenie kontekstu generacji Znalezienie wyjściowego bloku Pobranie wartości z wyjściowego bloku Kompilacja kodu programu cieniującego Finalizacja kodu programu cieniującego Wyznaczenie wypadkowego koloru Rysunek 4.8: Proces generacji kodu programów cieniujących W pierwszej kolejności przygotowywany jest kontekst generacji, który jest inicjowany parametrami kompilacji (np. oczekiwany poziom szczegółowości). W kolejnej fazie wyszukiwany jest blok wyjściowy. Następnie zależnie od typu generowanego kodu pobierane są wartości ze znalezionego wyjściowego bloku. Pozwala to na wyliczenie na podstawie pobranych wartości wypadkowego koloru zwracanego przez Pixel Shader. Ostatnim krokiem jest kompilacja wygenerowanego kodu przy użyciu wbudowanego w DirectX SDK kompilator HLSL. Skompilowany program może zostać następnie wgrany do pamięci karty graficznej i użyty do wizualizacji konkretnego efektu Kontekst Każdy generowany program posługuje się kontekstem generacji. Służy on do przechowywania informacji o następujących właściwościach procesu: o poziomie szczegółowości - Jest to informacja o oczekiwanym poziomie szczegółowości. Wartość ta wpływa na wykorzystane algorytmy. Skutkuje to różną długością i poziomem skomplikowania wygenerowanego kodu programu cieniującego. o pobranych wartościach stałych - Każdy program cieniujący ma do dyspozycji wartości stałe, są to wartości ustawione dla danej wizualizacji (np. macierz transformacji widoku, kolor obiektu, czas od początku wyświetlania danej sceny). 64

65 Kontekst przechowuje informacje o tym, które wartości zostały już wygenerowane oraz pod jaką zmienną zostały zapisane. o połączeniach między shaderami - Często wymagana jest funkcjonalność przekazania wartości z Vertex Shadera do Pixel Shader, np. przekazanie koordynatów tekstur. Kontekst przechowuje informacje o wykorzystaniu połączeń między shaderami. Wymagane jest to, gdyż jest ograniczona ilość możliwych do przekazania wartości, a każde kolejna wartość musi zostać przypisana do kolejnego wolnego slotu. o wykorzystaniu zmiennych - Każdy program cieniujący może mieć dowolną ilość zmiennych lokalnych. Kontekst przechowuje informacje o utworzonych zmiennych, ich pochodzeniu oraz wartości. o przetworzonych wyjściach - Kontekst przechowuje informację o przetworzonych wyjściach bloków. Pozwala to na zoptymalizowanie kodu programu, gdyż każde wyjście przetwarzane jest dokładnie raz. o formacie wierzchołków - Kod programów cieniujących przygotowywany jest dla konkretnego formatu wierzchołka. Kontekst przechowuje informacje o dostępnych parametrach wierzchołka, co pozwala na automatyczne wyliczanie brakujących wartości z już istniejących. Material Shader Compiler Vertex Shader Compiler Deferred Shader Compiler Rysunek 4.9: Dostępne konteksty generacji Projekt uwzględnia 3 różne konteksty generacji. Pokrótce opiszę każdy z nich: Material Shader Compiler - Materiałowy generator kodu. Jest to bazowy kontekst generacji. Udostępnia jednolity interfejs do generacji kodu programów cieniujących. Vertex Shader Compiler - Wierzchołkowy generator kodu. Jest to rozszerzenie bazowego kontekstu generacji o obsługę formatu wierzchołków. Wartości stałe są wyliczane na podstawie parametrów wierzchołka oraz parametrów wizualizacji. 65

66 Generator ten wykorzystywany jest w fazie geometrii potoku renderingu. Deferred Shader Compiler - Odroczony generator kodu. Jest to rozszerzenie wierzchołkowego generatora kodu o obsługę pobierania informacji z buforów pośrednich. Generator ten wykorzystywany jest w fazie oświetlenia dla metody odroczonego cieniowania. MaterialShaderCompiler -vertexshadercode : QString -pixelshadercode : QString +quality : Quality +variables : QStringList +getp(wartość value : VertexShaderValue) : QString +getv(wartość value : PixelShaderValue) : QString +hasvariable(wartość variable : QString) : bool +addvariable(wartość variable : QString) : bool +ps(wartość value : QString) +vs(wartość text : QString) +linkastexcoord() : bool +code() : QString Rysunek 4.10: Diagram UML klasy MaterialShaderCompiler Implementacja kontekstu udostępnia metody, które pozwalają na wykonanie wszystkich opisanych wcześniej operacji: getv(value) - Pobranie nazwy zmiennej dla wartości stałej w kontekście Vertex Shadera. Metoda automatycznie generuje kod potrzebny do pobrania wartości stałej. getp(value) - Pobranie nazwy zmiennej dla wartości stałej w kontekście Pixel Shadera. Metoda automatycznie generuje kod potrzebny do pobrania wartości stałej. hasvariable(nazwa) - Sprawdzenie, czy zmienna o podanej nazwie istnieje w kontekście Pixel Shadera. addvariable(nazwa) - Sprawdzenie, czy zmienna o podanej nazwie istnieje w kontekście Pixel Shadera. Jeśli nie istnieje funkcja zwróci wartość true i doda do wewnętrznej struktury opisującej listę zmiennych. vs(text) - Wydrukowanie tekstu w kontekście funkcji dla kodu Vertex Shadera. ps(text) - Wydrukowanie tekstu w kontekście funkcji dla kodu Pixel Shadera. linkastexcoord(nazwa, długość) - Przekazanie wektora o zadanej długości i określonej nazwie z programu Vertex Shadera do programu Pixel Shadera. code() - Pobranie wynikowego kodu programu cieniującego Przetwarzanie bloków Jak już zostało wcześniej wspomniane każdy blok składa się z wejść i wyjść. Do wejścia może być podłączone dokładnie jedno wyjście, natomiast wyjście może 66

67 być podłączone do dowolnej ilości wejść innych bloków. Generacja kodu opiera się na przechodzeniu w głąb diagramu: od wejścia do wyjścia. +index : int ShaderBlock +inputvarname(wartość compiler, wartość index : int) : QString +outputvarname(wartość compiler, wartość index : int) : QString +compilevarname(wartość compiler, wartość index : int, wartość varname : QString) +buildtempvarname(wartość compiler, wartość name : QString) : QString Rysunek 4.11: Rozszerzenie klasy ShaderBlock o metody generacji kodu programu cieniującego Obsługa wchodzenia w głąb diagramu przepływu wymusiła rozszerzenie funkcjonalności klasy ShaderBlock o kilka dodatkowych metod używanych tylko w kontekście generacji: inputvarname(i) - Pobranie nazwy zmiennej dla i-tego wejścia aktualnie przetwarzanego bloku. outputvarname(i) - Pobranie nazwy zmiennej dla i-tego wyjścia aktualnie przetwarzanego bloku. compilevarname(i, nazwazmiennej) - Metoda abstrakcyjna. Jest odpowiedzialna za generację kodu do obsługi danego wyjścia. outputvarname Zbuduj nazwę zmiennej wyjściowej Czy zmienna jest dodana do kontekstu? Nie Dodaj zmienną i wykonaj metodę compilevarname Tak Zwróć nazwę zmiennej Rysunek 4.12: Algorytm działania metody outputvarname 67

68 inputvarname Czy do wejścia przypisany jest inny blok? Nie Zwróć wartość domyślną dla oczekiwanego typu wejścia Tak Uruchom metodę outputvarname dla bloku, który przypisany jest do wejścia Czy typy danych na wyjście innego bloku jest zgodny z tym blokiem? Tak Zwróć wartość zwróconą przez outputvarname Nie Przekonwertuj typ na zgodny Zwróć przekonwertowaną wartość zwróconą przez outputvarname Rysunek 4.13: Algorytm działania metody inputvarname void ShaderBlockTexturingSampler::compileVarName( MaterialShaderCompiler& compiler, unsigned index, const QString& varname) const { switch(index) { case ocolor: compiler.ps("float4 %1 = tex2d(%2, %3);", varname, inputvarname(compiler, isampler), inputhaslink(icoords)? inputvarname(compiler, icoords) : compiler.getp(materialshadercompiler::ptexcoords)); break; } case oalpha: compiler.ps("float %1 = %2.a;", varname, outputvarname(compiler, ocolor)); break; } Program 4.1: Przykładowa implementacja metody compilevarname 68

69 4.3.4 Unikatowość zmiennych Metoda compilevarname jako jeden z parametrów przyjmuje nazwę zmiennej, do której ma być zapisany wynik jej działania. Od unikatowości tej zmiennej zależy poprawność wygenerowanego kodu programu cieniującego. W systemie został zaimplementowany mechanizm generacji unikatowych nazw zmiennych dla różnych kontekstów kompilacji. Konstrukcję nazw zmiennych najlepiej przedstawia poniższa formuła: {typ}_{prefiks}{indeks}_{nazwa}_{wyjście} Gdzie: typ - Jest to nazwa typu zmiennej. Typ zależny jest od kontekstu w jakim wykorzystywana jest zmienna. Wyróżniamy następujące typy zmiennej: brak - Typ zarezerwowany dla oznaczenia zmiennej, będącej wartością na wyjściu bloku. const - Jest to typ, określający zmienną, przechowującą wartość bloku parametrycznego, czyli bloku, który może definiować wartości parametryzujące kod programu cieniującego. tmp - Jest to typ określający zmienną tymczasową. prefiks - Jest to nazwa określająca kontekst w jakim jest aktualnie kompilowany program. Nazwa ta jest zależna od klasy definiującej diagram przepływu. Wyróżniamy następujące prefiksy: ms - Prefiks używany do oznaczenia klasy MaterialShader. ls - Prefiks używany do oznaczenia klasy LightShader. ts - Prefiks używany do oznaczenia klasy TerrainShader. gs - Prefiks używany do oznaczenia klasy GeneralShader. indeks - Jest to indeks bloku w wewnętrznej strukturze klasy Shader. Indeks ten wprowadza unikatowość nazwy dla danego Shadera. nazwa - Jest to opcjonalny parametr dołączany, gdy do bloku przypisana jest nazwa. Nazwa budowana jest ze wszystkich znaków spełniających następujące wyrażenie regularne: [A-Za-z0-9]. wyjście - Jest to nazwa wyjścia bloku. Przeanalizujmy następujące nazwy zmiennych: ms1 diffusetexture Sampler - Nazwa określa zmienną przechowującą wartość na wyjściu Sampler dla bloku o indeksie 1, który ma przypisaną nazwę diffusetexture const ls5 lightposition - Nazwa określa zmienną parametryczną przechowującą wartość przypisaną do bloku parametrycznego o indeksie 5, który ma przypisaną nazwę lightposition 69

70 tmp ts2 shadowing lightdir - Nazwa tymczasowej zmiennej używanej w kontekście kompilacji bloku o numerze 2 z przypisaną nazwą shadowing. Zmienna wewnątrz generatora bloku ma nazwę: lightdir Wyznaczanie wypadkowego koloru Wynikiem wygenerowanego kodu programu cieniującego musi być wypadkowy kolor zwracany przez program cieniujący piksele. Odpowiedzialny za to jest mechanizm specjalizacji generatora w kontekście potoku renderingu. Inaczej będzie generowany wypadkowy kolor dla potoku renderingu opartego o cieniowanie wprost a inaczej dla potoku renderingu opartego o odłożone cieniowanie. Zadaniem programisty jest takie przygotowanie generatora, aby ten na wyjściu przypisał wartość specjalnej zmiennej programu cieniującego piksele: outcolor. Najlepiej przedstawia to przykładowy generator kodu programu cieniującego. Jest to implementacja metody, która jako pierwszy parametr przyjmuje kontekst generacji kodu cieniującego, a jako drugi blok wyjściowy shadera materiałowego. Idea polega na wyszukaniu wejścia o nazwie: Diffuse i pobranie wartości przypisanej do tego wejścia. Jeśli do wejścia dołączone jest wyjście zostanie zwrócona wywołania funkcji outputvarname dla tego bloku. Jeśli nie, zostanie zwrócona wartość domyślna dla danego oczekiwanego typu wejścia. void compilesolidcolor( MaterialShaderCompiler &compiler, const QSharedPointer<ShaderBlock>& output) { if(shaderblock::inputlink colorlink = output->input("diffuse")) { compiler.ps("outcolor.rgb = %1;", colorlink.varname(compiler)); if(shaderblock::inputlink alphalink = output->input("opacity")) compiler.ps("outcolor.a = %1;", alphalink.varname(compiler)); else compiler.ps("outcolor.a = 1.0f;"); } else { compiler.ps("outcolor = %1;", compiler.getp(materialshadercompiler::pcolor)); } }. Program 4.2: Przykładowy generator kodu programu cieniującego, który do outcolor zapisuje wartość Diffuse z shaderu materiałowego 70

71 4.3.6 Kod programu cieniującego Rezultatem generacji jest kod programu cieniującego. Kod ten ma jednolitą strukturę, która podzielona jest na kod programu cieniującego wierzchołki i cieniującego piksele. Szablon, który jest używany do wypełnienia wartościami został przedstawiony poniżej. Opis jego poszczególnych pól wygląda następująco: 1. definiowane są parametry wierzchołka przekazywane do Vertex Shadera. 2. definiowane są zmienne, służące do przekazania wartości między Vertex Shaderem a Pixel Shaderem. 3. definiowane są wartości stałe programu cieniującego. 4. definiowane są wartości bloków parametrycznych. 5. umieszczany jest kod programu cieniującego wierzchołki. 6. umieszczany jest kod programu cieniującego piksele. #ifdef VERTEXSHADER float4 VertexShader( // input variables (1) // output variables (2) // global variables (3) // user-defined variables (4) ) : POSITION0 { (5) return voutscreen; } #endif #ifdef PIXELSHADER float4 PixelShader( // input variables (2) // global variables (3) // user-defined variables (4) ) : COLOR0 { float4 outcolor = 0; (6) return outcolor; } #endif Program 4.3: Struktura kodu programu cieniującego 71

72 4.3.7 Wartości stałe Przy generacji programów cieniujących dostępna jest grupa wartości stałych. Wartości stałe są to wartości ustawione dla danej wizualizacji. Przykładami takich wartości są: pozycja kamery i macierze transformacji z przestrzeni świata do przestrzeni ekranu. Dostępne są następujące wartości stałe: Nazwa Cel Typ Opis Time wierzchołek piksel float Czas od początku wyświetlania danej sceny DeltaTime wierzchołek float Różnica czasu od ostatniej ramki piksel PixelSize wierzchołek float2 Wielkość piksela danego widoku piksel ProjViewMatrix wierzchołek matrix Złożona macierz projekcji i widoku ObjectMatrix wierzchołek matrix Macierz transformacji obiektu CameraOrigin wierzchołek float3 Położenie kamery w przestrzeni świata CameraDistance wierzchołek float Zasięg kamery w przestrzeni świata CameraAt wierzchołek float3 Wektor patrzenia kamery w przestrzeni świata CameraUp wierzchołek float3 Wektor skierowany do góry, prostopadły do patrzenia kamery w przestrzeni świata CameraRight wierzchołek float3 Wektor skierowany w prawo, prostopadły do patrzenia kamery w przestrzeni świata ObjectColor wierzchołek color Zwraca globalny kolor obiektu Do wartości stałych należy dołączyć jeszcze parametry wierzchołka. Każdy Shader definiuje oczekiwany typ wierzchołka. Typ wierzchołka jest to struktura zawierająca informację o miejscu przechowywania określonych jego parametrów, np.: koordynaty tekstur, wektor normalny. Jeśli dany parametr jest potrzebny do realizacji jakiejś funkcji (np. cieniowania) jest on automatycznie wyliczany z pozostałych wartości stałych dostępnych w programie. Dostępne są następujące parametry wierzchołka: Nazwa Typ Opis Wartość automatyczna Origin float3 Pozycja wierzchołka Color color Kolor wierzchołka Kolor czarny Normal float3 Wektor normalny Wektor skierowany ku kamerze 72

73 Nazwa Typ Opis Wartość automatyczna Tangent Binormal float3 Wektory styczne Wektory styczny do wektora normalnego TexCoords float2 Koordynaty tekstury Wartość pozycji wierzchołka MapCoords float2 Koordynaty dodatkowej Wektor zerowy tekstury 4.4 Obsługiwane bloki funkcyjne Graficzny edytor cieniowania posiada grupę bloków, ułatwiających realizację bardziej zaawansowanych funkcji. Poniższa sekcja przedstawia oraz szczegółowo opisuje obsługiwane funkcje Funkcje matematyczne Jest to grupa bloków, implementujących określone funkcje matematyczne. Każdy z bloków posiada wejście, wyjście oraz opcjonalne parametry konfiguracyjne. Lista zaimplementowanych funkcji wygląda następująco: Funkcja Wejścia Wyjścia Parametry Opis Abs In (float4) Out (float4) Zwraca wartość bezwzględną Clamp In (float4) Out (float4) Min (float) Max (float) Przycina wartości do określonego zakresu Combine A (float4) Out (float4) Op 1 Wylicza wartość B (float4) funkcji złączenia A i B Component In (float4) Out (float4) R (bool) Przekazuje określone Mask G (bool) strumienie wartości B (bool) z wejścia, a zeruje A (bool) pozostałe. Floor In (float4) Out (float4) Przekazuje wartość podłogi na wyjście Frac In (float4) Out (float4) Przekazuje wartość ułamkową na wyjście 1 Jest to jedna z następujących operacji: wybierz wejście A lub B, A+B, A B, A B, A/B, max(a, B), min(a, B), dot(a, B), dot(a.xyz, B.xyz), wartość średnia 73

74 Funkcja Wejścia Wyjścia Parametry Opis FromSpheric Phi (float) Out (float3) Zamienia współrzędne Theta (float) sferyczne na wektor Radius (float) wodzący Interpolate A (float4) Out (float4) Interpoluje wektor 2 B (float4) Time (float) Join R (float) G (float) B (float) Out (float4) Łączy wartości R, G, B i A w jeden wektor wyjściowy A (float) Normalize In (float4) Out (float4) Normalizuje długość wektora Saturate In (float4) Out (float4) Przycina wartości z zakresu 0,1 ScaleBias In (float4) Out (float4) Scale (float) Skaluje i przesuwa Bias (float) wartości 3 Sign In (float4) Out (float4) Pobiera znak dla każdego elementu wektora Split In (float4) R (float) Dzieli wartości G (float) wektora na R, G, B (float) B i A A (float) ToSpheric In (float3) Phi (float) Zamienia wektor Theta (float) wodzący na Radius (float) współrzędne sferyczne Transform In (float3) Normal Mnoży wektor przez Matrix (float3) macierz Matrix (matrix) Projected i wylicza wartości: (float3) Normal, Projected Transformed oraz Transformed (float4) 2 Out = A T ime + B (1 T ime) 3 Out = In Scale Bias 74

75 4.4.2 Parametryczne Jest to grupa bloków pozwalających na dodanie do programu cieniującego zmiennych. Ich zastosowanie wymagane jest np. do przekazania do programu cieniującego tekstur, pozycji oświetlenia, itp. Lista dostępnych typów zmiennych wygląda następująco: Zmienna Wyjścia Opis Kolor Color (color) Dodaje zmienną definiującą kolor. Na Alpha (float) wyjściu zwracany jest kolor lub wartość kanału alpha przekazanego koloru. Float Out (float) Dodaje zmienną definiującą wartość zmiennoprzecinkową. LightPosition LightPosition (float3) Dodaje zmienną pozwalającą zdefiniować LightRadius (float) pozycję światła jako wartość wektora LightDir (float3) LightDist (float) (X,Y,Z,1/odległość). Zwraca LightPosition 4, LightRadius 5, LightDir 6 oraz LightDist 7. Matrix Matrix (matrix) Dodaje zmienną definiującą macierz 4x4. RenderTarget Out (sampler) Dodaje zmienną definiującą cel renderowania. Do celu renderowania może być przypisana np. mapa cieni. Texture Out (sampler) Dodaje zmienną definiującą teksturę. Vector Out (float3) Dodaje zmienną definiującą wektor trójargumentowy Stałe Jest to grupa bloków, pozwalających na pobranie aktualnych parametrów przetwarzanej klatki. Lista zaimplementowanych stałych wygląda następująco: Zmienna Wyjścia Opis Kolor Color (color) Stała określająca kolor rysowanego obiektu. Czas Time (float) Stała zwracająca informację o czasie od początku rysowania danej sceny. 4 Pozycję światła 5 Zasięg światła 6 Wektor padania światła 7 Wsp. tłumienia z odległością 75

76 4.4.4 Efekty Jest to grupa bloków realizujących określone typy efektów. Każdy z bloków posiada wejście, wyjście oraz parametry przetwarzania. Lista zaimplementowanych efektów wygląda następująco: Funkcja Wejścia Wyjścia Parametry Opis Layers Base (float4) Out (float4) Efekt służy do A (float4) B (float4) C (float4) D (float4) Mask (float4) łączenia wielu warstw (np. tekstur) w jedną warstwę na podstawie maski łączenia. Efekt wykorzystywany jest np. przy wyświetlaniu tekstury terenu. Lighting LightDir (float3) Diffuse (float) Efekt służy wyliczeniu LightDist (float) Specular (float) koloru rozproszenia Normal 8 (float3) oraz odbicia Specularity 9 dla podanych (float3) parametrów światła. Efekt wykorzystuje model Phonga-Blinna. Parallax Height (float) Coords (float2) Scale (float) Efekt pozwalający Coords (float2) na wyznaczenie przesunięcia koordynatów tekstury według algorytmu parallax mapping. Parametr Scale określa intensywność efektu. Pulse In (float) Out (float) Interval Efekt pozwala na Time (float) (float) Amplitude (float) symulację pulsowania. Wykorzystywany jest np. przy oświetleniu Phase (float) w celu symulacji światła pulsującego. 8 Wektor normalny w przestrzeni świata 9 Intensywność odbić 76

77 Funkcja Wejścia Wyjścia Parametry Opis Quality Low (float4) Out (float4) Efekt pozwala Medium (float4) na symulację High (float4) różnych poziomów szczegółowości. W zależności od parametrów kompilacji wybierane jest jedno z wejść: Low, Medium lub High. Variance LightDir (float3) Shadows (float) Samples 10 Efekt pozwala na Shadowing LightDist (float) (int) symulację cieniowania Shadows Delta 11 według metody (sampler) (float) variance shadow Shadowed 12 (float) mapping. 4.5 Obsługa potoków renderingu Zastosowanie automatycznego mechanizmu generacji programów cieniujących z diagramu przepływu, pozwala na implementację dowolnych potoków renderingu przy wykorzystaniu za każdym razem tego samego diagramu przepływu, ale pobierając z diagramu przepływu inne parametry. W tym podrozdziale opisane zostaną 3 przykładowe potoki renderingu w kontekście generacji kodu programów cieniujących. Dwa pierwsze pozwalają na pełną wizualizację sceny z dowolnym modelem oświetlenia. Natomiast trzeci opisuje wykorzystanie diagramu przepływu do automatycznej generacji map cieni na potrzeby wizualizacji dowolnego typu oświetlenia. Ten podrozdział skupi się na mechanizmach wykorzystanych do generacji kodu programów cieniujących dla konkretnego potoku renderingu. Natomiast, nie będzie przedstawiał jego szczegółów implementacji Przypadek testowy Rozważmy następujący przypadek testowy. Wyróżniamy dwa shadery: 10 Ilość wykorzystanych próbek przy wyliczaniu cienia 11 Parametr konfiguracyjny algorytmu 12 Wartość zwracanej funkcji w cieniu 77

78 shader materiałowy - Shader widoczny jest na rys Definiuje on materiał z jedną teksturą. Kolor tekstury jest przekazywany do Ambient i Diffuse. Rysunek 4.14: Przykładowy shader materiałowy shader oświetlenia - Shader widoczny jest na rys Definiuje on model oświetlenia Phonga z kolorem rozproszenia materiału (Diffuse) i kolorem oświetlenia (lightcolor). Wypadkowy kolor zapisywany jest do Final::Color. Rysunek 4.15: Przykładowy shader oświetlenia Cieniowanie wprost Cieniowanie wprost (ang. Forward rendering lub Forward Shading) jest to metoda dosyć często określana jako standardowe podejście do problemu rysowania świateł przy wizualizacji scen trójwymiarowych. Jest to jedna z najbardziej rozpowszechnionych i szeroko wykorzystywanych metod w grach i aplikacjach czasu rzeczywistego. Na potrzeby projektu zaimplementowano rysowanie wieloprzebiegowe świateł. Schemat generacji kodu programów cieniujących z wykorzystaniem techniki cieniowania wprost przedstawia rys Modularna architektura pozwoliła na podział na logiczne komponenty, które realizują wyspecjalizowane funkcje. Te trzy komponenty to: Material Shader - Jest to shader materiałowy zdefiniowany przez diagram przepływu. Jego zadaniem jest dostarczenie parametrów materiału, tj.: koloru 78

79 Material Shader Parametry materiały: * tekstury * kolor Wartości stałe i parametry wierzchołków: * pozycja * koordynaty tekstu Wyznaczenie parametrów materiału Blok wyjściowy: * Kolor rozproszenia * Wektor normalny Blok wejściowy: * Kolor rozproszenia * Wektor normalny Light Shader Parametry oświetlenia: * pozycja * zasięg * kolor Wyliczenie parametrów oświetlenia Kolor wypadkowy Generator cieniowania wprost Wyjście programu cieniującego piksele KONIEC Rysunek 4.16: Schemat generacji kodu dla cieniowania wprost rozproszenia i odbicia, wektora normalnego, itp. Light Shader - Jest to shader oświetlenia, który na podstawie parametrów materiału i parametrów oświetlenia wylicza wypadkowy kolor cieniowanego piksela. Generator - Jest to komponent odpowiedzialny za przygotowanie kontekstu. Jego głównym zadaniem jest połączenie wyjścia shadera materiałowego z wejściem shadera oświetlenia oraz przypisanie na wyjście Pixel Shader wypadkowego koloru oświetlenia. Wynikiem działania mechanizmu jest wypadkowy kolor oświetlenia zwracany w zmiennej outcolor programu cieniującego piksele. Tworzony jest monolityczny kod programu 79

80 cieniującego, który sekwencyjnie wylicza wszystkie potrzebne wartości począwszy od wyznaczenia parametrów oświetlenia: kolor rozproszenia, wpływ cieniowania, zasięg oddziaływania światła, typ oświetlenia skończywszy na efektach dodatkowych, np. pulsacja. Wygenerowany kod można zobaczyć w dodatku D.1 dołączonym do pracy magisterskiej Odłożone cieniowanie Odłożone cieniowanie (ang. Deferred Shading lub Deferred Rendering) w odróżnieniu od cieniowania wprost polega na wykorzystaniu buforów pośrednich, do których renderowana jest geometria. W drugiej fazie nazwanej fazą oświetlenia następuje wyliczenie wpływu oświetlenia na kolor materiału. Dzieje się to już bez konieczności ponownego rysowania geometrii tylko poprzez wykorzystanie, buforów pośrednich w których zapisane są wszystkie informacje o budowie sceny oraz właściwościach materiałów. Na potrzeby projektu zaimplementowano podstawową wersję metody, która wykorzystuje 3 bufory pośrednie do zapisu budowy sceny oraz parametrów materiałów. Modularna architektura pozwoliła na automatyczne przygotowanie programów cieniujących. Shadery są przygotowywane oddzielenie dla każdej fazy na podstawie shadera materiałowego i shadera oświetlenia. Proces generacji kodu programów cieniujących wygląda następująco: dla fazy geometrii - W fazie geometrii wykorzystywany jest shader materiałowy oraz generator fazy geometrii. Shader materiałowy odpowiada za przekazanie do generatora informacji o parametrach materiału. Generator następnie przekształca reprezentację danych na format, który pozwala na zapisanie ich do buforów geometrii. Stosując przy tym operacje matematyczne, które pozwalają zmniejszyć ilość danych potrzebnych do zapisu. W obecnej implementacji wykorzystywane są trzy bufory. W pierwszym zapisywany jest kolor rozproszenia. Drugi bufor przechowuje skompresowany wektor normalny a trzeci odległość od obserwatora, która pozwala na późniejsze wyznaczenie pozycji piksela w przestrzeni 3D. dla fazy oświetlenia - W fazie oświetlenia następuje odwrócenie procesu. Z buforów pośrednich są pobierane informacje o podstawowych parametrach materiału, które są następnie przekazywane do shadera oświetlenia. Wynikiem działania jest wypadkowy kolor zwracany w zmiennej outcolor programu cieniującego piksele. Wynikowy kod można zobaczyć w dodatkach D.2.1 i D.2.2 dołączonych do pracy magisterskiej. 80

81 Material Shader Parametry materiały: * tekstury * kolor Wartości stałe i parametry wierzchołków: * pozycja * koordynaty tekstu Wyznaczenie parametrów materiału Blok wyjściowy: * Kolor rozproszenia * Wektor normalny Generator fazy geometrii Bufor 1 * kolor rozproszenia Bufor 2 * wektor normalny Zamień pozycję na odległość od obserwatora Bufor 3 * odległość Koniec Rysunek 4.17: Schemat generacji kodu dla fazy geometrii odłożonego cieniowania Parametry fazy geometrii Bufor 1 * kolor rozproszenia Bufor 2 * wektor normalny Bufor 3 * odległość Zamień odległości na pozycję piksela Blok wejściowy: * Kolor rozproszenia * Wektor normalny Light Shader Parametry oświetlenia: * pozycja * zasięg * kolor Wyliczenie parametrów oświetlenia Kolor wypadkowy Generator fazy oświetlenia Wyjście programu cieniującego piksele KONIEC Rysunek 4.18: Schemat generacji kodu dla fazy oświetlenia odłożonego cieniowania 81

82 4.5.4 Mapy cieni Generowanie mapy cieni musi się odbywać niezależnie od wykorzystanej metody nakładania świateł. Postanowiono uzupełnić informację o potokach renderingu o wykorzystanie automatycznego generowania programów cieniujących do tworzenia kodu programów wyznaczających mapę cieni. Na potrzeby projektu zaimplementowano wersję metody, wykorzystującą dwa parametry zapisane w mapie cieni. Zasada działania polega na wykorzystaniu parametrów shadera materiałowego do wyznaczenia odległości od obserwatora i przekazania jako wynikowy kolor. W przypadku, gdy diagram przepływu nie ma wpływu na odległość od obserwatora zostanie wygenerowany najprostszy możliwy kod, który potrafi zamienić pozycję wierzchołka na odległość. Przykładowy wygenerowany kod można zobaczyć w dodatku D.3 dołączonym do pracy magisterskiej. Material Shader Parametry materiały: * tekstury * kolor Wartości stałe i parametry wierzchołków: * pozycja * koordynaty tekstu Wyznaczenie parametrów materiału Blok wyjściowy: * Kolor rozproszenia * Wektor normalny Generator mapy cieni Zamiana pozycji na odległość od obserwatora Wyjście programu cieniującego piksele KONIEC Rysunek 4.19: Schemat generacji kodu dla mapy cieni 82

83 Rozdział 5 Demo technologiczne ayuine2c Aplikacja ayuine2c jest demem technologicznym implementującym funkcjonalność Graficznego edytora cieniowania. Demo technologiczne pozwala na pełną symulację wirtualnego świata. Posiada mechanizmy wizualizacji dużych scen trójwymiarowych a w szczególności: 1. Możliwość dodawania, modyfikacji i usuwania obiektów geometrycznych z wirtualnego świata. 2. Możliwość dodawania, modyfikacji i usuwania źródeł oświetlenia. 3. Możliwość określania hierarchii sceny. 4. Możliwość wizualizacji terenu. 5. Możliwość modyfikacji parametrów fizycznych obiektów. 6. Możliwość edycji obiektów geometrycznych. 7. Możliwość edycji tekstur. 8. Możliwość edycji programów cieniujących. 9. Możliwość uruchomienia dem w trybie benchmarku wydajnościowego. 10. Możliwość importu geometrii, scen i wirtualnych światów z innych formatów geometrycznych. 5.1 Technologia Projekt ayuine2c został napisany z wykorzystaniem języka C++ na podstawie biblioteki Qt 4.8. Qt jest to zestaw przenośnych bibliotek i narzędzi programistycznych dedykowanych dla języków C++. Pozwoliło to na zunifikowanie kodu źródłowego aplikacji i zaimplementowanie spójnego interfejsu graficznego. Kod był pisany w środowisku programistycznym QtCreator. Wykorzystane zostały następujące technologie i biblioteki: QtCore - biblioteka standardowa środowiska Qt QtGui - biblioteka okienkowa środowiska Qt QPropertyGrid - biblioteka implementująca edytor właściwości na potrzeby środowiska Qt 83

84 QtCreator - środowisko programistyczne MS DirectX SDK - biblioteka do obsługi środowiska DirectX - wykorzystane zostały komponenty do obsługi klawiatury, myszki oraz do obsługi renderingu grafiki NVidia PhysX SDK - biblioteka do obsługi fizyki OpenAL - biblioteka do obsługi dźwięku niflib - biblioteka do importu plików.nif boost - biblioteka rozszerzeń do języka C++ Projekt powstawał około 9 m-cy z przerwami. W chwili obecnej liczy około 50 tyś. linii własnego kodu. 5.2 Budowa Projekt został zbudowany modułowo. Każdy z modułów realizuje określoną funkcję. Wszystkie moduły zostały zaprojektowane na potrzeby aplikacji będącej przedmiotem pracy magisterskiej. Zależności między modułami przedstawione są na rys Pokrótce przedstawię zastosowanie i jego znaczenie każdego modułu w projekcie. Kolorem pomarańczowym został oznaczony moduł implementujący Graficzny edytor cieniowania, będący przedmiotem niniejszej pracy magisterskiej. Kolorem szarym zostały oznaczone moduły implementujące graficzne edytory WYSWIG. Kolor zielonym został oznaczony moduł pozwalający na uruchomienie projektu. Core Moduł bazowy projektu odpowiedzialny za implementację funkcjonalności serializacji oraz deserializacji obiektów, rozbudowy systemu Qt RTTI o możliwość automatycznego tworzenia obiektów. Moduł dodatkowo implementuje system zasobów wraz z automatyczną obsługą różnych typów danych. Wprowadza podział na typy natywne, czyli typy posiadające reprezentację tożsamą ze strukturą projektu oraz typy importowane, w których następuje konwersja na typ reprezentujący strukturę projektu. Math Moduł matematyczny projektu odpowiedzialny za implementację matematycznych operacji na przestrzeni trójwymiarowej. Moduł obsługuje następujące struktury i działania: wektory - obsługa wektorów dwu-, trzy- i czterowymiarowych. Zaimplementowane są m.in. operacje rotacji, wyliczania iloczynów skalarnych, wektorowych, transformacji. 84

85 Core Math Render Physics MaterialSystem MaterialSystem Editor Pipeline MeshSystem MeshSystem Editor SceneGraph SceneGraph Editor GameSystem Launcher Editor Rysunek 5.1: Architektura dema technologicznego ayuine2c 85

86 płaszczyzny - obsługa płaszczyzn w przestrzeni trójwymiarowej. Zaimplementowane są m.in. operacje wyliczania odległości punktu od płaszczyzny, wyliczania punktu przecięcia promienia z płaszczyzną. macierze - obsługa macierzy 4x4. Zaimplementowane są m.in. operacje wyliczania mnożenia i odwracania macierzy, wyliczania macierzy perspektywy, obrotu, translacji. ostrosłup widzenia - obsługa wyznaczania płaszczyzn ostrosłupa widoku na podstawie macierzy widoku. Zaimplementowane są m.in. operacje sprawdzania czy punkt, trójkąt, sześcian, kula znajdują się w ostrosłupie widoku. kamera - obsługa wyliczania macierzy transformacji dla kamery. Zaimplementowany jest widok pierwszej osoby, trzeciej, widok modelu, widok ortogonalny. wektory styczne - obsługa wyliczania wektorów stycznych z parametrów wierzchołka: pozycji i koordynatów tekstur. Physics Moduł odpowiedzialny za implementację fizyki. W chwili obecnej jest on interfejsem obudowującym użycie biblioteki NVidia PhysX SDK 1. W przyszłości moduł ten może korzystać z innych silników fizycznych, np.: bullet 2. Zaimplementowana została obsługa następujących zachowań fizycznych: metody kolizji - obsługa różnych metod kolizji. Zaimplementowana została obsługa kolizji z: sześcianami, kulami, bryłami wypukłymi składającymi się z otoczki punktów, bryłami geometrycznymi składającymi się z listy trójkątów oraz mapą wysokości terenu. modele statyczne - obsługa stałych elementów sceny (statycznych). Zaimplementowana została hierarchia sceny fizycznej, możliwość określenia modeli kolizji, możliwość wpływania na zachowanie się obiektów w czasie rzeczywistym. modele dynamicznie - obsługa przesuwalnych elementów sceny (dynamicznych). Zaimplementowana została możliwość reakcji na punkty kolizji, możliwość nadawania modelowi prędkości liniowej i kątowej w dowolnym miejscu. kontroler gracza - obsługa modelu gracza opisanego cylindrem. Zaimplementowane zostały mechanizmy wykrywania kolizji z modelami statycznymi oraz dynamicznymi, możliwość określenia masek kolizji (np. kolizja tylko z określonymi modelami sceny), obsługa grawitacji oraz skoku

87 Render Moduł odpowiedzialny za implementację interfejsu graficznego na potrzeby wizualizacji. Moduł udostępnia zunifikowany interfejs obsługi API graficznego. W chwili obecnej dostępny jest tylko jeden: DirectX 9.0c, jednakże w przyszłości istnieje możliwość łatwego zmodyfikowania kodu w celu udostępnienia np. OpenGL. Moduł posiada obsługę następujących funkcjonalności API graficznego: bufory wierzchołków - obsługa tworzenia opisu wierzchołków przechowywanych w pamięci graficznej. System zbudowany jest na zunifikowanym formacie wierzchołków, udostępniającym najważniejsze z punktu widzenia projektu formaty wierzchołków, np.: pozycja, wierzchołek z pozycją i koordynatami tekstur, itp. bufory indeksów - obsługa tworzenia opisu indeksów wyświetlania przechowywanych w pamięci graficznej. System pozwala na wykorzystanie 16 i 32 bitowych indeksów. tekstury - obsługa map bitowych przechowywanych w pamięci graficznej. System pozwala na zapis tekstur dwuwymiarowych, trójwymiarowych i sześciennych. Wbudowana jest obsługa różnych formatów plików graficznych, np.:.jpg,.png,.dds. cele wizualizacji - obsługa tekstur będących celami wizualizacji, tzw. Render Targets. System pozwala na tworzenie tekstur o całkowitej i zmiennoprzecinkowej precyzji, np. na potrzeby efektów HDR, obsługuje wizualizacje do tekstur dwuwymiarowych i szcześciennych. programy cieniujące - obsługa kompilacji i wykorzystania programów cieniujących napisanych w języku HLSL. System pozwala na pobranie listy stałych programu oraz przypisanie ich wartości w potoku renderingu. Occlussion Query - obsługa mechanizmów przyspieszania procesu renderingu poprzez sprawdzenie ilości wyświetlanych pikseli. System pozwala na narysowanie obiektu i stwierdzenie czy obiekt wpłynął i jeśli tak to jak mocno na wynikowy obraz. rysowanie - obsługa mechanizmów grupowania obiektów, tzw. instancing. Pozwala to na przyspieszenie poprzez zmniejszenie ilości wywołań procedur DrawPrimitive. czcionki - obsługa wizualizacji tekstur na widoku graficznym. Dodatkowo moduł posiada swój Edytor, który pozwala na przyspieszenie procesu edycji tekstur. MaterialSystem Moduł odpowiedzialny za implementację Generatora programów cieniujących. Moduł ten jest przedmiotem niniejszej pracy magisterskiej i był już wcześniej szczegółowo opisany. Na potrzeby MaterialSystem powstał graficzny edytor WYSWIG, pozwalający na łatwą i szybką modyfikację programów cieniujących. 87

88 Pipeline Moduł odpowiedzialny za implementację potoku renderingu. Dostarcza on implementacje następujących komponentów: Ramka Komponent ten odpowiedzialny jest za definicję zachowania się potoku renderingu. Implementacja polega na rozszerzeniu funkcjonalności klasy abstrakcyjnej Frame. Każda ramka posiada informacje o obiektach oraz źródłach światłach, które muszą być uwzględnione przy renderowaniu. W zależności od implementacji potok renderingu może być rozbity na dowolną ilość faz. Frame Forward Shaded Frame Deferred Shaded Frame Simple Frame Wire Frame Solid Frame Depth Frame Rysunek 5.2: Obsługiwane typy ramek Obsługiwane są następujące ramki, a co za tym idzie metody renderingu: Forward Shaded Frame - implementacja Cieniowania wprost. Metoda została zaimplementowana w najprostszej postaci, tzn. geometria rysowana jest tyle razy ile jest świateł ją oświetlających. Deferred Shaded Frame - implementacja Odłożonego cieniowania. Metoda została zaimplementowana z wykorzystaniem 3 buforów pośrednich z podziałem na dwie fazy: fazę geometrii (do buforów pośrednich zapisywane są parametry geometryczne: pozycja, wektor normalny, kolor rozproszenia) i fazę oświetlania (każde światło jest rysowane niezależnie wykorzystując do wyliczenia parametrów oświetlenia bufory pośrednie) Wire Frame - implementacja rysowania siatki trójkątów bez wypełnienia Solid Frame - implementacja rysowania wypełnionej siatki trójkątów, bez oświetlenia z wykorzystaniem tylko koloru rozproszenia Depth Frame - implementacja generacji map cieni, do tekstury zapisywana jest odległość od obserwatora w tym przypadku źródła światła 88

89 Fragment Obsługa różnych typów geometrii zrealizowana jest poprzez wykorzystanie podejścia podziału ich na fragmenty. Każdy obiekt geometryczny może zostać zamieniony na dowolną skończoną ilość fragmentów. Każdy fragment posiada następujące parametry: format - informacja o wykorzystywanym formacie wierzchołka shader - informacja o wykorzystywanym shaderze materiałowym stan - informacja o ustawieniach shadera jakość - informacja o oczekiwanym poziomie szczegółowości wyświetlanego fragmentu. Im obiekt dalej tym niższy ma poziom szczegółowości. przezroczystość - informacja o wykorzystaniu lub nie przezroczystości. Wpływa to na to, czy obiekt ma być wyświetlany w głównym procesie renderingu, czy ma być przepisywany do kolejki obiektów przezroczystych. W oddzielnej kolejce obiekty są sortowane na podstawie odległości od obserwatora i rysowane od końca. Koszt wyświetlenia obiektów przezroczystych jest znacznie większy, niż obiektów zwykłych. Silnik posiada implementację kilku predefiniowanych typów fragmentów, które mogą być dowolnie rozszerzane w innych komponentach. Fragment Instanced Fragment Sky Fragment Terrain Fragment Grid Fragment Mesh Fragment Textured Fragment Point Fragment Box Fragment Sphere Fragment Sheet Fragment Rysunek 5.3: Obsługiwane typy fragmentów Instanced Fragment - implementacja fragmentu, który symbolizuje obiekt występujący wielokrotnie, ale w różnych miejscach wyświetlanej sceny. Rysowanie tego typu fragmentów jest akcelerowane z wykorzystaniem techniki Instancingu, czyli łączeniem wielu wywołań Draw w jedno. Sky Fragment - implementacja kopuły nieba, wyświetlana jest tylko jej górna część 89

90 Terrain Fragment - implementacja wizualizacji terenu Grid Fragment - implementacja siatki na potrzeby wyświetlania jej w edytorze Textured Fragment - implementacja wyświetlania figur prostych, tj.: punktu, sześcianu, kuli, płaszczyzny Światło Obsługa różnych typów oświetlenia zrealizowana jest poprzez dodawanie do ramki kolejnych dynamicznych źródeł światła. Implementacja kolejnego źródła światła realizowana jest poprzez rozszerzenie funkcjonalności klasy Light. Obecna wersja dostarcza obsługę: oświetlenia tła, świateł punktowych oraz świateł reflektorowych. MeshSystem Moduł odpowiedzialny za implementację oraz obsługę obiektów geometrycznych. Dostarcza on zunifikowany interfejs obsługi obiektów geometrycznych dla całego silnika graficznego. Obsługuje on następujące zbiory danych: Mesh - Definicja obiektu geometrycznego. Obiekt przechowuje m.in. listę wierzchołków, listę trójkątów, parametry fizyczne kolizji. MeshSubset - Definicja podzbioru geometrii. Określa jak ma być rysowany obiekt geometryczny. Przechowuje informacje o materiale, liście trójkątów oraz właściwościach graficznych potrzebnych do optymalizacji procesu renderingu. MeshVertex - Definicja wierzchołka geometrii. W wierzchołku zapisana jest informacja o: pozycji (współrzędne trójwymiarowe), koordynatach tekstur (współrzędne dwuwymiarowe), koordynatach mapowania (współrzędne dwuwymiarowe), wektorze normalnym (współrzędne trójwymiarowe) oraz wektorach stycznych (współrzędna trójwymiarowa ze znakiem). MeshSubsetFragment - Definicja procesu renderingu podzbioru geometrii. Klasa rozszerza funkcjonalność Instanced Fragments. Dodatkowo moduł posiada swój Edytor, który pozwala na edycję parametrów obiektu geometrycznego. SceneGraph Moduł odpowiedzialny za implementację oraz obsługę wizualizacji scen trójwymiarowych [2]. Jego podstawowym zadaniem jest zdefiniowanie grafu sceny, który ma wpływ na mechanizmy przetwarzania sceny. Struktura sceny ma bezpośredni wpływ na szybkość i wypadkową jakość wizualizacji sceny. Graf sceny odpowiedzialny jest za optymalizację struktury w zależności od typu wizualizacji. Wyróżniamy dwa typy 90

91 Rysunek 5.4: Okienko edytora obiektów geometrycznych wizualizacji: indoor - Wizualizacje zamkniętych pomieszczeń. Wydajna wizualizacja wymusza konieczność wykorzystania algorytmów opartych o drzewa BSP lub podobne. outdoor - Wizualizacje otwartych przestrzeni. Wydajna wizualizacja wymusza konieczność wykorzystania algorytmów opartych o drzewa ósemkowe (lub podobne). Rysunek 5.5: Typy wizualizacji: po lewej indoor, po prawej outdoor W module tym, wyróżniamy dwa podstawowe obiekty: Actor oraz Scene. Actor jest klasą reprezentującą pojedynczy byt na Scenie. Hierarchia obiektów została przedstawiona na rys Actor Manager - Reprezentuje aktora, który może zarządzać innymi aktorami. Klasa ta pozwala na dodanie nowego poziomu hierarchii. W zależności od implementacji późniejsze przetwarzanie może odbywać się z wykorzystaniem drzewa BSP lub drzewa ósemkowego. Portal i Sector Actor - Grupa aktorów definiujących podział sceny na portale i sektory. Obiekty te są potrzebne do przyspieszenia generacji drzewa BSP. Light Actor - Grupa aktorów, które implementują źródła oświetlenia na scenie (lights) Mesh Actor - Grupa aktorów, które implementują obiekty geometryczne (fragments). 91

92 Scene N Actor 1x Actor Manager Portal Actor Sector Actor Light Actor Mesh Actor Naive Actor Manager BSP Actor Manager Point Light Actor Spot Light Actor Static Mesh Actor GameSystem Rysunek 5.6: Okienko edytora obiektów geometrycznych Moduł odpowiedzialny za implementację interaktywnej symulacji sceny trójwymiarowej. Pozwala uruchomić scenę w trybie gry. Tryb gry odpowiada m.in. za symulację: zachowań fizycznych, interakcji między obiektami, obsługa wejścia (myszka i klawiatura), obsługa kamery obsługa dema wydajnościowego (generowanie statystyk w czasie rzeczywistym) Launcher Moduł główny pozwalający na uruchomienie dowolnego trybu w zależności od ustawień plików konfiguracyjnych. Wyróżniamy następujące tryby pracy środowiska: gry - Uruchamia środowisko w trybie interaktywnej symulacji sceny trójwymiarowej. dema wydajnościowego - Uruchamia środowisko w trybie wydajnościowym. Dokładniejszy opis tego trybu jest w dodatku dołączonym do niniejszej pracy magisterskiej. edycji - Uruchamia środowisko w trybie designerskim, który pozwala na pełną modyfikację scen, obiektów geometrycznych oraz materiałów. 92

93 Rozdział 6 Testy poprawności i jakości wykonania Testowanie jest bardzo ważnym etapem w procesie tworzenia oprogramowania. Dowodzenie poprawności działania programów w sposób formalny byłoby idealnym rozwiązaniem. Nie da się jednak tego zastosować w większości typowych przypadków przy tworzeniu dużych aplikacji. Testowanie umożliwia wykrycie błędów we wczesnych stadiach rozwoju oprogramowania, co pozwala zmniejszyć koszty usuwania tego błędu. Z tego i wielu innych powodów powstało wiele metod i narzędzi ułatwiających testowanie. Testy możemy podzielić na następujące grupy: poprawnościowe - Są to testy sprawdzające zgodność implementacji ze specyfikacją. wydajnościowe - Są to testy starające się wykryć potencjalne wolne miejsca. Przeprowadza się je w celu oceny stopnia spełnienia wymagań wydajnościowych przez system lub moduł. obciążenia / przeciążenia - Są to testy starające się określić zachowanie aplikacji w sytuacjach skrajnych. Przeprowadza się je w celu oceny konsekwencji wystąpienia sytuacji krytycznej dla, np. bezpieczeństwa przetwarzanych danych. Rozdział ten ma na celu zaprezentowanie próby weryfikacji jakości stworzonego oprogramowania. Z uwagi na charakter wykonanego projektu oraz na zakres opisu rozwiązania będącego przedmiotem tej pracy magisterskiej przeprowadzenie testów automatycznych i opisanie ich w tym rozdziale okazało się niewłaściwe z użytkowego punktu widzenia. Dlatego zdecydowałem o przeprowadzeniu testów wydajnościowych wizualizacji 3D. Test wydajnościowy będzie polegał na wykorzystaniu automatycznego generatora do przygotowania programów cieniujących. 93

94 6.1 Opis testów Wizualizacja została uruchomiona dla 1000 klatek o stałym czasie trwania w wirtualnym świecie. Wizualizację przeprowadzono z użyciem potoku renderingu opartego o odłożone cieniowanie. Dokładny opis metody oraz implementacja została przedstawiona we wcześniejszych rozdziałach. Wirtualny czas trwania pojedynczej klatki został ustalony na 50ms. Z 1000 zebranych próbek zostało odrzuconych 5% o najniższych i najwyższych wartościach w celu zniwelowania wpływu szybkości systemu operacyjnego oraz mechanizmów kolejkowania karty graficznej na szybkość generacji pojedynczej klatki obrazu. Następnie z otrzymanych wartości wyliczono średnią arytmetyczną i odchylenie standardowe czasu trwania klatki. Wizualizacja została przetestowana na dwóch komputerach w trzech scenariuszach (mających wpływ na jakość wizualizacji) oraz sześciu rozdzielczościach ekranu. Wyniki następnie zostały zebrane w formie tabeli i porównane. Opis sceny 3D Testy zostały przeprowadzone na specjalnie do tego przygotowanej mapie 3D. Mapa ta cechowała się następującymi parametrami: ilość źródeł światła - 46 ilość łatek terenu ilość kontrolerów podziału sceny ilość obiektów geometrycznych ilość wyświetlanych trójkątów tyś. Licencja Wszystkie materiały graficzne (tekstury, materiały, modele, struktura scen 3D) zostały zaczerpnięte z gry Fallout 3 produkcji Bethesda Softworks. Materiały te są własnością firmy Bethesda Softworks a w pracy magisterskiej zostały wykorzystane jedynie do prezentacji potencjalnych możliwości systemu wizualizacji. Dane te zostały rozpakowane przy pomocy: Fallout 3 Archive Utility Version 1.0. Następnie potrzebne modele zostały przetłumaczone z formatu nif na format Wavefront OBJ przy użyciu aplikacji NifSkope. Na koniec został napisany analizator pliku gry ESM, który stworzono na podstawie opisu z 1. Z pliku esm została zaczytana struktura map 3D. Stworzone elementy własne, to wszystkie shadery materiałowe i shadery oświetlenia, na których skupia się niniejsza praca magisterska

95 Konfiguracja sprzętowa Testy zostały przeprowadzone na każdej z następujących rozdzielczości: 640x480, 800x600, 1024x768, 1280x1024, 1680x1050, 1920x1080 przy pomocy komputerów o następujących konfiguracjach: 1. Komputer stacjonarny: Procesor - Pentium Dual-Core E5200 (2,5GHz) Pamięć RAM - 2GB DDR2 Karta Graficzna - NVidia GF9600GT 512MB System Operacyjny - Windows 7 x86 Professional 2. Komputer przenośny (zewnętrzna karta graficzna): Procesor - Intel Core i7-2620m (2,7GHz) Pamięć RAM - 6GB DDR3 Karta Graficzna - AMD Radeon HD6490M System Operacyjny - Windows 7 SP1 x64 Professional 3. Komputer przenośny (zintegrowana karta graficzna): Procesor - Intel Core i7-2620m (2,7GHz) Pamięć RAM - 6GB DDR3 Karta Graficzna - Intel HD3000 System Operacyjny - Windows 7 SP1 x64 Professional Scenariusze testowe Każda z konfiguracji została sprawdzona w trzech scenariuszach: wysoka jakość - Jakość generowanych programów cieniujących została ustawiona na wysoką. Instancing włączony, efekty HDR wyłączone. niska jakość - Jakość generowanych programów cieniujących została ustawiona na niską. Instancing włączony, efekty HDR wyłączone. jakość automatyczna - Jakość generowanych programów cieniujących została ustawiona na automatyczną, czyli zależną od odległości obiektu lub źródła światła od obserwatora. I tak: do 5m jakość wysoka, do 10m jakość średnia, powyżej jakość niska. Poziomy szczegółowości Przygotowane programy cieniujące cechowały się następującymi efektami zależnymi od jakości wizualizacji: 95

96 Czas generacji klatki [ms] Ilość obiektów geometrycznych jakość wysoka średnia niska symulacja rozproszenia (diffuse) symulacja odbić (specular) symulacja wypukłości (normal maps) ilość próbek cieni 13 1 (Variance Shadow Mapping) Tablica 6.1: Ustawienia poziomów szczegółowości 6.2 Wizualizacja 3D Wymagania wydajnościowe wizualizacji 3D zostały przedstawione na rys. 6.1 i 6.2. Rysunki przedstawiają ilość obiektów geometrycznych oraz źródeł światła w każdej klatce animacji. Dodatkowo na drugiej osi został umieszczony czas generacji pojedynczej klatki obrazu. Czas ten pochodzi z symulacji scenariusza wysokiej jakości na karcie graficznej GF9600GT oraz w rozdzielczości 1920x1080. Na rys. 6.1 można dopatrzyć się słabej korelacji między czasem generacji klatki a ilością wyświetlanych obiektów geometrycznych. Wynika z tego, że koszt przygotowania buforów dla fazy geometrii jest mało znaczący w stosunku do innych składowych potoku renderingu odłożonego cieniowania. 120 Zależność czasu generacji klatki od ilości obiektów Numer klatki wizualizacji Czas generacji klatki [ms] Ilość obiektów geometrycznych Rysunek 6.1: Ilość obiektów geometrycznych 96

97 Czas generacji klatki [ms] Ilość źródeł światła Rys. 6.2 przedstawia silną korelację między czasem generacji klatki a ilością źródeł światła. Takie zachowanie jest zgodne z oczekiwaniami. Głównym obciążeniem metody odłożonego cieniowania jest faza oświetlenia. W tej fazie powstaje problem ograniczonej przepustowości wypełniania (ang. fill-rate bonud). Faktem jest natomiast, to, że ilość możliwych do wyświetlenia świateł w tym samym czasie generacji jest znacząco większa niż przy zastosowaniu cieniowania wprost. Wybór pomiędzy odłożonym cieniowanie a cieniowaniem wprost dzięki zastosowaniu generatora programów cieniujących przedstawionego w niniejszej pracy, może zostać wykorzystany bez ponoszenia dodatkowych kosztów implementacji. 120 Zależność czasu generacji od ilości źródeł światła Czas generacji klatki [ms] Ilość źródeł światła Rysunek 6.2: Ilość źródeł światła 6.3 Wpływ jakości na szybkość renderingu Każdy z przeprowadzonych testów został powtórzony trzykrotnie a jego wyniki zostały uśrednione. W pierwszej kolejności przeprowadzono test dla wysokiej jakości grafiki. Można zauważyć znaczącą przewagę GF9600GT nad pozostałymi chipsetami graficznymi. Karta ta osiąga maksymalną ilość klatek dla rozdzielczości 640x480, 800x600 oraz 1024x768. Maksymalna ilość klatek wynika z zastosowania synchronizacji pionowej (ang. V-Sync), która jest zależna od częstotliwości odświeżania ekranu. Częstotliwość odświeżania na komputerach testowych była ustawiona na 60Hz. GF9600GT daje zadowalającą płynność (powyżej 30 klatek na sekundę) nawet w rozdzielczości 1920x1080. Podobny test został przeprowadzony dla niskiej jakości. Wykorzystano do tego ten sam diagram przepływu, który był używany przy teście wysokiej jakości, 97

98 Wysoka jakość 1920x x x1024 HD x768 HD6490M GF9600GT 800x x480-10,0 20,0 30,0 40,0 50,0 60,0 70,0 Ilość klatek na sekundę Rysunek 6.3: Wyniki wydajnościowe dla wysokiej jakości Niska jakość 1920x x x1024 HD x768 HD6490M GF9600GT 800x x480-10,0 20,0 30,0 40,0 50,0 60,0 70,0 Ilość klatek na sekundę Rysunek 6.4: Wyniki wydajnościowe dla niskiej jakości dodając do niego odwołania do bloku Effect::Quality. Blok ten pozwala na kompilację zależną od oczekiwanego poziomu szczegółowości. Podobnie jak poprzednio zdecydowanie najlepiej radzi sobie karta graficzna GF9600GT osiągając najwyższą wydajność w każdej z testowanych rozdzielczości. Zadowalająca płynność uzyskuje również karta HD6490M dla 1920x1080 (w okolicach 30 klatek). Test ten pokazuje jak duży wpływ na szybkość renderingu ma dobór odpowiednich programów cieniujących. Zmniejszenie poziomu szczegółowości pozwoliło na osiągnięcie bardzo dobrej wydajności 98

99 w nawet wysokich rozdzielczościach. Warto dodać, że osiągnięto to zerowym kosztem - wykorzystane zostały te same shadery materiałowe i shader oświetlenia a tylko z innymi oczekiwanymi poziomami szczegółowości generatora. 6.4 Tryb automatyczny Kolejny test polegał na aktywacji trybu automatycznej jakości. Tryb ten zależnie od odległości od obserwatora wykorzystuje programy cieniujące o wysokiej, średniej i niskiej jakości. Pozwala to zachować przyzwoitą ilość detali bez znaczącej utraty jakości wynikowego obrazu. Wynika, to z faktu, że wraz ze wzrostem odległości ilość dostrzeganych detali, tj. wypukłości, czy agresywne algorytmy wygładzania cieni, znacząco się zmniejsza. Jakość automatyczna 1920x x x1024 HD x768 HD6490M GF9600GT 800x x480-10,0 20,0 30,0 40,0 50,0 60,0 70,0 Ilość klatek na sekundę Rysunek 6.5: Wyniki wydajnościowe dla jakości automatycznej Wyniki tego testu pokazują pewne uśrednienie rezultatów z testu wysokiej i niskiej jakości. Zastosowanie mechanizmu automatycznej generacji programów cieniujących dla różnych poziomów szczegółowości pozwoliło na znaczne przyspieszenie czasu renderingu pojedynczej klatki. Zdecydowanie najszybszą jest karta graficzna GF9600GT. Jednakże przyzwoitą płynność i jakość zapewnia już HD6490M w rozdzielczości 1280x1024. HD3000, który jest najsłabszym z chipsetów, pozwala na płynna zabawę w 1024x768. W przypadku HD3000 można dalej zmienić ustawienia szczegółowości, aby uzyskać większą płynność w wyższych rozdzielczościach. Wpływ wyboru scenariusza testowego na ilość klatek najlepiej pokazuje rys Zestawienie takie przygotowany tylko dla HD6490M, ponieważ karta ta jest najbardziej 99

100 HD6490M 1920x x x1024 Niska jakość 1024x768 Jakość automatyczna Wysoka jakość 800x x480-10,0 20,0 30,0 40,0 50,0 60,0 70,0 Ilość klatek na sekundę Rysunek 6.6: Porównanie wydajności dla HD6490M w różnych scenariuszach testowych repreznetatywnym przykładem - znajduje się w środku stawki przeprowadzonych testów. Z tego porównania wywnioskować można, że wykorzystanie automatycznej jakości pozwala na zyskanie około 20% szybszego renderingu, względem trybu wysokiej jakości. Oczywiście zysk ten jest zależny od agresywności algorytmu wyboru jakości dla obiektów. Można by uzyskać jeszcze wyższe wartości, zmniejszając wartości graniczne odległości dla wysokiego i średniego poziomu szczegółowości. 100

101 Rozdział 7 Podsumowanie W wyniku prac nad Graficznym edytorem cieniowania powstał projekt, mający duże możliwości w zakresie wizualizacji scen trójwymiarowych. Zaprojektowany interfejs WYSWIG pozwala w łatwy sposób dodawać, modyfikować i usuwać obiekty ze sceny trójwymiarowej, definiować parametry oświetlenia, parametry efektów środowiskowych oraz wiele innych wpływających na odbiór końcowego obrazu. Wszystkie komponenty systemu z wykluczeniem bibliotek systemowych i bibliotek Qt zostały zaprojektowane i zaprogramowane przez autora. Kod źródłowy ma łączną długość około 50tyś linii. Korzystając z przedstawionych narzędzi zaprojektowano i wykonano wiele testów potwierdzających skuteczność implementacji graficznego edytora cieniowania. Zaprezentowane rozwiązania mogą stanowić punkt zaczepienia do stworzenia produktu użytecznego dla grafików przygotowujących programy cieniujące na potrzeby programów lub silników gier 3D. Niniejsze rozwiązanie cechuje prosta obsługi, duże możliwości systemu oraz wysoki stopień wydajności w stosunku do programów cieniujących tworzonych przy wykorzystaniu innych narzędzi. Przyzwoita szybkość generowanego kodu jest efektem zastosowania wielu optymalizacji. Zidentyfikowanie wąskich gardeł procesu renderingu umożliwiło dodatkowe optymalizacje, które następnie pozwoliły zwiększyć szybkość wyświetlania pojedynczej ramki obrazu. Mimo, iż system jest kompletny pewne jego elementy nie zostały należycie zgłębione w niniejszej pracy. W przyszłości warto by zaimplementować obsługę innych API graficznych, m.in.: OpenGL/ES. Równie istotna jest implementacja kolejnych efektów graficznych, np.: bardziej wyrafinowane modele oświetlenia. Ponadto warto by rozważyć możliwość generacji kodu GeometryShader. Funkcjonalność tego typu mogłaby być pomocna przy wyświetlaniu dynamicznej roślinności akcelerowanej przez kartę graficzną. 101

102 102

103 Bibliografia [1] J. F. Blinn. Models of light reflection for computer synthesized pictures. ACM SIGGRAPH Computer Graphics, [2] D. H. Eberly. 3D Game Engine Architecture: Engineering Real-Time Applications with Wild Magic. Morgan Kaufmann, [3] J. F. Hughes J. D. Foley; A. van Dam; S. K. Feiner. Computer Graphics: Principles and Practice. Addison-Wesley Publishing Company, [4] M. Woo J. Neider, T. Davis. OpenGL Programming Guide (The Red Book). Silicon Graphics, [5] K. Kluczek. Przechowywanie Złożonych Funkcji Oświetlenia w Postaci Map Normalnyc. Krajowa Konferencja Wytwarzania Gier Komputerowych, Gdańsk, [6] F. D. Luna. Introduction to 3D Game Programming with DirectX R 9.0c: A Shader Approach. Wordware Publishing, Inc., [7] F. D. Luna. Introduction to 3D Game Programming with DirectX R 10. Jones & Bartlett Learning, [8] J. R. Wallace M. F. Cohen. Radiosity and Realistic Image Synthesis. Morgan Kaufmann, [9] Politechnika Warszawska M. Korniluk. Light pre-pass renderer. Uniwersystet Gdański, Zjazd Twórców Gier 2010, [10] K. Akeley M. Segal. The OpenGL Graphics System: A Specification. Silicon Graphics, [11] W. R. Mark. Future graphics architectures. ACM Queue 6(2), Marzec/Kwiecień [12] Microsoft. Dynamic Linking. windows/desktop/ff471420(v=vs.85).aspx,

104 [13] Microsoft. Programming Guide for HLSL. library/windows/desktop/bb509635(v=vs.85).aspx, [14] AMD Graphics products Group N. Thibieroz. Harnessing the Power of DirectX 10. Develop conference, [15] nvidia. NVidia CUDA Programming Guide Version download.nvidia.com/compute/cuda/1_0/nvidia_cuda_programming_guide_1. 0.pdf, [16] nvidia. NVIDIA OpenGL Extension Specifications for the GeForce 8 Series Architecture (G8x). nvidia, [17] M. J. Kilgard R. Fernando. The Cg Tutorial: The Definitive Guide to Programmable Real-Time Graphics. Addison-Wesley Professional, [18] K. Rocki. Przetwarzanie obrazów w czasie rzeczywistym za pomocą gpu. Master s thesis, Politechnika Warszawska, WEiTI, [19] M. Harris S. Hargreaves. Deferred Shading. GDC presentation, [20] A. Lawrance S. Kircher. Inferred Lighting: Fast dynamic lighting and shadows for opaque and translucent objects. SIGGRAPH, [21] O. Shishkovtsov. GPU Gems 2: Programming Techniques for High-Performance Graphics and General-Purpose Computation, chapter Chapter 9. Deferred Shading in S.T.A.L.K.E.R. NVidia, [22] S. St-Laurent. The COMPLETE Effect And HLSL Guide. Paradoxal Press, [23] P. Szczerbuk. Porównanie metod wizualizacji scen trójwymiarowych w czasie rzeczywistym. Master s thesis, Politechnika Gdańska, WETI, [24] M. Valient. ShaderX2, chapter Advanced lighting and shading with Direct3D 9. Wordware, [25] A. Lauritzen W. Donnelly. Variance Shadow Maps. Symposium On Interactive 3D Graphics and Games, ACM, [26] WT Vetterling BP Flannery WH Press, SA Teukolsky. Numerical Recipes: The Art of Scientific Computing. New York: Cambridge University Press,

105 Dodatek A Język HLSL HLSL (High Level Shading Language for DirectX) [13] [22] jest wysokopoziomowym językiem cieniowania. Pisząc programy z wykorzystaniem HLSL można wykorzystując strukturę języka podobną do C stworzyć programy cieniujące dla potoku renderingu Direct3D. Język HLSL powstał z myślą o wykorzystaniu pełnych możliwości kart graficznym przy możliwie jak najprostszym ich programowaniu. HLSL umożliwia tworzenie programów cieniujących do każdego z programowalnych elementów potoku renderingu, tzn. Vertex Shader, Geometry Shader (w przypadku DirectX 10/11) oraz Pixel Shader. Wprowadzenie Użycie programowalnej jednostki cieniującej wierzchołki wyłącza wbudowane mechanizmy przetwarzania wierzchołków. W najprostszej wersji program shadera musi zwrócić pozycję wierzchołka w tzw. jednorodnej przestrzeni obcinania (ang. homogeneous clip space), w której ma m.in. miejsce operacja obcinania wielokątów względem ostrosłupa widzenia. Dodatkowo shader może przekazać do potoku renderingu: koordynaty tekstur, kolor wierzchołków, parametry oświetlenia, parametry mgły, itp. Przetwarzanie pikseli na podstawie Pixel Shaderów jest wykonywane na pojedynczych pikselach. Parametrami jednostki cieniującej piksele są wartości na wyjściu cieniowania wierzchołków - wyjście z Vertex Shadera jest wejściem dla Pixel Shadera. Pozostałe operacje na pikselach, tj.: efekty mgły, operacja na buforze szablonowym, itd. są nakładane po zakończeniu wykonywania shaderów. 105

106 // zmienne globalne (stałe) float4x4 projviewobject; sampler diffusetexture; // program cieniujący wierzchołki float4 VertexShader( // parametry wierzchołka in float3 localorigin : POSITION0, in float2 texcoords : TEXCOORD0, // wartości przekazywane do pixel shadera out float2 otexcoords : TEXCOORD0) : POSITION0 { // przekaż koordynaty tekstur do pixel shadera otexcoords = texcoords; } // przetransformuj wierzchołek return mul(float4(localorigin, 1.0f), projviewobject); // program cieniujący piksele float4 PixelShader(in float2 texcoords : TEXCOORD0) : COLOR0 { // wyznacz kolor tekstury diffusetexture // w miejscu określonym przez texcoords return tex2d(diffusetexture, texcoords); } #endif Program A.1: HLSL: Przykładowy program cieniujący wierzchołki i piksele. Zmienne Deklaracja zmiennych w języku HLSL jest realizowana identycznie jak w C. Każda zmienna składa się z opcjonalnego modyfikatora, typu danych, nazwy zmiennej, opcjonalnego parametru określającego wielkość tablicy oraz przypisania. W języku HLSL wyróżniamy następujące typy danych: podstawowe - są to typy, tj.: bool (prawda, fałsz), int i uint (liczba całkowita), half, float i double (liczba zmiennaprzecinkowa 16, 32 i 64 bitowa) wektorowe - są to typy zbudowane z typu podstawowego oraz dołączonej liczby określającej ilość elementów wektora, np.: float2 (wektor dwuargumentowy, zmiennoprzecinkowy), int4 (wektor czteroargumentowy, całkowity) macierzowe - są to typy zbudowane z typu podstawowego oraz dołączonych liczb określających ilość wierszy oraz kolumn, np.: float2x2 (macierz w 2 wierszach i kolumnach, zmiennoprzecinkowa), int2x4 (macierz 2 wierszach i 4 kolumnach, 106

107 całkowita) teksturowe - są to typy przechowujące specjalny uchwyt na jednostkę teksturującą karty graficznej, która pozwala na pobieranie koloru tekstury w dowolnym jej punkcie, np.: sampler2d (uchwyt na teksturę dwuwymiarową), samplercube (uchwyt na teksturę sześcienną), sampler3d (uchwyt na teksturę trójwymiarową) zdefiniowane przez użytkownika - są to nazwy typów będące akronimem dla innych typów. float fvar; float fvar = 3.1f; int ivar[3]; int ivar[3] = {1,2,3}; Program A.2: HLSL: Deklaracja zmiennych. Parametry shaderów Każdy program cieniujący akceptuje dwa typy danych wejściowych: zmienne i stałe. Wartości zmienne są unikatowe dla każdego wykonania shadera. W przypadku Vertex Shadera wartości zmienne (np. pozycja, wektor normalny) pochodzą ze struktury opisującej dany wierzchołek. Wartości stałe (np. kolor materiału, macierz transformacji) są niezmienne dla wszystkich wykonań programu cieniującego. Wartości stałe mogą być zadefiniowane w programie cieniującym dwojako: jako zmienne globalne lub jako oznaczenie argumentów głównej funkcji programu cieniującego modyfikatorem uniform. Wartość globalna jest dostępna dla wszystkich funkcji we wszystkich funkcjach zdefiniowanych w danym kodzie programu cieniującego, natomiast wartość przekazana jako argument funkcji jest dostępna tylko dla danej funkcji. float4x4 projviewobject; float4 VertexShader(uniform float4 materialcolor) : POSITION0 { } Program A.3: HLSL: Wartości stałe. Wartości zmienne muszą być specjalnie oznaczane w kodzie programu cieniującego przez użycie odpowiedniej deklaracji pochodzenia. Wyróżniamy następujące najważniejsze 1 pochodzenia wartości zmiennych: POSITIONn - pozycja wierzchołka TEXCOORDn - koordynaty tekstury dla wierzchołka lub piksela 1 Szczegółowy opis można znaleźć pod tym adresem: windows/desktop/bb509647(v=vs.85).aspx 107

108 COLORn - kolor wierzchołka lub piksela NORMALn - wektor normalny wierzchołka Deklaracja pochodzenia różni się w zależności od umiejscowienia programu cieniującego w potoku renderingu. Programy cieniujące wierzchołki pobierają informacje per-wierzchołek (np. pozycja, wektor normalny, koordynaty tekstur, wektory styczne), natomiast programy cieniujące piksele pobierają informacje przypisane do danego piksela (np. kolor, koordynaty tekstur, głębia). Deklarację pochodzenia dołącza się do zmiennej przy pomocy jednej z dwóch metod: poprzez dołączenie do deklaracji argumentu funkcji cieniującej dwukropka z informacją o pochodzeniu lub definicję struktury opisującej wejście programu i przypisanie każdemu elementowi struktury pochodzenia. struct VS_INPUT { float4 vposition : POSITION; float3 vnormal : NORMAL; }; struct VS_OUTPUT { float4 vposition : POSITION; float4 vdiffuse : COLOR; }; VS_OUTPUT VertexShader(const VS_INPUT v) { } float4 VertexShader2(in float4 vposition : POSITION, in float3 vnormal : NORMAL out float4 vdiffuse : COLOR) : POSITION { } Program A.4: HLSL: Wartości zmienne - dwa przykłady deklaracji pochodzenia zmiennej. Funkcje Funkcje pozwalają na podział większych algorytmów na mniejsze podproblemy. Małe zadania są łatwiejsze w poprawianiu i rozszerzaniu funkcjonalności lub mogą być użyte wielokrotnie. Funkcje mogą być zastosowane do ukrycia szczegółów implementacji, co pozwala na skonstruowanie programu prostszego w zrozumieniu. Funkcje HLSL są podobne do funkcji języka C w następujących aspektach: Oba języki posiadają definicję, ciało funkcji. Oba deklarują zwracany typ oraz listę argumentów. 108

109 Oba języki wykonują sprawdzanie typów przekazywanych argumentów oraz automatyczną konwersję między typami w czasie kompilacji programu. Najistotniejszą różnicą jest fakt, że funkcje wejściowe (główne) HLSL wykorzystują w przekazywanych i zwracanych typach informacje o pochodzeniu danych. Pozwala to na łatwiejsze przekazanie wartości zmiennych do programów cieniujących oraz na przekazanie ich między kolejnymi etapami potoku renderingu. Funkcja musi posiadać definicję, czyli ciało funkcji poprzedzone przez jej deklarację. // Opcjonalna deklaracja funkcji - wymagana, // gdy~chcemy użyć funkcji przed jej~definicją. float4 VertexShader_Tutorial_1(float4 inpos : POSITION ) : POSITION; // Wymagana deklaracja funkcji float4 VertexShader_Tutorial_1(float4 inpos : POSITION ) : POSITION { return mul(inpos, WorldViewProj ); }; Program A.5: HLSL: Funkcje - deklaracja i definicja. Każda deklaracja funkcji musi zawierać następujące informacje: Zwracany typ Nazwę funkcji Opcjonalną listę argumentów Opcjonalną deklarację pochodzenia Sterowanie przepływem HLSL jak każdy inny język posiada instrukcje, pozwalające na warunkowe lub zapętlone wykonanie określonych funkcji. Język obsługuje sterowanie przepływem oparte o wykorzystanie: warunkowego wykonania instrukcji, statycznych skoków oraz pętli, dynamicznych skoków oraz pętli. W języku HLSL podobnie do języka C mamy dostępne następujące instrukcje sterowania przepływem: do, while, for, if, switch, break, continue, discard. Shader Model a profile kompilacji Kompilator HLSL dostępny w środowisku DirectX implementuje różne wersje Shader Model. Jednakże sama kompilacja opiera się o wykorzystanie tzw. profili kompilacji (ang. Shader Profile). Każdy profil kompilacji określa przeznaczenie programu cieniującego (cieniowanie wierzchołków, geometrii lub pikseli) oraz zakres obsługiwanych funkcji. 109

110 // wykorzystanie dynamicznego skoku in int Value; if(value > 0) opos = Value1; else opos = Value2; // wykorzystanie statycznej pętli uniform int Count; for(int i = 0; i < Count; ++i) { opos += 1; } Program A.6: HLSL: Sterowanie przepływem. Shader Profile kompilacji Model 1.0 vs ps 2 0, ps 2 x, vs 2 0, vs 2 x 3.0 ps 3 0, vs gs 4 0, ps 4 0, vs 4 0, gs 4 1, ps 4 1, vs gs 4 0, ps 4 0, vs 4 0, gs 4 1, ps 4 1, vs 4 1, gs 5 0, ps 5 0, vs 5 0, hs 5 0 Tablica A.1: HLSL: Dostępne profile kompilacji, gdzie: vs - Vertex Shader, ps - Pixel Shader, gs - Geometry Shader Funkcje wbudowane Język HLSL udostępnia bogatą bibliotekę wbudowanych funkcji. Funkcje te pozwalają na wyliczanie wartości określonych wzorów matematycznych, tj.: iloczyn wektorowy, skalarny, transformacja wektorów, wartość bezwzględna, funkcje trygonometryczne, itp. Krótki opis najciekawszych z nich został zaprezentowany poniżej: Nazwa Opis abs Zwraca wartość bezwzględną all Sprawdza czy wszystkie wartości są różne od 0 any Sprawdza czy co najmniej jedna wartość jest różna od 0 asint Zbiór funkcji pozwalających na konwersję typów danych asfloat

111 Nazwa ceil ceil clamp cos cross distance dot frac InterlockedAdd InterlockedAnd... lerp max min normalize sin sqrt tex2d texcube tex3d tex2dgrad texcubegrad tex3dgrad Opis Zwraca sufit lub podłogę danej wartości Przycina wartość do określonego zakresu [min,max] Zwraca kosinus Zwraca iloczyn wektorowy dwóch wektorów trójwymiarowych Zwraca odległość między dwoma punktami Zwraca iloczyn skalarny dwóch wektorów Zwraca część ułamkową wartości Zbiór funkcji umożliwiających pisanie programów wielowątkowych, pracujących na tym samym zbiorze danych Zwraca wartość interpolacji liniowej Zwraca większą lub mniejszą wartość Normalizuje wektor Zwraca sinus Zwraca pierwiastek kwadratowy Zwraca kolor tekstury dwuwymiarowej, sześciennej lub trójwymiarowej Zbiór funkcji pobierających kolor tekstury z możliwością określenia poziomu szczegółowości 111

112 112

113 Dodatek B Zawartość płyty DVD W tym dodatku pokrótce przedstawię zawartość płyty DVD dołączonej do niniejszej pracy magisterskiej. Na płycie DVD znajdują się wszystkie pliki potrzebne do uruchomienia i kompilacji projektu na dowolnym komputerze wyposażonym w odpowiednie środowisko developerskie. Są również wszystkie pliki danych, wygenerowane i zoptymalizowane kody programów cieniujących potrzebne do uruchomienia aplikacji. W celu uruchomienia projektu należy wybrać jeden ze skrótów (Launch.bat lub LaunchDebug.bat) a następnie wybrać ładowaną konfigurację z listy. Struktura plików i katalogów przedstawia się następująco: /config/ - katalog zawiera pliki dla różnych konfiguracji uruchomień dema technologicznego. /data/ - katalog zawiera pliki danych dema technologicznego. /debug/ - katalog zawiera pliki wykonywalne skompilowane w konfiguracji debug (kompilacja testowa). /install/ - katalog zawiera plik instalacyjny biblioteki NVidia PhysX. Instalacja tej biblioteki jest wymagana do działania aplikacji. /release/ - katalog zawiera pliki wykonywalne skompilowane w konfiguracji release. /src/ - katalog zawiera pliki źródłowe projektu. Projekt można otworzyć w QtCreatorze. /Launch.bat - skrót do uruchomienia dema technologicznego w wersji produkcyjnej. Jest to zalecana wersja oprogramowania. /LaunchDebug.bat - skrót do uruchomienia dema technologicznego w wersji testowej. /MSc.pdf - wersja elektroniczna niniejszej pracy magisterskiej. 113

114 114

115 Dodatek C Uruchomienie środowiska testowego Poniżej pokrótce przedstawiam cały proces instalacji i konfiguracji środowiska uruchomieniowego aplikacji. C.1 Wymagania Do poprawnej pracy wymagana jest instalacja bibliotek do obsługi modułu fizyki NVidia PhysX. Instalator dostarczony przez firmę NVidia znajduje się w katalogu /install/ na dołączonej do pracy płycie DVD. Wymagana jest instalacja pliku: PhysX Game installer 281.msi. Oprócz wymaganego komponentu komputer, na którym ma być uruchomiona aplikacja musi spełniać następujące wymagania: System operacyjny - Windows Vista lub 7, x86 lub x64 Karta graficzna - Z obsługą Shader Model 3.0 Pamięć RAM - 2GB C.2 Obsługa W celu uruchomienia aplikacji należy uruchomić jeden z dwóch plików.bat: Launch.bat - Produkcyjna wersja aplikacji z włączonymi wszystkimi optymalizacjami kompilacji. Jest to wersja zalecana. LaunchDebug.bat - Testowa wersja aplikacji z informacjami debuggera. Jest to wersja pomocnicza w przypadku problemów z wersją produkcyjną. Po uruchomieniu użytkownik ma możliwość wyboru profilu konfiguracyjnego aplikacji, tj. na rysunku C.1. W zależności od wybranej opcji pojawi się okno wyboru rozdzielczości, okno edycji materiału, okno edytora lub okno dema technologicznego. 115

116 Rysunek C.1: Wybór profilu konfiguracyjnego aplikacji Wybór rozdzielczości Okno zaprezentowane na rys. C.2 pozwala na wybór rozdzielczości w jakiej zostanie uruchomione demo. Użytkownik może uruchomić w jednej z wymienionych na liście rozdzielczości, w trybie okienkowym lub pełnoekranowym. Obsługiwane są następujące rozdzielczości: 800x600, 1024x768, 1280x1024, 1920x1440, 1280x800, 1360x768, 1680x1050, 1920x1080 Rysunek C.2: Okno wyboru rozdzielczości Edytor Opisany Graficzny Edytor Cieniowania jest tylko małym wycinkiem całej funkcjonalności projektu. Projekt pozwala na edycję: tekstur, materiałów, shaderów, obiektów geometrycznych oraz scen. Uruchomienie przeglądarki zasobów pozwala na wykorzystanie jego pełnej funkcjonalności. Dwukrotne kliknięcie na jeden z obiektów listy (np. Forge01.grcz) poskutkuje jego załadowaniem i uruchomieniem w trybie edycji. Tryb edycji sceny (rys. C.3) pozwala, m.in. na dodawanie nowych obiektów, konfigurację parametrów oświetlenia, konfigurację mechanizmów widoczności, konfigurację parametrów i zachowań fizycznych. 116

117 Rysunek C.3: Okno edytora sceny Edycja materiału Po wybraniu z menu konfiguracji edytora materiału, uruchomi się okno prezentujące obszar edycyjny shadera materiału (rys. C.4). Edycja shaderów oparta jest o wykorzystanie techniki drag&drop. Określone czynności realizuje się w następujący sposób: zaznaczanie - kliknięcie w tytuł bloku spowoduje jego zaznaczenie. dodawanie - dodanie nowego bloku do diagramu przepływu polega na przeciągnięciu go z listy bloków na obszar edycyjny. usuwanie - usunięcie następuje po wciśnięciu klawisza Delete po zaznaczeniu bloków do usunięcia. łączenie - połączenie wyjść z wejściami bloków polega na przeciągnięciu wyjścia i upuszczeniu jego na wejście bloku. Po poprawnym połączeniu ikonka zmieni stan na pełny. rozłączanie - rozłączenie połączenia następuje po kliknięciu w ikonkę przy nazwie wejścia. Ikonka zmieni stan na pusty. zmiany - wszystkie zmiany są automatycznie odzwierciedlane na podglądzie. Obsługa okna podglądu obrót kamery - ruch myszy przy wciśniętym prawym przycisku myszy skutkuje obrotem kamery. przybliżenie kamery - ruch myszy w przód i w tył przy wciśniętym lewym i prawym przycisku myszy skutkuje przybliżeniem lub oddaleniem widoku. 117

118 Rysunek C.4: Okno edytora materiałów przesunięcie kamery - ruch myszy przy wciśniętym prawym przycisku myszy oraz klawiszu Control skutkuje przesunięcie kamery oraz źródła światła. Demo technologiczne Po wybraniu z menu konfiguracji jednego z dem technologicznych użytkownikowi pokaże się okno widoku (rys. C.5). Dema technologiczne mogą działać w dwóch trybach: wydajnościowym - uruchamiany jest w określonej rozdzielczości i z określonymi parametrami renderingu. Pozwala jedynie na podgląd wizualizacji. W zależności od wydajności komputera animacja może sprawiać wrażenie przyspieszonej lub spowolnionej. Wynika, to z faktu, że symulacja przeprowadzana jest z określoną częstością wizualizacji (np. 60Hz). Wynikiem działania jest informacja o minimalnym, maksymalnym, średnim, medianie i odchyleniu standardowym czasu trwania klatek. Dodatkowo w szczególnych przypadkach możliwe jest zapisanie wyników i czasu trwania poszczególnych klatek do pliku csv. interaktywnym - pozwala na interakcję z wirtualnym światem. Użytkownik ma możliwość przejścia się po wirtualnym świecie i interakcji z obiektami fizycznymi. 118