Програмиране на 3D графика в Java, Част 3: OpenGL

Измина известно време от последната ни вноска в тази поредица за програмиране на 3D графики в Java (повече за това в края на тази колона). Ето кратко опресняване на това, което последно обсъждахме и къде спряхме.

В предишните две колони (вж. Ресурси) изследвахме Java 3D. Обсъждахме статично съдържание и малки сцени, след това използвахме по-големи графики на сцени и вградихме интерактивност в някои основни 3D светове.

Сега, след като знаете малко за използването на Java 3D, е време да сравните и сравните подхода на Java 3D към 3D графики с водещия претендент за графичен API: OpenGL.

Моля, обърнете внимание, че тази статия първоначално е била предназначена за интензивен код, но последващото решение на Arcane Technologies относно обвързването Magician (виж по-долу) налага премахването на примерите за кодове. Надявам се, че съдържанието на тази статия може да бъде адаптирано за бъдещо свързване на Java-OpenGL, но все още недостъпно от консорциума OpenGL.

Във всеки случай се постарах да предоставя всички подходящи и полезни референции и URL адреси, свързани с OpenGL, в Ресурсите в края на тази колона. Ако искате да се задълбочите в Java-OpenGL, силно препоръчвам да прегледате тези препратки.

Java-OpenGL сравнение с Java 3D

В предишни вноски на Java 3D предоставих списък на силните и слабите страни на използването на Java 3D за графични приложения. Нека повторим този списък, но го направете, като разгледате силните и слабите страни на решенията, базирани на Java-OpenGL, вместо решенията, базирани на Java 3D.

Силни страни на използването на OpenGL (и, като разширение и където е отбелязано, свързвания Java-OpenGL):

  • OpenGL предоставя процедурен модел на графика

    Това съвпада с много алгоритми и методи, които графичните програмисти са използвали в миналото. Процедурният модел е едновременно интуитивен и ясен за много завършени любители на 3D графиката.

  • OpenGL осигурява директен достъп до конвейера за рендиране

    Това важи за всеки от различните езикови обвързвания, включително повечето обвързвания на Java. OpenGL дава възможност на програмистите директно да определят как да се изобразяват графики. Човек не просто намеква и иска, както при Java 3D, както се посочва.

  • OpenGL е оптимизиран по всеки възможен начин

    OpenGL е оптимизиран за хардуер и софтуер и целеви платформи, вариращи от най-евтините персонални компютри и игрови конзоли до най-високите графични суперкомпютри.

  • Доставчиците на всякакъв вид хардуер, свързан с 3D графики, поддържат OpenGL

    OpenGL е

    на

    стандарт, спрямо който производителите на хардуер измерват графичната си технология, няма никакви. Тъй като Microsoft се присъедини към SGI в инициативата по Фаренхайт, за мнозина става все по-очевидно, че това всъщност е непрякото признание на Microsoft, че OpenGL спечели API войните за 2D и 3D графики.

От друга страна, нищо не е идеално. Свързването на OpenGL и със сигурност Java-OpenGL има някои съществени недостатъци:

  • Силните страни на процедурния подход към графичното програмиране са едновременно слабост за много Java програмисти

    За сравнително нови програмисти, много от които може да са получили първите си официални инструкции за програмиране в Java, използвайки обектно-ориентирани методологии, процедурният метод на OpenGL не се съчетава добре с обектно-ориентиран подход и добра инженерна практика.

  • Оптимизацията на OpenGL за много производители има за цел да намали избора на хардуер

    В интерес на всеки доставчик е да изгради собствени разширения и да направи собствени оптимизации, за да продава повече от собствения си хардуер. Както при всички хардуерни оптимизации, трябва да използвате специфични за ускорителя OpenGL оптимизации с разбирането, че всяка оптимизация за една платформа намалява преносимостта и производителността на няколко други. По-общите оптимизации на Java 3D имат за цел най-вече да увеличат преносимостта на Java 3D приложенията.

  • Докато C интерфейсите към OpenGL са повсеместни, Java интерфейсите все още не са стандартизирани и не са широко достъпни

    Продуктът на Arcane Technologies Magician доскоро беше на пазара, за да промени този проблем с преносимостта, но с неговото угасване отива голяма част от историята на различни платформи за Java-OpenGL, поне в момента. Повече за това по-долу.

  • Излагането на OpenGL на вътрешните детайли на процеса на рендиране може значително да усложни иначе опростените 3D графични програми

    Мощността и гъвкавостта идват на цената на сложността. В бързите цикли на развитие в съвременния технологичен свят сложността сама по себе си е нещо, което трябва да се избягва, когато е възможно. Старата поговорка за грешки е вярна: колкото повече редове код, толкова повече грешки (като цяло).

Както можете да видите от плюсовете и минусите на подходите, базирани на OpenGL, Java-OpenGL е силен в много от областите, в които Java 3D е слаб. OpenGL дава на програмистите достъп на ниско ниво до процеса на рендиране, който Java 3D изрично избягва, а OpenGL понастоящем се предлага на много повече платформи от Java 3D (настрана Magician). Но тази гъвкавост идва с потенциална цена: програмистите имат много място за оптимизиране, което обратно означава, че имат много място да объркат нещата. Java 3D има повече вградена оптимизация и по-лесен модел за програмиране, който може да се окаже особено полезен за програмисти, които са нови в Java, 3D графична работа или мрежово и разпределено графично програмиране.