Prawie jak DirectX

2008-09-14 23:28

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ł ;]

Be Sociable, Share!
Be Sociable, Share!
Tags: ,
Author: Xion, posted under Programming, Studies »


8 comments for post “Prawie jak DirectX”.
  1. SirMike:
    September 15th, 2008 o 15:37

    Zarzucisz jakims jarem? Albo chociaz apletem? :)

  2. bs.mechanik:
    September 15th, 2008 o 15:47

    Hmm.. Software’owy render, no to rozumiem – ale czemu akurat w javie?
    Choc przyznam, ze “projekt uczelniany” wiele mowi ;)

  3. Counterclockwise:
    September 15th, 2008 o 19:28

    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?

  4. Xion:
    September 16th, 2008 o 15:00

    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 ;)

  5. Charibo:
    September 16th, 2008 o 17:05

    Trochę aliasuje ;p

  6. lukaszw:
    September 16th, 2008 o 17:10

    Pewnie jakby nie “aliasowało” to żaden współczesny komp by tego nie uciągnął :P

  7. czoper:
    September 18th, 2008 o 10:37

    heh, mam nadzieję dzisiaj swój projekt oddać ;) Wniosek po napisaniu własnej implementacji cieniowania Gouraud – niech nam żyje DirectX i OpenGL

  8. Sabre:
    October 6th, 2008 o 15:01

    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.

Comments are disabled.
 


© 2023 Karol Kuczmarski "Xion". Layout by Urszulka. Powered by WordPress with QuickLaTeX.com.