Massimiliano Piscozzi – piscozzi@dico.unimi.it

1. Sistemi multimediali Massimiliano Piscozzi – piscozzi@dico.unimi.it

2. Struttura del corso • Introduzione a X3D • Architettura interna di X3D • Presentazione degli oggetti principali che compongono una scena X3D e corrispondente codifica in XML • Creazione al computer di scene X3D • Utilizzo del software X3D-Edit

3. Introduzione a X3D X3D: eXtensible 3D Cos’è X3D?! • Nuova generazione di specifiche grafiche per la descrizione di contenuti tridimensionali interattivi (ISO Open Standard) • Successore di VRML97 • Nuove funzionalità • Codifica XML • Architettura a componenti più facilmente estendibile Cosa non è X3D?! • Un programma di modellazione / animazione 3D • Un linguaggio di programmazione

4. Aree di applicazione • Presentazioni multimediali • Pagine web • Visualizzazione in ambienti RV immersivi • Mondi virtuali multiutente • Visualizzazione scientifica • Formato di interscambio tra diverse applicazioni 3D Maya Browsers X3D 3D Studio Max

5. Funzionalità di X3D (1) • Grafica 3D Geometria poligonale, geometria parametrica, trasformazioni gerarchiche, illuminazione, materiali e textures • Grafica 2D Testo, forme planari inserite all’interno della gerarchica delle trasformazioni 3D • Animazione Timers e interpolatori per gestire le animazioni in modo continuo, morphing e animazione di umanoidi (H-Anim) • Audio e video Sorgenti audiovisive mappate sugli oggetti geometrici della scena • Navigazione Gestione dei punti di vista, movimento dell’utente nello spazio 3D, test di collisione, prossimità e visibilità

6. Funzionalità di X3D (2) • Interazione con l’utente Sensori per il picking e dragging via mouse, input da tastiera • Oggetti definiti dall’utente Possibilità di estendere le funzionalità built-in del browser creando nuovi data types • Scripting Possibilità di cambiare dinamicamente la scena tramite linguaggi di programmazione e scripting • Networking Possibilità di comporre una scena a partire da risorse distribuite sulla rete, hyperlinking di oggetti verso altre scene o risorse sul web • Simulazione fisica Animazione di umanoidi (H-Anim), dataset geospaziali, integrazione col protocollo DIS (Distributed Interactive Simulation)

7. Struttura del corso • Introduzione a X3D • Architettura interna di X3D • Presentazione degli oggetti principali che compongono una scena X3D e corrispondente codifica in XML • Creazione al computer di scene X3D • Utilizzo del software X3D-Edit

8. Architettura di X3D X3D/VRML files, streams Eventi esterni (pagine Web) Browser Parser API EAI External Authoring Interface SAI Scene Authoring Interface XML VRML classic Binary Scripting Engines (Ecmascript, Java...) X3D Node types Prototype, External Prototype SAI (Scene Authoring Interface) Scene graph manager Scene graph Event graph

9. Eventi esterni (pagine Web) Browser Parser API EAI External Authoring Interface SAI Scene Authoring Interface VRML classic Binary Scripting Engines (Ecmascript, Java...) X3D Node types Prototype, External Prototype SAI (Scene Authoring Interface) Scene graph manager Event graph Architettura di X3D X3D/VRML files, streams • Da cosa è composto lo scene graph?! • Quali sono le dichiarazioni X3D e come codificarle in XML?! XML Scene graph

10. Scene graph (1) Lo scene graph: • è la struttura fondamentale dell’ambiente run-time di X3D • contiene tutti gli oggetti del sistema e le loro relazioni Primitive geometriche Materiali Sorgenti luminose Punti di vista Sensori Sorgenti audio · · · Transformation hierarchy: Descrive le relazioni spaziali fra gli oggetti da visualizzare Behaviour graph: Descrive le connessioni tra i campi degli oggetti e il flusso degli eventi attraverso il sistema

11. Node A Node D Nodi radice Node B Node E Node F Nodi figli Node C Scene graph (2) Lo scene graph: • è un grafo aciclico orientato (DAG – direct acyclic graph) in cui i nodi possono contenere dei campi costituiti da nodi-figli

12. Scene graph Transformation hierarchy (1) All’interno dello scene graph si può individuare una gerarchia delle trasformazioni (transformation hierarchy) che include tutti i nodi radice e i loro discendenti aventi una collocazione nello spazio 3D In base alla transformation hierarchy: • i nodi radice sono posizionati rispetto al sistema di coordinate globale (world) della scena • i nodi figli sono posizionati rispetto ad un sistema di coordinate locale (local) definito in termini di trasformazioni a partire dal sistema di coordinate del nodo padre

13. Sistemi di coordinate locali (rispetto ai nodi padre) y x z Scene graph Transformation hierarchy (2) • Ogni scena X3D definisce implicitamente un sistema di coordinate globali Sistema di coordinate globale

14. Sistemi di coordinate locali (rispetto ai nodi padre) y x z Scene graph Transformation hierarchy (2) • Ogni scena X3D definisce implicitamente un sistema di coordinate globali Sistema di coordinate globale  Le trasformazioni geometriche di un nodo coinvolgono tutti i suoi nodi discendenti

15. Sistemi di coordinate locali (rispetto ai nodi padre) y x z Scene graph Transformation hierarchy (2) • Ogni scena X3D definisce implicitamente un sistema di coordinate globali Sistema di coordinate globale  Le trasformazioni geometriche di un nodo non coinvolgono il nodo padre

16. Scene graph Behaviour graph (1) All’interno dello scene graph vi possono essere delle connessioni (routes) fra campi di nodi distinti  esse costituiscono il behaviour graph Node C Node A Node B Node D Il behaviour graph: • specifica come gli eventi si propagano nel sistema • è modificabile dinamicamente reindirizzando (rerouting), aggiungendo o sopprimendo delle connessioni

17. Timer Interpolatore ConoTransf startTime fraction translation · ·· endTime value fraction key · ·· keyValue · ·· Scene graph Behaviour graph (2) Esempio di routing degli eventi:  al trascorrere del tempo (tra 0 e 5 secondi) il cono si muove dalla posizione A alla posizione B A B

18. L’ambiente run-time L’ambiente run-time di X3D: • visualizza la scena (rendering) • riceve input da diverse sorgenti (sensori) e coordina l’elaborazione degli eventi • gestisce lo stato corrente dello scene graph • gestisce i collegamenti tra il browser X3D e applicazioni esterne per l’hyperlinking e l’accesso tramite API • gestisce il ciclo di vita dei singoli oggetti (sia gli oggetti built-in sia quelli definiti dall’utente)

19. L’object model • Il sistema X3D è costituito da un insieme di entità astratte chiamate oggetti Fields (campi) Derivati dall’oggetto X3DField rappresentano dei concetti semplici come ad esempio valori booleani, stringhe di caratteri, array di valori in virgola mobile, ... Nodes (nodi) Derivati dall’oggetto X3DNode rappresentano dei concetti più complessi e possono contenere uno o più fields per memorizzare dei dati interni o per spedire e ricevere degli eventi  Alcuni oggetti (dichiarazioni ROUTE, PROTO, metadata, informazioni su Components e Profiles) non sono né campi né nodi

20. L’object model: i campi (1) Fields Un campo può contenere: • un singolo valore di un dato tipo (SF...) • un array di valori dello stesso tipo (MF...) Tipi definiti in X3D: • SFBool, MFBool TRUE / FALSE • SFColor, MFColor (R G B) componenti (0,1) • SFColorRGBA, MFColorRGBA (R G B A) componenti (0,1) • SFDouble, MFDouble floating-point in doppia precisione • SFFloat, MFFloat floating-point in singola precisione • SFInt32, MFInt32 intero a 32-bit

21. L’object model: i campi (2) ...tipi definiti in X3D: • SFImage, MFImage immagine bidimensionale non compressa  larghezza, altezza, n° componenti  ‘larghezza x altezza’ valori (pixels) • SFNode, MFNode nodo X3D • SFRotation, MFRotation (x y z a): rotazione di a radianti rispettoall’asse (x y z) • SFString, MFString stringa codificata in UTF-8 • SFTime, MFTime valore in doppia precisione: secondi a partire dal 1° gennaio 1970, 00:00:00 • SFVec2d, MFVec2d vettore bidimensionale di double • SFVec2f, MFVec2f vettore bidimensionale di float • SFVec3d, MFVec3d vettore tridimensionale di double • SFVec3f, MFVec3f vettore tridimensionale di float

22. L’object model: i nodi (1) Nodes • I nodi sono istanziatidichiarandoli in un file o usando codice procedurale a run-time • Si possono creare nuovi tipi di nodi (meccanismo di prototyping) • Diventano parte dell’ambiente run-time • Vengono trattati come gli oggetti built-in • La maggior parte dei tipi dei nodi implementano delle funzionalità aggiuntive attraverso l’ereditarietà di interfacce (proprietà e funzionalità comuni)

23. L’object model: i nodi (2) Ciascun nodo contiene zero o più campi che definiscono: • lo stato persistente del nodo • i valori che il nodo può spedire e ricevere sotto forma di eventi Vi sono 4 tipi di accesso ai campi di un nodo: • initializeOnly:non riceve e non spedisce eventi • inputOnly:è permessa la sola ricezione di eventi • outputOnly:è permessa la sola spedizione di eventi • inputOutput:sono permesse sia la ricezione sia la spedizione di eventi

24. L’object model: i nodi (3) Regole per l’assegnazione dei nomi ai campi: • Tutti i nomi composti da più parole cominciano con una minuscola, mentre le successive iniziali sono maiuscole • Esempio: nomeCompostoDaVarieParole • I campi inputOnly hanno il prefisso “set_” • Esempio: set_foo • Eccezioni: addChildren, removeChildren, alcuni campi del tipo ‘SFTime’ • I campi outputOnly hanno il suffisso “_changed” • Esempio: foo_changed • Eccezioni: i campi di tipo SFBool (ex: isActive), alcuni campi del tipo ‘SFTime’ • I campi inputOutput aggiungono al proprio nome il prefisso “set_” o il suffisso “_changed” a seconda che siano usati nella ricezione o nell’invio di eventi • Esempio: foo, set_foo, foo_changed

25. L’object model: i nodie il flusso degli eventi • Gli eventi sono il mezzo primario per generare dei comportamenti nell’ambiente run-time • Gli eventi in output sono connessi agli eventi in input in modo dichiarativo • Per poter stabilire una connessione (ROUTE) fra due campi occorre associare ai nodi un nome • Costrutto DEF / USE • Gli eventi sono generati da sensori o script e poi propagati lungo il behaviour graph • Una cascata di eventi è caratterizzata dallo stesso timestamp Nodo initializeOnly campoA campoB inputOnly campoC outputOnly campoD inputOutput · ··