Zaimplementowałem mechanizm Mesh Materials silnika Physx pozwalający na definicję skomplikowanych obiektów, z którymi kalkulowane będą kolizje. Mechanizm ten posłużył do detekcji kolizji kostek do rzucania z planszą w grze Backgammon. Efekt znajduje się na poniższym filmiku.
Back to Backgammon :)
Rok temu zacząłem tworzyć grę w oparciu o OpenGL. Grą tą był Backgammon, jedna z najstarszych gier świata. Chciałem stworzyć wszystko w 3d i zachować jak największy realizm, co okazało się trudnym zadaniem dla początkującego programisty tego typu aplikacji.
Po kilku miesiącach przerwy zasiadłem do pracy ponownie. Zacząłem bawić się silnikiem Physx firmy NVidia, aby gra była bardziej realna. Jak to bywa, co chwilę napotykam na problemy, z którymi męczę się przez kilka godzin, a rozwiązanie okazuje się banalne
Poniżej 2 filmiki z etapów tworzenia gry
To dopiero sam początek, więc za bardzo nie ma czym się zachwycać, ale pokazują one mniej więcej, jak będzie wyglądać gra.
Poniższe filmiki pokazują działanie silnika fizycznego do obsługi kostek. Na razie nie są brane pod uwagę kolizje z planszą, a jedynie pomiędzy kostkami. Kolejnym etapem są kolizje z planszą oraz z pionkami.
Etap 1
Etap 2
Nie wiem kiedy powstanie etap 3, ale mam nadzieję, że niedługo..
Google spanikował :)
Jakiś czas temu światło dzienne ujrzała nowa wyszukiwarka Microsoftu o wdzięcznej nazwie Bing. Bardzo mnie to ucieszyło, gdyż monopolu, w żadnej formie nie lubię, a Google na naszym rynku niestety jest monopolistą. Czekałem tylko na wieści dotyczące statystyk udziału wyszukiwarek na rynku. Po tygodniu MS zabrał ok. 5%. Wydawało mi się to dość dobrym wynikiem, ale nie spodziewałem się tak szybkiej i panicznej reakcji Googla, a raczej jednego z jego właścicieli.
Jak donosi gazeta w artykule “Google boi się Binga“, Brin osobiście zaangażował się w walkę z Microsoftem i zaczął cisnąć swoich inżynierów, aby wzięli się do roboty
Mimo, że nie wieszczę MS’owi spektakularnego sukcesu, bardzo cieszę się, że ich ponowne wejście na rynek, po nieudanym starcie z live.com, obudziło zdrową konkurencję na rynku wyszukiwarek, co zwiastuje istotne zmiany w produkcie Googla. Mam nadzieję, że Google wyciągnie asa z rękawa i pokaże co trzymał w zanadrzu i że ta “pilna aktualizacja” okaże się czymś naprawdę dobrym, a nie tylko marketingowym posunięciem.
Przekonamy się wkrótce
Scala – Ray Tracing – bump mapping
Kolejną rzeczą, jaką dodałem do ray tracera jest bump mapping. Aktualnie silnik obsługuje zarówno bump mapping proceduralny, jak i oparty o tekstury. Definiowanie parametrów określonego shadera jest jeszcze jednak dość skomplikowane.
Mam też niewielki błąd (szumy) na krawędziach obiektów, co jest moim kolejnym zadaniem w tym projekcie.
Poniżej mały sample z bumpem i różnymi właściwościami powierzchni (połyskliwość).
Projekt Kenai
Wraz z pojawieniem się pierwszych wersji NetBeansa w wersji 6.7 do programu dołączona została obsługa Projektu Kenai.
Czym jest Projekt Kenai ?
Projekt Kenai to dzieło Sun’a. Jest to, można powiedzieć, odpowiednik starego dobrego sourceforge’a, czy też nowszego code.google.com, z tym że mocno zintegrowany z IDE (NetBeans).
W skład Projektu Kenai wchodzą:
- integracja z IDE
- hostowanie kodu
- bug tracking
- wiki
- listy mailingowe
- forum
- download
- support online
- i kilka innych
Czyli dostajemy takie Code.google.com + integracja z ide, forum i mailingi. Na pierwszy rzut oka całkiem całkiem…
Poniżej info jak skonfigurować projekt, do pracy z Projektem Kenai. Pominę zakładanie konta
Tak więc, aby współdzielić projekt, z menu podręcznego wybrać “Share on Kenai”
Następnym krokiem jest wypełnienie prostych danych, takich jak nazwa projektu, opis, bla bla.
Po chwili od wciśnięcia “Finish” w zakładce “Kenai” mamy szereg opcji.
Mamy możliwość przeglądania ticketów, dodawania nowych, przeglądania źródeł z SVNa.
Szczególnie śledzenie błędów przypadło mi do gustu. W Eclipsie był bodajże Mylyn, jednakże wersja systemu ticketów od Suna bardziej do mnie przemawia.
Nie będę się rozpisywał w szczegółach na temat Kenai. Chciałbym tylko zwrócić uwagę na ten projekt, gdyż zapowiada się bardzo obiecująco. Biorąc pod uwagę z jaką częstotliwością wychodzą kolejne wersje Beta i RC NetBeansa można podejrzewać, że nowy właściciel (Oracle) widzi korzyści z rozwijania zarówno NB jak i Projektu Kenai.
Scala – ray tracing – tekstury
Nie trzeba było długo czekać, a projekt raytracera w Scali doczekał się małej aktualizacji
Dodane zostało teksturowanie.
Za mapowanie tekstury odpowiada następujący fragment kodu:
def getTexel(vp: Vector): Color = {
hasTexture match {
case false => color
case true =>
val vn = new Vector(0,-1,0)
val ve = new Vector(-1,0,0)
val phi = Math.acos(-vn.dot(vp))
val v = phi / Math.Pi
val theta = (Math.acos(vp.dot(ve) / Math.sin(phi))) /
(2 * Math.Pi)
val u = vn.crossProduct(ve).dot(vp) > 0 match {
case true => theta
case false => 1 - theta
}
val color = new java.awt.Color(
textureFile.getRGB(((u * _textureScale * textureFile.getWidth
+ _tPosX) % (textureFile.getWidth - 1)) .toInt,
((v * _textureScale * textureFile.getHeight + _tPosY) %
(textureFile.getHeight - 1)).toInt))
new Color(color.getRed / 255.0, color.getGreen / 255.0,
color.getBlue / 255.0)
}
}
Efekt załączony na poniższym rysunku:
Kod projektu znajduje się w repozytorium: http://code.google.com/p/scala-raytracer/source/browse/
Ray tracing w języku Scala
Kolejnym podejściem do ray tracingu jest implementacja prostego silnika ray tracera w Scali.
Scala jest językiem funkcyjnym, działającym na wirtualnej maszynie Javy. Fajnie integruje się ze standardowymi klasami Javy, co znacznie zwiększa jego funkcjonalność.
Silnik obsługuje na razie tylko prosty model oświetlenia Phonga oraz przecinanie promienia jedynie z kulami.
Zamierzam dopisać do tego bump mapping, ale z czasem może być krucho i na zamiarach może się skończyć
Poniżej przykład wygenerowanego obrazu (zamierzam sprawić, że będzie to bardziej spektakularne
)
Projekt hostowany jest na code.google.com i dostępny na licencji MIT.
Link do projektu: http://code.google.com/p/scala-raytracer/
W chwili wolnego czasu opiszę kawałki kodu, gdyż języki funkcyjne delikatnie różnią się od tych, w których najczęściej programujemy
Rozproszony Ray Tracing
Na zajęcia z systemów rozproszonych postanowiłem rozwinąć lekko swój projekt ray tracera, tworzony w zeszłym roku.
Projekt oparty został o bibliotekę QT w wersji 4.5. Komunikacja odbywa się za pomocą socketów TCP.
Architektura tego rozwiązania opiera się o 3 elementy:
- Klient – program, w którym operuje użytkownik chcący wygenerować obraz metoda ray tracing.
- Serwer zarządzający – który rozsyła części obrazu do generowania przez serwery robocze
- Serwery robocze – pracujące nad generowaniem poszczególnych części obrazu.
Jak to bywa w projektach studenckich, także i ten jest napisany obecnie dość chaotycznie i zawiera na pewno wiele błędów. Będą one jednak usuwane z biegiem czasu, a w chwili obecnej istotne jest raczej to, że projekt mniej więcej działa
Na początek jeden screen klienta:

Projekt został wrzucony na code.google.com i znajduje się pod adresem: http://code.google.com/p/distributedraytracing/.
Sama biblioteka ray tracera jest osobną dll’ką i jest nieco niedopracowana. Postaram się, bliżej wakacji, poprawić wszystkie błędy w niej zawarte i wprowadzić obsługę standardowych formatów scen (obecnie stosowany jest system niestandardowy, lecz dorzucone są przykładowe sceny).
Postaram się w przyszłości opisać niektóre fragmenty tego rozwiązania.
Ray Tracing – Przecięcie promienia i cylindra
Aktualnie zajmuję się stworzeniem wolumetrycznego efektu dymu. Zarówno do tego przedsięwzięcia, jak i do testów przecięć z typowymi prymitywami może być potrzebny test przecięcia promienia (raya) i cylindra.
Jak to zrobić?
Otóż, jeżeli mamy nasz promień w postaci
R = Origin + V * Direction
oraz równanie cylindra w postaci..
OpenCL – język obliczeń równoległych – już jest!
5 grudnia br. została upubliczniona wersja 1.0 specyfikacji języka OpenCL (Open Computing Language), który ma być pomostem pomiędzy API poszczególnych technologii równoległego przetwarzania danych na GPU i CPU (między innymi w technologii NVidia CUDA, ATI Stream na procesorach Cell (tych z PS3
).
Khronos Group (twórca specyfikacji) chwali się tym, iż język ten ma zapewnić pełną niezależność języka od wykorzystanej technologii, a lista firm zaangażowanych w projekt, czyli: 3DLABS, Activision Blizzard, AMD, Apple, ARM, Barco, Broadcom, Codeplay, Electronic Arts, Ericsson, Freescale, HI, IBM, Intel, Imagination Technologies, Kestrel Institute, Motorola, Movidia, Nokia, NVIDIA, QNX, RapidMind, Samsung, Seaweed, Takumi, Texas Instruments i Umeå University uspokaja mnie, jeżeli chodzi o powodzenie tego projektu
Wcześniej zajmowałem się stricte technologią CUDA, ale z racji tego iż gdzieś na półce kurzy się moje PS3, to technologię tą zacznę wykorzystywać z jeszcze większą chęcią.
W najbliższym czasie postaram się opisać szerzej język OpenCL (jak tylko przeczytam specyfikację
), a także sprawdzę na ile język ten jest wygodny, elastyczny i.. czy działa.
A jeżeli zadziała, może być ciekawie





