Grafika komputerowa i wizualizacja
Informatyka S1 - 2015/2016

Poprawa egzaminu i laboratoriów

W odpowiedzi na liczne pytania z Państwa strony informuję, że w tym roku akademickim odbędzie się jeszcze tylko jeden termin poprawy egzaminu: 13 września.

§26 Regulaminu Studiów ZUT wymaga aby odbyły się przynajmniej dwa terminy poprawkowe uzgodnione ze studentami. W harmonogramie sesji który Państwo zaakceptowali są to: 12 lutego i 13 września. Na Państwa życzenie odbył się dodatkowy termin 15 lutego. Proszę pamiętać że został obniżony próg punktowy pozwalający na zdobycie pozytywnej oceny, a także możliwe było zdobycie zwolnienia z egzaminu na podstawie pracy na laboratoriach. Nie jest przewidywane żadne więcej ułatwienie zaliczenia przedmiotu.

Jednocześnie informuję, że nie są planowane żadne więcej terminy poprawy oceny z laboratoriów. Dwa takie terminy odbyły się w trakcie sesji zimowej.

Egzamin - wyniki

Spakowane z użyciem 7zip, hasło wg ustaleń na egzaminie:

Termin Poprawkowy IV (wrzesień) (2016-09-13)

Termin Poprawkowy III (marzec) (2016-03-15)

Termin Poprawkowy II (2016-02-15)

Termin Poprawkowy (2016-02-12)

Termin Podstawowy (2016-02-04 i 2016-02-08)

Skala ocen:

Wyniki konkursu

Ogłoszenie wyników konkursu odbędzie się 25 stycznia o godzinie 10.15 w sali 227 WI2. Obecność obu grup wykładowych jest obowiązkowa!

Egzamin

Uczestictwo w egzaminie wymaga wcześniejszego uzyskania pozytywnej oceny z laboratoriów. Prace egzaminacyjne osób które w dniu pisania egzaminu nie mają pozytywnej oceny z laboratoriów nie będą sprawdzane.

Wszelkie przejawy nieuczciwości podczas pisania egzaminu skutkują brakiem możliwości uzyskania pozytywnej oceny z przedmiotu. Podczas pisania egzaminu nie można korzystać z żadnych materiałów ani urządzeń innych niż długopis i arkusz egzaminacyjny.

Zaliczenie laboratoriów

Gotową grę należy zaprezentować prowadzącemu zajęcia. Podczas prezentacji zostanie przeprowadzona rozmowa o użytych rozwiązaniach technicznych, na podstawie której zostanie zaproponowana ocena. Następnie należy oddać paczkę ze źródłami gry. Dopiero wówczas ocena zostanie finalnie wystawiona.

Czego NIE zawierać w paczce z kodami źródłowymi?

Przesyłając komuś kod źródłowy projektu, absolutnie nie należy załączać pliku *.sdf (ogromna baza danych tworzona przez VS, ona i tak zostanie odtworzona na docelowym komputerze), katalogu ipch (precompiled headers), całej postaci skompilowanej i pośredniej (katalogi Debug, Release oraz nazwa_projektu/Debug, nazwa_projektu/Release), plików z ustawieniami użytkownika (pliki *.user, *.suo).

Pomijając zbędne pliki można zredukować rozmiar źródeł nawet o kilkadziesiąt megabajtów.

Źródła przeciętnego, pozbawionego zasobów (tekstur, modeli etc.) programu na laboratoria nie powinny zajmować więcej niż 500 kB!

Uwaga wszyscy powtarzający laboratoria!

Z powodu istnienia dużej liczby studentów III roku którzy nie mają zaliczonych laboratoriów z GKiW, formowane są cztery dodatkowe grupy laboratoryjne. Zajęcia odbywają się w dniach:

  • grupa 1 – czwartki N godz. 16.15, sala 317 WI2
  • grupa 2 - czwartki N godz. 17.45, sala 317 WI2
  • grupa 3 – piątki P godz. 16.15, sala 300/317 WI2
  • grupa 4 - piątki P godz. 18.15, sala 300/317 WI2

Wobec tego wszystkie osoby które powtarzają laboratoria, a które nie są przypisane do grup dziekańskich II roku, proszone są o przychodzenie na zajęcia nowych grup dodatkowych. Sposób pracy i zasady będą inne niż w grupach standardowych, co zostanie omówione na pierwszych zajęciach. Obecność na zajęciach jest obowiązkowa.

Wykłady

  1. Wprowadzenie. Synteza trójwymiarowej grafiki czasu rzeczywistego. OpenGL. Transformacje geometryczne. 2015-10-05

    Wykład 1 - Prezentacja w formacie PDF

  2. Techniki wyświetlania obrazu. Kamera. Implementacja kamery pierwszoosobowej. 2015-10-19

    Wykład 2 - Prezentacja w formacie PDF

  3. Potok renderowania. Techniki oświetlenia i cieniowania. 2015-11-02

    Wykład 3 - Prezentacja w formacie PDF

  4. Zaawansowane techniki oświetlenia. Definiowanie geometrii. 2015-11-16

    Wykład 4 - Prezentacja w formacie PDF

  5. Tekstury. Mapy bitowe, pojęcie tekstury, potok teksturowania, zastosowania.2015-11-30

    Wykład 5 - Prezentacja w formacie PDF

  6. Scena i kolizje. Organizacja sceny. Techniki optymalizacji renderowania. Wykrywanie i reakcja na kolizje.2015-12-14

    Wykład 6 - Prezentacja w formacie PDF

  7. Obrazowanie HDR. Fotografia. Powstawanie i wyświetlanie obrazów HDR.2016-01-11

    Wykład 7 - Prezentacja w formacie PDF

Materiały na zajęcia laboratoryjne

  1. Laboratorium 0
    Budowanie projektu korzystającego z OpenGL i GLUT/freeglut

    Podczas zajęć wprowadzających poruszona zostanie kwestia dołączenia biblioteki freeglut do projektu w środowisku programistycznym MS Visual Studio. Omówione zostaną dobre praktyki korzystania z tego środowiska.

    Oczekiwany wynik działania poprawnie zbudowanego programu z załączonego projektu:

    Wynik działania programu

    Materiały

  2. Laboratorium 1
    Transformacje geometryczne

    Na zajęciach omówione zostaną podstawy użycia OpenGL. Zbudowana zostanie prosta, złożona z kilku brył scena.

    Sposoby programowania grafiki z użyciem OpenGL które będą wykorzystywane na zajęciach nie odpowiadają współczesnemu podejściu. Jest to celowe i ma charakter edukacyjny - tzw. immediate mode i fixed pipeline, choć archaiczne, są dużo łatwiejsze do zrozumienia i pozwalają na bardziej bezstresowe zrobienie pierwszych kroków w dziedzinie grafiki komputerowej czasu rzeczywistego.

    Zainteresowanych podejściem współczesnym odsyłam do dokumentacji nowego OpenGL (wersja 3.2 i nowsze) i np. do bardzo dobrej książki Real-Time Rendering. Third edition. Akenine-Muellera, Hainesa i Hoffmana.

    Zadanie nr 1

    Zadaniem do wykonania na pierwszych laboratoriach jest utworzenie animowanego "pajacyka" składającego się z kilku prostych brył. Sugerowane jest posłużenie się załączonym projektem, jako punktem wyjściowym.

    Poniżej przedstawiono oczekiwany wygląd wykonanego zadania, w dwóch wersjach zależnych od ambicji wykonującego:

    Materiały

    Układ współrzędnych w OpenGL

    Rysunek, który jest często bardzo pomocny dla poprawnego wyobrażenia sobie struktury sceny:

    Układ współrzędnych w OpenGL

  3. Laboratorium 2
    Kamera FPP, obsługa wejścia z klawiatury

    Zajęcia będą obejmowały zagadnienie kontroli kamery pierwszoosobowej (FPP - First-Person Perspective). Poruszone zostaną kwestie związane z podstawową obsługą wejścia od użytkownika.

    Zadanie nr 2

    Zadaniem jest zaimplementowanie działania kamery pierwszoosobowej.

    • Wesja podstawowa
      • Kontrola ruchu z klawiatury: ruch do przodu, do tyłu, na boki
      • Kontrola z klawiatury obrotu wokół jednej osi (przydadzą się współrzędne biegunowe)
      • Wykorzystanie gluLookAt(...)
      • Poprawna obsługa repetycji klawiszy
      • Mile widziana inercja - ruch kamery nie zatrzymujący się natychmiastowo, ale płynnie wygasający

      Lab2 - Wersja podstawowa (Youtube)

    • Wesja zaawansowana

      To co wersja podstawowa, a także:

      • obrót wokół dwóch osi (przydadzą się współrzędne sferyczne)
      • obrót kontrolowany z użyciem myszy (przydatne: glutWarpPointer(x, y), glutSetCursor(GLUT_CURSOR_NONE), glutPassiveMotionFunc(f))

      Lab2 - Wersja zaawansowana (Youtube)

    Materiały

  4. Laboratorium 3
    Oświetlenie

    Celem zajęć jest poznanie podstawowych technik cieniowania z użyciem nieprogramowalnego potoku renderowania OpenGL (fixed pipeline).

    Fixed pipeline pozwala jedynie na uzyskanie cieniowania płaskiego per face lub gładkiego per vertex, gdzie dla drugiego z nich wynik jest obliczany dla każdego wierzchołka, po czym jest on interpolowany pomiędzy tymi wierzchołkami. Jest to tzw. cieniowanie Gouraud. Daje to kiepskie efekty wizualne szczególnie dla komponentu specular.

    Współcześnie standardem jest stosowanie lepszego jakościowo cieniowania per fragment (per pixel), a więc obliczanie koloru na podstawie modelu oświetlenia dla każdego fragmentu osobno, po uprzedniej interpolacji wektora normalnego. Ten rodzaj cieniowania, nazywany cieniowaniem Phonga (lub z małym uproszczeniem Phonga-Blinna), można jednak uzyskać tylko korzystając z programowalnego potoku renderowania, w oparciu o własne programy cieniujące wykonywane na karcie graficznej, tzw. shadery które wykraczają poza materiał przerabiany na laboratoriach w ramach tego przedmiotu (jednak gorąco zachęcam do zapoznania się z tą techniką).

    Zadanie nr 3

    Zadaniem jest umieszczenie na scenie różnych, zmieniających się źródeł światła.

    • Wesja podstawowa
      • Dwa źródła światła: directional i pointlight
      • Wykorzystanie komponentów ambient/diffuse
      • Wygaszanie światła (attenuation)
      • Kontrola położenia źródła światła - poddanie jego pozycji transformacjom geometrycznym, np. związanie jednego ze źródeł z położeniem gracza
      • Zmienność źródeł światła (np. zmiana koloru, jasności, kierunku, wygaszania)
      • Mile widziane zastosowanie w bardziej złożonym środowisku - jak w przykładzie

      Lab3 - Wersja podstawowa (Youtube)

    • Wesja zaawansowana

      To co wersja podstawowa, a także:

      • Świadome użycie komponentu specular
      • Światło typu spotlight
      • Przemyślane użycie światła dla celów estetycznych

      Lab3 - Wersja zaawansowana (Youtube)

    Materiały

  5. Laboratorium 4
    Definicja własnej geometrii

    Podczas zajęć omówione zostaną sposoby definiowania własnych brył z użyciem OpenGL i tzw. immediate mode. Choć zaawansowaną geometrię zazwyczaj modeluje się za pomocą specjalistycznego oprogramowania (np. Blender), następnie jedynie importując gotowy model, to wiedza o podstawach i wyobraźnia przestrzenna są mimo wszystko niezmiernie przydatne. Dlatego te zajęcia będą dotyczyły opisywania kształtów "ręcznie".

    Zadanie nr 4

    Zadaniem jest umieszczenie na scenie własnej, nieskomplikowanej, poprawnie oświetlonej bryły.

    • Wesja podstawowa
      • Własna bryła zawierająca zarówno krawędzie "ostre", jak i "gładkie"
      • Poprawnie zdefiniowane wektory normalne, pozwalające na poprawne oświetlenie bryły
      • Poprawne rysowanie bryły przy włączonym cullingu
      • Wstawienie wielu instancji bryły na scenie, posługując się transformacjami

      Lab4 - Przykładowa wersja podstawowa (Youtube)

    • Wesja zaawansowana

      To co wersja podstawowa, a także:

      • Niezależny ruch części bryły
      • Wstawianie wielu instancji w sposób efektywny, tj. bez każdorazowego przekazywania współrzędnych wierzchołków (np. przy użyciu Display List, Vertex Array, VBO)

      Lab4 - Przykładowa wersja zaawansowana (Youtube)

    Materiały

  6. Laboratorium 5
    Teksturowanie, import modeli

    Zadanie nr 5

    Zadaniem jest oteksturowanie niestandardowej bryły z użyciem dopasowanej do jej geometrii tekstury (najlepiej własnej).

    • Wesja podstawowa
      • Nałożenie niestandardowej tekstury na niestandardową bryłę
      • Tekstura musi być czymś więcej, niż jednolitym wzorem - chodzi o to, by była dopasowana do bryły, np. poprzez umieszczenie na niej elementów w świadomy sposób odpowiadających kształtowi. Tak, by nie było wątpliwości że współrzędne tekstury zostały dobrane celowo
      • Technika filtracji tekstury ma zostać wybrana w sposób świadomy

      Lab5 - Przykładowa wersja podstawowa (Youtube)

    • Wesja zaawansowana

      To co wersja podstawowa, a także:

      • Kilka poprawnie oteksturowanych brył/obiektów o skomplikowanej formie, np. zamodelowanych wcześniej w Blenderze
      • Mile widziany teren, skybox/skydome, mgła, etc.

      Lab5 - Przykładowa wersja zaawansowana (Youtube)

    Materiały

  7. Laboratorium 6
    Wykrywanie kolizji gracza z mapą

    Laboratoria dotyczą wykrywania i reakcji na kolizję gracza z elementami świata.

    Wykrywanie kolizji jest rzeczą zupełnie odrębną od renderowania sceny. Wymaga własnoręcznego zaimplementowania całego mechanizmu: przechowywania informacji o obiektach (bryłach na potrzeby wykrywania kolizji - nie muszą wcale pokrywać się z tym, co jest rysowane!), algorytmów wykrywania czy zaistniała pomiędzy obiektami kolizja (obliczenia matematyczne), oraz algorytmów służących do uzyskania pożądanej reakcji na zaistniałe kolizje (zmiana kierunku ruchu, wybuch, uszkodzenie, zdobycie punktów...).

    OpenGL nie służy do wykrywania kolizji, nie będzie tutaj pomocny. Wykrywanie kolizji należy napisać własnoręcznie.

    Prezentowana tutaj przykładowa implementacja powinna służyć jako inspiracja. Zamiast zwyczajnie kopiować ją do swojego projektu, należy ją przeanalizować, dostosować do swojej gry, udoskonalić.

    Elipsoida

    Gracz jest reprezentowany przez elipsoidę. Jest to o tyle wdzięczna bryła, że za pomocą prostej transformacji przestrzeni świata możemy doprowadzić do sytuacji, w której elipsoida staje się kulą o promieniu długości 1. Wówczas wszelkie obliczenia stają się dużo prostsze, a jednocześnie sama bryła (po powrocie do pierwotnej przestrzeni) wciąż pozwala nam na przybliżenie gracza w sposób "wydłużony" w pionie, co jest często przydatne w realnych zastosowaniach. Dodatkowo, kształt ułatwia "wspinanie się" po niewielkich przeszkodach, schodach i pochyłych powierzchniach.

    Elipsoidę definiujemy za pomocą długości trzech promieni, odpowiadających kolejno osiom układu współrzędnych (w wersji przykładowej - współrzędnych świata, nieobracających się wraz z graczem, przez co Rx i Rz powinny być równe).

    Przykładowy projekt

    Projekt (GKiW_Lab6) przedstawia implementację systemu dynamicznego wykrywania kolizji elipsoidy z wielokątami (w załączonej scenie - z czworokątami). Jest to w niewielkim stopniu zmodyfikowana implementacja techniki opisanej przez Fauerby'ego (Improved Collision detection and Response). Gracz ma możliwość swobodnego poruszania się po terenie ograniczonym ścianami. Może też wspiąć się na niewielką przeszkodę.

    Użycie tej implementacji obsługi kolizji w swojej grze będzie skutkować bardzo wnikliwymi pytaniami nt. sposobu jej działania, które padną podczas oddawania projektu. To nie jest gotowe rozwiązanie, tylko przykład!

    Sposób reakcji na kolizje jest niedoskonały. Praktycznie we wszystkich grach stosuje się w tym obszarze różnego rodzaju uproszczenia i hacki, jak np. każdorazowe odsuwanie o stały offset od powierzchni ściany. Zachęcam do podjęcia próby rozwinięcia całego algorytmu tak, aby reakcje były pozbawione nieprzyjemnego skakania przy jednoczesnym braku możliwości napotkania tzw. efektu tunelowania, czyli niepoprawnego przechodzenia przez przeszkody (przy odpowiednim rozmachu i uniwersalności zaproponowanego rozwiązania, mogłaby z tego powstać przyzwoita praca inżynierska).

    Cały projekt z racji swojej większej złożoności posiada bardziej rozwiniętą niż dotychczasowo architekturę. Jego struktura opiera się na idei użycia sceny jako podstawowego elementu hierarchii elementów świata oraz wprowadzenia posiadającego wspólny korzeń drzewa klas dla wszystkich elementów świata. Jest to podejście, które daje dużo większą elastyczność kodu i możliwość jego łatwej rozbudowy. Polecam zastosowanie podobnego (lub lepszego) rozwiązania w swoich projektach.

    Materiały

Zasady zaliczenia przedmiotu

Kontakt

mgr inż. Bartosz Bazyluk
bbazyluk@wi.zut.edu.pl
Pokój 322 WI2

Konsultacje

(semestr zimowy 2015/2016)
Piątek P, godz. 14.45-16.15
Środa N, godz. 13.45-15.15
Pok. 322 WI2

Przewiń do...