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

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

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 SPIEGARE A COSA SERVE X3D (INTERAZIONE) Può essere usato con vari componenti hardware

Aree di applicazione Presentazioni multimediali Pagine web Visualizzazione in ambienti RV immersivi Mondi virtuali multiutente Visualizzazione scientifica Formato di interscambio tra diverse applicazioni 3D MOSTRARE ESEMPI (immagini) Maya Browsers X3D 3D Studio Max

Funzionalità di X3D (1) Grafica 3D Grafica 2D Animazione Audio e video 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à (GRAFICA 3D) X3D permette di definire degli oggetti poligonali specificando, attraverso diversi strumenti, l’insieme delle facce che li compongono. Oltre alla geometria di tipo poligonale X3D mette a disposizione delle primitive geometriche (quali sfere, coni, cilindri, parallelepipedi) nonché degli strumenti per la creazione di oggetti parametrici come ad esempio curve e superfici NURBS. Oltre a poter traslare gli oggetti creati nello spazio 3D è possibile anche ruotarli e scalarli rispetto ad assi arbitrari. Una caratteristica importante è costituita dalla possibilità di organizzare gerarchicamente queste trasformazioni geometriche; in tal modo è possibile definire dei rapporti di “parentela” tra gli oggetti, in cui la posizione di un “oggetto figlio” è relativa a quella dell’”oggetto padre” (immaginate ad esempio due sfere che rappresentano un pianeta e un suo satellite...oppure la posizione delle ruote di un’automobile rispetto alla scocca della stessa) L’aspetto degli oggetti è definito specificando diversi tipi di sorgenti luminose e impostando le proprietà dei materiali di cui sono composte le superfici (per chi di voi già utilizza dei programmi di modellazione 3D ritroverà concetti quali il colore di diffusione, il colore ambiente e il colore speculare). Per meglio definire l’aspetto degli oggetti che compongono la scena è possibile associare alle superfici delle textures (delle immagini). Una caratteristica avanzata di X3D che non era presente nel predecessore VRML è quella del multi-texturing, cioé la possibilità di definire una superficie attraverso la sovrapposizione di più textures; X3D fornisce vari modi in cui uno “strato” di texture influenza gli altri. (GRAFICA 2D) Per quanto riguarda la grafica bidimensionale è possibile creare delle forme planari (come ad esempio cerchi, archi, rettangoli...); come per gli oggetti tridimensionali anch’esse si inseriscono all’interno della gerarchia delle trasformazioni 3D. Inoltre X3D fornisce degli strumenti per comporre in modo facile del testo, specificando diversi fonts e tipi di formattazione (ANIMAZIONE) L’animazione delle entità che costiuiscono la scena virtuale è gestita principalmente da timers ed interpolatori. I timers fungono da orologi che indicano l’avanzare del tempo, mentre gli interpolatori permettono di definire alcuni valori chiave per quanto riguarda, ad esempio, la posizione di un oggetto,la sua rotazione o il suo colore. Come keyframe, ma i timers (a differenza della timeline di Maya) sono “periodici” (-> si vuole creare un mondo 3D in cui gli oggetti sembrino avere una vita propria) Sempre attraverso gli interpolatori è possibile realizzare degli effetti di morphing interpolando le coordinate dei vertici di un oggetto. Un’altra caratteristica di X3D (che non vedremo) è la possibilità di definire e animare semplici umanoidi; ciò è utile ad esempio nella realizzzione di avatar da impiegare, ad esempio, in una chat 3D. (AUDIO e VIDEO) Come ho accennato prima parlando di texture è possibile mappare sugli oggetti geometrici delle immagini; le possibilità offerte da X3D si spingono però oltre, dando che potrete inserire anche dei filmati video (immaginate un televisore costituito da un file .avi su un cubo). Una caratteristica molto interessante di X3D nella creazione di veri e propri mondi virtuali è quella di permettere l’inserimento di sorgenti acustiche nello spazio 3D. Potrete importare dei files audio e collocarli nello spazio 3D; durante la navigazione della scena virtuale percepirete i suoni in base ad un modello acustico che tiene conto della distanza (e dalla direzione) tra voi e la sorgente. I files audio possono essere importati nei formati PCM, MIDI ed MP3 (NAVIGAZIONE) L’utente può esplorare la scna virtuale attraverso dei differenti paradigmi di navigazione: camminare, volare, esaminare... E’ possibile inoltre definire dei differenti punti di vista (posizione dell’utente nello spazio virtuale e direzione dello sguardo) richiamabili successivamente; questi punti di vista possono essere richiamati attraverso dei link così come in una pagina web è possibile stabilire dei link interni alla pagina. Inoltre X3D permette di effettuare dei test di collisione fra l’utente e gli oggetti, nonché dei test di prossimità o visibilità (cioé: l’utente vede l’oggetto?!). Per il test di prossimità immaginate una porta automatica che si apre grazie ad una fotocellula...

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) (INTERAZIONE CON L’UTENTE) L’utente può interagire con gli oggetti della scena attraverso il picking di un oggetto (cioé cliccandovi sopra) o attraverso il dragging (cioé trascinandolo). X3D permette di realizzare questi comportamenti in modo molto semplice attraverso delle entità chiamati “sensori”. Diversi tipi di sensori permettono diversi tipi di dragging: è possibile ad esempio trascinare un oggetto traslandolo o facendolo ruotare (immaginate quanto ciò può essere utile nella creazione di widgets di un’interfaccia 3D: barre di scorrimento, manopole che ruotano...) (OGGETTI DEFINITI DALL’UTENTE) Oltre ad utilizzare gli oggetti definiti da X3D è possibile definire dei nuovi tipi di oggetti più complessi e richiamarli successivamente (immaginate ad esempio un pedone degli scacchi costituito da un cono-corpo ed una sfera-testa; è possibile creare un tipo di oggetto “pedone”) (SCRIPTING) Il mondo virtuale può essere modificato dinamicamente, ad esempio creando nuovi nodi o sopprimendone altri, in risposta ad eventi interni alla scena oppure esterni. Con eventi interni si intende ad esempio comportamenti relativi alla navigazione e all’esplorazione della scena virtuale. Con eventi esterni si intendono invece collegamenti tra il mondo virtuale ed applicazioni esterne com un browser internet. Le modifiche vengono effettuate attraverso dei linguaggi di programmazione o dei linguaggi di scripting interno. Vedremo degli esempi di utilizzo di scripting.... (NETWORKING) Per quanto riguarda il networking è importante sottolineare il fatto che una scena X3D può essere composta da entità che si trovano distribuite sulla rete. E’ inoltre possibile definire dei link ad altre scene (esempio: click su porta e si apre la scena di una stanza) o a pagine web. (SIMULAZIONE FISICA) X3D permette inoltre di interfacciarsi a dei dataset spaziali nonché integrarsi con il protocollo DIS, uno standard per la definizione di “simulazioni fisiche distribuite su internet” inizialmente sviluppato in ambito militare. Questi due aspetti non li tratteremo poiché esulano dalle vostre necessità...

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

Eventi esterni (pagine Web) Architettura di X3D X3D/VRML files, streams Eventi esterni (pagine Web) Browser Parser API XML VRML classic Binary SAI Scene Authoring Interface EAI External Authoring Interface Scripting Engines (Ecmascript, Java...) X3D Node types Prototype, External Prototype SAI (Scene Authoring Interface) ********************************************************* *** PARLARE ANCHE DELLA PARTE DESTRA E DELL’AMBIENTE RUN-TIME *** ********************************************************************************************** *** SOTTOLINEARE DIFFERENZA TRA LO SCENE GRAPH (I NODI) E LA CODIFICA IN XML (CHE SARA’ SPIEGATA IN SEGUITO) *** Dopo aver elencato in modo abbastanza superficiale le funzionalità di X3D vediamo qual è la sua architettura interna. La definizione della scena virtuale avviene dichiarando le entità che la costituiscono; con entità si intendono non solo gli oggetti geometrici ma tutto ciò che serve a definire il nostro mondo virtuale: quindi anche punti di vista, hyperlink, comportamenti interattivi. Queste dichiarazioni sono contenute in uno o più files X3D (o per compatibilità verso il basso in files VRML). Per realizzare un mondo virtuale impareremo quindi a creare un file X3D: esso può essere scritto secondo tre codifiche distinte: due di tipo testuale (XML e VRML-classic cioé la stessa codifica/sintassi che era usata in VRML) e una di tipo binario. Per comodità utilizzeremo una delle due codifiche testuali in modo da poter creare i nostri files X3D con il semplice “notepad” o un qualsiasi altro programma di elaborazione testi. Tra la codifica XML e quella VRML preferiremo la codifca XML; pur essendo più prolissa della codifca utilizzata in VRML essa risulta molto più leggibile e permette tra l’altro una maggior integrazione con le pagine web (?!). L’interpretazione, l’esecuzione e la presentazione dei files X3D avviene attraverso il browser X3D. Il browser interpreta quindi i files X3D caricati e in base alle dichiarazioni che essi contengono crea gli oggetti corrispondenti. Questi oggetti come poi vedremo possono essere dei nodi già definiti in X3D o definiti dall’utente (chiamati prototipi) L’ultimo riquadro che ho illuminato in colore giallo rappresenta proprio Scene graph manager Scene graph Event graph

Eventi esterni (pagine Web) Architettura di X3D Eventi esterni (pagine Web) VRML classic Binary Parser Scene graph manager X3D Node types Prototype, External Prototype SAI (Scene Authoring Interface) SAI Scene Authoring Interface EAI External Authoring Scripting Engines (Ecmascript, Java...) API Browser Event graph X3D/VRML files, streams Da cosa è composto lo scene graph?! Quali sono le dichiarazioni X3D e come codificarle in XML?! XML Dopo aver elencato in modo abbastanza superficiale le funzionalità di X3D vediamo qual è la sua architettura interna. La definizione della scena virtuale avviene dichiarando le entità che la costituiscono; con entità si intendono non solo gli oggetti geometrici ma tutto ciò che serve a definire il nostro mondo virtuale: quindi anche punti di vista, hyperlink, comportamenti interattivi. Queste dichiarazioni sono contenute in uno o più files X3D (o per compatibilità verso il basso in files VRML). Per realizzare un mondo virtuale impareremo quindi a creare un file X3D: esso può essere scritto secondo tre codifiche distinte: due di tipo testuale (XML e VRML-classic cioé la stessa codifica/sintassi che era usata in VRML) e una di tipo binario. Per comodità utilizzeremo una delle due codifiche testuali in modo da poter creare i nostri files X3D con il semplice “notepad” o un qualsiasi altro programma di elaborazione testi. Tra la codifica XML e quella VRML preferiremo la codifca XML; pur essendo più prolissa della codifca utilizzata in VRML essa risulta molto più leggibile e permette tra l’altro una maggior integrazione con le pagine web (?!). L’interpretazione, l’esecuzione e la presentazione dei files X3D avviene attraverso il browser X3D. Il browser interpreta quindi i files X3D caricati e in base alle dichiarazioni che essi contengono crea gli oggetti corrispondenti. Questi oggetti come poi vedremo possono essere dei nodi già definiti in X3D o definiti dall’utente (chiamati prototipi) L’ultimo riquadro che ho illuminato in colore giallo rappresenta proprio Scene graph

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 Con oggetti si intende nodi; quindi non soltanto gli oggetti geometrici, ma tutte le entità che costituiscono il sistema.... Ad esempio bla... bla... bla... Gli oggetti nello scene graph non sono scollegati tra loro, ma sussistono differenti relazioni tra di essi... Le principali sono la Transformation hierarchy e il Behaviour graph *** INTRODURRE NODI E CAMPI (CAMPI SEMPLICI O CAMPI COMPOSTI DA NODI)  TIPO CLASSI IN LINGUAGGIO AD OGGETTI *** *** FARE ESEMPI DI TRASFORMATION HIERARCHY E BEHAVIOUR GRAPH *** Behaviour graph: Descrive le connessioni tra i campi degli oggetti e il flusso degli eventi attraverso il sistema

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 Nodi radice Nodi figli Node A Node B Node C Node D Node E Node F Un file X3D è costituito da almeno un nodo radice. Ogni nodo, a seconda del suo tipo, può avere 0 o più nodi figli

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 Dire che esistono nodi che fanno parte dello scene graph, ma non sono modificati dalla transormation hierarchy: ad esempio i nodi ambientali (che definiscono il background), i nodi script, i timers...

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

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

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

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

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 *** RICAPITOLANDO: SCENE GRAPH, TRANSF. HIERARCHY, BEHAVIOUR GRAPH *** Interpolatore fraction value key keyValue · · · Timer startTime endTime ConoTransf translation

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) Lo scene graph è una descrizione statica di come sono strutturati gli oggetti nel sistema Ora vediamo l’ambiente run-time *** Nel “punto 3” dire che può modificare lo scene graph in risposta al behavioral system *** *** VEDIAMO ORA PIU’ IN DETTAGLIO COSA SONO E COME SONO FORMATI GLI OGGETTI ***

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

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

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 rispetto all’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

L’object model: i nodi (1) Nodes I nodi sono istanziati dichiarandoli 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) *** FAR NOTARE CHE UN CAMPO DI TIPO SFNode o MFNode PERMETTE DI ASSOCIARE AD UN NODO UNO O PIU’ NODI FIGLI ***

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 *** FAR NOTARE CHE UN CAMPO DI TIPO SFNode o MFNode PERMETTE DI ASSOCIARE AD UN NODO UNO O PIU’ NODI FIGLI ***

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 *** FAR NOTARE CHE UN CAMPO DI TIPO SFNode o MFNode PERMETTE DI ASSOCIARE AD UN NODO UNO O PIU’ NODI FIGLI ***

L’object model: i nodi e il flusso degli eventi Nodo initializeOnly campoA inputOnly campoB outputOnly campoC inputOutput campoD · · · 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 *** COMPLETIAMO IL DISCORSO SUGLI EVENTI *** Modo dichiarativo permette di creare comportamenti complessi senza ricorrere alla programmazione imperativa Spiegare differenza tra “nomi DEF / USE” e nomi dei “tipi oggetto” Spiegare bene cascata di eventi (contemporanei) e timestep ************************************* *** FARE RIASSUNTO SULL’ARCHITETTURA!!! ***