Programmazione grafica 3D in Java, Parte 3: OpenGL

È passato un po 'di tempo dalla nostra ultima puntata di questa serie sulla programmazione grafica 3D in Java (ne parleremo più alla fine di questa colonna). Ecco un rapido aggiornamento su ciò di cui stavamo discutendo l'ultima volta e da dove avevamo interrotto.

Nelle due colonne precedenti (vedi Risorse), abbiamo esplorato Java 3D. Abbiamo discusso di contenuto statico e scene piccole, quindi abbiamo utilizzato grafici di scene più grandi e abbiamo integrato l'interattività in alcuni mondi 3D di base.

Ora che sai qualcosa sull'uso di Java 3D, è il momento di confrontare e confrontare l'approccio Java 3D alla grafica 3D con il principale concorrente di API grafiche: OpenGL.

Si prega di notare che questo articolo era originariamente concepito per essere ad alta intensità di codice, ma la decisione tardiva di Arcane Technologies riguardo al binding di Magician (vedi sotto) ha richiesto la rimozione degli esempi di codice. Spero che il contenuto di questo articolo possa essere adattato per un futuro binding Java-OpenGL, non ancora disponibile da OpenGL Consortium.

In ogni caso, ho cercato di fornire tutti i riferimenti e gli URL pertinenti e utili relativi a OpenGL nelle risorse alla fine di questa colonna. Se desideri approfondire Java-OpenGL, ti consiglio vivamente di rivedere questi riferimenti.

Confronto Java-OpenGL con Java 3D

Nelle puntate precedenti su Java 3D, ho fornito un elenco dei punti di forza e di debolezza dell'utilizzo di Java 3D per applicazioni grafiche. Riprendiamo l'elenco, ma lo facciamo esaminando i punti di forza e di debolezza delle soluzioni basate su Java-OpenGL invece delle soluzioni basate su Java 3D.

Punti di forza dell'utilizzo di OpenGL (e, per estensione e dove indicato, collegamenti Java-OpenGL):

  • OpenGL fornisce un modello procedurale di grafica

    Ciò corrisponde strettamente a molti degli algoritmi e dei metodi che i programmatori grafici hanno utilizzato storicamente. Il modello procedurale è allo stesso tempo intuitivo e diretto per molti esperti appassionati di grafica 3D.

  • OpenGL fornisce l'accesso diretto alla pipeline di rendering

    Questo è vero con uno qualsiasi dei vari collegamenti linguistici, inclusa la maggior parte dei collegamenti Java. OpenGL consente ai programmatori di specificare direttamente come la grafica dovrebbe essere resa. Uno non si limita a suggerire e richiedere come con Java 3D, si stipula.

  • OpenGL è ottimizzato in ogni modo immaginabile

    OpenGL è ottimizzato in hardware e software e piattaforme mirate che vanno dai PC e console di gioco più economici ai supercomputer grafici di fascia alta.

  • I fornitori di ogni tipo di hardware relativo alla grafica 3D supportano OpenGL

    OpenGL è

    il

    standard rispetto al quale i fornitori di hardware misurano la loro tecnologia grafica, nessuno escluso. Poiché Microsoft si è unita a SGI nell'iniziativa Fahrenheit, è diventato sempre più ovvio per molti che questo è in effetti il ​​riconoscimento indiretto di Microsoft che OpenGL ha vinto le guerre API per la grafica 2D e 3D.

D'altra parte, niente è perfetto. OpenGL, e certamente i collegamenti Java-OpenGL, hanno alcune carenze significative:

  • I punti di forza dell'approccio procedurale alla programmazione grafica sono contemporaneamente un punto debole per molti programmatori Java

    Per i programmatori relativamente nuovi, molti dei quali potrebbero aver ricevuto la loro prima istruzione di programmazione formale in Java utilizzando metodologie orientate agli oggetti, il metodo procedurale di OpenGL non si sposa bene con un approccio orientato agli oggetti e una buona pratica ingegneristica.

  • Le ottimizzazioni OpenGL di molti fornitori hanno lo scopo di ridurre la scelta dell'hardware

    È nell'interesse di ogni fornitore creare estensioni proprietarie e fare ottimizzazioni proprietarie per vendere più del proprio hardware. Come per tutte le ottimizzazioni hardware, è necessario utilizzare ottimizzazioni OpenGL specifiche per l'acceleratore con la consapevolezza che ogni ottimizzazione per una piattaforma diminuisce la portabilità e le prestazioni per molte altre. Le ottimizzazioni più generali di Java 3D mirano principalmente a massimizzare la portabilità delle applicazioni Java 3D.

  • Mentre le interfacce C per OpenGL sono onnipresenti, le interfacce Java non sono ancora standardizzate e non sono ampiamente disponibili

    Fino a poco tempo fa, il prodotto Magician di Arcane Technologies era stato sul mercato per modificare questo problema di portabilità, ma con la sua fine si svolge gran parte della storia multipiattaforma per Java-OpenGL, almeno al momento. Maggiori informazioni su questo di seguito.

  • L'esposizione da parte di OpenGL dei dettagli interni del processo di rendering può complicare notevolmente i programmi di grafica 3D altrimenti semplici

    Potenza e flessibilità vengono al prezzo della complessità. Nei rapidi cicli di sviluppo del mondo tecnologico di oggi, la complessità è di per sé qualcosa da evitare ove possibile. Il vecchio adagio sui bug è vero: più righe di codice, più bug (in generale).

Come puoi vedere dai pro e contro degli approcci basati su OpenGL, Java-OpenGL è forte in molte delle aree in cui Java 3D è debole. OpenGL offre ai programmatori l'accesso di basso livello al processo di rendering che Java 3D evita esplicitamente, e OpenGL è attualmente disponibile su molte più piattaforme rispetto a Java 3D (Magician a parte). Ma questa flessibilità ha un prezzo potenziale: i programmatori hanno molto spazio per ottimizzare, il che, al contrario, significa che hanno molto spazio per rovinare le cose. Java 3D ha una maggiore ottimizzazione incorporata e un modello di programmazione più semplice che può rivelarsi particolarmente utile per i programmatori che non conoscono Java, il lavoro di grafica 3D o la programmazione grafica in rete e distribuita.