Wyświetlanie obrazu Bufor klatki, synchronizacja pionowa, pętla główna gry.

Transkrypt

1 Wyświetlanie obrazu Bufor klatki, synchronizacja pionowa, pętla główna gry. Gry komputerowe, Informatyka S1, II Rok, 2018 r.

2 WYŚWIETLACZE WEKTOROWE Korzystając z możliwości odchylania wiązki elektronów, możliwe jest utworzenie na warstwie luminoforu dowolnego kształtu. W latach 80 wiele automatów do gier oferowało ten sposób wyświetlania. Źródło obrazu: Atari Przykład: Battlezone (1980), uznawana za pierwszą grę oferującą środowisko 3D. 2

3 WYŚWIETLACZE RASTROWE CRT Z uwagi na własności luminoforu, emituje on światło jedynie przez krótką chwilę. Każdy punkt obrazu musi więc być cyklicznie pobudzany. Od momentu pobudzenia będzie stopniowo wygasać. Wyświetlacze CRT (kineskopowe) Sposób odświeżania całego rastra: odchylanie pionowe (m. cz.) służące do przechodzenia kolejnych wierszy i odchylanie poziomie (w. cz.) do przechodzenia kolumn w obrębie każdego z wierszy Zdjęcie obrazu wyświetlanego na ekranie CRT, wykonane z bardzo krótkim czasem otwarcia migawki: Źródła obrazów: Wikipedia 3

4 WYŚWIETLANIE OBRAZU Współczesne wyświetlacze komputerowe traktują obraz jako raster Wyświetlacze działają ze stałą częstotliwością odświeżania (dawniej odchylania pionowego) Najczęściej spotykaną częstotliwością odświeżania jest obecnie 60Hz Dla obrazu stereoskopowego, będzie to dwa razy więcej Progresywne wyświetlanie klatki: 1/60s Źródło obrazu: 4

5 WYŚWIETLANIE KLATEK Karta graficzna odpowiada za przygotowanie zawartości klatki, przechowywanie jej i wysłanie do monitora gdy ten będzie gotowy wyświetlić kolejną klatkę Obraz do wyświetlenia przechowywany jest w buforze klatki Proces generowania zawartości bufora klatki i proces przesyłania jej do wyświetlacza są niezależne Program Renderowanie Bufor klatki Wyświetlanie KARTA GRAFICZNA 5

6 WYŚWIETLANIE OBRAZU Komponowanie zawartości bufora klatki nie jest natychmiastowe. W grafice czasu rzeczywistego elementy sceny renderowane są jeden po drugim. Zatem dopóki nie zakończy się renderowanie wszystkich elementów sceny, bufor klatki może zawierać nieukończony obraz. Aby uniknąć migotania obrazu podczas jego przerysowywania gdy występuje konieczność jego akutalizacji, stosuje się technikę podwójnego buforowania (ang. double buffering) Mamy wówczas dwa bufory klatki: Bufor "przedni" (ang. front buffer) Bufor "tylny" (ang. back buffer) Jest wyświetlany Jest aktualizowany Gdy zakończy się aktualizacja back buffera, zamieniane są one miejscami (ang. buffer swap) Użycie podwójnego buforowania rozwiązuje ten problem. Dopóki nowa klatka nie zostanie ukończona, wyświetlana będzie poprzednia klatka. Front Front Back 6

7 WYŚWIETLANIE OBRAZU Komponowanie zawartości bufora klatki nie jest natychmiastowe. W grafice czasu rzeczywistego elementy sceny renderowane są jeden po drugim. Zatem dopóki nie zakończy się renderowanie wszystkich elementów sceny, bufor klatki może zawierać nieukończony obraz. Aby uniknąć migotania obrazu podczas jego przerysowywania gdy występuje konieczność jego akutalizacji, stosuje się technikę podwójnego buforowania (ang. double buffering) Mamy wówczas dwa bufory klatki: Bufor "przedni" (ang. front buffer) Bufor "tylny" (ang. back buffer) Jest wyświetlany Jest aktualizowany Gdy zakończy się aktualizacja back buffera, zamieniane są one miejscami (ang. buffer swap) Użycie podwójnego buforowania rozwiązuje ten problem. Dopóki nowa klatka nie zostanie ukończona, wyświetlana będzie poprzednia klatka. Back Front Front 7

8 WYŚWIETLANIE OBRAZU Dla zachowania wrażenia płynności wyświetlanego ruchomego obrazu, należy upewnić się że kolejne klatki animacji będą docierać do monitora, gdy ten będzie gotowy je wyświetlić W tym celu stosuje się tzw. synchronizację pionową (ang. vertical synchronisation / VSync) Sterownik karty graficznej lub program czeka z zamianą buforów, aż monitor będzie gotowy wyświetlić kolejną klatkę W innym wypadku pomimo sprzętowej możliwości wygenerowania nawet większej liczby klatek na sekundę niż wyświetla monitor, obraz nie będzie płynny Artefakt nazywany tearing, wyświetlany obraz składający się z więcej niż jednej klatki 8

9 WYŚWIETLANIE OBRAZU Dla wyświetlaczy oferujących wyższą częstotliwość odświeżania ekranu niż 60Hz, czas cyklu będzie krótszy niż 1/60s. czas renderowania jednej klatki cykl odświeżenia obrazu na wyświetlaczu VSync Off max FPS swap interval = 0 Procesor graficzny czekając na gotowość wyświetlacza nie musi wykonywać operacji, podczas gdy bez użycia synchronizacji od razu zaczynałby renderować kolejną klatkę. VSync On swap interval = 1 VSync On swap interval = 2 (sleep) (sleep) (sleep) 1/60s Użycie synchronizacji pionowej może więc też prowadzić do zmniejszenia zużycia energii. (sleep) 60 FPS (sleep) 30 FPS 1/60s czas 9

10 WYŚWIETLANIE OBRAZU Synchronizacja pionowa wyłączona Synchronizacja pionowa włączona Artefakt tego rodzaju nazywa się często ang. słowem tearing. 10

11 WYŚWIETLANIE OBRAZU Technologia NVIDIA G-Sync Synchronizacja wyświetlacza z kartą graficzną czyli podejście odwrotne Wyświetlacz ma adaptacyjną częstotliwość odświeżania, dostosowującą się do aktualnej liczby klatek na sekundę Zakres Hz, zależnie od sprzętu Podejście wbrew pozorom nie jest nowe, podobne rozwiązanie Adaptive Sync jest częścią standardu DisplayPort 1.2a zaimplementowane choćby przez AMD w ich FreeSync; różnice: G-Sync duplikuje klatki gdy ich częstotliwość poniżej minimum G-Sync zapobiega nadpisywaniu klatek Źródło obrazu: NVIDIA 11

12 GAME LOOP Nieskończona pętla Warunkiem stopu jest wystąpienie żądania zakończenia działania programu Postać podstawowej wersji pętli: while (użytkownik nie chce wyjść) { sprawdź urządzenia wejścia; wykonaj zadania AI; przemieść przeciwników; sprawdź kolizje; renderuj świat; odtwórz dźwięki; prześlij dane do serwera;... } 12

13 GAME LOOP W dalszych rozważaniach przyjmiemy uproszczenie, że podstawowy game loop ma postać: while (użytkownik nie chce wyjść) { aktualizuj stan gry; renderuj świat gry; } Zatem zdefiniujmy następujące określenia: Aktualizacja stanu gry Wszystkie operacje wpływające na stan świata, wynik rozgrywki, pozycję obiektów, obsługa wejścia i zdarzeń,... Renderowanie świata gry Wybór obiektów do renderowania, wyznaczenie ich macierzy przekształceń, zlecenie renderowania karcie graficznej, zamiana buforów,... 13

14 GAME LOOP Najprostsza forma: IMPLEMENTACJE while (użytkownik nie chce wyjść) { aktualizuj stan gry; renderuj świat gry; } Podstawowy game loop Aktualizacja występuje ze stałym krokiem. Absolutnie nie jest to podejście zalecane! Zalety: Prostota (?) Problemy: Szybkość rozgrywki zależna od wydajności sprzętu Szybkość rozgrywki może się zmieniać w trakcie gry 14

15 GAME LOOP IMPLEMENTACJE Stały krok gry Podejście może być korzystne w przypadku gier na urządzenia mobilne. Może bowiem redukować zużycie energii. Określamy, co ile czasu ma wykonać się aktualizacja stanu gry. Każda aktualizacja stanu zawsze oznacza następujące po nim renderowanie obrazu. Zalety: Stałe tempo gry (o ile wystarczający sprzęt) Oszczędność baterii Problemy: Sprzęt nie daje rady osiągnąć tyle FPS => gra zwalnia. Wydajny sprzęt => i tak mamy tyle FPS, co update'ów. 15

16 GAME LOOP IMPLEMENTACJE Krok gry uzależniony od FPS Pozwalamy na renderowanie tak szybko, jak to jest możliwe. Każdemu renderowaniu towarzyszy aktualizacja stanu ze zmiennym krokiem. Podejście na pierwszy rzut oka bardzo dobre, ale ma istotne słabe strony. Zalety: Maksymalna liczba FPS Problemy: Niedeterminizm rozgrywki Konieczność aktualizacji zależnej od zmiennego czynnika 16

17 GAME LOOP IMPLEMENTACJE Stały krok gry i maksimum FPS Podejście w podstawowej postaci prowadzi do marnowania mocy obliczeniowej. Rozwinięcie koncepcji stałego kroku aktualizacji Jeśli mamy opóźnienie, to wykonujemy dodatkową aktualizację ze stałym krokiem żeby nadrobić stratę. Zalety: Jeśli mamy jeszcze czas do zaplanowanej, następnej aktualizacji, to renderujemy dodatkową klatkę. Rozwiązuje problem wpływu długiego czasu renderowania na częstotliwość aktualizacji. Eliminuje zbędne oczekiwanie (czasem to minus). Problemy: Jeśli mamy odpowiednio wydajny sprzęt, renderujemy wiele takich samych klatek. 17

18 GAME LOOP IMPLEMENTACJE Stały krok gry i maksimum FPS + interpolacja Aby nie renderować identycznych klatek pomiędzy aktualizacjami, można dokonać interpolacji. Wprowadza opóźnienie o wielkości jednego cyklu. Innym, pokrewnym podejściem jest predykcja. Szczególnie dla wartości kontrolowanych przez gracza może wywołać niepożądane efekty. Podejście zalecane dla jednowątkowej architektury. Zalety: Stały krok aktualizacji, maksimum FPS. Każda klatka jest inna. Problemy: Nieznaczne opóźnienie. 18

19 GAME LOOP IMPLEMENTACJE Zrównoleglony game loop Rozdzielenie aktualizacji i renderowania na dwa osobne wątki, które mogą być wykonywane równolegle przez np. procesor wielordzeniowy. Konieczne jest korzystanie z interpolacji bądź predykcji. Schemat w przykładzie jest tutaj uproszczony. Wątków może być znacznie więcej. Zalety: Współbieżne renderowanie i aktualizacja, niezależne od siebie. Stały krok aktualizacji i maksymalna liczba FPS. Problemy: Konieczność uważnego planowania architektury silnika. 19

20 GAME LOOP IMPLEMENTACJE Wielowątkowość w grach możliwości i problemy Nie warto uciekać od wielowątkowości w nowoczesnych silnikach. Współczesny sprzęt daje ogromne możliwości. Należy je wykorzystać. Jeden kontekst OpenGL może w danym momencie być używany tylko przez jeden wątek. Komunikacja CPU -> karta graficzna nie może być traktowana jako możliwa do zrównoleglenia. Można stworzyć kilka kontekstów, które współdzielą dane nie jest to jednak podejście wydajne ani zalecane. Inne możliwości wykorzystania wielowątkowości: Odczyt tekstur i zasobów z dysku odbywający się "w tle". Dysk nie jest urządzeniem pozwalającym na odczyt równoległy (z wyłączeniem macierzy dyskowych i wewnętrznego przetwarzania w dyskach SSD)! Wydajna, zrównoleglona aktualizacja stanu: Obliczenia AI podzielone na kilka wątków. Symulacja fizyki. Systemy cząsteczkowe. Odtwarzanie dźwięku. 20

21 GAME LOOP IMPLEMENTACJE Należy rozważyć przede wszystkim dwa podstawowe podejścia: Użycie w GLUT Implementacja pętli głównej w GLUT (i freeglut) nie należy do elastycznych. Chcąc mieć większą kontrolę nad działaniem pętli głównej warto sięgnąć po inną bibliotekę, np. GLFW. Stały krok aktualizacji i dowolna liczba klatek Ograniczona precyzja timera możliwe przeskoki co sekundę z powodu tego, że 17ms to nie 1/60. Można też uwzględnić "nadganianie" sytuacji gdy od ostatniej aktualizacji świata minie faktycznie znacznie więcej czasu, niż zakładano. // main: gluttimerfunc(17, OnTimer, 0); glutdisplayfunc(onrender); void OnTimer(int id) { gluttimerfunc(17, OnTimer, 0); // aktualizacja świata } void OnRender() { // renderowanie świata } 21

22 GAME LOOP IMPLEMENTACJE Należy rozważyć przede wszystkim dwa podstawowe podejścia: Użycie w GLUT Implementacja pętli głównej w GLUT (i freeglut) nie należy do elastycznych. Chcąc mieć większą kontrolę nad działaniem pętli głównej warto sięgnąć po inną bibliotekę, np. GLFW. Zmienny krok aktualizacji, zależny od liczby klatek Pełna płynność animacji Trzeba uważać na sytuacje, w których z jakiegoś powodu dt jest nienaturalnie duży (warto wtedy rozważyć limit i/lub wykonanie kilku podkroków aby "nadgonić" czas) int lasttime = 0; // main: glutdisplayfunc(onrender); void OnRender() { int currenttime = glutget(glut_elapsed_time); float dt =.001f * (currenttime lasttime); // [s] lasttime = currenttime; // aktualizacja świata z krokiem dt // renderowanie świata } 22

23 Kamera w scenie 3D Pojęcie kamery. Implementacja interaktywnej kamery FPP. Gry komputerowe, Informatyka S1, II Rok, 2018 r.

24 Kamera Jest to wirtualny koncept opisujący sposób oglądania sceny przez obserwatora, dla którego renderujemy obraz Wyróżnia się dwa podstawowe rodzaje rzutowań: Rzut perspektywiczny Rzut prostokątny (ang. orthographic) 24

25 Kamera perspektywiczna Kamera musi być opisana w sposób matematyczny, aby możliwe było uwzględnienie jej cech w procesie renderowania Przede wszystkim musi posiadać zdefiniowane: Pozycję (punkt zaczepienia): p Kierunek widzenia: d d p 25

26 Kamera perspektywiczna Położenie w przestrzeni 3D jest po prostu 3-elementowym wektorem Zmiana położenia powoduje przemieszczenie naszego wirtualnego "aparatu fotograficznego" 26

27 Kamera perspektywiczna Kierunek w przestrzeni 3D również jest 3-elementowym wektorem Kierunek można rozumieć jako wektor leżący na półprostej łączącej punkt zaczepienia z miejscem, na które kamera ma być skierowana Kierunek zwyczajowo przechowuje się jako wektor jednostkowy ( d = 1 ) 27

28 Kamera perspektywiczna To jednak nie wystarczy, aby jednoznacznie określić sposób obserwacji sceny Oba poniższe przykłady zostały wyrenderowane z tego samego miejsca, w tym samym kierunku: 28

29 Kamera perspektywiczna Konieczne jest wprowadzenie dodatkowo wektora pionu (ang. up vector): u Najczęściej jest to (0, 1, 0) jeśli za drugą współrzędną przyjmiemy tę skierowaną ku górze świata u d p 29

30 Kamera perspektywiczna Dodatkowo kamerę określają: Kąt widzenia (najczęściej w stopniach) fov Jego zmiana odpowiada zmianie ogniskowej obiektywu (popularnie zwanej "zoomem" w aparacie fotograficznym) Nie jest tożsamy z przybliżeniem/oddaleniem kamery! Szeroki kąt Wąski kąt (krótka ogniskowa) (długa ogniskowa) 30

31 Kamera perspektywiczna Dodatkowo kamerę określają: Odległość płaszczyzn przycinania: bliskiej n i dalekiej f (ang. near/far clipping plane) Określają, od jakiej do jakiej odległości będzie renderowana scena Ma to związek z precyzją bufora głębokości Im większy zakres odległości jest renderowany, tym większa szansa powstania problemów typu z-fighting wartości powinny zostać dobrane odpowiednio do charakterystyki danej sceny f n 31

32 Test głębokości (ang. depth test) Algorytm malarza (ang. painter's algorithm) Nie jest dokonywany test głębokości Obiekty przykrywają się zgodnie z kolejnością rysowania To, co zostanie narysowane później, zawsze przykryje to, co było narysowane wcześniej Najpierw narysowano fioletowy sześcian Najpierw narysowano niebieski sześcian Źródło obrazu: 32

33 Test głębokości (ang. depth test) Algorytm bufora Z Oprócz bufora koloru, tworzony jest też bufor głębokości (bufor Z) o odpowiadającym mu rozmiarze W buforze Z przechowywane są informacje o odległości od kamery tego fragmentu powierzchni obiektu, któremu odpowiada kolor znajdujący się w tym pikselu w buforze koloru Jeśli w wyniku renderowania kolejnego obiektu sceny okaże się, że w danym pikselu bufora już coś się wcześniej znalazło, wykonywany jest test głębokości: Jeśli odległość od kamery nowego fragmentu powierzchni obiektu jest mniejsza niż wartość w buforze głębokości, to nadpisujemy ją nową wartością i nadpisujemy kolor Bo nowy obiekt jest bliżej kamery, więc przysłania to, co wcześniej było w buforze koloru Jeśli odległość od kamery nowego fragmentu jest większa niż wartość w buforze głębokości, to pomijamy nową wartość Bo wcześniej już narysowaliśmy coś, co przysłania nasz nowy obiekt Źródło obrazu: Wikipedia 33

34 Test głębokości Bufor Z (ang. depth test) Jest jednokanałową mapą bitową, w której każdy na każdy piksel przeznaczono określoną liczbę bitów W związku z tym możliwe jest zapisanie jedynie skończonej liczby różnych wartości odległości od kamery Najczęściej 24 bity lub 32 bity np. wartości całkowite od 0 do Prowadzi to do potencjalnych konfliktów d [m] 0 Źródło obrazu: Wikipedia 34

35 Test głębokości Precyzja bufora Z (ang. depth test) Zbyt mała precyzja prowadzi do konfliktów, które objawiają się artefaktem z-fighting Należy ograniczyć zakres odległości Poprzez użycie płaszczyzn odcinania Stosuje się nieliniowe mapowanie odległości na wartości bufora Z Najczęściej logarytmiczne Większa precyzja dla małych odległości, mniejsza dla dużych Mapowanie liniowe: 0 Źródło obrazu: GeeXLab, JEGX Mapowanie nieliniowe: d [m] 0 d [m] 35

36 Test widoczności (ang. visibility test) Istotny problem w środowiskach 3D: Renderowanie tylko tych powierzchni, które są widoczne Idea bufora Z przez wiele lat była niemożliwa do użycia w czasie rzeczywistym Podejście oparte na wysyłaniu promieni (ang. ray casting) Jeśli poruszamy się tylko po płaszczyźnie, wystarczy tylko tyle promieni, ile mamy pikseli w poziomie w buforze klatki Perspektywa: na podstawie odległości rysujemy pionową linię o proporcjonalnej wysokości Źródła obrazów: Fabien Sanglard, WIkipedia 36

37 Test widoczności (ang. visibility test) Podejście oparte na wysyłaniu promieni (ang. ray casting) Za głównego popularyzatora ray castingu jako narzędzia służącego do renderowania ścian pseudo-trójwymiarowej sceny uważa się Johna Carmacka, założyciela id Software. Pierwsze użycie tego podejścia miało miejsce w grze Hovertank 3D. Podejście to, wzbogacone o mapowanie tekstur i proste oświetlenie, zostało użyte w bardzo popularnej w swoich czasach grze Wolfenstein 3D. Źródła obrazów: id Software, Wikipedia 37

38 Test głębokości (ang. depth test) Można stosować komponowanie klatki za pomocą zarówno testu głębokości, jak i algorytmu malarza. Interfejs użytkownika zwykle nanosimy na wyrenderowaną wizualizację świata bez użycia testu głębokości Kiedyś stosowano uproszczenia w celu przyspieszenia renderowania, np. samochód gracza mógł być rysowany na tle otoczenia, bo rzadko kiedy dochodzi do sytuacji w której miałby być czymś przysłonięty Źródło obrazu: Virgin Interactive 38

39 Kamera perspektywiczna Dodatkowo kamerę określają: Proporcje boków podstawy ściętego ostrosłupa (ang. frustum) Stosunek szerokości do wysokości 4:3, 16:9, 16:10,... 39

40 Kamera perspektywiczna Podsumowując, do jednoznacznego opisania kamery potrzebne są wartości następujących atrybutów: Cechy widoku: Położenie Kierunek Wektor pionu Cechy projekcji: Kąt widzenia Odległości płaszczyzn przycinania Proporcje 40

41 Kamera w OpenGL Aby opisać jednoznacznie położenie kamery, należy określić: Pozycję p Kierunek widzenia d Wektor pionu u Każdy z tych elementów w przestrzeni 3D jest 3-elementowym wektorem u d p 41

42 Kamera w OpenGL Aby łatwo uzyskać w OpenGL macierz transformacji odpowiadającą kamerze umieszczonej w zadanym punkcie, patrzącą w zadanym kierunku i o zadanym wektorze pionu, najlepiej posłużyć się funkcją: glulookat( eyex, eyey, eyez, lookatx, lookaty, lookatz, upx, upy, upz ) eye* - współrzędne XYZ punktu zaczepienia kamery lookat* - współrzędne XYZ punktu, na który ma spoglądać kamera up* - współrzędne XYZ wektora pionu W dalszych rozważaniach dla uproszczenia przyjmiemy, że wektor pionu zawsze będzie równy (0;1;0) 42

43 Kamera w OpenGL Należy zwrócić uwagę, że glulookat() nie przyjmuje kierunku widzenia kamery, a punkt na który kamera ma spoglądać Jest to szczególnie istotne, gdy naszym zadaniem jest zaprogramowanie interaktywnej kamery pierwszoosobowej W takim przypadku dużo wygodniej jest przechowywać kierunek widzenia jako wektor jednostkowy Na podstawie pozycji kamery o raz kierunku można łatwo uzyskać współrzędne punktu, który można przekazać do glulookat(). d p 43

44 Kamera w OpenGL Należy zwrócić uwagę, że glulookat() nie przyjmuje kierunku widzenia kamery, a punkt na który kamera ma spoglądać Jest to szczególnie istotne, gdy naszym zadaniem jest zaprogramowanie interaktywnej kamery pierwszoosobowej W takim przypadku dużo wygodniej jest przechowywać kierunek widzenia jako wektor jednostkowy Na podstawie pozycji kamery o raz kierunku można łatwo uzyskać współrzędne punktu, który można przekazać do glulookat(). d p 44

45 Kamera w OpenGL Należy zwrócić uwagę, że glulookat() nie przyjmuje kierunku widzenia kamery, a punkt na który kamera ma spoglądać Jest to szczególnie istotne, gdy naszym zadaniem jest zaprogramowanie interaktywnej kamery pierwszoosobowej Punkt o współrzędnych p+d bez wątpienia znajduje się na osi widzenia kamery znajdującej się w punkcie p, skoro wektor d wskazuje jej kierunek widzenia. W takim przypadku dużo wygodniej jest przechowywać kierunek widzenia jako wektor jednostkowy Na podstawie pozycji kamery o raz kierunku można łatwo uzyskać współrzędne punktu, który można przekazać do glulookat(). d p+d p 45

46 Stan kamery Reprezentacja stanu kamery w pamięci Strukturę/klasę przechowującą dane wektora wygodnie jest rozbudować o przydatne metody (np. długość, normalizacja, iloczyn wektorowy) i przeciążone operatory dla częstych operacji arytmetycznych. Podejść do implementacji kamery jest wiele. Przytoczone tutaj jest wygodne dla prostych scen i stosunkowo łatwe w zrozumieniu. Poszukując rozwiązania bardziej uniwersalnego, warto przyjrzeć się podejściu opartemu na kwaternionach. Wygodne jest zapamiętanie trzech wektorów 3-elementowych: Położenia Kierunku patrzenia Pionu Sugerowane jest utworzenie struktury przechowującej trzy składowe XYZ: struct vec3 { float x, y, z; }; Wówczas stan kamery można przedstawić następująco: struct SCameraState { vec3 pos; vec3 dir; vec3 up; }; 46

47 Stan kamery Jako że dla uproszczenia przyjęliśmy, że wektor pionu jest stały, możemy go pominąć Przydatne może okazać się przechowanie aktualnej prędkości przesuwania kamery Np. w celu płynnego wygaszania ruchu Zatem struktura stanu kamery może przyjąć następującą postać: struct SCameraState { vec3 pos; vec3 dir; float speed; }; Na potrzeby zadania utworzymy globalną instancję tej struktury i nazwiemy ją player SCameraState player; 47

48 Stan kamery W takiej sytuacji, możemy każdorazowo zasilać wywołanie glulookat() następującymi danymi: glulookat( player.pos.x, player.pos.y, player.pos.z, player.pos.x + player.dir.x, player.pos.y + player.dir.y, player.pos.z + player.dir.z, 0, 1, 0 ); 48

49 Ruch kamery w przód/tył Aby zrealizować taki ruch, trzeba zmodyfikować położenie kamery kierunek i pion pozostaną bez zmian "Przód" w danym momencie odpowiada wektorowi kierunku kamery Pozycję po przesunięciu obliczamy w prosty sposób: p ' = p+ speed d d p d p' p p' Mała prędkość (mnożnik) Duża prędkość (mnożnik) 49

50 Ruch kamery w bok Aby uwzględnić kierunek widzenia kamery, ruszając się na boki należy poruszać się po kierunku prostopadłym W założeniu mamy poruszać się tylko po płaszczyźnie XZ e p' d p p ' = p+ speed e, e d Jak wyznaczyć wektor prostopadły do danego? () ( ) dx d= d y dz d z e= 0 dx 50

51 Obrót kamery Obrót kamery jest zmianą kierunku jej widzenia, bez wpływu na punkt zaczepienia W założeniu mamy poruszać się tylko po płaszczyźnie XZ Rezultatem jest wektor kierunku obrócony o zadany kąt Jak wyliczyć jego współrzędne? d p d' 51

52 Obrót wektora kierunku w 2D y Dla uproszczenia sprowadźmy problem do dwóch wymiarów. d Będziemy dokonywać obrotu tylko w obrębie jednej płaszczyzny, którą roboczo nazwiemy x/y. x Chcąc poruszać się po płaszczyźnie x/z układu współrzędnych OpenGL należy odpowiednio zmienić oznaczenie osi! 52

53 Obrót wektora kierunku w 2D y Chcemy dokonać obrotu kamery o zadany kąt α. α Miara tego kąta może być rozumiana jako krok wykonany podczas tej jednej operacji obracania. d x 53

54 Obrót wektora kierunku w 2D y d' Naszym wynikiem powinien być nowy wektor kierunku d', uzyskany po obróceniu pierwotnego wektora d wokół początku układu współrzędnych. α d x 54

55 Obrót wektora kierunku w 2D y d' = (xd'; yd') d = (xd; yd) Można przyjąć, że wektory zaczepione w początku układu współrzędnych to położenia punktów znajdujących się na ich końcach. α x 55

56 Obrót wektora kierunku w 2D y d' = (xd'; yd') d = (xd; yd) Rozpatrzmy najpierw samą współrzędną x. α Znamy xd xd' xd x Znamy miarę kąta α Nie znamy natomiast xd 56

57 Obrót wektora kierunku w 2D y d' = (xd'; yd') d = (xd; yd) yd' Analogiczna sytuacja zachodzi dla współrzędnej y. yd Znamy yd α xd' xd x Znamy miarę kąta α Nie znamy natomiast yd 57

58 Obrót wektora kierunku w 2D y d' = (xd'; yd') yd' Dodatkowo wiemy, że długości wektorów d i d są równe 1 ponieważ przyjęliśmy takie założenie odnośnie wektora d, a także chcemy aby nasz d zachował tę własność. yd 1 α xd' 1 xd d = (xd; yd) x 58

59 Obrót wektora kierunku w 2D y yd' 1 Warto zwrócić uwagę, że mamy tu do czynienia z dwoma trójkątami prostokątnymi. α xd' 1.. xd yd x { xd, xd, yd, yd } są długościami kolejnych przyprostokątnych, zaś przeciwprostokątne mają długość 1. 59

60 Obrót wektora kierunku w 2D y yd' 1 Gdyby znać miarę kąta α+β, znając długość przeciwprostokątnej (jest równa 1), możliwe byłoby wyznaczenie długości przyprostokątnej czerwonego trójkąta (czyli xd lub yd ) z pomocą odpowiednich funkcji trygonometrycznych. α xd' 1 yd β xd x 60

61 Obrót wektora kierunku w 2D y yd' 1 Miarę kąta β możemy znaleźć posługując się znanymi długościami boków zielonego trójkąta. α xd' tan (β)= 1 yd β xd x yd xd 61

62 Obrót wektora kierunku w 2D y Najwygodniej, z uwagi na możliwość wystąpienia kąta w dowolnej ćwiartce układu współrzędnych, posłużyć się funkcją atan2. Funkcja cyklometryczna atan2 jest dwuargumentową odmianą funkcji arcus tangens, biorącą pod uwagę ćwiartkę układu w której znajduje się zadany kąt. yd' 1 α xd' tan (β)= yd xd 1 yd β xd x β=atan 2( y d, x d ) [ 62

63 Obrót wektora kierunku w 2D Kiedy już znamy miarę kąta β, możemy przystąpić do obliczania długości przyprostokątnych czerwonego trójkąta korzystając z funkcji trygonometrycznych sinus i cosinus. y yd' 1 α xd' tan (β)= yd xd 1 yd β xd x β=atan 2( y d, x d ) xd ' =cos(β+α) d ' yd ' =sin (β+α) d ' 63

64 Obrót wektora kierunku w 2D y d' = (xd'; yd') Pamiętamy, że długość przeciwprostokątnych jest równa 1, co dodatkowo upraszcza obliczenia. W ten sposób otrzymujemy ostateczne współrzędne punktu d po obrocie punktu d o kąt α wokół początku układu współrzędnych. yd' 1 α xd' tan (β)= yd xd 1 d = (xd; yd) yd β xd x β=atan 2( y d, x d ) x d ' =cos(β+α) y d ' =sin (β+α) 64

65 Kamera w scenie 3D Pojęcie kamery. Implementacja interaktywnej kamery FPP. Gry komputerowe, Informatyka S1, II Rok, 2018 r.