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ść).
Bump mapping
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:
Ray Tracing - Scala - tekstury
Kod projektu znajduje się w repozytorium: http://code.google.com/p/scala-raytracer/source/browse/
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.
Scala Ray Tracing
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 🙂
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:
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.
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..
Żeby zacząć zabawę, należy kupić zabawkę.
Postanowiłem zaopatrzyć się w sprzęt, który pozwoli w pełni wykorzystać technologię CUDA do obliczeń związanych z ray tracingiem. Zdecydowałem się na Asusa GTX260, który nie miał zbyt wygórowanej ceny, ale oferował to co misie lubią najbardziej, czyli dużo “thread proccessors”. Sprzęcik wygląda mniej więcej tak:
Asus GTX260
Jeżeli chodzi o mechanizm CUDA, początkowo (czego nie dotyczytałem wcześniej) okazało się, że funkcje __global__, __device__ (czyli te uruchamiane na karcie graficznej), nie obsługują rekursji! Więc algorytm rekursywnych testów przecięć się nie sprawdzi. Może jednak uda się zaimplementować równoległe przeprowadzanie testów cieni, co w przypadku scen z dużą liczbą świateł, może dość mocno przyspieszyć generowanie obrazu.
W kolejnych postach postaram się zaprezentować przykładowe zastosowanie CUDA do szybkich obliczeń, a także powiedzieć coś więcej o samej technologii.
