Programowanie grafiki 3D w Javie, Część 3: OpenGL

Minęło trochę czasu od naszej ostatniej części z tej serii poświęconej programowaniu grafiki 3D w Javie (więcej o tym na końcu tej kolumny). Oto krótkie przypomnienie tego, o czym ostatnio rozmawialiśmy i gdzie zakończyliśmy.

W poprzednich dwóch kolumnach (zobacz Zasoby) omówiliśmy język Java 3D. Omówiliśmy zawartość statyczną i małe sceny, a następnie wykorzystaliśmy większe wykresy scen i wbudowaliśmy interaktywność w kilka podstawowych światów 3D.

Teraz, gdy wiesz już trochę o używaniu Java 3D, czas porównać i porównać podejście Java 3D do grafiki 3D z czołowym rywalem graficznego API: OpenGL.

Zwróć uwagę, że ten artykuł pierwotnie miał być intensywnym kodem, ale późna decyzja Arcane Technologies dotycząca powiązania Magician (patrz poniżej) wymagała usunięcia przykładów kodu. Mam nadzieję, że treść tego artykułu będzie mogła zostać dostosowana do przyszłego powiązania Java-OpenGL, które jest jeszcze niedostępne w Konsorcjum OpenGL.

W każdym razie starałem się podać wszystkie istotne i przydatne odniesienia i adresy URL związane z OpenGL w Zasobach na końcu tej kolumny. Jeśli chcesz zagłębić się w Java-OpenGL, zdecydowanie zalecam przejrzenie tych odniesień.

Porównanie Java-OpenGL z Java 3D

W poprzednich odsłonach dotyczących języka Java 3D przedstawiłem listę mocnych i słabych stron korzystania z języka Java 3D w aplikacjach graficznych. Powtórzmy tę listę, ale zróbmy to, patrząc na mocne i słabe strony rozwiązań opartych na Java-OpenGL zamiast rozwiązań opartych na Java 3D.

Mocne strony korzystania z OpenGL (oraz, zgodnie z rozszerzeniem i tam, gdzie to zaznaczono, powiązania Java-OpenGL):

  • OpenGL zapewnia proceduralny model grafiki

    Jest to ściśle zgodne z wieloma algorytmami i metodami używanymi przez programistów graficznych w przeszłości. Model proceduralny jest jednocześnie intuicyjny i prosty dla wielu utalentowanych miłośników grafiki 3D.

  • OpenGL zapewnia bezpośredni dostęp do potoku renderowania

    Dotyczy to wszystkich różnych powiązań językowych, w tym większości powiązań Java. OpenGL umożliwia programistom bezpośrednie określanie sposobu renderowania grafiki. Jeden wymaga nie tylko podpowiedzi i żądań, jak w przypadku Java 3D .

  • OpenGL jest zoptymalizowany na każdy możliwy sposób

    OpenGL jest zoptymalizowany pod względem sprzętu i oprogramowania oraz platform docelowych, od najtańszych komputerów PC i konsol do gier po najbardziej zaawansowane superkomputery graficzne.

  • Sprzedawcy wszelkiego rodzaju sprzętu związanego z grafiką 3D obsługują OpenGL

    OpenGL jest

    the

    standard, w stosunku do którego dostawcy sprzętu mierzą swoją technologię graficzną, bez wyjątku. Gdy Microsoft połączył się z SGI w inicjatywie Fahrenheit, dla wielu stało się coraz bardziej oczywiste, że jest to w efekcie pośrednie potwierdzenie Microsoftu, że OpenGL wygrał wojny API dla grafiki 2D i 3D.

Z drugiej strony nic nie jest idealne. OpenGL i na pewno wiązania Java-OpenGL mają kilka istotnych wad:

  • Mocne strony proceduralnego podejścia do programowania graficznego są jednocześnie słabością wielu programistów Java

    Dla stosunkowo nowych programistów, z których wielu mogło otrzymać pierwsze formalne instrukcje programowania w Javie przy użyciu metodologii obiektowych, metoda proceduralna OpenGL nie pasuje dobrze do podejścia zorientowanego obiektowo i dobrych praktyk inżynierskich.

  • Optymalizacje OpenGL wielu dostawców mają na celu zmniejszenie wyboru sprzętu

    W interesie każdego dostawcy leży tworzenie własnych rozszerzeń i wprowadzanie własnych optymalizacji, aby sprzedawać więcej własnego sprzętu. Podobnie jak w przypadku wszystkich optymalizacji sprzętowych, należy zastosować optymalizacje OpenGL specyficzne dla akceleratora, przy założeniu, że każda optymalizacja dla jednej platformy zmniejsza przenośność i wydajność kilku innych. Bardziej ogólne optymalizacje Java 3D mają głównie na celu maksymalizację przenośności aplikacji Java 3D.

  • Chociaż interfejsy C do OpenGL są wszechobecne, interfejsy Java nie są jeszcze znormalizowane i nie są powszechnie dostępne

    Produkt Magician firmy Arcane Technologies do niedawna był na rynku, aby zmienić ten problem z przenośnością, ale wraz z jego upadkiem wiele platform dotyczy Java-OpenGL, przynajmniej obecnie. Więcej na ten temat poniżej.

  • Ujawnienie przez OpenGL wewnętrznych szczegółów procesu renderowania może znacznie skomplikować, skądinąd proste programy graficzne 3D

    Siła i elastyczność kosztują złożoność. W szybkich cyklach rozwoju dzisiejszego świata technologii złożoność jest sama w sobie czymś, czego należy unikać, jeśli jest to możliwe. Stare powiedzenie o błędach jest prawdziwe: im więcej wierszy kodu, tym więcej błędów (ogólnie).

Jak widać z zalet i wad podejść opartych na OpenGL, Java-OpenGL jest silna w wielu obszarach, w których Java 3D jest słaba. OpenGL daje programistom niskopoziomowy dostęp do procesu renderowania, którego Java 3D wyraźnie unika, a OpenGL jest obecnie dostępny na znacznie większej liczbie platform niż Java 3D (pomijając Magician). Ale ta elastyczność ma potencjalną cenę: programiści mają dużo miejsca na optymalizację, co odwrotnie oznacza, że ​​mają dużo miejsca na zepsucie rzeczy. Java 3D ma bardziej wbudowaną optymalizację i łatwiejszy model programowania, co może okazać się szczególnie przydatne dla programistów, którzy nie znają języka Java, prac z grafiką 3D lub programowania w grafice sieciowej i rozproszonej.