MokaByte Numero 24  -  Novembre 98
 
Il seminario
su Java 3D
di 
M. Bigatti
Breve resoconto del seminario su Java 3D tenutosi a Milano il 22 ottobre 

 


 


Il 22 ottobre scorso si è tenuto, presso il Centro Direzionale Colleoni (Milano) – sede della Sun Microsystems Italia – il seminario Java3D (API per la grafica 3D in tempo reale). L’incontro era parte del worldwide tour organizzato da Sun per diffondere e promuovere l’uso di Java3D. All’incontro hanno partecipato Ken Tallman (ken.tallman@sun.com), product manager di Sun per Java3D e Mason Woo (mason@woo.com), un consulente indipendente della World Wide Woo, che ha lavorato per una decina d’anni alla Silicon Graphics su OpenGL.

 
 
 
 

 

Introduzione

Il seminario si è aperto con una presentazione del prodotto Java3D da parte di Ken Tallman in cui sono stati posti in evidenza i punti chiave di Java3D:

Lo slogan “Write once, run anywhere” è stato adattato dal marketing Sun di Java3D a “Write once, view anywhere”, focalizzando l’attenzione sulla portabilità delle applicazioni o applet realizzate con Java3D. Al termine della presentazione, la parola è passata a Mason Woo, che, attraverso quasi un centinaio di diapositive, nel corso del resto della giornata, ha presentato tecnicamente le API del prodotto.
 

Il motore di Java3D

Java 3D, estensione standard di Java, consente la produzione in tempo reale di grafica 3D tramite un insieme di API omogenee e multipiattaforma. 
Java3D non si occupa del rendering a basso livello delle immagini: questa operazione è delegata dal motore di rendering di Java3D a librerie native (OpenGL, Direct3D). Le feature disponibili, infatti, sono un insieme standard di caratteristiche riscontrabili in queste librerie native. Ad esempio non è possibile gestire le ombre degli oggetti o le texture animate, come le superfici trasparenti o gli specchi. Ma queste non sono limitazioni di Java3D, ma delle librerie native. Le operazioni citate sono infatti molto dispendiose in termini di risorse e non vengono utilizzate in grafica 3D in tempo reale. È lecito aspettarsi che quando l’evoluzione tecnologica porterà gli standard 3D a supportare questo tipo di caratteristiche, anche Java3D ne fornirà il supporto.
Java3D non è però solo un semplice wrapper su API esistenti: il suo motore si occupa anche di ottimizzazioni e operazioni aggiuntive che non sono previste nella API native. Il motore sceglie l’ordine di attraversamento dell’albero degli oggetti 3D e non è limitato ad una direzione di tipo sinistra-destra o sopra-sotto (eccetto per quanto riguarda attributi con limiti di spazio come le sorgenti di luce o l’effetto nebbia), quindi può ottimizzare la visualizzazione.
Il motore è concettualmente un ciclo infinito che effettua una fase di render ogni ciclo rielaborando ogni volta eventuali modifiche apportate e passando ad una fase di idle al termine delle modifiche necessarie. Cosa interessante, il sistema è inoltre aperto all’elaborazione parallela.
Java3D è costruito su AWT ed è con questo perfettamente compatibile. Entrambi infatti sono di tipo heavyweight. Swing (Java Foundation Classes), invece è di tipo lightweight ed è quindi incompatibile con Java3D. Non è prevista a breve una soluzione al problema in quanto a Java3D sono strettamente necessarie le coordinate fisiche in cui effettuare il rendering. Per il momento l’interfaccia utente di supporto alle applicazioni (o applet) Java3D dovranno fare uso esclusivamente di AWT.
 
 
 

La struttura dati

Java3D permette di definire scene graph (ambienti in cui sono presenti oggetti 3D) ed organizza gli oggetti necessari a descrivere l’universo virtuale tramite un albero. Gli oggetti appartenenti all’albero non sono omogenei (come ad esempio in un albero binario utilizzato per mantenere un insieme di dati ordinati), ma sono di tipi diversi. La radice dell’albero è un oggetto VirtualUniverse e serve come punto di riferimento per gli altri oggetti. Da questo discende un oggetto di classe Locale (attenzione a non confonderla con la classe utilizzata per i supporto alla internazionalizzazione delle applicazioni) che consente di definire la posizione all’interno dell’universo. Da Locale discendono oggetti di classe BranchGroup e TransformGroup. Da quest’ultimo, sul lato destro dell’albero discende un ViewPlatform a cui è collegato un View. Questi oggetti servono per definire l’osservatore della scena. Sul lato sinistro sono presenti gli oggetti 3D (sottoclassi di Shape3D). La costruzione di un albero Java3D non è banale, infatti è presente una utility (la classe SimpleUniverse) che consente di creare in automatico un semplice universo. L’universo base creato da SimpleUniverse è simile a quanto descritto in precedenza con la sola eccezione del braccio sinistro dell’albero che non viene creato. L’insieme degli oggetti che dovranno essere presenti nella scena deve essere creato manualmente.
L’unica classe presente in Java3D che definisce una forma geometrica è Shape3D. Per definire forme specifiche è necessario fare riferimento alle classe utility presenti nel pacchetto. Alcune forme disponibili sono: Box, Sphere, Cylinder, Cone. La scelta di non comprendere nei core package forme specifiche è dettata dal fatto che le core API di Java3D si intendono mantenere il più semplici possibile. Anche funzionalità future verranno molto probabilmente inserite negli utility package. Per collegare gli oggetti 3D al lato sinistro dell’oggetto Locale è necessario utilizzare oggetti di classe BranchGroup e TransformGroup, come si è visto per il lato destro dell’albero. Oggetti di queste classi permettono di collegare le forme geometriche tra di loro (Branch) e di applicare trasformazioni (Transform), quali la geometria (Geometry), la posizione della luce, la vista.
Per ottimizzare ulteriormente le prestazioni è possibile compilare tutta una parte dell’albero. Una volta compilato il ramo, però, non sarà più possibile effettuare variazioni su di esso.
 

Attributi e collisioni

Java3D può gestire diversi attributi, sia per quanto riguarda i colori, che le linee o i poligoni. Alcune di queste comprendono il Gouraud shading per i colori, l’antialiasing per le linee o i punti, o le modalità di riempimento dei poligoni: punti, wire frame o filled. Inoltre vengono gestite le texture mapping – anche in questo caso le limitazioni delle librerie native (in questo caso OpenGL) sono riportate sullo strato Java3D. Le immagini da utilizzare come texture devono infatti avere dimensioni come potenze del due.
Java3D gestisce inoltre le collisioni tra oggetti. Questa caratteristica è stata dimostrata tramite un programma di prova che implementava due racchette ed una pallina da tennis. La pallina, una volta colpita dalla racchetta, inverte la direzione. Il movimento degli oggetti è ottenuto tramite Interpolatori. Questi oggetti consentono di modificare i parametri di un oggetto di classe TransformGroup (come degli attributi del materiale degli oggetti) e intervengono sui colori, la posizione, la rotazione, la scala ed altro.
 

Conclusione

Java3D consente, con relativa semplicità, di produrre applicazioni o applet dotate di grafica 3D. L’utilizzo di librerie native garantisce prestazioni accettabili (il seminario si è tenuto utilizzando una macchina SPARC non di ultima generazione – tutte quelle nuove erano allo Smau) mentre l’interfaccia Java fornisce portabilità e il progetto generale una buona semplicità d’uso anche se da l’idea di essere stato sviluppato un po’ in disparte rispetto alle altre tecnologie Java. L’incompatibilità con Swing ne è un esempio (come la classe Locale che trova un duplicato in java.util) che potrebbe frenare progetti ambiziosi su Java3D. Nonostante ciò Java3D completa l’offerta della piattaforma Java con un elemento chiave quale la grafica 3D fornendo un ulteriore e valido tassello alla tecnologia globale Java.
 
 


MokaByte Web  1998 - www.mokabyte.it 
MokaByte ricerca nuovi collaboratori. 
Chi volesse mettersi in contatto con noi può farlo scrivendo a mokainfo@mokabyte.it