Flash:

ARVisualiser – only hyperlink because I’ve had weird problems with embedding.

Because of ARToolkit bases on black and white markers, I’ve used one of predefined:

So if You want to try given swf You have to print this marker or draw it on some white paper.

And this is standard wersion on wonderfl:

Results after quick codding in ActionScript and Papervision 3D at www.wonderfl.com:

I like the idea of wonderfl.net website, we quickly can develop some experimental things using popular libraries without installing any IDE and SDK’s. There is also code ranking. I’m recommending to check this out :)

Podstrona projektu: http://depth.mi-ku.net

Jeżeli ktoś będzie miał jakieś ciekawe idee na rozwinięcie pomysłu to jestem otwarty na propozycje.

Sterowanie:
Przeciąganie niebieskiej kulki za pomocą lewego przycisku myszy.

Rezultat:

Do pobrania:

• http://www.mi-ku.net/projekty/sense/demos/ClothPhysicsDemo01.zip

Żeby nie referat to pewnie powróciłbym do tego tematu później, bo w między czasie (teraz a początek semestru) zacząłem robić mini demko symulacji materiału kolidującego z dowolnymi złożonymi siatkami, aktualnie już działa, ale na CPU jest strasznie wolne i przeniosę implementację na GPU – a dokładnie OpenCL a dodatkowo chcę zrobić coś na wzór demka scenowego więc muszę jakoś to poskładać ładnie.

Więcej informacji o projekcie wkrótce, a jakby ktoś w komentarzu napisał żę informacja o algorytmie też by była fajna (ew. ktoś ma problem z implementacją itp.) to opiszę.

Wynik

Zanim jeszcze przejdę do rzeczy pokażę co zaimplementowałem na kodzie który w około 90% pokrywa się z tym opisanym tutaj. Otóż napisałem sobie kontrolkę która w założeniu ma służyć do przemieszczania, obracania i skalowania obiektów w edytorze, który sobię koduję na boku.

Oto rezultat:

Do pobrania:

http://www.mi-ku.net/projekty/sense/demos/Sense3DGUISample.zip

Do implementacji GUI 3D jest nam potrzebne połączenie wejścia (klawiatura + mysz) z elementami graficznymi które znajdują się w przestrzeni trójwymiarowej. Aby kierować zdarzenia z wejść do obiektów z reprezentacją graficzną potrzebny jest nam jakiś nadrzędny byt, który stwierdzi, że akurat ten obiekt powinien otrzymywać zdarzenia. Już na początku mamy pewien problem związany z tym, że pozycje zdarzeń myszy (kliknięcia i ruch) otrzymujemy w przestrzeni dwuwymiarowej a reprezentacja obiektów trzymamy w przestrzeni trójwymiarowej. W związku z tym potrzebna jest nam technika rozpoznania jaki obiekt znajduje się na danej pozycji bufora 2d obrazu. Często stosowanymi technikami są:

• użycie pomocniczego bufora obrazu
• kolizje promienia utworzonego na podstawie pozycji 2D myszy z obiektami na scenie

Ja wybrałem użycie bufora pomocniczego, w nadziei, że będzie szybsze niż sprawdzanie kolizji siatek 3D z promieniem. No i ten sposób wydaje mi się łatwiejszy w implementacji.

Jak stencil nam pomoże w stwierdzeniu jaki obiekt znajduje się na danej pozycji w 2D? Otóż zastosujemy klasyczną technikę, renderowania każdego obiektu z innym indeksem (wartością którą może przechowywać stencil), a w obsłudze zdarzeń myszy stwierdzimy który element jest aktywny przez odczytywanie wartości bufora na danej pozycji myszy. W skrócie pętla renderingu wygląda tak:

1. Czyszczenie bufora obrazu, głębi oraz stencila
2. Renderowanie wszystkich elementów GUI do stencila
3. Renderowanie wszystkich elementów GUI do właściwego bufora obrazu

W większości przypadków chyba oba kroki można połączyć i rysować od razu do stencila i własciwego bufora obrazu.

A w obsłudze zdarzeń myszy:

1. Ustal pozycje myszy.
2. Pobierz wartość bufora stencil na danej pozycji myszy.
3. Jeżeli pobrana wartość równa się wartości początkowej (np. 0) odrzuć zdarzenie.
4. Znajdź element GUI który odpowiada danej wartości bufora.
5. Wyślij zdarzenie myszy do znalezionego elementu.

Menedżer zdarzeń

Na wstępie implementacji jest nam potrzebny jakiś menedżer zdarzeń klawiatury i myszy. W przypadku kiedy w używanym przez nas API mamy dostęp do zdarzeń “niskopoziomowo” (np. procedura obsługi okna) to opakujmy wszystko w klasy takie jak InputManager wraz ze słuchaczami dziedziczącymi po KeyboardEventListener i MouseEventListener. Przykład implementacji:

Żeby nie utrudniać czytania implementacje metod klasy InputManager pominąłem, ale w zasadzie są dosyć oczywiste. Pierwsze sześć metod zajmuje się przekazywaniem konkretnych struktur zdarzeń do słuchaczy. Kolejne metody Add/Remove nie robią nic innego jak dodają/usuwają kolejnych słuchaczy z kolekcji EventListenerCollector< KeyboardEventListener >::Listeners oraz EventListenerCollector< MouseEventListener >::Listeners.

Podpięcie takiego managera do obsługi zdarzeń z okna może wyglądać następująco:

Mamy już klasę tworzącą warstwę pomiędzy zdarzeniami z obsługi okna oraz obiekt do dalszego ich rozsyłania. Stworzenie tej warstwy umożliwia również implementacje obsługi zdarzeń z innych źródeł na innych platformach niż Windows, czy też chociażby na zaimplementowanie sprawdzania asynchronicznego stanu urządzeń wejściowych.

Rozdzielanie zdarzeń do elementów GUI 3D

Teraz czas na implementacje obiektu, który będzie zarządzał zdarzeniami w ramach obiektów z reprezentacją w przestrzeni trójwymiarowej. Zastanówmy się co jest nam potrzebne. Tak jak wspomniałem obiekty powinny się renderować oprócz do bufora obrazu to i do stencila. Musimy posiadać jakiś mechanizm który powie tym obiektom z jaką wartością stencila mają się renderować. Stwórzmy klasę którą nazwiemy np. StencilInputEventDispatcher która będzie mogła przechowywać wskaźniki do swoich słuchaczy (prawie identycznie jak w przypadku InputManager ) jednak dodatkowo do klasy słuchacza dodamy metody ustawiające wartość stencila oraz odczytujące ustawioną wartość (Set/GetIndex). Przydadzą się jeszcze metody MouseOver i MouseOut, dla oświadczenia danemu słuchaczowi (czyli obiektowi 3D), że najechaliśmy na niego myszą lub też z niego “zjechaliśmy”. Od klasy StencilInputEventDispatcher oczekujemy również, że będzie przesyłać zdarzenia wtedy gdy “zjedziemy” myszą z obiektu z wciśniętym przyciskiem myszy.

Przykład imlpementacji:

Mając tak napisany obiekt, wystarczy go podpiąć do instancji InputManager (a tą polecam przechowywać jako np. singleton).

Wspomnę jeszcze o tym, że jak chcemy zmieniać aktywny obiekt za pomocą klawiatury np. poprzez TAB/Shift+TAB to trzeba odrobinę zmodyfikować implementację StencilInputEventDispatcher, ale to już zostawiam wytrwałym którzy tu dobrneli i jeszcze mają ochotę na wykorzystanie fragmentów mojej implementacji :D.

Przejdźmy do sedna, czyli jak zaimplementować kontrolkę reagującą na zdarzenia? Nic prostrzego, jedyne wymagania od takiej klasy to dziedziczenie po StencilInputEventListener aby móc ją zarejestrować w dispatcherze oraz to żeby się go posłuchała i renderowała się do stencila z podanym przez niego indeksem

prawie pseudo kod:

IRenderer to jak sama nazwa wskazuje interfejs poprzez ktory dostajemy sie do renderera, tu zamiast niego wystarczy wykorzystać swój własny, lub bezpośrednio się odwołać do funkcji danego API. SceneNode to używana przeze mnie klasa pomocnicza implementująca większośc funkcji węzła w grafie sceny. Dla prostych obiektów wystarczy przeciążyć metodę Render.

Dalej to już zabawa z obsługą zdarzeń. Przycisk jak to przyciski powinny mieć w swoim zwyczaju powinien przeciążyć zdarzenie MouseButtonDown i odpowiednio na nie zareagować. Natomiast bardziej złożone kontrolki mogą zawierać kontrolki podrzędne implementujące interfejs słuchacza dispatchera. Pozostawiam to już Wam.

Podsumowanie

Opisałem przykład implementacji przekazywania zdarzeń do kontrolek 3D, który mi osobiście narazie wystarcza, jeżeli ktoś ma jakieś pytania i/lub pomysły na dalszy rozwój to czekam na komentarze.

• Kolizje organizm-organizm,
• kolizje organizm-pocisk.
• śmierć gracza.
• dwóch mobilnych “przeciwników”,
• trochę ładniejsze mutowanie,
• double-click lewym przyciskiem myszy ustawia cel do strzelania, czyli teraz można poruszać się i strzelać w różnych kierunkach
• minimalna optymalizacja kodu

Przez te poprawki “gra” nabrała trochę sensu, natomiast brakuje jeszcze celu gry, a tym w zamierzeniu ma być na dojście do odpowiedniego miejsca lub wyeliminowanie wszystkich przeciwników.

Do pobrania

http://www.mi-ku.net/projekty/BioShoot/BioShootR2.zip

Screen shoot’y

http://www.kloonigames.com/blog/general/articles-about-rapid-game-prototyping

Dla czego o tym temacie wspominam? Otóż na specjalizacji na studiach dostaliśmy zadanie własnie stworzenia prototypu gry w jak najkrótszym czasie. Czyli chcąc nie chcąc (bardziej chcąc :D ) musiałem coś zrobić. Oto wynik pracy która zajęła około 40 godzin:

Opis gry

Jako, że nie mielismy wyznaczonego jasno tematu prototypu to w grze jesteśmy sobie dziwnym organizmem w dziwnym świecie. Chodzi o to żeby zbierać mutatory (power upy) i nie dać się zabić w świecie w którym się znaleźlismy.

Dostępne mutatory:
Zielony – Ciało
Czerwony – Działko (oryginalna nazwa? )
Biały – Osłona
Niebieski – Głowa przy pomocy której możemy się poruszać

Sterowanie

LPM – Poruszanie
PPM – Strzelanie (jeżeli łyknęlismy mutator do strzelania)

Edytor
TAB x1 – tryb edycji świata
TAB x2 – tryb edycji mutatorów

W trybie edytora polecam pobawić się: LPM, PPM, Środkowy przycisk myszy, Del, Shift, Ctrl. Edytor jest w miarę intuicyjny więc się nie rozpisuje – polecam się pobawić. Przeciwnicy są zhardkodowani.

Co nie zostało zrobione

- Tarcie w kolizjach – teraz można się nieźle zaplątać:)
- kolizje między organizmami
- kolizje organizm -> “pocisk” <- co oczywiście chwilowo psuje cały efekt i nie pokazuje gameplayu - co w zasadzie miało być kwintesencją prototypu hehe, ale dodam w kolejnej wersji.
- te kolizje co są nie są oparte na żadnym drzewie ósemkowym itp. w związku z tym gra potrafi nieźle przyciąć kompa

Do pobrania

http://www.mi-ku.net/projekty/BioShoot/BioShootR1.zip

Screen shooty

Po zjedzeniu zielonego mutatora:

Pod ostrzałem :)

Z edytora świata:

Technikalia

projekt został całkowicie napisany pod frameworkiem PopCap. Z frameworka wykorzystałem głównie: rysowanie przez Graphics, Image, XML, Dźwięki, Obsługę wejścia. Poza frameworkiem dopisalem kilka funkcji pomocniczych do Graphics’a i prostą fizykę sprężyn.

Technicznie trochę prze-engineerowałem jak to się mawia, mam pełny polimorfizm, możliwość dodawania nowych nodów, powerupów, kontrollerów dla organizmów(np. kolejne AI), możliwe jest też napisanie całkowicie innych broni i podpięcie ich w łatwy sposób, np zdalnie naprowadzanych pocisków itp. Wrogowie mogą być również mobilni. Dużo czasu też poświęciłem edytorowi który przynajmniej umożliwia edycje świata i powerupów bo w xmlu bym się zachetał to pisać.

Dźwięki zapożyczyłem ze Starcrafta, więc nie mam do nich praw….. aha odpalając gre lepiej mieć przyciszony dźwięk :P

Podsumowanie

W sumie całość nie jest jeszcze skończona, ale nie mogłem się powstrzymać przed umieszczeniem aktualnej wersji :) a obawiam się że teraz mogę nie mieć już czasu na tą gierkę. Gdy zaimplementuje kolizje pocisków z organizmami i co za tym idzie śmierć gracza to dopiero wtedy okaże się czy gameplay ma sens.

Miłej zabawy z niedokończonym prototypem :) :) :)

• Bazy danych
• Programowanie aplikacji biznesowych
• Sieci komputerowe
• Multimedia
• Robotyka
• Multimedia – programowanie gier

W zasadzie tematyka każdej specjalizacji jakoś bardziej lub mniej mnie interesuje i miałem spory dylemat którą wybrać, w rachubę wchodziło też wybranie dwóch specjalizacji i realizowanie pracy inżynierskiej pod kątem obu. Po długim namyśle wybrałem jakże egzotyczną jak na polskie realia (chociaż ostatnio sytuacja się poprawia) specjalizację “programowanie gier”, gdyż ta bezpośrednio umożliwia mi realizację jednego z pomysłów które siedzą mi w głowie od dawna.

Pomysł

Chcę wykonać grę która będzie wykorzystywała specjalny “kontroler” służący do pomiaru aktywności umysłu, której celem będzie osiąganie stanu relaksu przez grającego. Pomysłów na realizację mam kilka, jeden (podrzucony przez jednego z prowadzących) uwzględnia dwóch graczy gdzie wygrywa ten który szybciej się zrelaksuje, inne pomysły to mini gry w których grający będzie musiał osiągnąć oczekiwany efekt audio-wizualny poprzez relaksację. Taka technika nosi nazwę Biofeedback’u, czyli sprzężenia zwrotnego utworzonego na podstawie odczytu i interpretowania jakiegoś sygnału generowanego przez człowieka i podawania informacji zwrotnych do jakiegoś zmysłu/zmysłów ludzkiego z komputera. Do pomiaru aktywności umysłu chcę wykorzystać metodę pomiaru rezystancji naskórka (galvanic skin response) która jest związana z opornością układu nerwowego, który z kolei pośrednio odpowiada aktywności umysłu.

Biofeedback służący do relaksacji ma poważne zastosowanie w np. w psychoterapii przy leczeniu między innymi ADHD. Może być też wykorzystywany przez ludzi żyjących w ciągłym stresie. W zasadzie zastosowań jest wiele, także mogę coś zrobić co się być może przyda innym.

Wstępna realizacja części sprzętowej

Jako, że do metody którą wybrałem potrzebne jest mi urządzenie komunikujące się z komputerem, a na czas testów nie chciałem projektować własnego układu opartego o mikrokontroler. Między innymi w związku z małym doświadczeniem na tym polu. To wpadłem na pomysł przerobienia analogowego joypada na moje potrzeby. Sposób był prosty, gałki analogowe działają na podstawie odczytanej rezystancji z potencjometru połączonego z gałką sterującą. To jak już pewnie wiecie zamiast potencjometru mechanicznego wystarczy podłączyć rezystancję “ludzką”, oczywiście wbudowane potencjometry mają o wiele mniejszą rezystancję niż skóra i wymagało to drobnych przeróbek, jednak wstępnie się udało. Elektrody na palce wykonałem z rzepów do których wszyłem splotkę przewodzącą prąd (to było najlepsze co mogłem zmontować z materiałów znalezionych w domu), które sprawdzają się całkiem nieźle. W ten oto sposób otrzymałem proste, działające jako tako urządzenie, które po wstępnych testach zachowuje się zgodnie z moimi przewidywaniami, czyli jest

• nie dokładne – w związku małą rozdzielczość pomiaru, joypad przewidywał tylko 256 próbek, które do gier oczywiście w zupełności wystarczają, jednak tutaj przydało by się przynajmniej tą dwójkę podnieść dwie potęgi wyżej :)
• nie stabilny odczyt – potrzeba kilka minut na stabilizację układu. To raczej w związku z moją przeróbką
• Wymagana kalibracja dodatkowym potencjometrem wykonana pod użytkownika

W każdym bądź razie się nie zrażam bo jak na jeden dzień pracy wyniki są zadowalające. W oknie kalibracji joypada da się zaobserwować zmiany rezystancji układu nerwowego. Nawet nie wiedzialem jak bardzo potrafi organizm zareagować na pewne bodźce, np. plasknięcie się po twarzy powoduje gwałtowne przesunięcie wskaźnika kontrolera :) a słuchanie relaksującej muzyki powoduje powolny powrót wskaźnika na dawne miejsce. Kontynuacja relaksacji powoduje jeszcze większe przesunięcie wskaźnika co oznacza, że osiągnąłem większy spokój niż przed zastosowaniem wspomnianego bodźca. Wracając do samego urządzenia to finalnie postaram się zrobić własne na USB typu HID wykorzystujące jakiś mikrokontroler.

Wynik przeróbki joypada:

Co dalej?

Pozostaje mi między innymi wymyśleć co dokładnie będzie tematem pracy inżynierskiej i zacząć powoli ją robić (o ile zostanie zaakceptowany :P ).

Sam pomysł biofeedbacku można rozwinąć i połączyć z wspomaganiem samej relaksacji poprzez w pewnym sensie wymuszanie odpowiedniej aktywności umysłowej poprzez pewne bodźce fizyczne, np. poprzez tzw. szumy dudnieniowe służące do synchronizacji półkul mózgowych do pracy w odpowiedniej częstotliwości.

Zainteresowanych odsyłam do poszukania w internecie informacji pod hasłami: biofeedback, gsr, hemi-sync. Swego czasu powstał komercyjny produkt, który w zasadzie odpowiada prawie 1 do 1 temu co chcę zrobić, można o nim poczytać na: www.relaksacja.pl. Do hemi-sync polecam programik Gnuaural. To chwilowo na tyle.