projekt

Gra wykorzystująca rzeczywistość rozszerzoną
Zaawansowane systemy grafiki komputerowej –
projekt
Paweł Tarasiuk, 186875
16 sierpnia 2013
1
1
Wstęp
Niniejszy projekt stanowi prostą grę komputerową, której kluczowym elementem jest wykorzystanie rzeczywistości rozszerzonej.
Gra rozgrywana jest za pomocą elementów rysowanych w miejscu, w którym
na obrazie z kamery wykryte zostały markery – są to działo i cel. Gracz steruje
rotacją działa (w dwóch kierunkach), z którego wystrzelony może zostać pocisk.
Celem gry jest trafienie pociskiem w cel. Inne ustawienie markerów działa oraz
celu w przestrzeni oznacza konieczność innego ustawienia działa i na tym właśnie
polega atrakcja przygotowanej gry. Szczegóły interfejsu oraz zasad związanych
z samą fizyką gry opisane są w kolejnych sekcjach.
2
Zastosowane technologie
Projekt został wykonany w języku Java, wybrane przeze mnie środowisko
programistyczne to Eclipse. processing został (zgodnie z tym, czym jest on naprawdę) zastosowany jako biblioteka Javy i posłużył do rysowania wszystkich
elementów interfejsu graficznego oraz obsługi sterowania klawiaturą. Obliczenia
związane z geometrią przestrzenną także zostały zaimplementowane przy wykorzystaniu klas z biblioteki processing (PMatrix, PVector). Ze względu na
błędy w zdobywającej popularność wersji beta, które zniechęciły mnie podczas
poprzednich ćwiczeń laboratoryjnych (np. błąd 173) zastosowana została wersja
stabilna – processing 1.5.1.
Obiekt PApplet dziedziczy po widgecie z biblioteki AWT, więc aby wyświetlać aplikację w oknie, osadziłem go wewnątrz obiektu Frame z AWT. Biblioteka AWT może być uważana za przestarzałą, ale w tym wypadku nie ma
to żadnych negatywnych skutków, gdyż za pomocą AWT nie są rysowane żadne elementy interfejsu graficznego ani napisy (Frame to po prostu systemowe
okno) – a przecież dziedziczenie po AWT stosowane jest także w aktywnie rozwijanych projektach takich jak np. SWT. Stosowanie w tym miejscu dodatkowych
bibliotek nie dałoby żadnej korzyści, a wiązałoby się z dodatkowym narzutem.
Do obsługi elementów rzeczywistości rozszerzonej wykorzystany został NyArToolkit. Jakkolwiek bardzo doceniam jakość wykrywania markerów przez
narzędzia zawarte w tej bibliotece, sporym problemem okazały się braki w dokumentacji (odczuwalnie przynajmniej z punktu widzenia osób nie znających
języka japońskiego). Zastosowanie tej biblioteki szczęśliwie ograniczyło się do
wskazywania macierzy przekształceń pozwalającej rysować obiekty pośrodku
wykrytego markera, tak aby odpowiednio obrócona płaszczyzna XZ pokrywała się z płaszczyzną markera. Macierze wskazywane przez odpowiednie metody
obiektu MultiMarker pozwoliły na dokonanie wszystkich obliczeń geometrycznych potrzebnych w ramach niniejszego projektu.
Podając MultiMarkerowi z NyArToolkit pewne podstawowe parametry obrazu, który ma być analizowany (np. jaki rozmiar względny ma być przypisywany
wykrytemu markerowi), można było działać na dowolnym obiekcie PImage (typ
z biblioteki processing) na którym było widać markery. Podstawowe zastosowa-
2
nie programu związane jest z analizą klatek pochodzących z kamery podłączonej
do komputera – do tego celu wykorzystana została biblioteka gsvideo. Tworzenie projektu nie zawsze jednak przebiegało w warunkach stosownych do kamerowania prawdziwych markerów – w takich wypadkach zamiast obrazu z kamery
podstawiana była cały czas ta sama klatka wczytana z pliku graficznego.
Tworzenie tego projektu ani na chwilę nie zmusiło mnie do opuszczania systemu operacyjnego GNU/Linux tudzież do uruchamiania maszyn wirtualnych
– co (przynajmniej w moich oczach) dobrze świadczy o twórcach wybranych
przeze mnie bibliotek. Trzeba pamiętać, że choć sama Java jest wieloplatformowa, to wszystkie trzy wymienione biblioteki wykorzystują specyficzne operacje
niskopoziomowe (jak np. obsługa kamerki) albo wymagające dużej wydajności (processing). We wszystkich przypadkach dostępne były jednak odpowiednie
natywne biblioteki współdzielone pod 64-bitową architekturę GNU/Linux albo
źródła umożliwiające samodzielne przygotowanie takich bibliotek natywnych.
3
Szczegółowe zasady
Programowo obliczane są położenia, rotacje i rozmiary działa oraz celu w bezwzględnym układzie współrzędnych (na podstawie wygenerowanych przez NyArToolkit macierzy przekształceń). Gracz decyduje o rotacji umieszczonego na
jednym ze znaczników działa, na drugim ze znaczników rysowany jest cel. Sens
dla zabawy ma obrócenie działa w dziwny sposób (nawet umieszczenie kartki
ze znacznikiem pionowo), więc jako płaszczyznę odniesienia stosuję płaszczyznę
z celem. Gdy któryś z markerów przestaje być widoczny (przysłonięcie kartki
lub przesunięcie jej poza pole widzenia kamery), wykorzystywana jest ostatnia
informacja o pozycji obiektu, która była pewna – jest to podejście dużo bardziej estetyczne niż znikanie obiektów. Dotyczy to także „pechowych” klatek
na których wykrycie markera się nie udaje, mimo iż jest on widoczny – dzięki
zastosowanemu podejściu nie powoduje to „migania” obiektów ani utrudnień
w grze.
3
W wybranym przez gracza momencie, z czubka lufy działa wystrzeliwany
jest pocisk, który ma pewną narzuconą wartość prędkości początkowej, skierowanej zgodnie z kierunkiem ustawienia lufy. Dalszy tor pocisku wyznaczany jest
poprzez symulację ruchu jednostajnie przyspieszonego, z przyspieszeniem symulującym grawitacyjne – tzn. skierowanym „w dół”, prostopadle do płaszczyzny
odniesienia. Pocisk eksploduje, gdy zetknie się z działem lub celem, lub gdy
znajdzie się po przeciwnej stronie płaszczyzny odniesienia niż był w poprzedniej klatce. Po wybuchu pocisku działo jest resetowane do losowej rotacji (aby
powtórzenie udanego strzału nie było zbyt proste) i tworzony jest nowy, gotowy do wystrzelenia pocisk. Strzał jest uznawany za udany, gdy wybuchający
pocisk jest odpowiednio blisko celu (wybuchem objęta jest nieco większa kula,
niż zajmowana przez sam pocisk – zatem można zdobyć punkt także trafiając
w płaszczyznę odniesienia tuż obok celu).
Kolizję z działem oraz celem wykrywane są w najprostszy możliwy sposób
(każdy z tych kształtów jest aproksymowany jako kula, co ma odzwierciedlenie
w kształcie modeli tych obiektów). Kolizja pocisku z lufą w ogóle nie jest sprawdzana, bo i tak jest niemożliwa (działo nie może zostać uniesione pionowo do
góry – graniczna wartość kąta to około 88◦ ).
4
Interfejs użytkownika
Rotacją działa steruje się za pomocą klawiszy W, S (unoszenie i podnoszenie), A, D (obracanie wokół osi prostopadłej do markera działa). Strzał wykonywany jest w momencie wciśnięcia klawisza X. Z pozoru banalne podejście
do sterowania działem jest jednocześnie podejściem najprostszym i najwygodniejszym – rozważania na temat „czy nie zastosować myszy” skończyły się na
wniosku, że o ile byłoby to ciekawe wyzwanie programistyczne, to wygoda korzystania z programu by spadła.
4
W oknie aplikacji wyświetlany jest obraz z kamerki wraz z dorysowanym
działem, celem oraz ewentualnie pociskiem. Ponadto w lewym górnym rogu
pokazywane są łatwe do zrozumienia ikonki opisujące celność trzech ostatnich
strzałów.
5
Podobne projekty
Najprostsze gry wykorzystujące rzeczywistość rozszerzoną oparte są na pojedynczym markerze, jak np. wykonany przez pewnego programistę wyścig samochodowy. Kluczową różnicą takich gier w porównaniu do mojego projektu
jest to, że u mnie zachodzą dosłowne interakcje między obiektami znajdującymi
się na różnych markerach.
Sprytne wykorzystanie wielu markerów zaobserwowałem w demonstracji budzącego mój podziw projektu wykorzystania elementów rzeczywistości rozszerzonej do gry w World of Warcraft. W uogólnieniu – pewien marker wyznacza
płaszczyznę gry, a drugi służy do sterowania. O ile takie podejście równie trudne
pod względem samej geometrii co moje, to idea wykorzystania wielu markerów
jest w moim odczuciu całkiem inna.
Pewne podobieństwo do swojego projektu stwierdzam natomiast w przypadku gry typu Tower Defense stworzonej przez Nathana Marshaka z University
of Pennsylvania. Postacie z tamtej gry spacerują między obiektami leżącymi na
(dowolnie ustawionych względem siebie na powierzchni) wielu znacznikach. Podobieństwo do zasad mojej gry polega na tym, że rozgrywka odbywa się przy
udziale wielu sporadycznie przesuwanych markerów, oraz że kluczowe jest wyznaczanie ścieżek od obiektu z jednego markera do drugiego. Oczywiście wspomniany projekt był rozwijany znacznie dłużej od mojego i ze znacznie ambitniejszymi założeniami, co ma odzwierciedlenie np. w jakości zastosowanych modeli
5
elementów gry.
6
Wnioski
Jakkolwiek mało odkrywcze by się to nie wydawało, moim pierwszym wnioskiem jest to, że jeżeli szukam wspólnego układu współrzędnych dla wielu różnych obiektów, najlepiej aby był to po prostu układ bezwzględny, na którym
operuję po podstawieniu jednostkowej macierzy przekształceń. Nawet jeżeli wektor siły ciążenia ma być prostopadły do jakiejś innej powierzchni (a zatem skierowany pod nietypowym kątem w układzie bezwzględnym), to takie właśnie
podejście okazało się przy programowaniu najwygodniejsze.
Kolejny wniosek dotyczy sterowania grą osadzoną w przestrzeni trójwymiarowej. Kursor myszy nadaje się praktycznie tylko do wskazywania punktu na
ekranie, natomiast wszelkiego rodzaju obracanie obiektów najwygodniej jest realizować za pomocą klawiatury.
Drobne problemy podczas tworzenia projektu związane były ze stosowaniem
wybranych przez siebie niestandardowych wzorców markerów. Braki w dokumentacji stanowiły utrudnienie w wykrywaniu tego błędu, jednak odpowiednią
informację udało mi się wyszukać dzięki obserwacji różnic między przykładami
a moim intuicyjnym podejściem. Domyślna konfiguracja NyArToolkit zakłada,
że opisany w specjalnym pliku kwadratowy marker o boku 4 powinien być obramowany czarną ramką o grubości 2.
Dokonany wybór bibliotek okazał się udany, gdyż projekt działa. Wydajność
dokonywanej analizy obrazu jest dla mnie wręcz zaskakująca – w połączeniu
z wyborem prostych modeli do dorysowywania, obciążenie mojego laptopa podczas testów jest naprawdę symboliczne, a żadne klatki z kamery nie muszą być
przeskakiwane.
7
Bibliografia
• http://www.creativeapplications.net/processing/augmented-realitywith-processing-tutorial-processing/ – opis zastosowania NyArToolkit w języku angielskim, znacznie przydatniejszy od oficjalnej dokumentacji
• http://cpbotha.net/2010/03/04/processing-gsvideo-nyartoolkiton-linux-x86_64/ – udany przypadek zastosowania wybranego przeze
mnie zestawu bibliotek w 64-bitowym systemie GNU/Linux (i to kilka
lat temu, gdy biblioteki były mniej dojrzałe i kwestia ta sprawiała więcej
trudności)
• http://www.hitl.washington.edu/artoolkit/documentation/ – dokumentacja oryginalnego ArToolkit ułatwia zrozumienie NyArToolkitu
• Algebra liniowa z geometrią – A. Białynicki-Birula, Warszawa 1979
6