Przedwczoraj w końcu udało mi się skończyć pewien “drobny” projekt, który – pomimo tego że był ściśle związany z programowaniem grafiki – nie należał wcale do lekkich, łatwych i przyjemnych. To pewnie dlatego, że chodzi tu o software’owy renderer, który (na)pisałem w Javie (!) jako projekt uczelniany. Niewykluczone, że niektórzy pamiętają jeszcze, o co chodzi ;-)
W wymaganiach przewidziana była na szczęście tylko jedna, za to konkretna scena – mianowicie pewien znany skądinąd most. W porównaniu z oryginałem nie wyszedł on może specjalnie imponująco, ale nie zapominajmy, że każdy z jego pikseli musiał zostać pieczołowicie wyliczony przez biedny procesor ;) Rezultaty prezentują się zaś następująco:
I wprawdzie tego nie widać, ale manipulowanie tą sceną (złożoną z kilkuset trójkątów) mogło się odbywać w sposób całkiem płynny – o ile oczywiście powiększenie nie było zbyt duże :) Tym niemniej nie wróżę jednak temu rozwiązaniu zbyt wielu praktycznych zastosowań. Co oczywiście ani na jotę nie zmienia faktu, że jego implementacja okazała się całkiem pouczająca. Jednym z praktycznych wniosków jest chociażby to, że modelowanie za pomocą ręcznego opisywania sceny we własnym formacie opartym na XML to zdecydowanie nie jest dobry pomysł ;]
Zarzucisz jakims jarem? Albo chociaz apletem? :)
Hmm.. Software’owy render, no to rozumiem – ale czemu akurat w javie?
Choc przyznam, ze “projekt uczelniany” wiele mowi ;)
Hehe, pamiętam dokładnie ten projekt. Pisałem go ponad 2 lata temu, ale ja miałem dynamicznie generowane fraktalne drzewo 3d.
Niektórzy mieli mosty, a więc prowadzący są wtórni :)
A dlaczego w Javie? Z tego co ja pamiętam u nas większość pisała w c++. Chyba w przypadku rysowania per pixel w javie wydajność kuleje z założenia?
Odpowiadając na pytania:
– Nie mam bladego pojęcia jak tworzyć release’owe wersje aplikacji Javowych w przypadku, gdy korzystają one z zewnętrznych bibliotek (w tym przypadku JOGL-a). A ponieważ poznawanie tego tematu nie wydaje mi się specjalnie potrzebne w tym momencie, więc… hmm… :)
– Projekt jest w Javie, bo jego ideą było to, aby w tak zwanym międzyczasie był on też projektem zaliczeniowym na przedmiot pt. “Java 2”. W teorii miało to być oszczędnością czasu, w praktyce wyszło nieco inaczej ;)
– Ciężko powiedzieć co najbardziej zwalnia cały proces renderowania, bo nie wykonywałem tu żadnego profilowania. Piksele są stawiane jako point sprites, więc ewentualnie strzelałbym właśnie w to – lub ewentualnie w samo liczenie pozycji i koloru każdego piksela, jako że trochę ich jednak jest.
W przypadku renderowania sceny przy takim widoku, jaki jest na screenach, program wyciąga jakieś 8-9FPS. Przy większym zoomie jest oczywiście “nieco” gorzej ;)
Trochę aliasuje ;p
Pewnie jakby nie “aliasowało” to żaden współczesny komp by tego nie uciągnął :P
heh, mam nadzieję dzisiaj swój projekt oddać ;) Wniosek po napisaniu własnej implementacji cieniowania Gouraud – niech nam żyje DirectX i OpenGL
Rysowanie “Per Pixel” w Javie moze byc calkiem wydajne nawet korzystajac zjava.awt.BufferedImage. Istotne jest, by od razu stworzyc obiekt zgody z kontekstem graficznym a pozniej korzystajac z niego nie doprowadzic do sytuacji gdy przestanie byc “zarzadzany” ( ang managed ) W skrocie :
ZLE :
1) myBufferedImage.getRaster().getDataBuffer();
2) myBufferedImage.{get,set}.RGB(…)
DOBRZE :
myBufferedImage.getRaster().getDataElements()
myBufferedImage.getRaster().setDataElements()
To drobiazg, ale roznice w wydajnosci moga dochodzic do dwoch\trzech rzedow wielkosci przy niektorych operacjach.
Wydajnosc biblioteki Swing jest czesto poddawana w watpliwosc, czasami zreszta slusznie, ale w wiekszosci przypadkow jest to efektem niewiedzy.