Ruby Scene Graph - RSG

Il linguaggio `e basato su S-Expression (si veda per una definizione il paragrafo 1.4), effettuando una mappatura diretta tra la struttura gerarchica della sexp con la gerarchia di oggetti del grafo di scena. Il linguaggio `e stato reso sufficientemente potente da supportare porzioni procedurali specificate in linguaggio Ruby (da cui Ruby Scene Graph). Vi sono alcune tipologie principali di espressioni nel linguaggio RSG, il tipo dell’espressione `e specificato dal suo primo elemento terminale. Espres-sioni che non sono di una delle tipologie principali sono interpretate come chiamate a metodo, infine elementi terminali che iniziano con il simbolo $ sono interpretati come parametri template e sostituiti con il loro valore effettivo. I commenti iniziano con il simbolo del punto e virgola. Le principali espressioni sono:

1.5 Specifica dell’ambiente di simulazione 21

• header : `e la prima espressione presente in ogni file RSG, specifica il tipo di linguaggio utilizzato e la sua versione. Il tipo header `e indicato con il nome RubySceneGraph o RSG, al momento l’unico header interpretato `e (RSG 0 1 ). Segue il corpo del file contenuto in un’unica grande sexp. Il corpo pu`o contenere un’espressione opzionale che che caratterizza il file come template, specificandone i parametri, e un insieme di espressioni di tipo node.

• node: i nodi del grafo sono dichiarati con l’espressione (node <ClassName>) o abbreviato con nd dove <ClassName> specifica il nome della classe registrata nel class factory system di Zeitgeist. L’interpretazione di un’espressione node comporta la creazione di una nuova istanza di oggetto del tipo specificato, e la sua aggiunta nella gerarchia di Zeitgeist. I nodi sono inseriti nella gerarchia come figli del nodo la cui espressione include la propria. Nodi non appartenenti ad alcuna sopra-espressione sono nodi top level e verranno inseriti come figli del nodo che importa il file RSG a cui appartengono. In questo modo l’espressione e la sua struttura gerarchica rispecchia direttamente la struttura gerarchica che sar`a creata in Zeitgeist.

FORMATO

(node <ClassName>

;Qui posso richiamare metodi e impostare attributi ;della classe <ClassName>

)

ESEMPIO Vedere esempio per template

• importScene - template: il linguaggio RSG consente il riutilizzo di porzioni di scene graph sotto forma di macro. E’ possibile richiamare una macro at-traverso l’espressione (importScene <filename> <parameter>*) che, in fa-se di efa-secuzione, chiama ricorsivamente la procedura di importazione sul file specificato, sostituendone opportunamente i parametri e impostando la scena come figlia del nodo padre attuale. Un file template si caratterizza per avere l’espressione (template <parameter>*), o templ in forma abbreviata, speci-ficata all’inizio del corpo del file. Segue un esempio di specifica e richiamo di un file template:

FORMATO (template <parameter>*)

ESEMPIO

File Box.rsg:

(RubySceneGraph 0 1) (

(template $lenX $lenY $lenZ $material) (node Box

(setExtents $lenX $lenY $lenZ) (setMaterial $material)

) )

DESCRIZIONE ^{File template per la costruzione di un parallelepipedo} di dimensioni e materiale personalizzato

FORMATO _{(importScene <filename> <parameter>*)} ESEMPIO (importScene Box.rsg 8 20 5 $gold)

• espressione define o def: definisce una variabile che avr`a visibilit`a nel file corrente e in tutti i file importati dal file corrente

FORMATO (def $<variableName> <value>) ESEMPIO (def $radius 25.5)

(def $PI 3.14159)

• espressione eval: richiama l’interprete Ruby per il calcolo di un’espressio-ne matematica. Il calcolo pu`o coinvolgere costanti o variabili, il risultato dell’operazione viene sostituito all’espressione.

FORMATO (eval <expression>) ESEMPIO _{(eval 5 * 3.1)}

(def $circum (eval 2 * $PI * $radius))

DESCRIZIONE ^{E’ possibile utilizzare eval all’interno di altre} espressioni; il valore calcolato sar`a sostituito.

Per quanto riguarda le chiamate a metodo, esse sono espresse come una sexp che specifica come primo elemento terminale il nome della funzione o metodo, seguito da

1.5 Specifica dell’ambiente di simulazione 23

una lista opzionale di parametri: (<method name> <parameter>*). La chiamata a metodo `e risolta nel contesto dell’espressione node che la racchiude e determina la chiamata all’interfaccia Ruby della classe C++ corrispondente. Non tutte le classi delle librerie Spark dispongono di un’iterfaccia Ruby. Mancando una documenta-zione ufficiale a proposito, le descrizioni qui presentate si sono ricavate da un’opera di reverse engineering dei file RSG presenti in SimSpark. I metodi utilizzati sono stati ricercati nella documentazione API autogenerata con Doxygen a seguito della compilazione di SimSpark.

• Space: `e una classe della libreria oxygen che incapsula un oggetto space di ODE. Uno Space ODE `e una geometria non posizionabile che pu`o contenere altre geometrie e Space e viene utilizzata per la gestione efficiente delle colli-sioni. E’ da utilizzare come nodo radice per un modello di robot se si vuole usufruire del controllo collisioni.

• Transform: classe utilizzata per effettuare trasformazioni geometriche locali, come traslazioni e rotazioni, rispetto il nodo padre. In RSG viene utilizzata per il posizionamento delle geometrie e dei giunti che compongono il modello. • StaticMesh: classe della libreria kerosin che incapsula una geometria a mesh e si occupa della sua renderizzazione. Utilizzato in RSG per la specifica degli elementi grafici del modello tramite mesh. Impostando questo nodo come figlio di un noto Transform `e possibile impostare rotazioni e traslazioni alla mesh. • Box, Cylinder, Sphere: classi della libreria kerosin per la costruzione e la

renderizzazione di parallelepipedi, cilindri e sfere. Utili per la creazione di un robot o elementi di un robot attraverso primitive anzich`e attraverso mesh. • BoxCollider, CylinderCollider, SphereCollider: classe della libreria

oxy-gen che incapsula un oggetto Box, Cylinder e Sphere ODE, geometrie dotate di propriet`a di collisione. In SimSpark il modello di collisione del robot non pu`o essere specificato tramite mesh, ma deve essere composto attraverso primitive geometriche.

• RigidBody: classe che incapsula le propriet`a di un corpo rigido.

• TimePerceptor: classe che implementa il perceptor del tempo di simulazione • AgentState: classe che raggruppa perceptor dello stato dell’agente (livello

• GameStatePerceptor: usato nella simulazione calcistica per ricevere informa-zioni sullo stato del gioco.

• HearPerceptor: classi che implementa i corrispondenti perceptor nella simu-lazione calcistica.

• GyroRatePerceptor, Accelerometer, ForceResistancePerceptor, Touch-Perceptor: classi che implementano i corrispondenti perceptor.

• SayEffector, BeamEffector: classi che implementano i corrispondenti effec-tor nella simulazione calcistica.

• VisionPerceptor, RestrictedVisionPerceptor: classi che implementano rispettivamente un sensore di visione omnidirezionale o grandangolare con rumore parametrizzabile. Utilizzabile nella simulazione calcistica.

• ObjectState: identifica un elemento visualizzabile con il sensore di visione. • HingeJoint, UniversalJoint, BallJoint, FixedJoint, Hinge2Joint,

Sli-derJoint: classi che implementano le corrispondenti tipologie di giunto ODE. • HingePerceptor, Hinge2Perceptor, UniversalJointPerceptor: classi che

implementano i corrispondenti perceptor, mancano al momento perceptor per giunti ball e slider.

• HingeEffector, Hinge2Effector, UniversalJointEffector: classi che im-plementano i corrispondenti effector, mancano al momento effector per giunti ball e slider.

Infine `e presente un semplice costrutto switch che consente la valutazione selettiva di sottoespressioni:

(switch $variable (<value1>

;Espressione da valutare se $variable = <value1> )

(<value2>

;Espressione da valutare se $variable = <value2> )

... )

1.5 Specifica dell’ambiente di simulazione 25