English (UK)

Introduzione a Java3D PART 4

Tratto da programmazione.it, scritto da Dario Guadagno

In quest'ultima parte, tratteremo alcuni problemi che si potrebbero verificare durante la scrittura di programmi in grafica 3D in ambiente Java, e saranno spiegati alcuni dettagli relativi al motore 3D.

Come accennato nella prima parte dell'articolo, Java3D si appoggia su librerie native, per cui è da esse che deriva le proprie feature principali, mentre non è in grado di fornire supporto per alcune funzionalità, come la gestione delle ombre o delle texture animate, superfici trasparenti o specchi). Tuttavia, 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 nelle API native. Il runtime engine sceglie l’ordine di attraversamento dell’albero e non è limitato ad una direzione di tipo sinistra-destra o sopra-sotto, quindi può utilizzare strategie per l'ottimizzazione della visualizzazione. La rappresentazione di un'immagine tridimensionale avviene seguendo il seguente schema:

  • definizione del view volume, ovvero della porzione di spazio visibile all’utente;
  • rendering: conversione del view volume in un’immagine 2D;
  • rasterization: l’immagine viene convertita in una griglia di pixel;
  • shading: viene impostato il colore dei pixel.

Tutte le suddette operazioni sono eseguite direttamente, e in maniera trasparente a programmatore ed utente, dalla Java Virtual Machine, che immediatamente dopo, mostra l’effettiva scena attiva, pronta all’eventuale interazione. Ulteriori problematiche potrebbero essere connesse ad altre due segnalazioni: le classi di Java 3D non sono serializzabili e, come noto, richiedono un notevole impiego di risorse. Quest'ultimo punto, in particolare, merita una cura in più: se da un lato, chiaramente, esso determina un rallentamento nelle prestazioni, peraltro piuttosto lieve e sicuramente accettabile, dall'altro, in caso di scene particolarmente complesse e cariche di oggetti, può addirittura causare il crash dell'applicazione per problemi di insufficienza di memoria (Out of Memory Error).

Il problema si presenta perché, di default, la JVM ricorre ad un heap di dimensioni contenute, ideale per la maggior parte delle applicazioni eseguite, ma non sufficiente nel caso di sistemi più complessi. È possibile aggirare tale rischio ampliando l’heap a disposizione della JVM, specificando dei parametri aggiuntivi all’atto di mandare in esecuzione l'applicazione. Il progetto, in generale, presenta una certa semplicità d’uso anche se dà 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 alcune limitazioni e complessità aggiuntive, comunque, è indubbio che Java3D sia un potentissimo strumento a disposizione dei programmatori Java. Le Api completano l’offerta della piattaforma, introducendo un elemento chiave quale la grafica 3D e fornendo un'ulteriore preziosa funzionalità all'intera tecnologia Java.


© 2017 Bruno Tessaro. My life in the web. All right reserved.