Projekty zaliczeniowe

Zasady gry
  1. Zadania powinno się wykonywać w grupach dwuosobowych. Dopuszczalne są jednak solówki i grupy trzyosobowe. Grupy trzyosobowe będą oceniane ostrzej.
  2. Tematy zostaną przedstawione na laboratoriach. Do 30 kwietnia 2020 starostowie poszczególnych grup laboratoryjnych (lub osoby wyznaczone) rozdzielą zadania w swoich grupach i prześlą odpowiednie listy do mnie.
  3. W jednej grupie nie może być dwóch zespołów wykonujących ten sam temat.
  4. W czasie sesji zostaną wyznaczone terminy i sala oddawania projektów. Oddanie projektu polega na krótkiej demonstracji i odpowiedzeniu na kilka pytań.
  5. Oddanie projektu po terminie może skończyć się tragicznie.
  6. Przy oddawaniu po terminie należy się liczyć również z trudnościami z dostaniem wpisu (mogę być na urlopie).
  7. Jeżeli zostanie wykryty plagiat, to kończy się to automatycznie wpisaniem oceny niedostatecznej, bez możliwości poprawy.
  8. Środowisko tworzenia projektu jest dowolne tak długo jak nie wymaga się od prowadzącego uruchamiania tego projektu samodzielnie.
  9. W razie wykorzystywania jakiegoś egzotycznego kompilatora/środowiska nie przybiegać do prowadzącego z płaczem że coś nie działa.
  10. Za nie egzotyczne środowiska uznawane są:
    • Linux+gcc we w miarę współczesnej wersji.
    • Visual Studio .NET 2019 lub wcześniejsza.
    • Codeblocks
Wymagania ogólne
  1. Wykorzystanie OpenGL i GLM o ile prowadzący nie wyraził zgody na coś innego.
  2. Scena zawiera kilka (więcej niż 4 i mniej niż nieskończoność) obiektów trójwymiarowych poruszających się niezależnie (choć to ostatnie może zależeć od projektu). W sytuacji gdy z jakiegoś powodu nie pasuje to do projektu należy dogadać się z prowadzącym.
  3. Interakcja z użytkownikiem (np. poruszanie przedmiotem lub kamerą), bądź animacja automatyczna (zależy od projektu). Program nie powinien być statyczny.
  4. Wszystkie obiekty są oteksturowane. Wykorzystano co najmniej dwie różne tekstury.
  5. Scena jest oświetlona z przynajmniej dwóch źródeł światła. Cieniowanie powinno być widoczne, a nie tylko włączone w kodzie.
  6. Nietrywialne modele 3D. Scena nie może składać się tylko z „gotowców” dostarczonych wraz z szkieletem programu do zajęć. Dopuszczalne jest pobranie gotowych modeli z sieci i wykorzystanie gotowej biblioteki do wczytania pliku z modelem. Kod rysujący dany model musi być jednak autorstwa studentów.
Co wolno
  1. Wykorzystywać dowolne biblioteki zewnętrzne nie związane z grafiką komputerową.
  2. Wykorzystywać modele ściągnięte z sieci.
  3. Wykorzystywać dodatkowe programy do modelowania – dowolne.
  4. Wykorzystywać istniejące biblioteki do wczytania modeli i plików graficznych. Każdą inną bibliotekę związaną w jakikolwiek sposób z grafiką komputerową należy konsultować z wykładowcą.
Czego nie wolno
  1. Wykorzystywać gotowych procedur rysujących. Cały kod rysujący musi być waszego autorstwa i znany na wylot.
  2. Używać koloru różowego
  3. Wykorzystywać cudzych prac.
  4. Indeks poleceń zakazanych:
    • glBegin, glEnd – zamiast tego nalezy używać glDrawArrays/glDrawElements
    • glVertex, glNormal, glTexCoord – zamiast tego nalezy używać glDrawArrays/glDrawElements
    • glRotate, glTranslate, glScale – zamiast tego nalezy używać procedur rotate/translate/scale z biblioteki GLM
    • gluLookat – zamiast tego nalezy używać procedury lookAt z biblioteki GLM
    • glFrustum, gluPerspective, glOrtho – zamiast tego należy uzywać procedur frustum/perspective/ortho z bibioteki GLM
    • glCreateList, glDeleteList, glCallList – zamiast tego nalezy używać glDrawArrays/glDrawElements
    • glPushMatrix, glPopMatrix – zamiast tego nalezy używać dowolnych struktur danych przechowujących obiekty mat4 z biblioteki GLM
    • glVertexPointer, glNormalPointer, glTexCoordPointer, glColorPointer – zamiast tego używać glVertexAttribPointer
    • glEnableClientState, glDisableClientState – zamiast tego używać glEnableVertexAttribArray/glDisableVertexAttribArray
Ogólne reguły oceniania projektów
  1. Nie da się wszystkiego przewidzieć i dlatego każdy przypadek będzie rozważany indywidualnie, ale ogólne reguły są następujące. Początkowa ocena 2.0…., a potem:
    • Wykorzystanie nietrywialnych modeli (najlepiej odczytanych z pliku): +0.5 do oceny
    • Poprawne zarządzanie obiektami na scenie (poprawne poruszanie i dobre wykorzystanie kamery): +0.5 do oceny
    • Poprawne oteksturowanie obiektów i ocieniowanie obiektów oraz poprawne wykorzystanie mechanizmów OpenGL do rysowania: +1.0 do oceny.
    • Umiejętność odpowiedzi na zadawane pytania: +1.0 do oceny. Uwaga! Nie znaczy to że można kupić projekt i dostać 4.0! W razie wykrycia takiej sytuacji „but”.
  2. W przypadku grupy trzyosobowej prowadzący będzie upierdliwy jak w sierżant wojsku. Poza tym reguły oceniania takie same.
  3. Projekty specjalne są specjalne a zatem powyższe reguły się nie liczą zupełnie. Ocena jest wystawiana całkowicie na podstawie rozmowy przy oddawaniu projektu.
Tematy zwykłe
Prócz tematów na poniższej liście można wymyślić i zaimplementować własny temat tak długo jak będzie on najpierw skonsultowany z prowadzącym i wyrazi on nań zgodę. Temat musi zapewniać możliwość spełnienia wyżej opisanych warunków.
  1. Rollercoaster. Symulacja Rollercoastera z możliwością umieszczenia kamery w wagoniku, bądź na zewnątrz.
  2. Statek. Statek pływający po morzu. Możliwe statki do wyboru to: galera (animowane wiosła), statek parowy (dym z komina – system cząstek, obracające się koło napędowe), żaglowiec (zmieniający się wiatr powodujący odpowiednią reakcję żagla – obrót i „wydęcie” albo „oklapnięcie” materiału żagla). Animacja wody.
  3. Dekorator wnętrz. Wizualizacja umeblowania pomieszczenia na podstawie pliku opisującego położenie mebli; biblioteka mebli predefiniowanych.
  4. Trójwymiarowy odtwarzacz partii szachowej. Przebieg partii odczytywany jest z pliku; położenie obserwatora zmieniane przez użytkownika. Przykładowym formatem opisującym przebieg partii szachowej jest PGN. Jeżeli ktoś jest masochistą to może implementować parser PGN, ale sugerowałbym jakiś łatwiejszy format (może być nawet własny).
  5. Trójwymiarowy odtwarzacz gry w GO. Przebieg partii odczytywany jest z pliku z pliku SGF; położenie obserwatora zmieniane przez użytkownika. Ponieważ sceny w przypadku niniejszego projektu są mniej skomplikowane niż w przypadku szachów, należy położyć większy nacisk na efekty specjalne, np.: odbicia żetonów na planszy, animacja przebiegu gry (np. stawiany żeton spada z „nieba”) itd.
  6. Symulator lotu. Lot powinien odbywać się ponad trójwymiarowym miastem; start, przelot i lądowanie; wykrywanie kolizji.
  7. Symulator jazdy samochodem/motocyklem. Predefiniowany tor wyścigowy; automatyczni przeciwnicy; wykrywanie kolizji.
  8. Trójwymiarowy Windows Explorer. Graficzny interfejs użytkownika do systemu plików.
  9. Zegar mechaniczny. 2 koła zębate, wahadło, wskazówki; synchronizacja elementów mechanicznych, m.in. kół zębatych.
  10. Cyborg. Sterowany z klawiatury, spacerujący model człowieka; 10 elementów ruchomych (przedramię z dłonią, ramię, głowa, tułów, itd.)
  11. Symulator pracy silnika czterosuwowego. Widoczne ruchome tłoki, zawory i wał korbowy.
  12. Animowany model parowozu. Obrotowe koła ze szprychami, maszyna parowa.
  13. Microcosmos. Modele owadów samodzielnie poruszających się w zamkniętym pomieszczeniu; 6 ruchomych nóg, tułów z detalami; owady zawracają po kolizji ze ścianą lub innym owadem.
  14. Wirtualne muzeum sztuki. 4 sale połączone przejściami, na ścianach wiszą obrazy, użytkownik poruszany z klawiatury, animowane uproszczone modele innych zwiedzających.
  15. Trójwymiarowa wersja gry: Tower Defence. Klasyczny Tower Defence w dowolnym wariancie. Wrogowie i wieżyczki powinny być modelami 3D. Poszczególne strzały mogą być np. źródłami światła. Teren może być pofałdowany ze wzgórzami i dolinami dając możliwość omijania strzał z wierz wrogom i zwiększając zasięg wierz będących na wzgórzach.
  16. Wirtualna szkoła. Program powinien pozwalać się na poruszanie po wirtualnej szkole. Po szkole powinni chodzić uczniowie i nauczyciele.
  17. Wirtualna galeria alkoholi. Program powinien pozwalać na poruszanie się po galerii alkoholi, jak również wybranie kilku butelek i napicie się z nich. W miarę picia poruszanie się powinno być utrudnione i powinny pojawiać się zaburzenia wzroku. Generowanie fraktali jest opcjonalne ;)
  18. Wirtualna świątynia grecka. Program powinien pozwalać na poruszanie się po świątyni wzorowanej np. na Akropolu. Po świątyni poruszamy się nie jako latająca kamera, ale jak człowiek (tak jak w grach FPS).
  19. Wirtualna katedra gotycka. Program powinien pozwalać na poruszanie się po gotyckiej katedrze np. Notre-Dame. Po katedrze poruszamy się nie jako latająca kamera, ale jak człowiek (tak jak w grach FPS). Informacje nt. stylu gotyckiego można znaleźć tutaj.
  20. Wirtualny zamek. Program powinien pozwalać na poruszanie się po wirtualnym średniowiecznym zamku. Na scenie mogą znaleźć się na przykład: fosa, most zwodzony (którym można sterować), wieże z flagami (opcjonalnie powiewającymi na wietrze), koszary z łóżkami dla żołnieży, główny budynek z wystrojem średniowiecznym np. miecza i toporami wiszącymi na scianach, albo stojącymi zbrojami. Można również umieścić kury biegające po scenie, albo rycerzy chodzących po murach, konie stojące w stajni.
  21. Symulacja kulki. Kulka staczająca się po wzgórzach wygenerowanych za pomocą funkcji matematycznej, bądź fraktala „plasma”. Generacji fraktala nie trzeba implementować. Można wygenerować w jakimś programie i wykorzystać plik graficzny. Kulkę można upuścić w dowolnym miejscu. Można upuścić na raz więcej niż jedną kulkę. Opcjonalnie można zaimplementować interakcję pomiędzy kulkami (detekcję kolizji i odbicia). Warto poczytać o silniku do symulacji fizycznych ODE.
  22. Symulacja rosnącego drzewa. Program pokazujący rosnące drzewo. Drzewo powinno rosnąć w sposób losowy (każde kolejne wykonanie programu daje inny wynik). Rosnące drzewo powinno dać się obejrzeć z dowolnego punktu sceny. Opcjonalnie można uwględnienić wiatr przy animacji drzewa.
  23. Trójwymiarowy wodospad. Trójwymiarowy model wodospadu, w którym rzeczywiście „płynie woda”. Do symulacji wody można wykorzystać system cząstek. Scenę powinno dać się oglądać z dowolnego punktu.
  24. Robot. Należy napisać program, który pokazuje chodzącego robota. Kamerę powinno dać się przesuwać. Można również przejąć kontrolę nad robotem, jeśli ma się na to ochotę. W przeciwnym wypadku robotem steruje komputer. Robot ma wyglądać podobnie do maszyn atakujących bazę rebeliantów na początku „Imperium kontratakuje”, czyli ma się poruszać na czterech nogach.
  25. Akwarium. Animowane akwarium, inspirowane znanym wygaszaczem ekranu, z pływającymi rybami i falującymi roślinami. Akwarium powinno się dać oglądać z dowolnego punktu sceny.
  26. Danse macabre. Tańczący szkielet (model, w formacie Blendera). Szkielet powinien tańczyć na podłodze, prócz tego powinno po scenie poruszać się kilka różnokolorowych świateł (np. stożkowych) (coś a’la dyskoteka ;)).
  27. Wulkan. Trójwymiarowy, eksplodujący wulkan. Na scenie powinien znajdować się trójwymiarowy wulkan, którego co chwila wydobywa się lawa, dym i kamienie. Do lawy i dymu można użyć systemu cząstek. Scenę powinno dać się oglądać z dowolnego punktu. Eksplozji powinny również towarzyszyć odpowiednie efekty świetlne.
  28. Symulator szybowca Latanie szybowcem ponad terenem górskim. Teren powinien być stworzony na podstawie mapy wysokości wygenerowanej np. fraktalem plasma. Po scenie powinny poruszać się inne szybowce, ptaki itp. Detekcja kolizji (można się rozbić o teren).
  29. Katakumby Skomplikowany labirynt trójwymiarowy w którym można się poruszać na zasadzie znanej z gier FPS np. Doom. Możliwość poruszania się we wszystkich trzech wymiarach (schody, mosty, przepaście itp.).
  30. Symulacja gazu doskonałego Cząstki pokryte teksturą. Tekstura powinna być proceduralna i jej wygląd powinien zależeć od parametrów modelu fizycznego (ciśnienie temperatura itp.). Np. dla niskich temperatur dominują kolory zimne – np. błękitny, niebieski, dla wysokich temperatur barwy ciepłe (czerwień, żółć). Prócz koloru, tekstura ta może zależęć od innych parametrów np. dla cząstek szybko się poruszających tekstura składay się z zygzakowatych różnokolorowych pasków, podczas gdy np. dla wolnych cząstek z plam różych kolorów, z płynnym przejściem pomiędzy tymi kolorami. Dodatkowo model powinien uwzględniać wpuszczenie do środowiska nowych cząstek o innej temperaturze niż otoczenia i pokazania przepływu energii pomiędzy tymi cząstkami – po zderzeniu cząstki dzielą się energią i w rezultacie otrzymują nowe prędkości i temperatury.
  31. Skakanie po dachach Prosta zabawa zainspirowana filmem „Matrix” („Każdy spada za pierwszym razem” ;)). Szaleniec biegający po dachach wieżowców i skaczący z jednego dachu na drugi.
  32. Pianino Pianino na którym można naciskać klawisze, oraz oglądać działanie wewnątrz (młoteczki uderzające w struny). Możliwość otwarcia i zamknięcia pianina.
  33. Symulator czołgu Model czołgu którym można jeździć po terenie. Możliwość obracania wieżyczką i lufą oraz strzału (systemy cząstek).
  34. Trójwymiarowa wersja gry: „5 kulek w linii” W oryginalnej wersji gry dana jest plansza o wymiarach NxN (od N zalezy stopień trudności gry). W każdym kolejnym kroku gry na planszy pojawia się w losowych miejscach kilka różnych „pionków” np. kulek. Następnie można przesunąć jeden z tych pionków w dowolne miejsce pod warunkiem, że żaden inny pionek nie stoi na drodze. Jeżeli ułoży się 5 takich samych kulek w jednej linii, to te kulki znikają. Chodzi o to, żeby usunąć jak najwięcej kulek. Sposób przeniesienia w 3 wymiar pozostawiamy studentowi.
  35. Trójwymiarowa wersja gry: „Jumping Jack”. Na planszy gry znajduje się kilka platform, jedna nad drugą. W każdej platformie znajdują się dziury (które się przesuwają). Celem jest dostać się na najwyższą platformę skacząc poprzez dziury do góry. Jeżeli nie ucieknie się od dziury to spada się platformę niżej i traci zdrowie. Zdrowie może odebrać również stworek latający po całej planszy. Próba skoku do góry, kiedy na głową nie ma dziury kończy się utratą punktów zdrowia. Przykładowy gameplay znajduje się pod niniejszym adresem: https://www.youtube.com/watch?v=Ai-ocyGR_LQ. Sposób przeniesienia gry w 3 wymiar pozostawiamy studentowi.
  36. Trójwymiarowa wersja gry: „Manic Miner”. Typowa gra platformowa. Poruszamy się po planszy uciekając przed potworkami szukając kluczy. Po zebraniu kluczy otwiera się przejście do następnej planszy. Krótki opis gry, wraz z darmową wersją mozna znaleźć pod niniejszym adresem: http://www.xmixdrix.com/manicminer. Sposób przeniesienia gry w 3 wymiar pozostawiamy studentowi.
  37. Trójwymiarowa wersja gry: „Pipe”. Na planszy w kształcie prostokąta znajdują się kawałki rur. Kawałki te mozna jedynie obracać. Należy tak je poobracać, aby woda ze źródła na środku ekranu dotarła do każdej rury. Krótki opis gry, oraz samą grę można znaleźć na stronie http://home.earthlink.net/~tdglenn/unicorn/pipegame.htm. Sposób przeniesienia gry w 3 wymiar pozostawiamy studentowi.
  38. Trójwymiarowa wersja gry: „Pacman”. Pacman jak stoi każdy widzi. Poruszasz się po labiryncie zbierając „cukierki” i uciekając przed potworami. Oryginalną grę (a w zasadzie flashowy remake oryginału) można zobaczyć na stronie http://www.thepcmanwebsite.com/media/pacman_flash/. Sposób przeniesienia gry w 3 wymiar pozostawiamy studentowi.
  39. Trójwymiarowa wersja gry: „Tetris”. Propagandowa gra pochodząca z płynącej miodem i winem krainy zza Buga. W wersji trójwymiarowej klocki powinny być bardziej skomplikowane i rozciągać się w 3 wymiarach. Zamiast wierszy powinno się układać płaszczyzny, a widok zamiast z boku, powinien być z góry.
  40. Trójwymiarowa wersja gry: „Flipper”. Gra w której po planszy toczy się piłeczka, którą odbija się za pomocą dwóch ramion. Nazywana również „Pinball”. Sposób przeniesienia gry w 3 wymiar pozostawiamy studentowi.
  41. Trójwymiarowa wersja gry: „Doom”. Dla wszystkich, którzy chcą się tutaj pośmiać ;) – oryginalny DOOM (podobnie jak DOOM2 i Hexen) miał 2 wymiarową mapę, w której dodatkowo definiowano wysokości poszczególnych obszarów. W rezultacie nie można było zbudować np. mostów (czegokolwiek, gdzie gracz mógł znajdować się w tym samym miejscu na różnych wysokościach). W niniejszym projekcie chodzi przede wszystkim o stworzenie gry typu FPS. Im bardziej skomplikowane plansze tym lepiej, ale nacisk powinien być raczej położony na mozliwość grania – przeciwnicy do których można strzelać i którzy odpowiadają ogniem. Skomplikowanie planszy jest mniej obowiązkowe.
  42. Trójwymiarowa wersja gry: „Parkowanie ciężarówki”. Dany jest plac z przeszkodami. Po placu można poruszać się ciężarówką – tirem z jedną albo dwoma przyczepami. Należy omijając wszystkie przeszkody zaparkować w wyznaczonym miejscu. W trójwymiarowej wersji gry powinna być możliwość patrzenia na plac z dowolnego miejsca (w oryginalnej grze patrzało się na plac z góry).
  43. Trójwymiarowa wersja gry: „Asteroidy”. Po ekranie latają asteroidy. Mamy stateczek obracający się o 360 stopni, który może latać po całym ekranie. Poruszanie jest zgodne z zasadami bezwładności. Stateczek może strzelać do asteroidów. Trafiony asteroid rozbija się na kilka mniejszych. Te mniejsze na kilka jeszcze mniejszych. Dopiero najmniejsze niszczone są całkowicie. Celem gry jest zniszczenie wszystkich asteroidów na ekranie. Opcjonalnie dodanie obsługi wielu „żyć” i wielu poziomów. Sposób przeniesienia gry w 3 wymiar pozostawiamy studentowi.
  44. Trójwymiarowa wersja gry: „Arkanoid”. Plansza gry składa się z:
    • paletki na dole ekranu, którą można się przemieszczać na lewo i prawo
    • niewielkich prostokątnych bloków z których może być złożona jakaś figura
    • piłki, która odbija się od paletki i od bloków.
    Każdy blok może wytrzymać określoną liczbę trafień piłką, po czym znika. Celem gry jest zniszczenie wszystkich bloków. Mamy do dyspozycji kilka piłek. Utrata wszystkich kończy grę. Opcjonalnie można zaimplementować wiele poziomów. Flashową wersję tej gry można zobaczyć pod adresem: http://www.tripletsandus.com/80s/80s_games/arkanoid_s.htm. Sposób przeniesienia gry w 3 wymiar pozostawiamy studentowi.
  45. Trójwymiarowa wersja gry: „Alien Invaders”. Na dole ekranu znajduje się statek, który może się przesuwać w lewo i w prawo. Działka statku skierowane są do góry. Z góry w kierunku statku zbliżają się grupy myśliwców „obcych”, do których należy (oczywiście) strzelać. Celem gry jest zniszczenie wszystkich myśliwców obcych. Opcjonalnie można zaimplementować kilka poziomów i wiele żyć. Przykładową grę można zobaczyć pod adresem http://www.pacxon4u.com/space-invaders/. Sposób przeniesienia gry w 3 wymiar pozostawiamy studentowi.
  46. Trójwymiarowa wersja gry: „Sokoban”. Dana jest plansza reprezentująca magazyn, w którym rozmieszczone są skrzynie. Gracz, który może jedynie popychać te skrzynie musi je umieścić w odpowiednich miejscach. Przykładową implementację gry można zobaczyć pod niniejszym adresem: http://www.game-sokoban.com/. Sposób przeniesienia w 3 wymiar pozostawiamy studentowi.
  47. Trójwymiarowa wersja gry: „Worms”. Na trójwymiarowej scenie powinien znajdować się pofałdowany teren, po którym mogą poruszać się „robaki”. Każdy robak posiada bazookę z której może strzelać. Lot pocisku powinien być zgodny z prawami fizyki i uwzględniać: kąt wystrzału, prędkość początkową, grawitację i wiatr. Każdy gracz ma jednego robaka. Robak trafiony pociskiem traci zdrowie, a po kilku trafieniach ginie. Opcjonalnie można zaimplementować sztuczną inteligencję i niszczenie terenu po trafieniu pociskiem. Trafieniu powinny towarzyszyć efekty świetlne i opcjonalnie eksplozja (systemy cząstek). Aby ominąć problemy z prawami autorskimi można zastąpić robaki inną zwierzyną.
  48. Trójwymiarowa wersja gry: „Lost islands”. Postać porusza się po planszy złożonej z kwadratów zbierając skarby. Po każdym kwadracie można przejść tylko określoną liczbę razy, po czym pole to „zapada się” zabijąc gracza przy okazji. Sposób przeniesienia w trzeci wymiar pozostawiamy studentowi.
  49. Trójwymiarowa wersja gry: „Snake”. Po planszy porusza się wąż i zjada „jabłka”. Po zjedzeniu jabłka wąż się robi coraz dłuższy. Wąż nie może się zatrzymać i tylko może zmieniać kierunek poruszania się. Kiedy zderzy się sam ze sobą ginie.
  50. Worm Rider. Program inspirowany grą/książkami/filmami „Diuna”. Gracz jeździ po pustyni na wielkim robaku. Można dorobić jakieś przeszkody albo atakujących wrogów, których można zestrzelić lub staranować. Wygląd jazdy na robaku można wzorować na: grze Dune.
Tematy specjalne
Tematy specjalne wymagają poświęcenia dodatkowego czasu na douczenie się dodatkowych tematów we własnym zakresie. Nagroda obecnie jeszcze nie jest ustalona i może się okazać, że jedyną nagrodą jest satysfakcja ;). Ideą tematów specjalnych jest zaproponowanie własnego tematu wybiegającego poza zakres omawiany na zajęciach. Poniżej wymieniono kilka tematów specjalnych, które realizowano w poprzednich latach. Należy je traktować jako przykład stopnia trudności. Konieczne jest jednak wymyślenie czegoś nowego.
  1. Optymalizator siatki (1 osoba) Z pliku 3d o zadanym formacie wczytywany jest model 3d. Model ten powinien być następnie uproszczony poprzez usunięcie nadmiarowych wierzchołków i ewentualne zastąpienie ich innymi. Program powinien również zawierać wizualizację wyników.
  2. Generator łańcuchów trójkątów (1 osoba) Szybkość rysowania modeli 3d można optymalizować łącząc trójkąty składające się na model w „łańcuchy”. Łańcuchy te składają się z trójkątów, z których każdy kolejny ma jeden bok wspólny (a zatem dwa wierzchołki) z poprzednim. Aby zatem narysować kolejny trójkąt w łańcuchu wystarczy podać jeden wierzchołek, a nie trzy, jakby to było w sytuacji gdyby trójkąty nie były połączone w łańcuchy. Istnieją algorytmy heurystyczne, które łączą trójkąty w zadanym modelu w możliwie długie łańcuchy. Projekt polega na implementacji takiego algorytmu.
  3. Implementacja techniki „oszustów” (2-3 osoby) Technika ta polega na zastepowaniu odleglych modeli przez odpowiednie prostokąty, pokryte teksturą na ktorą wyrenderowano te własnie odległe modele. Dla dużych scen z duzą liczbą statycznych modeli pozwala to na znaczne skrócenie czasu generowania sceny, przy niewielkim jedynie pogorszeniu jej jakości. Gdy kamera sie zbliza do takiego prostokątu w pewnym momecie trzeba zamiast niego renderować oryginalne modele, tak by to oszustwo bylo jak najmniej widoczne. Jednym z problemów, które należy tutaj rozwiązać, jest ocena kiedy odswieżyć teksturę oszusta, lub kiedy renderować oryginalne modele. Projekt polega na: implementacji techniki oszustów, zaproponowaniu własnych funkcji oceny, oraz wizualizacji sceny wykorzystującej tą technikę. Warto przeczytać sobie ten artykuł.
  4. Galeria szkła (2 osoby) Używajac języka Cg, lub Glsl, należy stworzyć pomieszczenie, galerię, w której znajdować się będą szyby o różnych kształtach. Zasymuluj refrakcję i refleksy + jako opcja rozproszenie chromatyczne.
  5. Implementacja programu do Raytracingu w egzotycznym środowiku (2 osoby) Wybierz jakieś egzotyczne środowisko uruchomieniowe, np. smartwatch, smartphone, przeglądarka internetowa. Zaimplementuj w tym środowisku prosty algorytm do raytracingu. Uwzględniane powinny być: światło otoczenia, światło rozproszone, światło odbite (oba rodzaje) i opcjonalnie światło załamane. Schemat klas powinien być tak zaprojektowany, aby możliwe było w przyszłości rozszerzanie funkcjonalności tej aplikacji (np. o nowe kształty obiektów, bardziej skomplikowane modele oświetlenia itp.).
  6. Inverse Kinematics (2 osoby) Kinematyka odwrotna jest metodą pozwalającą na ustalanie przestrzennego ułożenia hierarchicznych modeli 2d i 3d, na podstawie pożądanego ułożenia niektórych z części tego modelu (patrz: http://en.wikipedia.org/wiki/Inverse_kinematics, http://cg.skeelogy.com/projects-IK.php). W wyniku projektu ma powstać: raport opisujący problem i użyty algorytm rozwiązania oraz aplikacja pozwalająca na animację ręki robota (przedramię, ramię, dłoń, 5 palców) poprzez wybieranie palca, oraz punktu, który ma być przez ten palec dotknięty. Program powinien obliczać kilka stanów pośrednich pomiędzy stanem początkowym a końcowym, aby możliwe było wyświetlenie animacji.