Tasques en un món virtual - UPC Universitat Politècnica...

Universitat Rovira i VirgiliEscola Tècnica Superior d'Enginyeria

Projecte Final de Carrera

Tasques en un món virtual

Autor: Jonàs Martínez BayonaDirectora del projecte: Dra. Maria Ferré Bergadà

Ensenyament: Enginyeria Tècnica en Informàtica de SistemesMaig de 2007


Índex de continguts1. Objectius del projecte................................................................... 72. Especificacions del projecte......................................................... 8

2.1 Entorn 3D..........................................................................................82.1.1. Classificació dels objectes atenent a la interactivitat........................ 8

Objectes no interactius....................................................................................... 8Objectes interactius............................................................................................9Objectes de la interfície gràfica d'usuari............................................................ 9

2.1.2 Classificació dels objectes atenent a la seva naturalesa.................. 10Elements de l'edifici i mobiliari......................................................................... 10Utensilis , ingredients i elements de decoració................................................ 10

2.1.3 Classificació dels objectes atenent a la intervenció en la tasca........11Objectes que intervenen en la tasca................................................................ 11Objectes que no intervenen en la tasca........................................................... 11

2.2 Navegació.......................................................................................112.2.1 Navegació lliure................................................................................ 112.2.2 Navegació dirigida............................................................................ 122.2.3 Controls de navegació.......................................................................12

2.3 Funcionalitat de les tasques...........................................................132.3.1 Definició general de les fites.............................................................132.3.2 Classificació de les fites atenent a la seva participació en la tasca.. 14

Fites directes.................................................................................................... 14Fites indirectes................................................................................................. 14

2.3.3 Classificació de les fites atenent a la seva dependència................. 14Fites independents........................................................................................... 14Fites dependents.............................................................................................. 15Fites generadores de dependència.................................................................. 15Fites sense generació de dependència.............................................................16

2.3.4 Classificació de les fites atenent a la seva finalització......................16Fites finalitzables.............................................................................................. 16Fites no finalitzables......................................................................................... 16

2.3.5 Classificació de les fites atenent a l'associació amb objectes...........16Fites amb un objecte associat.......................................................................... 16Fites sense associació amb objectes................................................................ 17

2.3.6 Progamabilitat del nivell de dificultat de la tasca............................. 17Nivell de concreció de la tasca......................................................................... 17Ajuda al pacient en temps d'execució.............................................................. 17Selecció de la funcionalitat dels objectes que no participen en la tasca.......... 18Selecció del tipus de navegació....................................................................... 18

2.4 Registre del progrés de l'usuari......................................................192.5 Control de coherència de la tasca ................................................. 19

2.5.1 Coherència de les relacions de dependència....................................192.5.2 Control de presència d'objectes en escena.......................................20

2.6 Reusabilitat de la tasca.................................................................. 203. Disseny ..................................................................................... 21

3.1 Disseny de l'entorn virtual..............................................................213.2 Disseny del sistema de navegació................................................. 21

2


3.2.1 Visualització...................................................................................... 213.2.2 Moviment del personatge dins l'escena............................................22

Estructura del cos a partir d'eixos ................................................................... 22Sistema de detecció de col·lisions.................................................................... 22

3.2.3 Sistema de control ........................................................................... 233.3 Decisions prèvies al disseny de la tasca.........................................23

3.3.1 Model centralitzat d'events...............................................................233.3.2 Model de dependències entre accions.............................................. 243.3.3 Interacció amb els objectes.............................................................. 253.3.4 Disseny de l'ajuda a l'usuari..............................................................253.3.5 Tipus d'accions..................................................................................25

Accions normals............................................................................................... 26Accions reversibles........................................................................................... 26

3.3.6 Modelització de la tasca mitjançant classes..................................... 273.4 Disseny de la tasca.........................................................................28

3.4.1 La classe Tasca................................................................................. 28Disseny de dades............................................................................................. 28Constructor de la classe................................................................................... 29Disseny de mètodes......................................................................................... 29

3.4.2 La classe Acció..................................................................................30Dades............................................................................................................... 31Constructor de la classe................................................................................... 32Disseny de mètodes......................................................................................... 32

3.4.3 La classe Alarma............................................................................... 33Dades............................................................................................................... 33Constructor de la classe................................................................................... 34Disseny de mètodes......................................................................................... 34

3.4.4 La classe Event................................................................................. 34Dades............................................................................................................... 35Constructor de la classe................................................................................... 35

4. Desenvolupament...................................................................... 374.1 Creació de la cuina virtual..............................................................37

4.1.1 Blender 3D........................................................................................ 37Blender Game Engine (BGE)............................................................................. 37El sistema de Logic Bricks................................................................................ 38Tipus de Sensors.............................................................................................. 38Tipus de controladors....................................................................................... 40Tipus d'actuadors............................................................................................. 40

4.1.2 Pygame i llibreries SDL..................................................................... 424.1.3 Exemples de desenvolupament........................................................ 43

Modelant una forquilla...................................................................................... 43Texturitzant la superfície dels fogons............................................................... 44Animant un objecte: tirar la sal a la paella....................................................... 45Il.luminant l'entorn virtual de la cuina.............................................................. 48

4.1.4 Optimització del rendiment de l'aplicació......................................... 504.2 Implementació del sistema de navegació...................................... 51

Propietats del sistema...................................................................................... 51Sensors del sistema..........................................................................................52Actuadors del sistema...................................................................................... 52

3


Controladors del sistema.................................................................................. 544.3 Implementació del sistema de control de la tasca......................... 56

4.3.1 Logics Bricks associats a qualsevol objecte interactiu......................56Propietats d'un objecte interactiu.....................................................................56Sensors associats a un objecte interactiu.........................................................56Actuadors associats a un objecte interactiu..................................................... 57Controladors associats a un objecte interactiu.................................................58

4.3.2 L'objecte “OBInici”: control d'inicialització, gestió d'alarmes i llançament de diàlegs emergents..............................................................58

Propietats de “OBInici”..................................................................................... 58Sensors associats a “OBInici”........................................................................... 59Actuadors associats “OBInici”.......................................................................... 59Controladors associats a “OBInici”................................................................... 59

4.3.3 Unificació del control en un únic script............................................. 604.3.4 Control d'inicialització de la tasca.....................................................614.3.5 Control d'events................................................................................634.3.6 Control d'alarmes..............................................................................654.3.7 Control d'interacció i finalització d'accions....................................... 67

4.4 Un exemple de tasca: fer una truita...............................................694.4.1 Identificació de les accions que conformen la tasca, les seves dependències i els possibles objectes associats........................................ 694.4.2 Identificació dels events inicials, finals i els que caracteritzen a cada acció...........................................................................................................724.4.3 Identificació de les alarmes que poden anar associades amb cada acció...........................................................................................................74

5. Avaluació.................................................................................... 765.1 Prova de navegació en l'entorn virtual de la cuina.........................76

5.1.1 Preguntes efectuades....................................................................... 765.1.2 Resultats obtinguts........................................................................... 77

6. Conclusions................................................................................ 797. Recursos utilitzats...................................................................... 81

7.1 Pàgines web....................................................................................817.2 Llibres.............................................................................................82

8. Manuals...................................................................................... 838.1 Manual de l'usuari.......................................................................... 83

4


Índex d'il·lustracionsEsquema de navegació.............................................................................................................. 21Vista en wireframes de la cuina................................................................................................. 36Logic Brick Joystick.................................................................................................................... 37Logic Brick Message (Sensor).................................................................................................... 37Logic Brick Ray.......................................................................................................................... 38Logic Brick Random (Sensor)..................................................................................................... 38Logic Brick Property (Sensor)..................................................................................................... 38Logic Brick Radar....................................................................................................................... 38Logic Brick Near......................................................................................................................... 38Logic Brick Collision................................................................................................................... 38Logic Brick Touch....................................................................................................................... 38Logic Brick Mouse...................................................................................................................... 39Logic Brick Keyboard................................................................................................................. 39Logic Brick Always..................................................................................................................... 39Logic Brick AND......................................................................................................................... 39Logic Brick OR........................................................................................................................... 39Logic Brick Expression............................................................................................................... 39Logic Brick Python..................................................................................................................... 39Logic Brick Visibility................................................................................................................... 39Logic Brick Game....................................................................................................................... 40Logic Brick CD............................................................................................................................ 40Logic Brick Message (Actuador)................................................................................................. 40Logic Brick Random (Actuador).................................................................................................. 40Logic Brick Scene....................................................................................................................... 40Logic Brick Edit Object............................................................................................................... 40Logic Brick Property (Actuador)................................................................................................. 40Logic Brick Sound...................................................................................................................... 40Logic Brick Camera.................................................................................................................... 41Logic Brick IPO........................................................................................................................... 41Logic Brick Constraint................................................................................................................ 41Logic Brick Motion...................................................................................................................... 41Forquilla dibuixada amb Splines................................................................................................ 42Forquilla subdivida amb una Lattice.......................................................................................... 42Lattice de la forquilla ajustada................................................................................................... 42Textura Reflex projectada.......................................................................................................... 43Superficie dels fogons sense texturitzar.................................................................................... 43Superficie amb reflexio.............................................................................................................. 43Textura panell aplicada............................................................................................................. 43Reflex.jpg.................................................................................................................................. 43Resultat final............................................................................................................................. 43Panell.jpg................................................................................................................................... 43Punt inicial sal............................................................................................................................ 44Punt ALFA de la sal.................................................................................................................... 45IPO de la sal............................................................................................................................... 46Punt BETA de la sal.................................................................................................................... 46Prova 1 d'il·luminació................................................................................................................. 47Prova 2 d'il·luminació................................................................................................................. 47Prova 3 d'il·luminació................................................................................................................. 47Prova 4 d'il·luminació................................................................................................................. 47Prova 5 d'il·luminació................................................................................................................. 48Logics Bricks per a la navegació................................................................................................ 50IPO associada a la inclinació...................................................................................................... 51IPO associada a la rotació.......................................................................................................... 52Logics Bricks associats a un objecte interactiu.......................................................................... 55

5


Logics Bricks de "OBInici".......................................................................................................... 57Esquema general de la tasca de fer una truita.......................................................................... 70Vista general de la cuina en wireframe...................................................................................... 76Vista de la cuina 1..................................................................................................................... 78Vista de la cuina 2..................................................................................................................... 78Execució amb cap tasca carregada........................................................................................... 82Diàleg de confirmació de sortida............................................................................................... 83

6

Tasques en un món virtual 1. Objectius del projecte

1. Objectius del projecte

El present projecte de final de carrera s'emmarca en un de més ampli on es pretén desenvolupar un sistema que implementi un procés de rehabilitació de funcions cognitives de pacients amb disfuncions neurològiques basat en entorn telemàtic col·laboratiu i una aplicació gràfica tridimensional. La idea central del sistema és permetre que el pacient pugui realitzar tasques de rehabilitació en un entorn gràfic 3D virtual, des de casa seva però sota control i supervisió remota d'un o més terapeutes.

El projecte realitzat és un subconjunt d'aquest entorn. L'objectiu consisteix en desenvolupar un escenari virtual que representi una cuina i crear un sistema de navegació en primera persona, que possibiliti el moviment del pacient dins l'escena de forma realista. Alhora, s'hauran de poder definir tasques amb dificultat escalable que posseeixin la capacitat de retroalimentar a l'usuari d'errors en la seva execució. L'aplicació també podrà informar i guiar al pacient per a que completi correctament la tasca, i anirà guardant un historial de l'evolució de l'exercici per a una posterior avaluació dels terapeutes. S'implementarà a la vegada, una tasca de demostració de funcionament que consistirà en fer una truita.

La definició d'una tasca s'haurà de poder fer independentment de l'escenari 3D; no estarà integrada en l'entorn. Així doncs, serà possible tenir múltiples tasques fàcilment configurables sense haver de fer canvis en l'aplicació principal.

Un altre punt important és la interacció amb l'aplicació que haurà de ser molt intuïtiva, contemplant-se la possibilitat de migrar fàcilment entre dispositius perifèrics que permeten el control de moviment.

7

Tasques en un món virtual 2. Especificacions del projecte

2. Especificacions del projecte

2.1 Entorn 3DL'entorn virtual haurà d'estar construït de manera que possibiliti el desenvolupament de les tasques, permetent alhora que la definició de possibles noves activitats sigui fàcilment integrable en l'escenari. Per tant, serà necessari crear una sèrie d'elements de suport comuns a un entorn en concret. Aplicat a una cuina per exemple, significaria que hauríem de modelar uns objectes (mobles, taula, nevera,fogons ,etc.) que permetessin una definició més amplia de les tasques. S'haurà de tindre especial compte amb els objectes estàtics alhora d'avaluar aquest punt, ja que la seva modificació i integració és costosa, i en alguns casos exigeix desfigurar parcialment l'escena.

Un altre aspecte molt important serà el realisme i grau de detall del món virtual que es buscarà que sigui el més pròxim a la realitat. Aquest fet augmentarà la credibilitat de l'escena i paral·lelament millorarà la percepció de la mateixa per part del pacient. Es a dir, que li serà molt mes fàcil moure's en un entorn que reconeix. Ara bé, s'haurà d'establir un compromís entre el rendiment de l'aplicació i el realisme que pugui oferir. Per tal de millorar aquest punt, es recorrerà a tècniques d'optimització enfocades bàsicament a l'escenari i a la pròpia lògica interna de control de la tasca.

Per tal de clarificar l'organització, funcions, aspecte i naturalesa possible dels objectes que apareixen en escena, s'ha distingit entre tres classificacions diferents atenent primer a la interacció, en segon lloc a la pròpia naturalesa de l'objecte i per últim, a la participació de l'objecte en la tasca.

2.1.1. Classificació dels objectes atenent a la interactivitat

Entenem que un objecte del món 3D és interactiu, quan el usuari pot ocasionar un canvi en l'estat del programa que s'està executant, ja sigui fent clic a sobre de l'objecte, o indicant d'alguna altra forma (per exemple, passant el ratolí per sobre o movent la palanca d'un joystick) que existeix interacció amb l'objecte.

Atenent al criteri d'interactivitat, l'entorn virtual està composat per tres tipus diferents d'objectes: per una banda tenim els objectes no interactius (parets, taules, terra, etc.) que no són susceptibles d'ésser modificats per l'usuari, per l'altra, tots aquells que si poden ser-ho d'alguna manera (una porta o armari que poden ser oberts, una forquilla que es pot agafar, etc.). Per últim, tenim els objectes que formen part de la interfície gràfica d'usuari que poden incorporar tan objectes interactius com no, i que tractem a part respecte els altres dos subconjunts atesa la seva rellevància i diferenciació clara respecte els objectes que apareixen a l'escenari .

A continuació passem a explicar amb més detall les especificacions associades a cada tipus d'objecte.

Objectes no interactius

El grup d'objectes no interactius està composat per tots aquells elements de l'escena virtual amb els que l'usuari no pot interaccionar en temps d'execució de l'aplicació.

Tots aquests objectes tenen activada la detecció física de col·lisions amb altres objectes en escena (ex: detecció de l'usuari), tot i que atenent a criteris de rendiment,

8


es podrà desactivar en aquells objectes amb els que no existeixi possibilitat de col·lisió (ex: un llum del sostre).

El grup d'objectes estàtics es llegirà d'un fitxer únic. Es podrà canviar inicialment i depenent de la tasca seleccionada, les següents propietats:

1. Visibilitat: la visibilitat es podrà activar o desactivar completament , o bé seleccionar un nivell intermedi de transparència (semitransparent)

2. Posició: la posició vindrà definida pel centre del model, i serà absoluta respecte les coordenades del escenari

3. Orientació: la orientació vindrà definida també pel centre del model, i serà relativa respecte l'objecte

Durant tot l'exercici, aquestes propietats només podran ésser modificades si algun objecte interactiu sol·licita el canvi.

Objectes interactius

El grup d'objectes interactius el composen tots aquells, que en algun moment donat de la realització de la tasca, poden ésser utilitzats per l'usuari si fa clic sobre els mateixos, permetent alhora superar l'activitat encomanada.

Per exemple, un calaix es podrà obrir i tancar en qualsevol moment fent clic sobre ell, o una forquilla es podrà utilitzar per batre un ou.

Un objecte interactiu, a més de poder modificar la seva visibilitat, posició i orientació, podrà reproduir una animació pròpia (ex: obrir una porta) o demanar que un altre objecte interactiu s'animi (ex: s'activa un fogó al fer clic al polsador associat). També serà capaç de reproduir sons i canviar les propietats de qualsevol objecte en escena.

Al igual que els objectes interactius tindran activada la detecció de col·lisions i es llegiran del mateix fitxer únic on estaven el objectes estàtics. També es podrà canviar inicialment les seves propietats

Objectes de la interfície gràfica d'usuari

El grup d'objectes que conformen la interfície gràfica (en anglès “GUI”) informaran a l'usuari dels següents punts:

1. Evolució de la tasca en general: numero de fites de l'activitat, progrés tota,etc.

2. Informació de la tasca actual.

3. Avís de possibles de problemes en temps d'execució (ex: quan no existeixi cap fitxer que defineixi una tasca).

4. Cursor de selecció centrat en pantalla, que permetrà una major precisió per seleccionar objectes

5. Informació a l'usuari a través diàlegs emergents, totalment programables per part dels terapeutes, i condicionada a l'evolució de la tasca (per exemple, un diàleg que indiqui que la nevera està oberta al cap d'una estona de no haver-la tancat).

6. Diàlegs de confirmació d'una opció a escollir. Per exemple, quan l'usuari vulgui sortir i premi ESC , sorgirà un diàleg preguntant-li per si realment ho vol fer.

7. Pantalla de progrés a l'inici del programa, per tal que l'usuari es “tranquil·litzi”

9


al veure que s'està fent “feina”.

Dins d'aquest grup d'objectes, trobem els diàlegs, cursors i panells informatius. Podran portar animacions associades i mai tindran la detecció de col·lisions desactivada. La seva visibilitat serà en alguns casos configurable per l'usuari en temps d'execució (ex: ocultar/mostrar un panell d'informació).

Es buscarà una estètica genèrica i cuidada per al conjunt d'elements de la GUI, intentant que interfereixin mínimament en el desenvolupament de l'activitat, i en cas de fer-ho, possibilitar a l'usuari la seva ocultació.

2.1.2 Classificació dels objectes atenent a la seva naturalesa

Donat que les tasques a dissenyar per els terapeutes es trobaran emmarcades en l'interior d'edificis, considerarem que existiran dos subgrups bàsics d'objectes donada la seva naturalesa: per una banda els mobles i els elements de l'edifici (parets, terra, etc.), i per l'altre els utensilis, ingredients i elements de decoració.

Els elements de la GUI no es consideren aquesta divisió, ja que no poden ésser classificats pel criteri que s'estableix.

Elements de l'edifici i mobiliari

Els elements de l'edifici, sempre seran considerats estàtics i no interactius.

En quant als mobles distingirem entre els següents tipus:

1. Mobles contenidors: composats de un o més compartiments que poden ser un mòdul amb portes o un calaix i que es podran obrir i tancar.

2. Superfícies de treball: encimeres o taules de la cuina sobre les quals es podrà dipositar objectes. En general seran estàtiques, però podran haver-hi excepcions, com per exemple, si tinguéssim una tauleta de fusta per tallar el pa que podríem moure.

3. Mobiliari amb funcionalitat específica: mobles integrats en l'escenari amb una funció definida, generalment fixes o amb moviment restringit. Un exemple serien els fogons que podríem obrir i tancar o el microones que es podria programar per a un determinat temps.

4. Mobiliari sense funcionalitat específica: mobles que no tindran a priori cap funció, i que per tant seran estàtics i no interactius. Un exemple de moble sense funcionalitat especifica seria una cadira o un quadre penjat a la paret.

Utensilis , ingredients i elements de decoració

Els utensilis seran objectes interactius. Estaran normalment dins els models contenidors i es podran seleccionar i transportar a les superfícies de treball fen clic a sobre. Dins els utensilis hi hauran dos tipus, els contenidors (plats, gots o paelles), i els no contenidors amb una funcionalitat específica (coberts, obrellaunes, etc.).

En quant als ingredients, també interactius, estaran dins els models contenidors. Es podran seleccionar i transportar a les superfícies de treball. Alhora serà possible vessar-los o posar-los dins altres models contenidors i transformar-los amb l'ajuda d'utensilis o mobiliari amb funcionalitat específica. Per exemple, mitjançant una forquilla podrem transformar un ou dins d'un plat, en ou batut.

10


En quants els elements de decoració com quadres o flors, no tindran cap funció concreta i seran estàtics i no interactius.

2.1.3 Classificació dels objectes atenent a la intervenció en la tasca

Un altre factor que pot intervenir en les propietats dels objectes, es la seva intervenció en la tasca. Entenem que un element participa en una tasca quan, en un algun moment donat de la seva realització, es necessària la interacció amb l'objecte. Per tant és un criteri depenent de la tasca encomanada en cada moment.

Objectes que intervenen en la tasca

Aquest grup d'objectes estarà conformat comunament per ingredients, utensilis i mobiliari. Seran sempre interactius.

Depenent del grau de dificultat desitjat per l'acció es podran modificar les seves propietats (per exemple, fent les portes o calaixos semitransparents per facilitar la cerca del material necessari per fer la tasca).

Objectes que no intervenen en la tasca

Aquest conjunt estarà conformat per tots els ingredients, utensilis, mobiliari i demés models sense una funcionalitat especifica per a la consecució del exercici.

Depenent del grau de dificultat es podrà desactivar la seva funcionalitat o bé fer-los directament invisibles a l'usuari.

2.2 NavegacióLa navegació en l'entorn, mostrarà una perspectiva en primera persona de l'escenari. Es podrà modificar la velocitat del moviment de translació durant l'execució del programa, per tal de que l'usuari pugui adaptar-la al seu ritme. També serà possible ajustar fàcilment la distancia focal reeditant el arxiu que contindrà l'escenari.

El sistema de detecció de col·lisions haurà d'identificar el objectes que barren el pas del personatge amb el mínim cost computacional. També s'haurà de simular la gravetat de l'entorn, per tal que la navegació sigui coherent amb la realitat.

La mobilitat en l'entorn es podrà plantejar de dues formes: lliure o dirigida.

2.2.1 Navegació lliure

La navegació lliure possibilitarà el moviment de translació i rotació del punt de visió:

1. Translació: estarà limitada per la detecció d'objectes. El punt que la definirà estarà just als peus del personatge.

2. Rotació: haurà de seguir el moviment natural que pot tindre el coll d'una persona; no es podrà aixecar o abaixar el cap més de 90 graus. La definiran dos punts: el primer es trobarà enllaçat al punt de translació( representarà el coll) i el segon punt es trobarà enllaçat al coll i serà el punt de visió en primera persona de l'escena. La rotació amb limitacions de l'eix del coll, possibilitarà una visió realista de l'escenari.

11


2.2.2 Navegació dirigida

Per una altra banda, amb la navegació dirigida l'usuari només es podrà moure per trajectòries preestablertes lligades a l'escenari. La definició de les trajectòries es pot entendre com una línia que recorre l'escena passant per tots els punts necessaris per desenvolupar la tasca. El pacient podrà avançar o retrocedir al llarg de la línia. També es podrà pensar, en una limitació opcional del punt de vista, reduint la rotació a un espai concret (per exemple, impedint que pugui girar 30 graus més avall el coll).

L'avantatge principal que aporta aquest sistema és que el nivell de dificultat de la tasca disminueix, i en el cas dels pacients poc habituats a la navegació per entorns virtuals, els pot facilitar la realització de l'activitat, al ésser més difícil desorientar-se si tenim un camí prefixat.

2.2.3 Controls de navegació

En quan als controls de navegació l'aplicació, s'utilitzarà un model que permeti commutar fàcilment entre un control amb ratolí, teclat o mixt:

1. Ratolí: s'hauria de buscar un model que implementes la rotació i translació íntegrament amb el ratolí. Un possible exemple seria:

Clic Clic + Moviment ratolí

Botó dret Selecció ----

Botó esquerre ----- Translació

La rotació en aquest exemple es faria quan no hi hagués cap boto premut i simplement es mogues el ratolí.

L'avantatge principal d'aquest model es que el control es molt intuïtiu i està centralitzat en un únic dispositiu.

2. Teclat: un model basat únicament de tecla seria més senzill d'implementar que el de ratolí i consistiria per exemple en :

-Una tecla de selecció d'objectes

-Quatre tecles assignades a la translació cap endavant , endarrer i ambos costats

-Dues tecles associades a la rotació lateral del punt de vista, i dos més per a la rotació en el sentit superior i inferior del cap.

Aquest model es molt menys intuïtiu que el control amb el ratolí, i requereix tindre localitzades dintre del teclat 7 tecles en total. La seva aplicació només tindria sentit en els casos en els que el model de ratolí o mixt no s'adapti al pacient.

3. Model mixt (ratolí i teclat): En el cas del model mixt, la translació dependrà del teclat i la rotació i selecció d'objectes, del ratolí.

Aquest model pot proporcionar un control ràpid i precís, ja que la rotació es molt mes senzilla amb el ratolí que amb teclat, i en canvi el moviment de translació pot ésser controlat eficaçment pel teclat.

Un inconvenient que posseeix és que exigeix la utilització simultània de dos

12


dispositius perifèrics, i en el cas que el pacient no estigui acostumat a aquest sistema li pot resultar difícil adaptar-se.

4. Altres dispositius: es podrà contemplar migrar o adaptar el sistema a altres dispositius diferents al teclat o ratolí, ja sigui amb palanques de comandament (en anglès “Joysticks”) o demés dispositius perifèrics que permetin el moviment en escena a través de la comunicació entre la persona i la aplicació.

2.3 Funcionalitat de les tasquesUna tasca es defineix com una activitat concreta a realitzar per l'usuari mitjançant algun tipus d'interacció amb objectes disponibles de l'escena.

L'element constitutiu bàsic de qualsevol tasca seran les fites o accions, que són passos identificables que permeten finalitzar l'acció (per exemple, en la tasca de preparar una pizza, una fita seria agafar la farina i posar-la a taula).

2.3.1 Definició general de les fites

Com hem comentat, podem dividir una tasca en una serie de passos que s'han d'anar acomplint de manera que l'evolució del que es veu per pantalla sigui coherent amb la tasca que realitzem. Per exemple, en el cas de tenir una tasca que consistís en en preparar un bistec, el programa no ens hauria de permetre fregir-lo sense haver posat prèviament la paella i oli dins la mateixa. Per tant, una fita es defineix com un pas o acció concreta per a la culminació de la tasca que pot exigir la finalització d'altres fites per tal de poder portar-se a cap.

També cal observar que la definició de les accions pot ésser diferent depenent d 'un nivell de concreció més o menys genèric del que representen. Es a dir, podríem considerar fites que fossin subconjunts d'altres accions amb una definició més amplia. Per tant, depenent del criteri de definició de les fites podrem trobar diferents maneres de plantejar-les dins una mateix tasca. Un exemple que il·lustra la variabilitat de representacions d'una mateixa tasca seria en el cas de d'una activitat que consistís en servir un got de llet. Podríem plantejar un primer esquema molt senzill en el que només s'hagués de seleccionar el got i la llet per finalitzar la tasca i en un segon anàlisi, concretar més i exigir posar el got i la llet a taula per a desprès bolcar la llet a dins el got.

Veiem doncs, que el nivell de concreció es un potent recurs per escalar la dificultat d'una tasca. Tanmateix s'haurà de cuidar que aquest nivell permeti definir la interactivitat amb els objectes, evitant sempre plantejar fites que no tinguin associat d'una forma clara un objecte.

Per tal que el realisme sigui màxim, es buscarà que el model de definició de fites no es limiti a establir una ordre seqüencial d'accions per a la realització de la tasca, sinó que s'hauran de dissenyar les dependències entre fites de manera que permetin una realització no seqüencial i possible de la tasca. Un exemple de dependència entre fites es la que té per exemple la fita de posar el got a la taula i la de posar la llet al got: fins que el got no estigui a taula no es podrà posar la llet. Aquestes possibles dependències hauran de quedar plasmades en la definició de cadascuna de les fites.

També s'haurà de considerar que una fita pot exigir que es pugui repetir la seva consecució en el futur, o tot al contrari, que no sigui possible tornar a completar-la en tot el transcurs de la tasca.

13


Per últim, s'haurà de distingir entre les fites que requeriran algun tipus d'interacció amb un objecte determinat, o que per contra, no requeriran de cap interacció directa amb objectes de l'escenari.

A continuació, veurem doncs els diferents tipus de fites que podem distingir atenent a la participació en la tasca, la dependència que adopten, la possibilitat d'ésser finalitzades i la possible associació amb un objecte.

2.3.2 Classificació de les fites atenent a la seva participació en la tasca

Fites directes

Aquestes fites participen activament per a la consecució de la tasca. Sense la seva finalització no es pot completar de cap manera l'activitat. Un exemple de fita primària directa seria agafar el pa en la tasca de fer-se un entrepà.

Fites indirectes

En un primer anàlisi podem considerar que totes les fites han de participar d'alguna manera en la consecució d'un tasca, a no ser que formin part d'altres tasques implementades i no s'hagin desactivat. Ara be, observem que poden existir fites que no siguin exigibles per acabar la tasca, però que la seva no consecució indiqui un error en la realització de la tasca. Aquest grup de fites entraria en el de les primàries indirectes. Un exemple clar seria en la realització de qualsevol tasca que requerís obrir el foc d'una cuina on es definiria un fita indirecte que consistís en apagar-lo un cop l'hem deixat d'utilitzar.

2.3.3 Classificació de les fites atenent a la seva dependència

A continuació analitzem les quatre característiques que haurà de tenir una fita, en quant les seves relacions de dependència amb altres fites. Qualsevol fita serà independent o dependent, i podrà generar o no dependència. Es mostren per millorar la comprensió un diagrama explicatiu de cada tipus.

Fites independents

Definim una fita independent com aquella que no requereix de la consecució d'altres per tal d'ésser portada a cap per l'usuari en qualsevol moment. Un exemple de fita independent es l'acció d'obrir la porta de la nevera, que no requereix de cap pas previ.

14

Obrir nevera

Obrir porta

Dependència

Diagrama de dependències

Fites independents


Fites dependents

Al contrari que les independents, les fites dependents requereixen que una o més fites s'hagin completat abans de que es pugui portar a terme. Un exemple clar és en el moment de fer una amanida, ja que es requerirà obtenir una espàtula i uns ingredients abans de poder barrejar-ho tot.

Fites generadores de dependència

Les fites generadores de dependència son aquelles que un cop han finalitzat poden possibilitar la consecució d'una o més fites dependents, en el cas que aquestes no exigeixin la finalització de més fites. Per exemple, la fita de posar el got a la taula, és una generadora de dependència perquè la fita de vessar la llet al got depèn d'ella. No obstant posar el got a taula, no garantirà la possibilitat de vessar la llet, perquè dependrà també de posar la llet a la taula.

15

Obtenir espàtula

Obtenir ingredients

Fer l'amanida

Dependència


Fita dependent

Agafar got

Agafar llet

Vessar llet al got

Dependència


Fites generadores de dependència


Fites sense generació de dependència

Per una altra banda, les fites que no generin cap dependència, al finalitzar no possibilitaran la consecució d'altres fites. Un exemple clar, seria la fita de vessar la llet al got, que un cop s'ha portat a cap no permet fer cap acció més.

2.3.4 Classificació de les fites atenent a la seva finalització

Fites finalitzables

Les fites finalitzables són aquelles que un cop que s'ha completat, tornar a repetir-les no tindria sentit per a la consecució de la tasca encomanada. Per exemple, un cop hem acabat de fregir algun aliment es considerarà finalitzada l'acció de fregir i no serà possible repetir-la en el futur.

Fites no finalitzables

Per una altra banda, les fites o accions que no siguin finalitzables, cada cop que es completin existirà la possibilitat de tornar a portar-les a terme en el futur. Un exemple clar d'aquest tipus de fites són les que consisteixen en obrir o tancar portes: si l'obrim, un cop l'hem tornada a tancar hi ha d'haver l'opció de tornar-la a obrir.

2.3.5 Classificació de les fites atenent a l'associació amb objectes

Fites amb un objecte associat

Com hem comentat en l'apartat referent a la interactivitat dels objectes, existiran en el món virtual una sèrie d'elements susceptibles d'interaccionar amb l'usuari. Ara bé, també hauran d'anar lligats a una fita que defineixi la seva funció en el moment que es doni la interacció. Per exemple, la fita de posar el got a taula, podria portar associat l'objecte got i es completaria quan l'usuari fes clic a sobre. D'aquestes fites direm que porten un objecte associat per a la seva dependència.

16

Agafar got

Agafar llet

Vessar llet al got

Dependència


Fita no generadora de dependència


Fites sense associació amb objectes

Les fites sense cap tipus d'associació amb un objecte només podran exigir en el cas de les dependents, que es resolguin les dependències de finalització pendents. Si es tractés d'un tipus de fita independent ens trobaríem amb un error perquè la seva finalització seria immediata. Un exemple de fita sense associació és la de fregir una truita a la paella, ja que només requereix que finalitzin altres fites de les que en depèn (obrir el foc, posar l'oli i ou batut a la paella,etc.), però no hi ha cap objecte interactiu que estigui relacionat amb la consecució directa de l'acció.

2.3.6 Progamabilitat del nivell de dificultat de la tasca

Un aspecte molt important en el disseny de tasques serà la possibilitat d'ajustar la seva dificultat, ja que el perfil de cada pacient podria exigir una complexitat variable per a la finalització de l'activitat. A continuació farem un anàlisi dels diversos mecanismes que ens permetran variar la dificultat d'un tasca.

Nivell de concreció de la tasca

Com hem apuntat en l'apartat on definíem les fites, l'extracció d'una serie d'accions que defineixin una tasca és pot fer de múltiples formes depenent del criteri propi. Així doncs, la pròpia elecció de tasques amb fites molt concretes, o per contra, més generals, influirà directament en la dificultat global.

Per poder tenir varis nivells de concreció s'haurà de proposar un sistema que permeti guardar tasques de forma totalment independent a la implementació de l'entorn virtual.

Ajuda al pacient en temps d'execució

S'implementarà un sistema d'ajuda al pacient per a guiar-lo i alertar-lo d'errors en la execució de la tasca mitjançant missatges de veu o text. Els dos punts bàsics que s'hauran de desenvolupar seran :

1. Descripció de la fita: quan l'usuari passi el cursor per sobre un objecte associat a una fita, se li podrà notificar de quina fita es tracta, ja sigui amb una missatge textual o de veu. En el cas del missatge textual, no haurà de bloquejar la navegació per l'entorn. S'haurà de controlar, que aquesta informació només es proporcioni quan la fita sigui realment realitzable i essent coherent amb l'estat actual. Per exemple, tenim la tasca de servir-se un got d'aigua que representa el següent diagrama:

17

Posar el got sota l'aixeta

Obrir l'aixeta

Posar el got a taula

Dependència



En el cas de que l'usuari encara no hagués posat el got sota l'aixeta, al passar el cursor per sobre el got li hauria d'informar d'aquesta possibilitat. Un cop l'hagués posat sota, no hauria de mostrar cap informació, perquè la fita de posar el got a taula exigeix la finalització de la d'obrir l'aixeta. Finalment desprès d'obrir l'aixeta i omplir el got d'aigua, si passes el cursor per sobre li hauria de notificar la possibilitat de posar el got a taula.

2. Notificació de fita no completada: També permetran les fites tenir missatges periòdics tant de veu com text que alertin de problemes en la seva finalització. En l'anterior exemple del got d'aigua, si l'usuari tarda un determinat temps en posar el got a taula, s'anirà repetint un missatge periòdicament, que l'indiqui que ho ha de fer.

Un aspecte important respecte les alertes, serà que només s'hauran d'activar quan tingui sentit fer-ho. Per exemple, no tindria sentit alertar de que hem de posar el got sota l'aixeta un cop ja ho hem fet.

Per tal de controlar-ho, en el cas de les fites finalitzables serà tant senzill com comprovar si han acabat, i si es així, desactivar les alarmes d'error associades. El cas de les fites no finalitzables serà més complex ja que s'hauria de mirar si realment té sentit o no tornar a activar la alarma, tenint en compte l'estat de les demès fites. Per exemple en el cas de la fita d'obrir el foc, podria haver una alarma que avisés al usuari que és necessari obrir-lo. Ara be, un cop s'hagués acabat d'utilitzar el foc,i després d'haver-lo desactivat, la fita d'obrir el foc seria realitzable però no tindria sentit alertar a l'usuari de que és necessari fer-la.

Selecció de la funcionalitat dels objectes que no participen en la tasca

Observem que dins un escenari concret es poden donar múltiples fites, però que només unes poques intervenen directament en el desenvolupament de l'activitat. A demès, la possibilitat de portar a terme fites sense cap funció específica dins la tasca augmenta el nivell de dificultat de la mateixa, perquè obliga a l'usuari a decidir si el que està fent té una aplicació efectiva en els objectius globals. Així doncs, el fet de poder activar o desactivar la funcionalitat d'objectes que no intervenen en l'activitat pot permetre configurar el nivell de complexitat. Els paràmetres que hauria de ser possible configurar depenent del grau de dificultat desitjat seran:

1. Visibilitat: directament fer invisible un objecte per a que el pacient no tingui cap constància de la seva presencia en l'escenari

2. Associació amb les fites: també es pot anul·lar l'associació d'un objecte amb les fites que no intervenen a la tasca de manera que serà visible, però no serà possible la interacció amb ell per part de l'usuari.

Selecció del tipus de navegació

Un últim aspecte que pot incidir en la dificultat de la tasca és el model de navegació seleccionat. Si s'escolleix el model lliure, la sensació d'immersió en el mon serà més profunda però la possibilitat de desorientar-se augmentarà. En canvi amb la navegació dirigida serà més fàcil ubicar la posició pròpia en cada moment

18


2.4 Registre del progrés de l'usuariPer tal que els terapeutes puguin avaluar la tasca després de que l'hagi realitzat el pacient, serà necessari implementar un sistema que permeti guardar la informació, la qual s'enviaria posteriorment, per a l'anàlisi dels resultats. Els paràmetres que podria ser interessant guardar són els següents:

1. Temps de finalització de les fites: s'hauria de mantenir un registre de les fites que es van finalitzar , i el temps exacte que ha passat a partir de l'inici de l'activitat. Amb aquesta informació es podria elaborar un informe global sobre la evolució del exercici en el temps, i les fites completades.

2. Interacció fallida: alhora que es guarden les fites que es completen favorablement, es podria mantenir informació paral·lela, respecte els intents de portar a terme accions que no estan relacionades amb la tasca. Per exemple, si el pacient intenta agafar un plat, en l'activitat de servir-se un got llet.

2.5 Control de coherència de la tasca Entenem com a tasca coherent aquella que es troba definida de manera que l'usuari pot completar-la en l'entorn virtual, i no existeixen relacions de dependència incongruents entre les diverses fites que la componen. A continuació passem a explicar els diferents aspectes que l'aplicació hauria de controlar per tal d'obtenir tasques correctes.

2.5.1 Coherència de les relacions de dependència

La coherència en les relacions de dependència es refereix a que la tasca ha de seguir certes normes per tal que sigui aplicable a l'entorn.

Un error que es podria donar seria si tenim una fita sense cap objecte interactiu associat i que no depèn de la finalització de cap altre fita. En aquest cas la fita estaria sempre “teòricament” acabada. Si es tractes d'una fita no finalitzable comportaria un greu problema perquè estaria alternant constantment entre un estat de finalització i no finalització. En el següent exemple, si la fita d'agafar el pa no portés associada cap objecte interactiu, veuríem com al preparar l'entrepà, automàticament l'agafaríem sense fer res, perquè es consideraria que no hi ha cap dependència o interacció sense resoldre que impedís completar aquesta fita finalitzable.

19

Agafar la sal i l'oli

Agafar el pa

Preparar l'entrepà

Dependència



2.5.2 Control de presència d'objectes en escena

També s'haurà de comprovar abans de realitzar una tasca, si els objectes que estan en escena en el moment de la carga possibiliten la consecució de la mateixa.

Particularment, s'haurà de verificar que existeixin els objectes interactius amb alguna associació amb les fites de la tasca. En el cas contrari es podria actuar amb dos alternatives: per una banda es podria tornar a verificar la coherència de la tasca sense la presencia de les fites que no tenen l'objecte, o per l'altra, directament generar un error en la execució. La primera alternativa té l'avantatge de poder oferir un resultat provisional, encara que falti un o varis models. No obstant la definició de la tasca es veuria desfigurada, fet que no succeiria si no permetem en cap cas, l'absència d'objectes interactius associats a una fita.

2.6 Reusabilitat de la tascaUn altre aspecte molt interessant per part del disseny de tasques és la necessitat de que la seva definició permeti que siguin reusables. Si per exemple en una determinada tasca hem definit una fita que consisteix en posar el got a taula, i en una altra tasca es volgués implementar la mateixa fita, hauria de poder-se reutilitzar la fita de la primera tasca en la segona sense problemes.

L'avantatge que tindria aquesta implementació, es que a partir de la definició inicial d'una seria de fites comunes, es podria construir una gran varietat de tasques amb poc temps. La reutilització podria ser d'una fita o un conjunt relacionat d'elles.

També es podria contemplar no només la possibilitat de reusar la fita tota ella com una entitat única, sinó que també seria factible seleccionar els aspectes de la mateixa que es desitja reusar. Per exemple, podríem importar d'una acció determinada, els missatges d'alerta que pogués portar associat o el objecte interactiu que l'activa.

20

Tasques en un món virtual 3. Disseny

3. Disseny

3.1 Disseny de l'entorn virtualDonades les especificacions del projecte, per tal de crear l'escena en la que l'usuari podrà acomplir les tasques, es crearà un entorn virtual en 3D (concretament una cuina). Aquest oferirà les següents característiques:

1. Capacitat per a la creació de primitives geomètriques, incloent corbes, malles poligonals, buits, NURBS, metaballs.

2. Eines d'animació i de control de cinemàtica dels objecte

3. Característiques interactives per a jocs com detecció de col·lisions, recreacions dinàmiques i lògica.

4. Possibilitats de renderitzat intern versàtil i integració externa amb algun llenguatge per tal d'automatitzar o controlar tasques vàries.

5. Motor de jocs 3D integrat

6. Simulacions dinàmiques i sistema de gravetat.

7. Sistema de partícules estàtiques.

El conjunt de característiques esmentades permetran el disseny d'escenaris capacitats per a integrar tasques.

3.2 Disseny del sistema de navegacióEl tipus de perspectiva adoptada per a la navegació és la de primera persona, que situa l'angle de visió de l'usuari com si estigues dins l'escenari. Així doncs, el nivell d'immersió és alt.

S'ha decidit implementar un model de navegació lliure , amb possibilitat de rotació del punt de visió i translació, únicament limitada per les col·lisions amb objectes de l'entorn. Tot seguit, passem a analitzar els punts bàsics que integren el model de navegació: la visualització, moviment i control del personatge.

3.2.1 Visualització

Per tal de visualitzar l'escena, s'utilitza una càmera que generarà una projecció en perspectiva de l'escena. S'ha de considerar que la perspectiva és un efecte visual que depèn de la longitud focal utilitzada. El fons de l'entorn semblarà estar més proper o més llunyà del subjecte, depenent de la distància focal utilitzada. L'aplicació vindrà amb una distancia focal predeterminada que es considera la optima, no obstant existirà la possibilitat d'ajustar-la.

També s'haurà de considerar on col·loquem el pla de retall proper i llunyà (paràmetres de “clipping”), que permeten definir el rang d'espai que es visualitza des de la posició actual de la càmera. En un principi, al tenir únicament escenaris que representen espais interiors, aquest paràmetres no tindran importància apreciable, però es consideraria el seu ajust en el cas de que tinguéssim escenaris que representessin espais més oberts, on el rendiment es pot veure greument afectat si el pla de retall llunyà està molt allunyat.

21


3.2.2 Moviment del personatge dins l'escena

Definirem el personatge com un punt de visió i un conjunt d'eixos relacionats que possibilitaran el moviment i visualització natural de l'escena. A continuació passem a detallar la configuració d'aquesta entitat.

Estructura del cos a partir d'eixos

Distingim els següents eixos i les limitacions associades a cadascun d'ells:

1. Càmera: eix que porta lligat el punt de visió. No es podrà rotar, i estarà fixat a una altura predeterminada respecte l'eix de l'espatlla.

2. Espatlla: eix que possibilita l'elevació i abaixament del punt de vista. Aconsegueix un efecte realista del moviment del cap, ja que quan per l'exemple l'abaixem, es percep com si una part superior del cos també ho fes. Es troba lligat a una altura fixe del eix dels peus.

Aquest eix per tant, està limitat a la rotació de la coordenada X, i no es pot elevar més de 89 graus, i abaixar més de 89 graus. D'aquesta manera evitem que es pugui donar una volta completa apujant o baixant el cap.

3. Peus: identificat en la il·lustració com a “jugador”, aquest eix possibilita la translació en qualsevol direcció i la rotació a través de la Z, fet que ens permet rotar lateralment el punt de visió ,sense cap tipus de limitació.

Sistema de detecció de col·lisions

L'usuari no pot traspassar en cap cas els objectes que interfereixen el seu camí i ha de sentir l'acció de la gravetat en els moviments que faci. Per tal de simular-ho, a l'eix dels peus s'ha afegit una esfera que detectarà si hi ha hagut alguna col·lisió d'un volum extern a la mateixa, i en cas positiu anul·larà la translació. D'aquesta manera, l'esfera mai intersectarà un objecte de l'espai virtual.

L'avantatge principal d'aquest enfocament, és que el càlcul de detecció de col·lisions és poc costos i reacciona bé en la majoria situacions. Com que l'espatlla i el punt de visió sempre es troben alineats verticalment respecte l'eix dels peus, no podran existir incoherències en la visualització del escenari. Per exemple, si tenim el punt de visió avançat respecte la espatlla i avancéssim en direcció a una paret podríem traspassar-la perquè la detecció de la col·lisió amb els peus es faria un cop ja s'hagués travessat amb el punt de visió.

22


3.2.3 Sistema de control

El sistema de control escollit per al control de l'aplicació es basa en un model mixt entre teclat i ratolí. La translació dependrà del teclat i la rotació i selecció d'objectes, del ratolí. A continuació es detalla per a cada tecla i botó de ratolí, quina funció anirà associada:

Teclat

↑ Translació cap endavant

↓ Translació cap endarrere

→ Translació lateral cap a la dreta

← Translació lateral cap a l'esquerra

Ratolí

Moviment del ratolí: rotació del punt de visió

Clic del botó dret: selecció d'objecte

Moure la rodeta cap amunt: augmentar velocitat de translació

Moure la rodeta cap abaix: disminuir velocitat de translació

3.3 Decisions prèvies al disseny de la tascaA continuació passem a analitzar les decisions preses per tal de definir una tasca qualsevol en l'entorn: el sistema d'events, la definició de dependències, com es produirà la interacció amb els objectes, el sistema d'ajuda al usuari, el tipus d'accions que distingirem i les seves propietats i per últim, el plantejament orientat a objectes que ens permetrà definir una tasca globalment.

3.3.1 Model centralitzat d'events

Observem que és necessari per a l'execució d'una tasca d'una serie de serveis comuns (reproducció de so, animació , missatges de text per pantalla, etc.) que es poden necessitar en qualsevol context. Per tant, s'ha optat per un model que permet la definició genèrica d'events. Entenem com a event un succés que pot ésser percebut per l'usuari en temps real, ja sigui a nivell visual o sonor. La principal avantatge d'aquest enfocament es que només serà necessari implementar un gestor que s'encarregui de servir els diferents events. D'aquesta manera la sincronització entre els mateixos serà més eficient i senzilla. Els events serviran per exemple, per definir amb flexibilitat quins successos es donaran en l'escenari desprès de finalitzar una fita, o quin serà el missatge que sortirà un cop completem la tasca.

A continuació mostrem una classificació dels diferents events a desenvolupar, atenent l'àmbit d'acció específic:

1 Objectes de l'escenari 3d

1.1 Animació d'objectes

23


1.2 Configuració de la visibilitat dels objectes

1.3 Configuració de la posició dels objectes

1.4 Configuració de l'orientació dels objectes

2 Interfície d'usuari (GUI)

2.1 Diàlegs emergents

2.2 Diàlegs de confirmació (Si o No)

3 Reproducció de sons

Si per exemple tinguéssim una acció que consistís en posar el plat a la taula podríem definir els següents events associats a la finalització de la acció:

1. Ocultar el plat lentament

2. Moure el plat a la taula

3. Fer visible lentament el plat

Aquesta seria una possibilitat, ara be hi hauria l'opció de canviar els events per uns altres, com per exemple que es veiés directament com es mou el plat a taula mitjançant una animació. A més, es permetrà que un event utilitzat en una acció concreta pugui ésser reutilitzat en qualsevol altre. Es a dir, quan es defineixi un event es farà com una entitat distingible i separada que inicialment no estarà associada a cap altre entitat. Un cop definit es podrà associar a tantes entitats com es vulgui.

Així doncs, veiem que aquest enfocament permet una gran flexibilitat i capacitat de configuració, que és desitjable per tal que les tasques puguin permetre una definició el més amplia possible i fàcil de modificar, al estar unificat tot el sistema d'events.

3.3.2 Model de dependències entre accions

Per tal de plasmar les possibles dependències que poden sorgir entre les fites que composen una tasca i que hem analitzat en les especificacions, s'ha optat per un disseny en el que cada acció individualment emmagatzemi les accions dependents de la seva finalització. Així doncs considerarem cada acció dependent com un acció filla, i aquestes la consideraran com una acció pare. Una fita podrà tenir tants pares i fills com sigui necessari però no podran haver-hi duplicats en cap cas. En el següent exemple que il·lustra la tasca de servir un got de llet, veiem la informació de dependències que es guarda per tal de implementar aquest model:

24

Agafar got

Agafar llet

Vessar llet al got

Dependència


Posar el got a taula

Accions filles :

-Vessar llet al gotAccions filles :

-Vessar llet al got

Accions filles :-Posar el got a taula


Al no guardar la informació dels pares que té una acció dins la mateixa, quan s'hagi d'obtenir una llista dels pares serà costós temporalment perquè haurem de recórrer cadascuna de les accions buscant possibles coincidències en la seva llista de fills. Ara bé s'ha de considerar que l'operació de cerca de pares no serà necessària quasi mai durant el control de tasca. El que es desitjarà és mantenir una llista ràpida de fills per actualitzar les accions filles quan l'acció pare finalitzi.

Una acció sabrà que no queden més pares per finalitzar, mitjançant algun camp intern inicialitzat a zero que indiqui el nombre de pares que han finalitzat i una altre que indiqui el nombre total pares que té l'acció. L'actualització d'aquests camps es faria cada cop que es carregués la tasca.

Una altra limitació important es que una acció no es podrà incorporar en cap cas a la seva pròpia llista de fills. Per tant si hi han n accions en la tasca, el numero màxim de fills per a cada acció serà de n-1, i el número màxim de referències a fills emmagatzemades en les llistes de cada acció en una tasca serà de (n-1)*n. Així doncs tindrem un creixement quadràtic. No obstant s'ha de considerar que el número d'accions no serà molt elevat i aquest factor de creixement, no serà en realitat un problema.

Evidentment la informació que es guarda a la llista de fills no consistirà en tota l'acció duplicada, sinó que serà una referència a la mateixa. La implementació que s'utilitzarà serà una taula hash o diccionari on la clau serà el nom de l'acció filla i el valor associat indicarà el estat de la dependència (finalitzada o no). D'aquesta manera tindrem insercions rapides i amb comprovació automàtica de si existia prèviament una clau idèntica, fet que ens permetrà controlar que no es guardin fills duplicats.

3.3.3 Interacció amb els objectes

S'ha decidit que la manera amb que es detectarà que l'usuari vol interaccionar amb l'objecte serà quan faci clic a sobre el mateix amb el cursor de selecció.

El fet de fer clic a sobre un objecte no garantirà que l'usuari pugui veure els events associats al mateix. Com ja hem comentat s'hauran de resoldre totes les dependències abans.

3.3.4 Disseny de l'ajuda a l'usuari

En l'apartat de especificacions s'ha indicat que un dels requeriments es implementar un sistema que alerti i guii al usuari per a la consecució de la tasca. La manera que s'implementarà serà mitjançant el que anomenarem alarmes. Una alarma permetrà portar associat una serie d'events (per exemple, missatge d'alerta per haver-se deixat el foc obert) que s'aniran repetint periòdicament.

Les alarmes hauran d'anar associades a una acció per a poder entrar en funcionament. S''activaran sempre i quan l'acció amb la que vagin associada ho requereixi i en qualsevol moment es podran desactivar si aquesta ho requereix.

3.3.5 Tipus d'accions

Per tal de definir una acció, s'ha decidit diferenciar dos tipus atenent a la possibilitat de finalització.

Per una banda tenim les fites normals, que un cop s'han finalitzat no és podran repetir. Per l'altre, les accions reversibles que no podran ésser finalitzades i tindran

25


dos estats diferents (inicial i de reversió) que s'aniran alternant cada cop que hi hagi interacció positiva amb les mateixes i s'hagin resolt possibles dependències. Per tant, veiem que la fita reversible es una especialització d'una acció no finalitzable amb dos estats. La seva utilitat és molt gran, ja que existeixen moltes accions que es podran definir com a reversibles com per exemple les accions d'obrir i tancar objectes (portes, armaris, envasaments,etc.). D'aquesta manera no es requerirà que l'usuari que dissenyi les tasques crei dos accions diferents connectades sinó que podrà portar tot el control d'aquest tipus d'accions mitjançant una única acció especialitzada.

Totes les accions tindran un identificador únic que les identificara dins la tasca, així com una diccionari que com hem comentat en l'apartat del model de dependències, incorporarà la llista de fills. Posseiran un identificador de l'objecte interactiu que pot tenir associat així com el de l'alarma. També tindran en comú les accions normals i reversibles, el camp que compta el numero d'accions pares completades així com el numero total d'accions completades.

Accions normals

La condició per a que una acció normal finalitzi es que no tingui dependències per resoldre i en cas de tenir un objecte interactiu associat, que aquest hagi sigut activat. A la vegada, per a poder activar el objecte s'haurà d'haver completat prèviament les dependències existents i fer clic a sobre el mateix amb el cursor de selecció.

La finalització d'aquestes accions comportarà l'execució un únic cop, d'una série d'events preconfigurats i l'actualització del camp comptador d'accions pares completades de cadascuna de les seves accions filles.

Aquestes accions permetran portar una alarma associada. Aquesta activarà el seu funcionament sempre i quan les dependències de l'acció s'hagin resolt i l'objecte associat no estigui activat. Es a dir, en el moment en quan l'usuari te possibilitat d'activar l'objecte interactiu i encara no ho ha fet.

Accions reversibles

La condició per a que una acció reversible passi de estat inicial al de reversió, i viceversa es que no existeixin dependències, i en cas de tenir un objecte associat, que aquest s'activi.

Les accions reversibles es consideraran sempre com incompletades. La “finalització” d'aquestes accions (tot i no ésser finalitzables, entenem per finalització que es resolguin totes les dependències i que s'activi el possible objecte associat) comportarà l'execució dels events associats a cada estat . Quan el canvi sigui de estat inicial a de reversió, l'actualització del camp comptador d'accions pares de cadascuna de les seves accions filles es farà sumant una unitat, mentre que quan el canvi sigui a l'invers, es decrementarà en una unitat. D'aquesta manera definim que el estat en el que una acció reversible permet que els fills es completin serà únicament en el de reversió.

Aquestes accions permetran portar una alarma associada a l'estat inicial i una altra al de reversió. Aquestes activaran el seu funcionament sempre i quan les dependències de l'acció s'hagin resolt en l'estat actual i l'objecte associat no estigui activat. Es a dir, al igual que amb les accions normals, en el moment en quan l'usuari té la possibilitat d'activar l'objecte i encara no ho ha fet. En el cas de l'alarma inicial, únicament es programarà en el cas de que quedi alguna acció filla per completar.

26


En el següent exemple es mostra una tasca que consisteix en posar una botella de vi dins la nevera:

L'acció de posar el vi a la nevera només es podria completar quan la nevera estigues oberta (en l'estat de reversió) i l'acció d'agafar la botella de vi s'hagués completat. L'usuari podria obrir i tancar quants cops volgués la porta de la nevera, però només quan estigues oberta es podria posar el vi a dins. Si s'associes una alarma a l'estat inicial d'obrir/tancar la nevera, aquesta només es programaria en cas de que posar el vi a la nevera encara no s'hagués completat.

3.3.6 Modelització de la tasca mitjançant classes

Per tal de definir una tasca en el món virtual s'ha optat per un model orientat a objectes, que és un paradigma de programació que defineix els programes en termes de "classes d'objectes". Aquests objectes són entitats que combinen estat (és a dir, dades), comportament (això és, procediments o mètodes) i identitat (propietat de l'objecte que el diferencia de la resta).

Aquesta elecció ens permetrà disposar de mecanismes d'interacció (els anomenats mètodes) que afavoreixen la comunicació entre objectes (d'una mateixa classe o de distintes), i en conseqüència, el canvi d'estat en els propis objectes.

A continuació mostrem un gràfic explicatiu de les classes que conformen la definició de tasca, i expliquem a grans trets la funcionalitat de cadascuna abans de passar a concretar-les amb més detall en el apartat de disseny de la tasca.

27

Obrir/Tancar la nevera

Agafar botella de vi Posar el vi a la nevera

Dependència


Fites normals

Fites revers ible

TASCA

ACCIÓ

ALARMA

EVENT

Llegenda

Utilització

Classe


En aquest gràfic, els rectangles arrodonits identifiquen cada classe, mentre que una fletxa des de un rectangle a un altre, significa que el primer utilitza instàncies d'objectes de la classe del segon. Per tant, en un primer nivell tindrem la classe “mare” anomenada Tasca , que utilitza per a part de la seva definició elements de la classe Acció (el que també entenem per fita) i Event. A la vegada una Acció pot definir-se amb objectes de la classe Event i de Alarma, que també utilitza la classe Event.

La classe Tasca permet definir a nivell global una activitat, com un conjunt d'accions i objectes interactius que permeten la consecució dels objectius establerts .

La classe Acció representa una fita dins una tasca, amb tota la informació necessària: dependències que genera , l'objecte que porta associat l'acció, etc.

La classe Alarma permet definir la serie d'events que s'executen periòdicament avisant d'algun problema al usuari.

Per últim la classe Event, permet definir un event que serà possible executar en el context de l'aplicació, com per exemple una animació concreta, o la reproducció d'un determinat so. L'event serà independent de l'acció a la que s'associi.

3.4 Disseny de la tascaA continuació passem a explicar amb més detall el disseny de cada classe analitzant les dades i mètodes que implementen, així com el/s constructor/s de cadascuna.

Per tal de fer menys feixuga la descripció dels mètodes de les diferents classes, es suposaran implementats tots els mètodes d'accés a les dades de cada classe.

3.4.1 La classe Tasca

La classe Tasca permet definir una activitat, a la que se li poden afegir, modificar i suprimir fites i objectes que intervenen en la tasca. També possibilita definir el conjunt d'events que s'activaran a l'inici i fi de la tasca, i proveeix dels mètodes necessaris per guardar i recarregar una tasca que estigui en un fitxer a part. Alhora incorpora un mètode per depurar la tasca de possibles incoherències en la dependència d'accions.

A continuació passem a explicar el disseny de les dades i els mètodes que implementa.

Disseny de dades

El conjunt de tipus de dades que incorpora i defineix un objecte Tasca és el següent:

● Nom: cadena text

● Accions: diccionari

Clau = nom acció: cadena text

Valor = instància d'Acciò

● Accions Completades: natural

● Objectes: diccionari

Clau = nom objecte: cadena text

28


Valor = propietats inicials (visibilitat, orientació,posició)

● Events inicials: llista de Event

● Events finals: llista de Event

Explicació de cadascun dels membres de la classe:

Nom: El nom que pren la tasca.

Accions: el conjunt d'accions que conformen la tasca. Cadascuna d'elles haurà de tenir un nom únic que s'utilitzarà com a clau del diccionari que les emmagatzema.

Accions completades: nombre natural que representa el número de fites que s'han acomplert fins al moment.

Objectes: el conjunt de objectes que intervenen en la tasca. Cadascun d'ells tindrà un nom únic que s'utilitzarà com a clau del diccionari. El valor associat a la clau serà la visibilitat, orientació i posició inicials de l'objecte en l'espai tridimensional.

Events inicials: la seria d'events que s'executarien cada cop que es carrega la tasca.

Events finals: la seria d'events que s'executarien al finalitzar l'activitat.

Constructor de la classe

El constructor estàndard de la classe és:

Tasca (nom: cadena text)

On el paràmetre nom identifica la tasca per la seva funció.

Disseny de mètodes

El conjunt de mètodes que incorpora un objecte Tasca són els següents:

Afegir event inicial (event: instància d'Event)

Descripció: afegeix un event a la llista d'events inicials. L'ordre en que s'afegeixen determina la seqüència d'events que es serveixen a l'inici de la carrega de la tasca.

Afegir event final (event: instància d'Event)

Descripció: afegeix un event a la llista d'events finals. L'ordre en que s'afegeixen determina la seqüència d'events que es serveixen un cop s'ha completat la tasca.

Afegir objecte(nom: cadena text, visible:booleà, posició: vector , orientació: vector)

Descripció: afegeix un objecte al diccionari d'objectes , tenint com a clau nom. Els paràmetres visible, posició i orientació son opcionals i determinen l'estat inicial de l'objecte.

Llista accions()

Descripció: retorna una llista amb el nom de totes accions associades a la tasca.

29


Afegir acció(acció: instància d'Acció):

Descripció: afegeix una acció a la tasca si no existeix encara.

Modificar acció(acció: instància d'Acció ):

Descripció: modifica una acció existent amb la nova acció passada per paràmetre.

Eliminar acció(nom: cadena text)

Descripció: elimina una acció si existeix alguna amb el nom passat per paràmetre

Eliminar totes les accions():

Descripció: elimina totes les accions associades a una tasca

Guardar tasca(nom_arxiu: cadena text)

Descripció: guarda tota la tasca en un arxiu amb el nom passat per paràmetre. Retorna fals si hi ha hagut algun problema amb l'escriptura.

Validar tasca ()

Descripció: actualitza els camp 'pares_totals' de cada acció de la tasca, i elimina les accions que no tenen cap pare ni objecte associat , per tal que l'activitat sigui coherent i executable

Informació tasca ()

Descripció: mostra tota la informació referent a la tasca actual i les accions que la composen

3.4.2 La classe Acció

La classe Acció permet crear una nova fita que després podem afegir a la tasca. Podem definir d'un objecte Accio, la possible associació amb un objecte, l'alarma que pot portar associada, el tipus d'acció (si és normal o reversible), les dependències que genera, els events que es generaran un cop es completi,etc. Es a dir, tot un conjunt de paràmetres que permeten definir amb molta precisió el comportament de l'acció i la relació amb l'entorn.

A continuació passem a explicar el disseny de les dades i els mètodes que implementa.

30


Dades

El conjunt de tipus de dades que incorpora i defineix un objecte Acció és el següent:

● Nom: cadena text

● Tipus: enumerat (NORMAL , REVERSIBLE)

● Fills: diccionari

Clau = nom acció filla: cadena text

Valor = dependència completada: booleà

● Alarma disponible: booleà

● Alarma: instància d'Alarma

● Objecte disponible: booleà

● Objecte activat: booleà

● Objecte: cadena text

● Completa: booleà

● Valida: booleà

● Pares completats: natural

● Pares totals: natural

Si Tipus es igual a NORMAL:

● Events: llista d'instàncies d'Event

Si tipus es igual a REVERSIBLE:

● Events normal: llista d'instàncies d'Event

● Events reversió: llista d'instàncies d'Event

● Alarma reversible: instància d'Alarma

● Alarma reversible disponible: booleà

● Estat: enumerat (INICIAL , REVERSIO)


Nom: El nom que pren l'acció.

Tipus: el tipus que adopta l'acció. Pot ser NORMAL o REVERSIBLE.

Fills: el conjunt d'accions dependents de l'acció. Cadascuna d'elles vindrà identificada per un nom únic que s'utilitzarà com a clau del diccionari. El valor associat a la clau serà un booleà que indicarà si s'ha resolt o no la dependència.

Alarma disponible: indica si l'alarma tindrà la possibilitat d'activar-se durant el transcurs de l'execució.

Alarma: alarma que s'anirà activant periòdicament que hi hagi possibilitat de portar a terme l'acció i passi un cert temps.

Objecte disponible: indica si l'objecte associat a la fita serà funcional durant el transcurs de l'execució.

31


Objecte activat: indica si hi hagut o no interacció amb l'objecte associat.

Objecte: identifica amb un nom, el possible objecte associat a l'acció.

Completa: indica si s'ha completat o no l'acció. En el cas de les accions no finalitzables (reversibles) sempre serà fals.

V alida : indica si l'acció compleix els criteris globals de coherència en el conjunt de la tasca.

Pares completats: nombre de accions pares que han finalitzat (en el cas de accions normals) o que estan en estat de reversió (en el cas d'accions reversibles).

Pares totals: nombre total d'accions pares.

Si Tipus es igual a NORMAL:

Events: conjunt d'events que s'executaran quan es completi l'acció.

Si tipus es igual a REVERSIBLE:

Events normal: conjunt d'events que s'executaran quan l'acció es trobi en estat inicial.

Events reversió:conjunt d'events que s'executaran quan l'acció es trobi en estat de reversió.

Alarma reversible: alarma que s'anirà activant periòdicament quan no s'hagi completat l'acció en l'estat de reversió i passi un cert temps.

Alarma reversible disponible: indica si l'alarma reversible tindrà la possibilitat d'activar-se durant el transcurs de l'execució.

Estat: indica l'esta actual de l'acció REVERSIBLE, que pot ésser l'inicia o el de reversió.



Accio (nom: cadena text,tipus: enumerat(NORMAL,REVERSIBLE))

On el paràmetre nom identifica l'acció per la seva funció, i el tipus es un paràmetre opcional que indica de quin tipus es tracta. En cas de no indicar-ho es considerarà sempre que es una fita normal.

Disseny de mètodes

El conjunt de mètodes que incorpora un objecte Acció són els següents:

Llista fills()

Descripció: retorna una llista amb el nom de totes les accions filles dependents.

afegir_fill(fill: cadena text)

Descripció: afegeix una acció filla a la relació d'accions filles dependents, a partir del seu nom, i en el cas que no existeixi.

32


Eliminar fill(filll: cadena text):

Descripció: elimina l'acció filla amb el nom passat per paràmetre en cas que existeixi

Eliminar tots els fills()

Descripció: elimina la relació de totes les accions dependents.

Afegir event(event: instància d'Event, estat: enumerat (INICIAL , REVERSIO)):

Descripció: afegeix una event a la llista d'events associada a la fita. El paràmetre estat es opcional i només s'utilitza en el cas que l'acció sigui REVRSIBLE, indicant si l'event s'afegirà a la llista d'events inicials o la de reversió. Per defecte, es considerarà l'inicial.

Fixar alarma(alarma: instància d'Alarma):

Descripció: associa una alarma a l'acció actual. En el cas que sigui una acció reversible dependrà de la consecució de l'estat inicial.

Fixar alarma reversible(alarma: instància d'Alarma)

Descripció: nomes disponible per accions reversibles, associa l'alarma que dependrà de la consecució de l'estat de reversió.

Fixar objecte(objecte: cadena text):

Descripció: associa un objecte amb l'acció, que dependrà de la activació del mateix per tal de tenir possibilitat de completar-se.

3.4.3 La classe Alarma

La classe Alarma permet crear un objecte que representa una avís que es repeteix mentre sigui necessari. Definim una Alarma com una serie d'events que s'executen periòdicament sempre i quan l'acció a la que estigui l'Alarma associada no estigui completa i sigui susceptible de ser completada immediatament.

Dades

El conjunt de tipus de dades que incorpora i defineix un objecte Alarma és el següent:

● Temps: natural

● Temps absolut: natural

● Events: llista d'instància d'Event

33



Temps: indica el temps en segons que tarda en tornar-se a executar l'alarma a partir de l'ultima activació periòdica.

Temps absolut: emmagatzema en segons el temps exacte a partir de l'inici del programa en que s'haurà de tornar a executar, sempre i quan encara es donin les condicions necessàries. Aquest paràmetre s'utilitza internament per al control d'alarmes.

Events: llista d'events que s'executaran cada cop que s'activi l'alarma.



Alarma (temps: natural)

On el paràmetre temps indica l'espai de temps que haurà de passar entre cada execució de l'alarma.

Disseny de mètodes

El conjunt de mètodes que incorpora un objecte Alarma són els següents:

Afegir event(event):

Descripció: Afegeix un Event a la llista d'events associada a l'alarma

3.4.4 La classe Event

Implementa una classe que permet definir events en l'entorn virtual. Els tipus de events que pot construir son els següents:

1. VISIBILITAT: permet definir si un objecte de l'escena es visible.

2. MOURE: mou un objecte des de la posició actual a una altra definida.

3. SO: reprodueix un so de manera immediata, o esperant a que acabi la reproducció actual.

4. ORIENTAR: orienta un objecte mitjançant una matriu d'orientació definida.

5. ANIMAR: anima un objecte dins un rang de 'keyframes' definits.

6. RETARD: retarda l'execució d'events durant un temps definit.

7. DIALEG: mostra un diàleg per pantalla suspenent l'aplicació principal fins que no es faci clic al boto D'acord.

34


Dades

El conjunt de tipus de dades que incorpora i defineix un objecte Event és el següent:

● Tipus: enumerat(VISIBILITAT,MOURE, SO,ORIENTAR, ANIMAR, RETARD ,DIALEG)

Si Tipus és igual a VISIBILITAT:


● Visible: booleà

Si Tipus és igual a MOURE:


● Posició: vector 3 dimensions

Si Tipus és igual a ORIENTAR:


● Orientació: matriu de 3x3

Si Tipus és igual a SO:

● Arxiu: cadena text

● Volum: nombre real

● Esperar: booleà

Si Tipus és igual a ANIMAR:


● Inici : natural

● Fi: natural

Si Tipus és igual a RETARD:

● Temps: natural

Si Tipus és igual a DIALEG:

● Títol: cadena text

● Text: cadena text


El constructor dependrà en cada cas del tipus d'event desitjat.

Explicació de cadascun dels membres de la classe i els paràmetres necessaris per a instanciar cada tipus:

1. Event(VISIBILITAT,objecte: cadena text,visible: booleà)

objecte: nom del objecte en escena al que se li aplicara el canvi de visibilitat.

visible: booleà que defineix si es mostra o no el objecte.

2. Event(MOURE,objecte: cadena text,posicio: vector 3 dimensions)

objecte: nom del objecte en escena al que se li aplicarà el canvi de posició.

posició: vector de 3 dimensions que defineix la posició absoluta del objecte.

35


3. Event(ORIENTAR,objecte: cadena text,orientacio: matriu de 3x3)

objecte: nom del objecte en escena al que se li aplicara el canvi d'orientació.

4. Event(SO,arxiu: cadena text: nombre real ,volum,esperar: booleà)

arxiu: ruta del arxiu de so que reproduirà l'event.

volum: volum de la reproducció (0.0 silenci - 1.0 volum màxim).

esperar: booleà (per defecte Cert) que defineix si el gestor d'events espera que acabi un possible so en reproducció per reproduir l'arxiu (Cert), o es reprodueix immediatament finalitzant qualsevol altre reproducció (Fals).

5. Event(ANIMAR,objecte: cadena text,inici: natural,fi: natural)

objecte: nom del objecte en escena que serà animat.

inici: frame d'inici de l'animació.

fi: frame de final de l'animació.

6. Event(RETARD,temps)

temps: temps durant el qual no es serviran peticions d'events.

7. Event(DIALEG,títol: cadena text,text: cadena text)

titol: cadena de text que conte el títol del diàleg.

text: cadena de text amb el cos de text del diàleg.

36

Tasques en un món virtual 4. Desenvolupament

4. Desenvolupament

4.1 Creació de la cuina virtualL'entorn virtual que s'ha modelat, a consistit en espai interior que simula una cuina amb menjador. S'ha procurat que els objectes incorporats permetessin una definició el més amplia possible de tasques dins l'escenari. Per això s'ha modelat des d'una nevera o un forn, passant per mobiliari divers (armaris, portes, taula,etc.) i altres elements comuns que es troben en qualsevol cuina: els fogons, una aixeta i la pica d'aigua, etc. A continuació fem menció del programari més important que utilitzarem i en quin sentit contribuiran a la creació de la cuina. Desprès farem un anàlisi de la relació d'objectes incorporats en l'escenari i la seva ubicació en l'espai 3D.

4.1.1 Blender 3D

Per a poder modelar l'entorn virtual i disposar alhora d'un motor de jocs 3D integrat s'ha utilitzat el programari lliure Blender 3D. Blender és un programa que integra una sèrie d'eines per a la creació d'un ampli rang de continguts 3D, amb els beneficis afegits de ser multiplataforma i tenir una grandària d'uns 5MB (irrisòria comparada amb altres programes semblants del mercat, com 3D Studio, que en l'última versió ocupa 2,43 GB). Destinat a artistes i professionals de multimèdia, Blender pot ésser usat per a crear visualitzacions 3D, tant d'imatges estàtiques com de vídeos d'alta qualitat, mentre que la incorporació d'un motor de 3D en temps real (Blender Game Engine) permet la creació de contingut interactiu que pot ser reproduït independentment. Originalment desenvolupat per la companyia 'Not a Number' (NaN), Blender es desenvolupa actualment com a 'Programari Lliure', amb el codi font disponible sota la llicència GNU GPL. La versió específica utilitzada per al desenvolupament d'aquest projecte ha sigut la 2.42a. És molt recomanable si es fa un projecte amb el Blender intentar no migrar mai de versió a no ser que sigui absolutament necessari, perquè sorgeixen molts problemes de compatibilitat entre els formats de les diferents versions. De fet, vaig sofrir un retràs molt important per voler intentar migrar els entorns de la 2.42 a la 2.43, i al final vaig haver de continuar amb l'antiga perquè era impossible fer-ho amb la nova.

Blender Game Engine (BGE)

Utilitzarem concretament les eines de creació d'entorn 3d que proveeix, i molt especialment, el motor 3D integrat que incorpora les següents funcionalitats:

● Plataformes: linux, windows, mac ● Sistema de blocs lògics (Logic Bricks) que permet controlar els objectes en

escena fàcil i intuïtivament.● Suporta Python

37

Vista en wireframes de la cuina


● Suporta glsl shader 2.0● Mapejat Parallax ● Mapejat Especular ● Mapes de color ● Mapes de detall ● Reflexions ● Il·luminació● Reproducció d'arxius en format WAV● Vertex color ● Phong shading ● Simulació física● Formats de textures suportats : tga+alpha, png+alpha, jpg ● Fonts bitmap ● Deformació de models mitjançant ossos (en angles, “bones”) ● LOD (nivell de detall escalable) ● Comunicació a través de la xarxa (amb Python) ● Coordenades Multi UV (amb Python) ● Mipmapping

El sistema de Logic Bricks

El conjunt de Logic Bricks, és un sistema propi del BGE. Un Logic Brick és una representació gràfica d'una unitat funcional lògica de Blender que pot ser un Sensor, Controlador o Actuador. Un Sensor pot anar connectat amb un Controlador, i aquest a la vegada amb un actuador. Els blocs lògics estan associats a un objecte en concret de l'escena.

Mitjançant diferents configuracions de blocs podem controlar múltiples aspectes del entorn 3d i la interacció de l'usuari amb aquest. A continuació passem a descriure breument cada tipus de bloc, i en els següents apartats anirem veiem diferents configuracions de Logic Bricks que serviran de base per a controlar la navegació o control d'interacció de la tasca.

Tipus de Sensors

Els sensors capturen diferents tipus de successos durant l'execució de l'aplicació, generant un pols que s'envia a cadascuna dels controladors amb els que poden estar associats. Al igual que els controladors i actuadors, de cada tipus de sensor podem modificar una sèrie de paràmetres. Distingim els següents tipus de sensors:

• Joystick: Genera un pols segons si em pressionat algun botó o hem mogut la palanca cap alguna direcció.

• Message: Genera un pols quan arriba un missatge. Els missatges es poden enviar mitjançant l'actuador de missatges.

38


• Ray: Genera un pols quan es detecta un objecte a una determinada distancia del objecte mitjançant un raig. La direcció del raig es pot configurar segons quin eix volem (X,Y, o Z), i si el volem en sentit positiu o negatiu respecte el centre de l'objecte al que està assignat el bloc.

• Random: Genera polsos de forma aleatòria a partir d'una llavor.

• Property: Genera un pols quan un certa propietat d'un objecte canvia, es troba en un cert rang de valors o és igual o diferent d'un valor determinat. He detectat un bug (ja comunicat a l'equip de desenvolupadors) que fa que el sensor no generi cap pols quan es vol detectar que un valor de tipus float es troba dins un interval determinat. En la versió 2.43 informen que s'ha corregit el problema, però continua fallant de forma aleatòria, inclús amb un rang generós per a que faci la detecció. Per tant, el més recomanable es programar les deteccions amb valors enters, que són mes estables.

• Radar: Genera un pols quan un altre objecte es troba a una determinada distancia i dins un rang de la esfera de detecció (es pot determinar entre quins angles s'escombrarà buscant objectes).

• Near: Semblant al Radar. Genera un pols quan un objecte es troba a una determinada distancia configurada. S'escombra en totes direccions.

• Collision: Genera un pols quan l'objecte col.lisiona amb un altre de l'escena.

• Touch: Genera un pols quan un objecte fa contacte amb un d'altre. A diferencia de Collision, es pot especificar quin material en concret a de tocar per tal que s'activi.(Ex. Que nomes s'activi quan toqui fusta).

39


• Mouse: Genera un pols quan ocorre algun event de ratolí (es mou, es fa clic, es fa girar la rodeta, etc.).

• Keyboard: Genera un pols quan es pressiona a o es deixa anar alguna tecla.

• Always: Genera polsos sempre. Es pot configurar la velocitat en que es generen. També hi ha l'opció de que només en generi un (molt útil per a les inicialitzacions).

Tipus de controladors

Els blocs controladors són activats pels sensors i tenen associats actuadors. Existeixen els següents tipus:

• AND: Activa els actuadors associats si tots els sensors han generat un pols.

• OR: Activa els actuadors associats si algun dels sensors ha generat algun pols.

• Expression: Activa els actuadors associats si es compleix l'expressió lògica.

• Python: Executa el script de Python. Des del context del script només es té accés als sensors i actuadors associats al controlador. Aquesta limitació a complicat el disseny posterior del control de la tasca.

Tipus d'actuadors

Si el controlador o sol·licita, els actuadors que porta associats activaran la seva funció específica. Els tipus existents són:

• Visibility: Mostra o oculta el objecte al que va associat.

40


• Game: Reinicia o surt de l'aplicació. Pot carregar també una nova a partir d'un fitxer extern.

• CD: Permet la reproducció continua o selectiva de pistes d'un CD.

• Message: Envia un missatge a tots els objectes o a un en concret de l'escena. Els missatges es composen de subjecte i cos del missatge.

• Random: Assigna un valor aleatori a una propietat de l'objecte al que l'actuador està assignat.

• Scene: Permet carregar una escena nova, eliminar-la, afegir escenes en primer pla (overlay scenes), suspendre l'escena actual, etc.

• Edit Object: Permet afegir objectes nous a escena (es pot configurar un temps de vida), editar-ne i eliminar existents.

• Property: Canvia el valor d'una determinada propietat de l'objecte.

• Sound: Permet carregar i reproduir un determinat so en format WAV.Únicament els sons prèviament carregats a Blender es poden reproduir (important limitació que solventem amb l'us de les llibreries Pygame de so).

41


• Camera: Fa que la càmera actual segueixi el objecte. Es pot configurar la distancia a la que es trobarà la càmera (dins un rang) i l'altura respecte l'objecte en l'eix X o Y.

• IPO: Permet reproduir una animació IPO definint el rang de frames que compendrà l'animació i el tipus de reproducció (reproduir un cop, repetir sempre, etc.).

• Constraint: Limita l'objecte de manera que no pugui col·lisionar amb cap objecte dins un rang determinat.

• Motion: Permet aplicar un força uniforme o de gir a un objecte. També es pot aplicar una determinada acceleració lineal o angular.

4.1.2 Pygame i llibreries SDL

Tot i que el Blender Game Engine implementa un sistema de reproducció de sons en format WAV, aquest es bastant limitat i en ocasions no respon satisfactòriament (he detectat un altre bug que fa que l'aplicació no respongui quan es reprodueixen sons WAV a una freqüència diferent de 44100 Hz). Per tal de solucionar aquest problema s'ha decidit utilitzar les llibreries Pygame, i concretament la part que es dedica a la gestió de sons.

Pygame és un conjunt de mòduls del llenguatge Python que permeten la creació en un principi de videojocs en dues dimensions d'una manera senzilla. Gràcies al llenguatge, es pot prototipar i desenvolupar ràpidament. També pot utilitzar-se per a crear altres programes multimèdia o interfícies gràfiques d'usuari.

Al igual que amb algunes funcions de Blender, Pygame funciona com interfície de les biblioteques SDL, que són un conjunt de llibreries desenvolupades amb el llenguatge C que proporcionen funcions bàsiques per a realitzar operacions de dibuixat 2D, gestió d'efectes de so i música, i càrrega i gestió d'imatges. SDL és una abreviatura en anglès de Simple DirectMedia Layer. Malgrat estar programat en C, té wrappers a altres llenguatges de programació com per exemple Python. També proporciona eines per al desenvolupament de videojocs i aplicacions multimèdia. Una de les seves grans virtuts és el tractar-se d'una llibreria multiplataforma, suportant oficialment els sistemes windows, linux, MacOS i QNX, a més d'altres

42


arquitectures/sistemes com Dreamcast, GP32,etc. D'aquí li vénen les sigles Simple Directmedia Layer que més o menys al·ludeix a capa d'abstracció multimèdia. La llibreria es distribuïx sota la llicència LGPL, que és la qual ha provocat el gran avanç i evolució de les SDL.

També cal dir, que l'aplicació final pot executar-se en qualsevol entorn Win sense necessitat de tenir instal·lat Python ja que incorpora totes les DLL's i llibreries necessàries.

4.1.3 Exemples de desenvolupament

A continuació es mostren una sèrie d'exemples que il·lustren una petita porció de la fenia de modelat, texturitzat, animació i il·luminació de l'escena. Es tracta de casos concrets que s'han desenvolupat per tal de crear l'entorn virtual la cuina, i que intenten il·lustrar en cada cas, la metodologia de treball seguida. Val a dir, que a més d'aquest casos, n'hi han hagut molts més que han exigit una solució diferent a l'exposada aquí.

Modelant una forquilla

Per tal de modelar una forquilla utilitzarem una lattice, que és una reixeta tridimensional de vèrtex no renderitzables. El seu principal ús és donar deformacions addicionals a qualsevol objecte "fill" que posseeixi. Aquests objectes poden ser malles, superfícies i fins i tot partícules.

Per modelar la forquilla crearem un dibuix simple (mitjançant splines) que representi una forquilla quadrada (bastant irreal). A continuació afegirem un objecte Lattice i subdividirem l'objecte en 7 divisions en l'eix Y, 2 en l'eix X i 2 més en el Z.

Ajustarem la resolució de la Lattice per a abastar el llarg de la forquilla. A continuació emparentem la forquilla amb la Lattice i comencem a escalar els vèrtexs. Si escalem per exemple els vèrtexs de l'eix Z de la Lattice tindrem

control sobre la profunditat de l'objecte.

Seleccionarem i mourem diferents seccions de vèrtexs per a donar-li a la forquilla les corbes adequades i obtenir el resultat final.

43

Dibuix inicial de la forquilla

Lattice ajustada

Subdivisió de la Lattice


Texturitzant la superfície dels fogons

A continuació mostrarem un exemple de texturització d'un model mitjançant la tècnica del Mapejat UV ("UV Mapping" en anglès).

El mapejat UV és una manera de plasmar textures en forma d'imatge sobre models tridimensionals assignant una part d'una imatge a un polígon en el model. Cada vèrtex del polígon és assignat a un parell de coordenades 2D que defineixen quina part de la imatge es plasma sobre el polígon. Aquestes coordenades 2D

es diuen UVs. L'operació de crear aquests mapes UV es coneix també com a desplegament ("unwrap" en anglès), degut al fet que tot ocorre com si la malla fos desembolicada o desplegada sobre un plànol 2D.

El model a texturitzar és la superfície dels fogons, que inclou també el panell de control. Utilitzarem una textura que simularà la reflexió (Reflex.jpg) i una altra que farà de dibuix del panell (Panell.jpg).

Inicialment tindrem el model sense texturitzar. Desplegarem l'editor de “UV Mapping” integrat dins el Blender i farem un “unwrap” de Reflex.jpg des de la projecció, de forma que les coordenades UV es calculin utilitzant la projecció de la finestra de visió de l'escenari 3d, i després s'escali a la

fracció de la textura de la imatge. A més, a les opcions de texturitzat en temps real indicarem que volem reflexió (“Reflection”) per tal que la textura s'orienti respecte l'usuari en tot moment, de manera que semblarà realment un material reflectant.

A continuació, ajustarem la textura Panell.jpg mitjançant una projecció cubica, a traves de les 2 cares triangulars que conformen el panell de polsadors. Es tindrà molta

cura en que els petits dibuixos que indiquen el fogó associat a cada polsador, estiguin correctament alineats amb els corresponents polsadors. En aquesta cas, a les opcions de texturitzat en temps real indicarem que volem texturització normal. Un cop fet, això ja tindrem el resultat final.

44

Reflex.jpgPanell.jpg

Superficie amb reflexio

Textura Reflex projectada

Dibuix aplicat al panell

Superficie dels fogons sense texturitzar

Resultat final


Animant un objecte: tirar la sal a la paella

Els objectes amb Blender es poden animar de diverses formes: canviant la seva posició, orientació o grandària en el temps, deformant els seus vèrtex i punts de control, etc.

Hi ha tres mètodes utilitzats normalment en programes d'animació per a poder animar un objecte en 3D:

• Key frames (fotogrames clau): La posició completa es guarda per unitat de temps (frames o fotogrames). Una animació es crea interpolant fluidament l'objecte al llarg dels fotogrames. L'avantatge del mètode és que et permet treballar amb unitats clarament visibles. L'animador pot treballar des d'una posició a la següent, pot canviar posicions creades anteriorment, o moure-les en el temps.

• Motion Curves (corbes de moviment): Poden dibuixar-se corbes per a cada component XYZ de la posició, rotació i grandària. Això forma el gràfic del moviment, amb el temps en les coordenades horitzontals i el valor en les verticals. L'avantatge d'aquest mètode és que et dóna control precís sobre el resultat del moviment.

• Path (Camí): Es dibuixa una corba en un espai 3D i se li assigna a l'objecte perquè la recorri d'acord a una funció de temps donada per a la posició al llarg del camí.

Els primers dos sistemes (key frames i motion curves) s'integrenen Blender, en un d'únic, el IPO (sistema d'Interpolació).

Fonamentalment, el sistema IPO consisteix en corbes de moviment estàndard. Una simple pulsació d'un botó canvia la IPO a un sistema de claus, sense conversió ni canvis en els resultats.

En el cas de l'animació associada a l'acció de tirar la sal a la paella (que serà necessària implementar en la tasca exemple de fer una truita), tenim l'objecte que representa el contenidor de sal el qual, es troba inicialment al costat del fogó on es posa la paella.

Per tal de definir el moviment, primer acotarem el temps total que durarà l'animació i de quines parts es compondrà. Considerem doncs, un temps total de 5 segons, dividit en les següents etapes:

1. 0s-0,83s: La sal, des d'un punt inicial, s'eleva a un de més elevat i s'apropa lleugerament a la paella. Anomenarem a aquest punt com ALFA.

2. 0,83s-1,66s: La sal baixa i s'apropa més a la paella fins a arribar a un punt límit on es considera que ja ha sortit la sal de dins contenidor. Anomenarem a aquest punt com BETA.

3. 1,66s-2,5s: La sal torna al punt ALFA.

4. 2,5s-3,33s: La sal torna al punt BETA.

5. 3,33s-4,16s: La sal torna al punt ALFA.

45

Punt inicial


6. 4,16s-5s: La sal torna al punt inicial.

Considerant que cada 24 keyframes tindrem un segon i que definirem l'animació en un rang a partir de 100 keyframes (de 0 a 100 ja estarà ocupat per altres tipus d'animacions), la divisió en keyframes serà la següent:

Frames Punts de recorregut

100-120 Del punt inicial a ALFA

120-140 De ALFA a BETA

140-160 De BETA a ALFA

160-180 De ALFA a BETA

180-200 De BETA a ALFA

200-220 De ALFA al punt inicial

Val a dir que el bloc IPO de Blender és universal No diferencia si es controla el moviment d'un objecte o la configuració del material. De totes maneres, Blender fa distinció entre diferents tipus de IPOs i la interfície ho té en compte automàticament. Cada tipus de bloc IPO té un nombre fix de canals disponibles. Cadascun té un nom (LocX, SizeZ, etc.) que indica com s'apliquen. En el cas que estem desenvolupant, definirem els tres punts mitjançant la seva posició absoluta(canals LocX,LocY, i LocZ) i la seva rotació (RotX,RotY i RotZ). Obtenim els punts següents:

Punt Posició Rotació (en graus)

LocX LocY LocZ RotX RotY RotZ

Inicial 7,731 -0,290 2,754 90 0 18,812

ALFA 8,127 0,363 3,666 -43,730 11,619 -21,473

BETA 8,468 0,690 3,114 -91,164 -8,890 -22,662

La interpolació de les IPO podrà ser:

• Constant: després de cada vèrtex de la corba, el seu valor roman constant. No hi ha interpolació.

• Lineal: s'interpola linealment entre els vèrtex.

• Bezier: la interpolació suau estàndard basada en corbes Bezier.

46

Punt ALFA


En el nostre cas utilitzarem interpolació Bezier per tal que el pas de un punt a l'altre sigui més suau. Així doncs tenim el següent esquema IPO:

Un desavantatge de treballar amb corbes de moviment és que la llibertat de les transformacions està limitada. Es pot treballar bastant intuïtivament amb corbes de moviment, però només si aquesta pot ser processada en una base XYZ. Per a una posició això és trivial, però per a una grandària o rotació hi ha disponibles millors descriptors: matrius (3x3) per a la grandària i “quaternions” (4x4) per a rotacions.

No obstant en aquest cas el resultat es satisfactori i realista, i el temps per a poder crear l'animació ha sigut bastant baix, en comparació a si haguéssim utilitzat una definició matemàtica del moviment.

47

Punt BETA


Il.luminant l'entorn virtual de la cuina

La il·luminació és un factor molt important a tenir en compte. Una escena excel·lentment modelada i texturizada podria espatllar-se si no té un bon esquema d'il·luminació, mentre que un model simple pot arribar a ser molt realista si aquesta hàbilment l'il·lumina. La il·luminació se sol menysprear pels dissenyadors amb menys experiència, que normalment creuen que en el món real les escenes ,que solen estar il·luminades per una sola llum (un llum, el sol, etc.), produiran el mateix efecte amb una sola llum en gràfics per ordinador. Això és fals, degut al fet que en el món real tot i que hi ha una sola llum present, aquesta es veu modificada per salts i es torna a irradiar en tota l'escena pels objectes en els quals rebota, fent ombres lleugeres i zones no completament fosques, però il·luminades parcialment. Les físiques de les ones lumíniques són simulades pels renders (Ray Tracing) i poden ser simulades amb Blender activant el motor "Radiosity". No obstant, en el nostre cas estem limitats a l'us del motor de render intern del Blender i el que ens interessa sobretot, és que el rendiment de l'aplicació sigui el més optim possible mantenint un compromís estable entre la tasa de frames per segon (FPS) i la qualitat visual de l'escena.

Tot i que Blender proporciona en principi quatre tipus de llums (Sun Light, Hemi Light, Lamp Light, Spot Light) només estan disponibles per al Game Engine la llum Sun, Spot i Lamp. El resultats visuals de la llum que simula el sol (Sun Light) han sigut extremadament pobres així doncs, s'han descartat des d'un principi. Per una altra banda, la llum Spot també mostrava un comportament poc realista i disminuïa el rendiment de l'aplicació considerablement. Així doncs s'ha optat per un model basat en llums de tipus Lamp.

La llum Lamp és de tipus omnidireccional (consisteix en un punt sense dimensions que irradia la mateixa quantitat de llum en totes les direccions). La direcció dels rajos de llum en la superfície d'un objecte ve donada per la línia que uneix el punt de la font de llum i el punt en la superfície de l'objecte. A més, es pot configurar que la intensitat de la llum decreixi a partir d'un radi donat de la distància del focus. Els paràmetres que podem configurar són:

48

Prova 1 d'il·luminació global

Prova 3 d'il.luminació global




● Distancia: dóna la distància a la qual la intensitat de la llum és la meitat de l'Energia. Els objectes que estan més prop que aquest punt, reben més llum, mentre que els quals estan més lluny reben menys llum.

● Atenuació: si s'activa, podem configurar atenuació lineal o quadràtica.

● Energia: intensitat de la llum que desprèn el focus emissor.

● Color: el propi color de la llum.

També podem configurar si volem que la llum mostri efectes de difusió o especulars.

A continuació s'analitzen una sèrie de proves efectuades amb la il·luminació global de la cuina. El focus emissor es troba sota les llums de la paret i es de tipus Lamp. En totes les proves el color del focus en RGB es [1,1,0.9] (blanc lleugerament groc) i la distancia es de 40 unitats.

No s'ha optat per implementar un model d'atenuació lineal o quadràtica, perquè disminuïa dràsticament el rendiment. A més, hi han certes superfícies amb la simulació de recepció de llum desactivada (com per exemple el terra) per tal d'estalviar recursos, i obtenint un resultat molt similar a si estiguessin il·luminades.

Prova 1 Prova 2 Prova 3 Prova 4 Prova 5

Energia 1.00 1.00 1.00 1.00 0.50

Especularitat Activada Desactivada Activada Desactivada Activada

Difusió Activada Activada Desactivada Desactivada Desactivada

A la prova 1 tenim acivada tant l'especularitat com la difusió que genera el focus de llum i observem en aquelles superfícies que tenen activada la recepció de llum com a mesura que canviem l'angle de visió s'observa l'efecte de la reflexió especular de la llum. Ara bé, amb alguns objectes això implica una pèrdua de realisme (com per exemple els que representen mobles de fusta) ja tenen un comportament especular massa exagerat. En comparació a la prova 2, on no tenim l'especularitat activada( i per tant tenim una mica més de rendiment) , la prova 1 no mostra masses diferències que justifiquin adoptar el seu model d'il·luminació.

Respecte les proves 3 i 4, els seus resultats són totalment irreals al no tenir cap de les dues activades la difusió de la llum per les superfícies, i en el cas de la 4, comentar que el rendiment és radicalment baix. En l'ultima prova, tenim el mateix sistema que amb la prova 2 però amb la mitat d'energia; comprovem que els resultats són millors amb una energia més elevada, ja que la cuina sembla com apagada com o mostra la il·lustració.

Així doncs, tenim que per a la escena de la cuina utilitzarem una Lamp col·locada a prop de les llums del sostre amb una energia de 1.00 i amb la difusió activada i la especularitat desactivada.

49



4.1.4 Optimització del rendiment de l'aplicació

Les següents tècniques ha permès un augment de la velocitat de l'apliació:

1. Desactivar els Blender Materials: Blender ofereix una opció molt còmoda que consisteix en assignar materials Blender (facilment editables) als objectes, i que aquests es visualitzin en el Game Engine. Ara bé, aquesta opció condueix a un temps de carrega un 50% més llarg i una disminució de la velocitat semblant al percentatge de carrega , perquè ha de traduir la definició dels materials a Open GL. A més, existeixen incongruències amb materials transparents. Per això, aquests s'han definit directament configurant els Vertexs Colors , Shaders i l'UV Mapping que proporciona l'Open GL.

2. Desactivar la il·luminació de determinades superfícies: s'ha anul·lat el càlcul de difusió de la llum en determinades superfícies obtenint un resultat molt semblant a si ho estiguessin (com per exemple el terra).

3. Millors textures, menys polígons: s'ha procurat rebaixar al màxim el nombre de polígons dels objectes, ja que és millor un objecte ben texturitzat i il·luminat, que un amb milions de polígons i amb deficient texturització.

4. Desactivació del canal d'especularitat de la llum.

5. Simulació de la reflexió d'objectes mitajnçant textures: en comptes de calcura la reflexió d'un objecte (per exemple, de la pica de l'aigua), se li ha assignat una textura amb un canal de reflexió que simula l'entorn i que fa l'efecte de que es reflecteixi sobre l'objecte assignat.

6. Utilització de poques textures: s'han incorporat poques textures utilitzades en diferents objectes de l'escena. S'aconsegueix la variació en determinats casos variant el color primari del objecte (vertex colors).

7. Utilització d'una única llum per a tota l'escena.

8. Conversió de tots els objectes a tipus mesh: els objectes tipus mesh només guarden informació poligonal estàtica i per tant, es carreguen més ràpid.

9. Amb determinats mobles contenidors que es poden obrir i tancar (l'armari, els calaixos, etc.), s'ha implementat un model simple de control d'animació, en comptes d'assignar una estructura completa de Logics Bricks del tipus objecte interactiu(veure apartat 4.2.1).

50


4.2 Implementació del sistema de navegacióEl sistema de navegació desenvolupat s'ha construït mitjançant els eixos definits a l'apartat de disseny, associats a la vegada amb un conjunt de Logics Bricks que possibiliten el moviment dins l'escena i el visionat de la mateixa. La definició general de propietats, sensors, controladors i actuadors necessaris d'aquest sistema la veiem en la següent il·lustració:

L'eix jugador s'ha configurat com una entitat Actor i Dynamic , es a dir, que el sistema de física integrada del BGE l'avaluarà. Se li ha assignat una massa i una esfera de col·lisió de radi 0.5 unitats per a evitar que el personatge interfereixi amb altres elements del entorn.

A continuació passem a detallar cadascun dels components del sistema de navegació integrat mitjançant el Blender Game Engine:

Propietats del sistema

Les següents propietats formen part del sistema de navegació:

● Sensibilitat: variable que determina la sensibilitat del moviment de rotació lateral i inclinació

● Ini: variable booleana que indica si es el primer cop que s'executa el sistema de navegació. Serveix per a fer les pertinents inicialitzacions un únic cop.

● MaxVel: variable que determina quina serà la màxima velocitat que es podrà assolir amb el moviment de translació.

● FiltreRatolí: variable que determina la sensibilitat global del ratolí.

● Volar: variable booleana que determina si estem en mode vol o no.

● Rot: variable que indica la rotació actual.

● Inclinació: variable que indica la inclinació actual. S'utilitza per controlar que no es passin els valors màxim i mínim d'inclinació.

51


Sensors del sistema

1 Sensors de teclat: configurats per a que detectin la pulsació d'una tecla. Generen polsos de detecció amb una freqüència de 30 Hz. En el cas de la tecla per commutar el mode de vol i la de sortir (teclaESC), generen un únic pols encara que mantinguem premuda la tecla durant un temps.

1.1 TeclaVolar: sensor que s'activa un cop, quan premem la tecla d'espai. Desperta l'execució del script volar.py.

1.2 TeclaEndavant: sensor que s'activa quan premem la tecla de cursor superior . Desperta l'execució del script caminar.py.

1.3 TeclaEndarrere: ídem que TeclaEndavant però prement el cursor inferior.

1.4 TeclaDreta: ídem que TeclaEndavant però prement el cursor dret.

1.5 TeclaEsquerra: ídem que TeclaEndavant però prement el cursor esquerre.

1.6 TeclaESC: sensor que s'activa un cop, quan premem la tecla ESC. Automàticament suspenent l'execució de l'entorn virtual i mostra un diàleg que ens confirma si volem o no sortir.

2 Sensors de ratolí: al igual que els sensors de teclat, els de ratolí detecten un canvi amb una freqüència de 30 Hz.

2.1 MovRatolí: sensor que s'activa quan l'usuari mou el ratolí. Desperta l'execució del script visio.py.

2.2 IncVel:sensor que s'activa quan l'usuari mou la rodeta del ratolí cap amunt. Desperta l'execució del script caminar.py.

2.3 DisVel:sensor que s'activa quan l'usuari mou la rodeta del ratolí cap abaix. Desperta l'execució del script caminar.py.

3 Sensor d'inclinació (property sensor):sensor que s'activa cada cop que hi ha un canvi en el valor de la inclinació per tal de controlar, amb dos controladors AND, si ha sobrepassat algun dels límits permesos.

Actuadors del sistema

1 Actuadors d'animació IPO

1.1 IpoEspatlla: l'animació IPO d'aquest actuador, va en funció de la propietat Inclinacio i està associada a l'eix de l'espatlla. La IPO és de la següent forma:

52


Veiem que cada keyframe de l'animació es correspon amb el valor corresponent a la rotació de l'eix X (inclinació del cap). fins a arribar al límit de 89 i -89 graus, on passa tindre un valor constant d'inclinació. Així doncs variant l'animació obtenim proporcionalment al keyframe, la inclinació corresponent. Aquest actuador l'utilitzen els scripts caminar.py i visio.py.

1.2 RotJugador:l'animació IPO d'aquest actuador, va en funció de la propietat rotacio (rot) i està associada a l'eix jugador (els peus). La IPO configurada és de la següent forma:

En aquesta cas veiem que cada keyframe manté els valors de rotació dels eixos X i Y constantment a 0º, mentre que el que varia proporcionalment al keyframe actual , és la rotació en Z de l'eix jugador. Aquest fet ens permet rotar lateralment el jugador, sense un limit fixat de voltes consecutives cap un costat o l'altre, i atenent al valor actual de la propietat Inclinacio. Aquest actuador l'utilitza el script visio.py.

2 Actuadors de moviment (motion)

2.1 MovTerra: aquest actuador de moviment possibilita exercir un impuls configurable (es calcula en el script caminar.py) per tal de que el personatge es pugui traslladar per l'escenari. L'impuls s'exerceix sobre l'eix jugador, que al estar lligat a la resta d'eixos mou tota la estructura que conforma el personatge. Aquest actuador l'utilitza el script caminar.py

3 Actuadors de propietats (property)

3.1 Act1: aquest actuador assigna a la propietat inclinació el valor de -89º. Això serà necessari quan es vulgui corregir la inclinació perquè s'ha sobrepassat un determinat llindar, tornant a assignar-li el valor màxim que pot abaixar-se l'eix de l'espatlla.

3.2 Act2: el mateix que amb Act1, però assigna 91º quan sobrepassa el llindar superior de inclinació.

4 Actuadors d'escena

4.1 Suspendre: aquest actuador permet suspendre l'escena de l'entorn virtual , permetent en qualsevol tornar a engegar-la en el punt on es va suspendre l'execució.

53


4.2 Sortir:aquesta actuador específica posa en primer pla un diàleg emergent preguntant-nos si realment volem o no sortir de l'aplicació.

Controladors del sistema

1 Controladors associats a una expressió

1.1 Cont1: aquest controlador s'activa quan hi ha un canvi d'inclinació, i activa el actuador Act1 sempre i quan la inclinació sigui més petita de -89º.

1.2 Cont2: el mateix que amb Cont1, però activa el actuador Act2 sempre i quan la inclinació sigui més gran de 91º.

2 Controladors AND

2.1 Cont: suspèn l'escena i mostra la pantalla de confirmació sempre que es premi la tecla ESC.

3 Controladors Python

3.1 Volar.py: commuta entre mode vol (sense gravetat) i normal (gravetat activada) cada cop que es prem la tecla espai. El funcionament és el següent:

si s'ha premut teclaVolar llavors

volar = negat(volar)

si volar = cert llavors

gravetat de l'entorn = [0,0,0]

sinó

gravetat de l'entorn = [0,0,-9.81]

3.2 Caminar.py: permet controlar la translació i la velocitat del personatge. El que fa es ajustar el keyframe adequat per a la rotació lateral i calcular si cal, l'impuls a aplicar al jugador. El funcionament és el següent:

si s'ha mogut la rodeta cap amunt llavors

augmentar el valor de maxVel

si s'ha mogut la rodeta cap abaix llavors

disminuir el valor de maxVel

si estem en mode vol llavors

orientació = orientació de l'espatlla

sinó

orientació =orientació dels peus

si s'ha premut la teclaEndavant/Endarrere/Dreta/Esquerra llavors

Calcular vector de velocitat lineal en base la direcció del moviment

54


si el vector de velocitat es nul llavors

aturar l'impuls

sinó

aplicar l'impuls a l'eix

3.3 Visio.py: permet el controlar la rotació de la visió de l'escena i ajusta el cursor al centre de la pantalla, per a que la selecció d'objectes sigui correcta. El funcionament és el següent:

si s'ha mogut el ratolí i és la primera vegada que s'executa el script llavors

Centrar el cursor del ratolí al centre de la pantalla i ocultar-lo

Inicialitzar les coordenades de posició del cursor a 0

si és la primera vegada que s'executa el script i s'ha mogut el ratolí llavors

Calculem quan s'ha desviat del centre el cursor ocult, i extraiem la rotació lateral (rot) i la inclinació nova que resulta d'aquest moviment

Apliquem el factor de sensibilitat per a escalar el moviment de rotació

Configurem la IPO de l'espatlla i la IPO del jugador (els peus) amb els actuadors que hem vist en l'anterior apartat.

Centrem altre cop el cursor al centre de la pantalla

55


4.3 Implementació del sistema de control de la tasca

4.3.1 Logics Bricks associats a qualsevol objecte interactiu

Per a que un objecte qualsevol de l'escenari passi a tenir la capacitat de estar a associat amb una acció i permetre la interactivitat amb l'usuari, haurà d'incorporar el següent esquema de Logic Bricks:

L'avantatge principal de tenir un esquema fix, serà que si volem que un objecte passi a ésser interactiu dins una tasca, només haurem de copiar aquest conjunt de blocs (es podria automatitzar amb un script), i a continuació el podrem associar a qualsevol acció de la tasca.

A continuació passem a detallar cadascun dels components del sistema de Logic Bricks que ha de tenir qualsevol objecte interactiu. Molts dels aspectes que s'aniran comentant es veuran amb més claredat en els següents apartats, on anirem desgranant detalladament les funcions específiques de control d'accions.

Propietats d'un objecte interactiu

Les següents propietats formen part de l'objecte interactiu:

● Frame: variable entera, que controlarà qualsevol animació de l'objecte, ja que indicarà en cada moment quin keyframe de l'animació s'ha de reproduir. També servirà per controlar qualsevol event de retard associat al objecte.

● Animant: variable entera que indicarà en quin estat es troba la animació del objecte. Podrem tenir tres estats (animant, petició d'animació enviada, no animant) que indicaran al gestor d'events com actuar en cada cas. Aquest control es detalla més endavant a l'apartat de control d'events.

Sensors associats a un objecte interactiu

1 Sensors de ratolí

1.1 Click: sensor que s'activa quan l'usuari prem el botó esquerre del ratolí. Desperta l'execució del script control.py.

56


1.2 Selec: sensor que s'activa quan el cursor de selecció passa per sobre l' objecte interactiu. Desperta l'execució del script control.py.

2 Sensors de propietat

2.1 Despertar: sensor que desperta l'execució del script control.py sempre que el valor de la variable frame sigui igual a un valor prefixat. Ens servirà per programar futures execucions de control.py. Per exemple quan iniciem una animació, al finalitzar aquesta s'haurà de tornar a executar el gestor d'events en el cas de que quedin events associats a l'objecte.

3 Sensors de recepció de missatges

3.1 Missatge:sensor que desperta l'execució del script control.py quan li arribi un missatge d'una altra entitat. Normalment, seran peticions per a que serveixi un determinat event que l'altre entitat no pot servir.

4 Sensors d'activació continua

4.1 Frames: aquest sensor s'activa a cada “Logic Tick” que genera el Game Engine del Blender. La freqüència d'activació es constant , i està establerta a 30 Hz. Aquest fet ens permetrà anar incrementant contínuament la variable interna comptadora Frame que controla totes les temporitzacions del objecte interactiu, ja siguin animacions, retards o reprogramacions de futures execucions del script control.py.

Actuadors associats a un objecte interactiu

1 Actuadors d'animació IPO

1.1 Anim: aquest actuador permet reproduir qualsevol animació configurada per a l'objecte, en base a la variable Frame. Aconseguirem unes animacions normals quan el valor de frame s'incrementi constantment en el temps. Mitjançant el control de Frame, serà possible des de escollir quin interval específic de keyframes de l'animació es reproduirà, fins a controlar la velocitat d'execució de l'animació.

2 Actuadors d'enviament de missatges

2.1 Enviar1: aquest actuador permet enviar un missatge a un objecte determinat, que serà rebut correctament en el cas de que disposi d'un sensor de recepció de missatges. Els objectes interactius hauran de tenir la capacitat d'enviar peticions a altres objectes interactius per tal de que executin events que no poden realitzar ells mateixos. També serà necessari poder enviar sol·licituds de reprogramació d'alarmes al objecte “OBInici”. En concret, l'actuador Enviar1 enviarà les sol·licituds a objectes interactius.

2.2 Enviar2: al igual que el actuador Enviar1 enviarà sol·licituds, però aquestes seran per al objecte “OBInici”, per tal de que reprogrami el gestor d'alarmes.

3 Actuadors de propietats (property)

3.1 SumFrame: aquest actuador incrementa en una unitat la variable Frame, cada cop que rep un pols (30 cops cada segon per defecte).

57


Controladors associats a un objecte interactiu

1 Controladors AND

1.1 Cont1: aquest controlador rep un pols a cada “Logic Tick” que es genera i activa directament el actuador sumFrame, que incrementa la variable Frame.


2.1 Control.py: aquest script es el encarregat de gestionar tots els aspectes del control de la tasca, i s'analitzarà en els següents apartats. La seva activació en el context d'un objecte interactiu, es donarà quan es faci clic a sobre l'objecte, es posicioni a sobre el cursor, es rebi una petició externa, o bé, es desperti l'objecte al haver finalitzat un retard o animació.

4.3.2 L'objecte “OBInici”: control d'inicialització, gestió d'alarmes i llançament de diàlegs emergents

L'escena conté un objecte buit (sense cap informació de model) anomenat OBInici (l'usuari en Blender veu com a nom Inici, però el Blender internament considera el nom dels objectes sempre amb un OB al començament) que ens permet inicialitzar els recursos necessaris i fer la gestió d'alarmes de la tasca, així com mostrar diàlegs emergents en primer pla. Aquest objecte haurà d'incorporar el següent esquema de Logic Bricks:

A continuació passem a detallar cadascun dels components del sistema de Logic Bricks. Com hem comentat en l'apartat anterior, molts dels aspectes que s'aniran comentant es veuran amb més claredat en els següents apartats.

Propietats de “OBInici”

● Timer: objecte timer que implementa el propi Blender. Ens servirà per determinar en quin moment concret s'ha completat una acció i així poder tenir un registre de l'evolució de l'exercici.

● Ini: variable booleana que ens indicarà si s'ha inicialitzat o no el sistema de control general de la tasca.

● Frame: variable entera que ens permetrà controlar les alarmes.

58


Sensors associats a “OBInici”

1 Sensors d'activació continua

1.1 Frames: al igual que amb els objectes interactius, aquest sensor s'activa a cada “Logic Tick” que genera el Game Engine del Blender. Aquest fet ens permetrà anar incrementant contínuament la variable interna comptadora Frame que controla totes les temporitzacions d'alarmes.

1.2 Inici: genera un únic pols d'activació que desperta el script control.py per a que faci totes les inicialitzacions necessàries.

2 Sensors de propietat

2.1 Despertar:al igual que amb els objectes interactius, aquest sensor desperta l'execució del script control.py sempre que el valor de la variable frame sigui igual a un valor prefixat. Ens servirà per programar l'alarma més propera en el temps.

3 Sensors de recepció de missatges

3.1 Missatge: sensor que desperta l'execució del script control.py quan li arribi un missatge d'una altra entitat. Sempre seran peticions per a que reprogrami les alarmes o per a que llenci un diàleg emergent.

Actuadors associats “OBInici”

1 Actuadors d'enviament de missatges

1.1 Enviar1: aquest actuador permet enviar un missatge a un objecte determinat, que serà rebut correctament en el cas de que disposi d'un sensor de recepció de missatges. Serà necessari utilitzar-lo, quan s'estiguin servint events en el context de “OBInici” i s'hagi de servir una petició d'animació o retard des de un altre objecte interactiu.

2 Actuadors de propietats

2.1 SumFrame: aquest actuador incrementa en una unitat la variable Frame, cada cop que rep un pols.

3 Actuadors d'escena

3.1 Suspendre: aquest actuador permet suspendre l'escena de l'entorn virtual, permetent en qualsevol moment tornar a rellançar-la en el punt on es va suspendre l'execució.

3.2 Diàleg: aquest actuador permet llençar en primer pla un diàleg configurable mitjançant la classe d'events DIALEG.

Controladors associats a “OBInici”

1 Controladors AND

1.1 Cont1: aquest controlador rep un pols a cada “Logic Tick” que es genera i activa directament el actuador SumFrame, que incrementa la variable Frame.


2.1 Control.py: aquest script es el encarregat de gestionar tots els aspectes del

59


control de la tasca, i s'analitzarà en els següents apartats. La seva activació en el context d'una alarma, es donarà quan es rebi una petició externa de reprogramació d'alarmes o de servei d'un event DIALEG, o bé, quan es desperti “OBInici” degut a que hi ha una o més alarmes que s'han activat.

4.3.3 Unificació del control en un únic script

Per tal de fer el control de la tasca s'ha desenvolupat un únic script en python anomenat control.py, que es dedica a gestionar tant els objectes interactius, com alarmes , events , inicialització de la tasca, etc.

L'estructura general a grans trets és la següent:

SCRIPT CONTROL

Si el script s'executa per petició de OBIni llavors

Si es el primer cop que s'executa llavors

Inicialitzem recursos

Carreguem tasca

Posem com a no disponibles objectes inexistents assignats a accions

Validem la tasca eliminant accions amb errors de coherència

Programem les alarmes d'accions que ja son vàlides

Ordenem la llista d'alarmes per proximitat temporal

Mostrem per la GUI de l'entorn, informació de la tasca

Actualitzem la posició,visibilitat i orientació d'objectes si està configurat

Encuem els events inicials a la cua general d'events

Servim events

sinó

Si hi ha una petició de reprogramació d'alarmes llavors

Tornem a programar les alarmes

Si hi ha una petició de llançament de diàleg llavors

Llencem el diàleg amb els paràmetres desitjats

Si s'ha activat alguna alarma llavors

Encuem els events de totes les alarmes activades

Reprogramem el gestor d'alarmes si en queden de pendents

Servim events

sinó

Si el objecte que ha cridat el script activa alguna acció de la tasca llavors

Obtenim la relació d'accions que activa el objecte

60


si L'objecte té els logics bricks correctes d'objectes interactius llavors

si el cursor es troba sobre l'objecte llavors

si hi han accions incompletes associades a l'objecte llavors

Mostrar informació sobre selecció

si s'ha fet clic amb el botó dret sobre l'objecte llavors

Actualitzem les accions encuant els events d'aquelles que finalitzin i actualitzant les alarmes

Si s'ha encuat alguna alarma llavors

Enviem petició de reprogramació d'alarmes

Si s'han completat totes les accions llavors

Encuem els events de finalització

Servim events

Si hi ha un petició externa o interna de servei d'events llavors

Servim events

L'avantatge principal d'unificar el control en únic script, és que la gestió d'events i alarmes també s'unifica per a qualsevol objecte, i això proporciona un control més estable i senzill de l'aplicació.

A continuació passem a analitzar amb més detall els diversos aspectes del control exercit per el script control.py , explicant com inicialitza la tasca, gestiona els events i alarmes i controla la finalització d'accions i de la propia tasca.

4.3.4 Control d'inicialització de la tasca

L'aplicació ha de tenir la capacitat de carregar mitjançant un fitxer separat la definició d'una tasca qualsevol. Per tant serà necessari implementar un sistema que un cop es carregui la tasca permeti depurar-la de possibles incoherències. Com hem especificat anteriorment els passos que seguirà seran els següents:

● Inicialització de recursos

○ Inicialitzar el sistema de so de Pygame

○ Inicialitzar la cua d'events i la d'alarmes

○ Inicialitzem el diccionari d'accés ràpid a les accions associades a un objecte, que mitjançant la clau del nom d'un objecte, ens retorna una llista amb totes les accions que pot activar

○ Inicialitzar el comptador d'accions correctes

○ Inicialitzar el timer general de l'aplicació

● Carreguem la tasca a partir d'un path preestablert. En cas que no existeixi o que sigui invalid llancem un diàleg indicant l'error

● Posem com a no disponibles objectes inexistents assignats a accions .

61


En el cas de que l'objecte existeixi a l'escena i estigui associat a alguna acció, l'inserim al diccionari que conté les accions associades a un objecte.

● Validem la tasca eliminant accions amb errors de coherència ( eliminant les accions que no tenen cap pare ni objecte associat) i actualitzem el camp de pares_totals de totes les accions vàlides. El procediment serà el següent:

per acció dins llista d'accions de la tasca fer

per fill dins llista dels fills de acció fer

si existeix fill llavors

incrementem en 1 el valor de 'pares_totals'

sinó

L'eliminem de la llista de fills

mentre quedin accions amb dependències no evaluades fer


per fill dins llista dels fills de acció fer

si l'acció no te cap pare ni objecte associat llavors

Decrementem el comptador 'pares_totals' dels seus fills en 1, i l'eliminem a continuació. Els fills queden pendents per a avaluació en la següent iteració

● Programem les alarmes d'accions que ja son vàlides i que el numero de pares completats sigui igual al numero de pares totals, de la següent forma:


si l'acció té l'alarma disponible llavors llavors

si pares totals de l'acció = pares completats de l'acció llavors

programar l'alarma associada a l'acció

● Ordenem la llista d'alarmes per proximitat temporal , per tal que el gestor d'alarmes es programi per despertar-se amb la més pròxima temporalment.

● Mostrem per la GUI de l'entorn, informació de la tasca com per exemple el nom o el número d'accions totals que té.

● Actualitzem la posició,visibilitat i orientació d'objectes si està preconfigurat

● Encuem els events inicials a la cua general d'events

● Servim els events inicials en el cas que n'hi hagi algun de programat

Un cop s'han seguit aquests passos correctament, l'aplicació ja estarà preparada per a gestionar els events i alarmes que puguin sol·licitar l'evolució de la tasca.

62


4.3.5 Control d'events

El control d'events és la part més complexa de tota l'aplicació. La seva tasca fonamental és gestionar les peticions d'events que arriben a la cua d'events, sincronitzant-les correctament en el temps, permetent d'aquesta manera, l'execució concurrent (per exemple de diverses animacions juntament amb so).

Si féssim una divisió atenent a com es serveixen els events, per una banda tindríem els de visibilitat, posició, orientació que es serveixen immediatament , es a dir , no requereixen d'un determinat temps per a la seva consecució. Per una altra banda, el events d'animació i retard no es serveixen immediatament, sinó que requereixen d'un temps per completar-se, i per una limitació del programari Blender, el script s'haurà de cridar per part de l'objecte associat a l'event. Per últim, l'event diàleg, és un cas especial que el gestiona únicament la entitat “OBInici”.

L'esquema general que segueix el gestor d'events és el següent:

mentre queda algun event amb possibilitat d'ésser servit fer

si l'event es referix a algun objecte (VISILBILITAT,ANIMACIO, etc.) llavors

si l'objecte referit esta animant-se llavors

No servir petició

sinó si l'objecte referit ja te una sol·licitud de servei d'events llavors

si objecte que crida script no és el mateix que el de la sol·licitud llavors

No servir petició

si tipus de l'event = VISIBILITAT llavors

Aplicar el canvi de visibilitat a l'objecte en escena

sinó si tipus de l'event = MOURE llavors

Aplicar el canvi de posició a l'objecte en escena

sinó si tipus de l'event = ORIENTACIO llavors

Aplicar el canvi d'orientació a l'objecte en escena

sinó si tipus de l'event = SO llavors

Fixar el volum desitjat

si hi ha algun so reproduint-se i volem esperar la seva finalització llavors

Encuem so a la cua de reproducció que proporciona Pygame

sinó

Reproduïm el so

sinó si tipus de l'event = ANIMAR ò RETARD llavors

si objecte que crida el script és el mateix que es vol animar llavors

si tipus de l'event = ANIMAR llavors

si l'objecte a animar no és visible llavors

Fer visible l'objecte a animar

63


Programem quan s'haurà de despertar el gestor d'events, un cop s'hagi acabat l'animació i pugui prosseguir amb events referits al mateix objecte en cas que n'hi hagin

Activem l'animació en l'interval de keyframes definits

sinó

Programem quan s'haurà de despertar el gestor d'events tenint en compte el retard desitjat

sinó

Enviem una sol·licitud d'events al objecte que es vol animar, per a que executi el gestor en el seu context i sigui possible l'animació o retard

sinó si tipus de l'event = DIALEG llavors

si objecte que crida el script és “OBInici” llavors

Configurar i llençar diàleg

sinó

Enviar petició a “OBInici” per a mostrar el diàleg

sinó

Si l'event no és de cap tipus reconegut, l'eliminem de la cua

64


4.3.6 Control d'alarmes

El sistema d'alarmes es servirà de 3 funcions bàsiques (programar alarma, desprogamar alarmes i reordenar alarmes) que permetran des de qualsevol context d'execució sol·licitar l'activació o desactivació d'alarmes.

Programar alarma permet afegir una alarma d'una acció, ja sigui normal o reversible, i assignar-li un temps d'execució futura tenint en compte el temps actual.

Desprogramar alarmes esborra de la llista d'alarmes, les que estiguin associades a l'acció a la que se li volen desactivar les alarmes. Es voldrà sempre que la desactivació d'alarmes sigui per a totes les associades a una acció, ja que quan finalitzem una fita , es vol que totes les alarmes associades ja no s'activin.

Reordenar alarmes ordena la llista d'alarmes per ordre temporal (més propera a llunyana) i programarà l'activació de l'alarma més propera en el temps.

L'activació d'una alarma es controlarà pel objecte buit, “OBInici”que anirà reordenant si cal, la llista d'alarmes de més propera a llunyana en l'execució, i es despertarà amb l'activació de l'alarma més propera, en cas que en quedi alguna.

A continuació passem a descriure les 3 funcions de suport i la part de control d'alarmes implementat pel objecte “OBInici”:

Programar alarma

si tipus d'alarma a programar = NORMAL llavors

alarma a programar = alarma normal de l'acció

sinó si tipus d'alarma a programar = REVERSIBLE i acció = REVERSIBLE llavors

alarma a programar = alarma reversible de l'acció

Configurar camp temps absolut de l'alarma en que es tornarà a activar tenint en compte temps actual

Encuar alarma a la cua d'alarmes

Desprogramar alarmes

Per totes les alarmes de la llista d'alarmes fer

si l'alarma està associada a l'acció a la que se li volen desprogramar llavors

Esborra alarma

Reordenar alarmes

si queda alguna alarma a la llista d'alarmes llavors

Reordenar tenint en compte el temps

si el script s'està executant en el context de “OBInici” llavors

Programar futura activació del gestor d'alarmes de “OBInici”

sinó

Enviar petició o “OBInici” per a que es programi per futures activacions

65


Gestor d'alarmes de OBInici (passos que s'executen en el cas que s'hagi despertat per una sol·licitud de gestió d'alarmes)

Si hi ha una petició de reprogramació d'alarmes llavors

Reordenar alarmes

Si hi ha una petició de llançament de diàleg llavors

Llencem el diàleg amb els paràmetres desitjats

Servim Events

Si s'ha activat alguna alarma (s'ha despertat “OBInici”) llavors

mentre temps actual = temps absolut de la 1a alarma de la llista fer

Encuem els events de l'alarma

Actualitzem el camp de temps absolut de l'alarma

Afegim l'alarma a una llista auxiliar i l'esborrem de la cua general

Afegim la llista auxiliar a la cua general de les alarmes

Reordenar alarmes

Servim events

66


4.3.7 Control d'interacció i finalització d'accions

Quan un objecte cridi al script de control podrà ésser per 3 motius diferenciats:

1. S'ha fet clic a sobre l'objecte o simplement s'ha passat el ratolí per sobre

2. S'ha acabat una animació o retard associat al objecte

3. Un altre objecte interactiu a sol·licitat que es desperti per a que serveixi un event que només pot servir ell (ANIMACIÓ o RETARD)

A més, si s'ha fet clic a sobre , s'haurà de considerar si l'acció o accions que estaven associades a l'objecte finalitzaran en aquell moment i com afectarà això a la resta d'accions de la tasca, actualitzant les dependències de tota la tasca. El funcionament d'aquest control serà el següent:

Si l'objecte que ha cridat el script activa alguna acció de la tasca llavors

Obtenim la relació d'accions que activa el objecte (accions objecte)

si L'objecte té els Logics Bricks correctes d'objectes interactius llavors

si el cursor es troba sobre l'objecte llavors

per acció dins accions objecte fer

si pares totals acció = pares completats acció llavors

Afegir nom de l'acció a informació de selecció (etiqueta que es mostra quan passem per sobre l'objecte amb el cursor)

si s'ha fet clic amb el botó dret sobre l'objecte llavors

accions avaluar = accions objecte

mentre queden accions amb dependències no avaluades fer

si pares totals acció==pares completats acció i ((acció amb objecte disponible i activat) o no disponible) llavors

si acció és NORMAL llavors

Encuem events de l'acció

Posem acció com a completada

Desprogramem alarmes acció

Escrivim al registre d'accions completades, en quin moment s'ha completat

sinó si acció és REVERSIBLE llavors

si estat és inicial llavors

estat acció = de reversió

Encuem events inicials de l'acció


si acció te alarma reversible llavors

Programar alarma reversible

67


si estat és de reversió llavors

estat acció = inicial

Encuem events de reversió de l'acció


si hi ha algun fill normal no completat i l'acció té alarma normal llavors

Programar alarma normal

per fill dins llista fills de l'acció fer

Fill s'incorpora a la llista d'accions sense dependències avaluades

si acció és REVERSIBLE i estat és inicial llavors

Decrementar en 1 pares completats fill

sinó

Incrementar en 1 pares completats fill

sinó si pares totals acció ==pares completats acció llavors

Programar alarma de l'acció

Si s'ha encuat alguna alarma llavors

Reordenar alarmes

Si s'han completat totes les accions llavors

Encuem els events de finalització

Servim events

Si hi ha un petició externa o interna de servei d'events llavors

Servim events

68


4.4 Un exemple de tasca: fer una truitaPer tal de comprovar el funcionament correcte del sistema de control, i la capacitat de definició que permet el disseny d'una tasca, s'ha implementat en l'entorn virtual de la cuina una tasca que consisteix en fer una truita. El script Truita.py , s'encarrega de generar la tasca a partir de les classes de Tasca.py, Event.py, Alarma.py i Accio.py i mitjançant els mètodes que aquestes proveeixen.

Durant els següents apartats anirem analitzant els apartats que s'haurà de seguir per tal de crear una tasca qualsevol, aplicant-ho al exemple de la truita. Es molt recomanable , en el cas de que es vulgui crear una tasca nova, anar seguint pas per pas les següents indicacions.

4.4.1 Identificació de les accions que conformen la tasca, les seves dependències i els possibles objectes associats

Per tal de plasmar una tasca, primer haurem de concretar quins són els passos que la conformen , i quines dependències hi han entre ells. A més haurem de concretar quins objectes existiran a la tasca , i amb quines accions aniran associats. En el cas de la truita tindríem la següent relació d'accions , dependències i objectes associats:

Accions identificades

● Posar el plat a taula

● Posar l'ou a taula

● Posar l'ou al plat

● Posar la forquilla a taula

● Batre l'ou al plat

● Posar la paella al foc

● Posar l'oli a taula

● Posar l'oli a la paella

● Posar l'ou batut a la paella

● Posar la sal a taula

● Tirar la sal a la paella

● Activar/Desactivar polsador de la paella (REVERSIBLE)

● Obrir/ Tancar la nevera (REVERSIBLE)

● Fer la truita a la paella

● Posar la truita feta al plat

Objectes identificats que participen en l'acció

● Plat

● Forquilla

● Ou

● Paella

69


● Sal

● Oli

● Polsador del foc

● Espàtula

● Rovell

● Ou batut

● Oli bolcat sobre la paella

● Truita feta

Relació de dependències i objectes associats de cada acció

ACCIÓ FILLS OBJECTE

Posar el plat a taula - Posar l'ou al plat Plat

Posar l'ou a taula - Posar l'ou al plat Ou

Posar l'ou al plat - Batre l'ou al plat Ou

Posar la forquilla a taula - Batre l'ou al plat Forquilla

Batre l'ou al plat - Posar l'ou batut a la paella Forquilla

Posar la paella al foc - Posar l'oli a la paella Paella

Posar l'oli a taula - Posar l'oli a la paella Oli

Posar l'oli a la paella - Posar l'ou batut a la paella Oli

Posar l'ou batut a la paella - Tirar la sal a la paella ---------

Posar la sal a taula - Tirar la sal a la paella Sal

Tirar la sal a la paella - Fer la truita a la paella Sal

Activar/desactivar polsador de la paella (estat inicial)

- Fer la truita a la paella Polsador del foc

Fer la truita a la paella - Posar la truita feta al plat ---------

Posar la truita feta al plat --------- Espàtula

70


El gràfic següent il·lustra la tasca de fer una truita. El camp OB indica el possible objecte associat. Si el diàleg és de color lila, significa que és una fita normal i si és blau, reversible. Les fletxes d¡un diàleg a una altre, indiquen les accions filles de cada acció.

71


4.4.2 Identificació dels events inicials, finals i els que caracteritzen a cada acció

Cada acció que hem definit l'haurem de modelar com un conjunt d'events, d'entre els disponibles, que la caracteritzin. També s'haurà de definir la seqüència d'events inicials i finals de la tasca.

En el cas de fer una truita per a cada acció hem extret els següents events:

Events inicials i finals

MOMENT D'EXECUCIÓ TIPUS EVENT DESCRIPCIÓ

Inicial SO Missatge de benvinguda

Final SO

DIALEG

Missatge indicant que s'ha acabat de fer la tasca.

Diàleg amb el següent text: ”Enhorabona ! Has acabat de fer la truita!”

7Events associats a cada acció

ACCIÓ TIPUS EVENT DESCRIPCIÓ

Posar el plat a taula SO

ANIMAR

MOURE

ANIMAR

So de selecció d'objecte

“Fade out” del plat

Moure el plat a la taula

“Fade in” del plat

Posar l'ou a taula SO

ANIMAR

MOURE

ORIENTAR

ANIMAR


“Fade out” del l'ou

Moure l'ou a la taula

Orientar l'ou com si estigues col·locat horitzontalment respecte la taula

“Fade in” de l'ou

Posar l'ou al plat SO

MOURE

ANIMAR

VISIBILITAT

ANIMAR


Moure l'objecte ocult que representa el rovell i la clara de l'ou, a sobre el plat.

“Fade out” del l'ou

Ocultar ou

“Fade in” del rovell i clara sobre el plat

Posar la forquilla a taula SO

ANIMAR

MOURE

ANIMAR


“Fade out” de la forquilla

Moure la forquilla a la taula

“Fade in” de la forquilla

72


Batre l'ou al plat SO

MOURE

ANIMAR

VISIBILITAT

ANIMAR


Moure l'objecte ocult que representa l'ou batut a sobre el plat.

“Fade out” del rovell i clara

Ocultació del rovell i clara

“Fade in” de l'ou batut

Posar la paella al foc SO

MOURE


Moure la paella a sobre un dels fogons del foc

Posar l'oli a taula SO

ANIMAR

MOURE

ANIMAR


“Fade out” de l'oli

Moure l'oli a la taula

“Fade in” de l'oli

Posar l'oli a la paella SO

MOURE

ANIMAR


Moure l'objecte ocult que representa l'oli bolcat sobre la paella.

“Fade in”de l'oli bolcat a la paella

Posar l'ou batut a la paella ANIMAR

MOURE

ANIMAR

“Fade out” de l'ou batut

Moure l'ou batut a sobre la paella

“Fade in” de l'ou batut

Posar la sal a taula SO

ANIMAR

MOURE

ANIMAR


“Fade out” de la sal

Moure la sal sobre la taula

“Fade in” de la sal

Tirar la sal a la paella SO

ANIMAR


Animar la sal de manera que sembli que s'està tirant sal sobre la paella.

Fer la truita a la paella ANIMAR

VISIBILITAT

ANIMAR

VISIBILITAT

MOURE

ANIMAR

“Fade out” de l'oli bolcat a la paella

Ocultem l'oli bolcat a la paella

“Fade out” de l'ou batut

Ocultem l'ou batut

Moure l'objecte ocult que representa la truita feta a sobre la paella.

“Fade in” de la truita feta

Posar la truita feta al plat SO

ANIMAR

MOURE


“Fade out” de la truita feta

Moure la truita a sobre el plat

73


ANIMAR “Fade in” de la truita feta a sobre el plat.

Activar/Desactivar polsador de la paella (Estat inicial)

SO

ANIMAR

ANIMAR


Moure el polsador a la posició de foc obert.

Il·luminar el fogó de vitroceràmica de color vermell.

Activar/Desactivar polsador de la paella (Estat de reversió)

SO

ANIMAR

ANIMAR


Moure el polsador a la posició de foc tancar.

Apagar la il·luminació del fogó de vitroceràmica .

Obrir/tancar el foc (Estat inicial)

SO

ANIMAR


Obrir la porta de la nevera

Obrir/tancar el foc (Estat de reversió)

SO

ANIMAR


Tancar la porta de la nevera

4.4.3 Identificació de les alarmes que poden anar associades amb cada acció

També podran tenir associat cada acció una o dos alarmes (depenent de si es normal o reversible) que es gestionaran automàticament durant l'execució del programa.

En el cas de la tasca de fer una truita , les accions configurades són les següents:

ACCIÓ ASSOCIADA FREQÜÈNCIA (s)

TIPUS EVENT

DESCRIPCIÓ

Posar el plat a taula 50 SO So avisant que s'ha de posar el plat a taula.

Posar l'ou a taula 55 SO So avisant que s'ha de posar el l'ou a taula.

Posar la forquilla a taula 60 SO So avisant que s'ha de posar la forquilla a taula.

Posar l'ou al plat 50 SO So avisant que s'ha de trencar l'ou i bolcar el contingut al plat.

Batre l'ou 55 SO So avisant que s'ha de batre l'ou amb la forquilla.

Posar paella al foc 100 SO So avisant que s'ha col·locar la paella sobre el foc.

Posar l'oli a taula 100 SO So avisant que s'ha de

74


posar l'olia sobre la taula.

Posar l'oli a la paella 100 SO So avisant que s'ha tirar l'oli a la paella.

Posar sal a taula 105 SO So avisant que s'ha d'agafar la sal i posar-la a la taula.

Tirar la sal 55 SO So avisant que s'ha de tirar sal a la paella.

Posar truita al plat 100 SO So avisant que s'ha de posar la truita al plat.

Activar/Desactivar polsador de la paella (Estat inicial)

100 SO So avisant que s'ha d'obrir el foc per tal de fer la truita.

Activar/Desactivar polsador de la paella (Estat de reversió)

50 SO So avisant que ens hem deixat el foc obert.

Obrir/tancar el foc (Estat de reversió)

50 SO So avisant que ens hem deixat la nevera oberta.

75

Tasques en un món virtual 5. Avaluació

5. AvaluacióA continuació es presenten els resultats d'un estudi de la navegació dins la cuina virtual creada. El model de navegació i interacció fou modificat per donar suport a diferents implementacions i avaluar cadascuna d'elles.

5.1 Prova de navegació en l'entorn virtual de la cuinaEl sistema de navegació utilitzat per a desplaçar-se per una escena tridimensional juga un destacat paper i ha de tenir-se en compte en el desenvolupament d'un entorn virtual: sistemes que a priori poden semblar adequats poden arribar a no ser-lo. Per tant, com pas previ al desenvolupament dels continguts de les tasques a realitzar en l'entorn virtual (cuina) és important conèixer quins sistemes de navegació són més adequats per als pacients amb dany cerebral adquirit.

Per aquest motiu es van realitzar proves de navegació a fi de comprovar quins sistemes de navegació dels proposats eren més apropiats. Les proves realitzades consistien en l'execució d'una senzilla tasca en l'entorn virtual (cuina). Aquesta tasca es basava a canviar la localització (de nevera a marbre cuina) d'un objecte (ou).

Per a desenvolupar la tasca es van implementar tres sistemes de navegació. En tots ells la interacció amb els objectes es realitza a través del botó esquerre del ratolí i mitjançant el desplaçament d'aquest s'ajusta la direcció de la visió. Les diferències entre els tres sistemes residien en el mètode utilitzat per a avançar per l'escena, utilitzant respectivament la barra espaiadora, les tecles de cursor o el botó dret del ratolí.

Les proves de navegació en l'entorn virtual (cuina) es van realitzar durant la primera i segona setmana del mes de Març de 2007 en una mostra de pacients amb Traumatisme Craneoencefàlic (TCE) que, en el moment de les proves, estaven rebent tractament neurorehabilitador en l'Hospital de Neurorrehabilitació Institut Guttmann.

La mostra estava formada per 13 pacients (10 homes i 3 dones) que havien sofert un TCE moderat o greu. L'edat dels pacients estudiats oscil·lava entre els 16 i 55 anys, amb una edat mitja de 27.6 anys i una desviació típica de 10.4 anys. El 77 % dels pacients de la mostra presentaven un TCE greu (GCS entre 3 i 8), mentre que el 23 % restant un TCE moderat (GCS entre 9 i 12). La principal causa del TCE van ser els accidents de tràfic, amb el 77 % (46 % accidents de moto, 23 % accidents de cotxe i 8% atropellaments), seguits de les precipitacions (23 %). Assenyalar que cinc dels pacients no havien utilitzat un ordinador fins a la seva arribada a l'Institut Guttmann.

5.1.1 Preguntes efectuades

El grau de dificultat per a moure's per l'escena amb cadascun dels sistemes de navegació es va valorar mitjançant una escala de 1 a 5, on 1 corresponia a “molt poca dificultat” i 5 a “molta dificultat”. Es van fer les següents preguntes:

1. Com et sembla d'atractiva/interessant l'escena representada (cuina) ?

2. Com et sembla de realista l’escena presentada; Sembla una cuina real?

3. T'ha semblat divertit o engrescador l'exercici?

4. Quin grau de dificultat has trobat per moure’t dins l’escena amb el ratolí

76


(mobilitat botó dret)?

5. Quin grau de dificultat has trobat per moure’t dins l’escena amb el ratolí + barra d’espai?

6. Quin grau de dificultat has trobat per moure’t dins l’escena amb el ratolí + tecles cursor?

7. Amb quin sistema de navegació et sents més còmode?

a) Ratolí (mobilitat botó dret)

b) Ratolí + barra d’espai

c) Ratolí + tecles cursor

8. Quin grau de dificultat has trobat per interactuar (agafar i moure) amb els objectes de l’entorn?

9. Has tingut ganes de continuar?

5.1.2 Resultats obtinguts

A la pregunta “Amb quin sistema t'has sentit més còmode?”, el 69 % va manifestar sentir-se més còmode amb el sistema basat en el mouse + botó dret, mentre que el 31 % amb el sistema basat en el mouse + barra espaciadora. Cap pacient va considerar el sistema de navegació mouse + tecles de cursor còmode per a interactuar amb l'entorn virtual.

Els pacients van referir major dificultat en els sistemes que implicaven l'ús de les dues mans. Probablement aquesta dificultat sigui degudes a problemes per a coordinar i sincronitzar els moviments entre ambdues mans. En funció d'aquests resultats es va prendre la decisió de prescindir del sistema de navegació basat en el mouse + tecles cursor ja que els pacients van manifestar que els resultava incòmode per a desplaçar-se per l'entorn virtual.

Al costat de la informació recollida sobre sistemes de navegació, es van fer altres preguntes la finalitat de les quals era valorar aspectes relatius a l'escena i els seus continguts. Així, en una escala de 1 a 5, el 54 % dels pacients considera que el grau de realisme visual de la cuina era elevat i un 38 % que l'escena era bastant realista. A la pregunta “has tingut ganes de continuar?” (una vegada conclosa la prova) el 54 % va assenyalar tenir moltes ganes, mentre el 38 % va indicar tenir bastants ganes de continuar.

El 84 % dels pacients van respondre no tenir cap dificultat per a interaccionar (agafar i/o moure) amb objectes de l'entorn. El 69 % va trobar molt útils els missatges de text que apareixien en pantalla durant la realització de la prova, mentre que la resta els va valorar com bastant útils. També es va incloure un apartat de suggeriments i observacions, perquè els pacients poguessin fer les seves aportacions i comentaris al disseny de l'entorn. Principalment

77Vista general de la cuina en wireframe


els suggeriments van fer referència als aspectes visuals de l'escena, tals com la decoració o la il·luminació de la mateixa.

La següent taula mostra el grau de dificultat que van manifestar els pacients per a interaccionar amb l'entorn virtual amb cadascun dels sistemes de navegació.

ratolí + botó dret

ratolí + barra espaiadora

ratolí + tecles de cursor

Molta dificultat ----- ----- -----

Bastant dificultat ----- 9 % 30 %

Dificultat mitjana 23 % 15 % 38 %

Poca dificultat 31 % 38 % 9 %

Molt poca dificultat 46 % 38 % 23 %

78

Tasques en un món virtual 6. Conclusions

6. ConclusionsS'ha aconseguit portar a terme l'objectiu principal del projecte, que consistia en desenvolupar un escenari virtual que representés una cuina i crear un sistema de navegació en primera persona que possibilités el moviment del pacient dins l'escena. Paral·lelament s'ha definit un sistema de creació de tasques flexible, que permet una gran variabilitat en la definició d'una activitat. Per tant, existeix el potencial per simular una elevat nombre de tasques que es presentin en el context, per exemple, d'una cuina.

El programari Blender m'ha deixat una impressió molt favorable. Tot i que inicialment es complicat d'utilitzar perquè basa la majoria d'accions amb combinacions del teclat, un cop superada la fase d'aprenentatge augmenta molt la productivitat. A més, tenint en compte que es programari lliure, incorpora una sèrie de funcionalitats que en molts casos no tenen res a envejar al programari comercial dedicat al disseny 3D, i en alguns aspectes (un bon exemple és el Game Engine integrat) els supera. Anteriorment havia utilitzat programes comercials com Cinema 4D o 3D Studio MAX, però en un futur, tinc molt clara l'opció de Blender, ja que em permetrà obtenir resultats amb més rapidesa amb l'avantatge afegit de no haver de pagar llicencies per a publicar algun producte. Per una altra banda, he descobert el llenguatge Python i crec que és un llenguatge amb molt de futur perquè permet escriure els programes amb més rapidesa i flexibilitat que altres llenguatges, i ofereix alhora integració amb multitud d'entorns. Val a dir que una part important de Blender, ha sigut totalment programada amb Python, i el rendiment global de l'aplicació és molt bo.

Un aspecte que cal reorientar, en base els resultats de la prova de navegabilitat efectuada a l'institut Guttmann, és el sistema de navegació que utilitza el ratolí i les tecles de cursor, ja que els pacients van manifestar que els resultava incòmode per a desplaçar-se per l'entorn virtual. Per aquest motiu, ens hauríem de basar en els dos sistemes de navegació que presenten menor grau de dificultat per als pacients amb dany cerebral adquirit: ratolí + botó dret i ratolí + barra espaiadora.

No obstant, donada la implementació separada entre els Logics Bricks i la lògica interna de navegació, l'únic canvi que s'hauria d'efectuar seria modificar els sensors associats a cada acció (avançar,retrocedir, etc.).Inclús seria factible tenir una aplicació on es pogués commutar el model de navegació en temps d'execució.

79

Vista de la cuina 1

+Vista de la cuina 2

Tasques en un món virtual 6. Conclusions

També seria important dissenyar en el futur un metaeditor de tasques, que permetes als terapeutes definir ràpida i intuïtivament activitats en l'entorn. Així doncs, no s'hauria de recórrer a la programació directa de la tasca mitjançant les classes definides, sinó que tindríem un entorn que ens permetria definir visualment les accions que composen un tasca i les relacions que prenen entre elles. Aquest editor generaria un arxiu de definició de tasca completament depurat de possibles incoherències, i preparat per a l'execució en l'entorn virtual.

Un altre aspecte important és la possibilitat d'ampliar el sistema d'interacció de l'usuari amb els objectes. Actualment, només existeix la possibilitat de fer clic a sobre el objecte, però seria interessant que també es poguessin fer operacions més complexes com per exemple, agafar l'objecte, traslladar-lo i deixar-lo en una altra posició.

Per últim comentar, que existeix la possibilitat immediata d'implementar un sistema de comunicació amb el servidor a través d'un programa client, permetent d'aquesta manera el control i supervisió de les activitats realitzades.

80

Tasques en un món virtual 7. Recursos utilitzats

7. Recursos utilitzats

7.1 Pàgines webBlender

http://wiki.blender.org/index.php/Main_Page

http:// www.blender.org/

http://blender.guanajuato.net/

http://mipagina.cantv.net/planetablender/

Game Engine

http://blender.iespana.es/ (molt bona web, amb exemples il·lustratius)

http://blenderartists.org/forum/forumdisplay.php?f=12 (pàgina molt actualitzada, serveix molt mirar anterior posts perquè molta gent pot haver tingut el mateix problema que tinguem)

http://www.blendernation.com/2006/09/28/blender-game-engine-demos/

http://www.blendernation.com/2007/03/06/using-the-wiimote-in-the-blender-game-engine/ (molt interessant, com integrar el comandament de la Wii en el Blender Game Engine, com un sensor més del sistema)

Python

http://es.wikipedia.org/wiki/Python

http://www.python.org/

http://pyspanishdoc.sourceforge.net/ (molt útil, tota la documentació Pydoc en castellà)

http://almacen.gulic.org/diveintopython-5.4-es/toc/

Pygame

http://www.pygame.org/news.html

http://www.pygame.org/docs/ref/mixer.html (documentació del modul mixer, utilitzat per a la gestió de so en l'entorn virtual)

http://es.wikipedia.org/wiki/Pygame

http://www.losersjuegos.com.ar/referencia/apuntes/descargas/guia_de_ejemplos_sobre_pygame.pdf

SDL

http://www.libsdl.org/

http://sdlhispano.ourproject.org/

81

http://wiki.blender.org/index.php/Main_Page

http://sdlhispano.ourproject.org/

http://www.libsdl.org/




http://www.pygame.org/docs/ref/mixer.html

http://www.pygame.org/news.html

http://almacen.gulic.org/diveintopython-5.4-es/toc/

http://pyspanishdoc.sourceforge.net/

http://www.python.org/

http://es.wikipedia.org/wiki/Python

http://www.blendernation.com/2007/03/06/using-the-wiimote-in-the-blender-game-engine/

http://www.blendernation.com/2007/03/06/using-the-wiimote-in-the-blender-game-engine/

http://www.blendernation.com/2006/09/28/blender-game-engine-demos/

http://blenderartists.org/forum/forumdisplay.php?f=12

http://blender.iespana.es/

http://mipagina.cantv.net/planetablender/

http://blender.guanajuato.net/

http://www.blender.org/


Tasques en un món virtual 7. Recursos utilitzats

7.2 LlibresAn Introduction to Python

• Guido van Rossum, i Fred L. Drake, Jr.

Python Cookbook

• Editat per Alex Martelli i David Ascher. O'Reilly (Juliol 2002)

Game Programming With Python, Lua, and Ruby

• Tom Gutschmidt. Premier Press, (Decembre 2003)

82

Tasques en un món virtual 8. Manuals

8. Manuals

8.1 Manual de l'usuari● Per iniciar l'aplicació executar l'arxiu

cuina.exe

● En cas de que no es trobi un fitxer de tasca (*.tasca) en el mateix directori on es troba cuina.exe, sorgirà un panell avisant que no s'ha pogut carregar cap tasca.

● Els controls de l'aplicació són els següents:

Teclat

↑ Translació cap endavant

↓ Translació cap endarrere

→ Translació lateral cap a la dreta

← Translació lateral cap a l'esquerra

I Ocultar/Fer visible el panell informatiu de la tasca

C Ocultar/Fer visible el cursor de selecció

S Ocultar/Fer visible l'etiqueta d'ajuda que mostra l'acció associada a l'objecte

ESPAI Mode normal/ mode vol

ESC Sortir de l'aplicació

Ratolí

Moviment del ratolí Rotació del punt de visió

Clic del botó dret Selecció d'objecte

Moure la rodeta cap amunt Augmentar velocitat de translació

Moure la rodeta cap abaix Disminuir velocitat de translació

83

Execució amb cap tasca carregada

Tasques en un món virtual 8. Manuals

● Quan premem ESC se'ns mostrarà un diàleg per confirmar-nos si volem sortir. (Atenció, si l'aplicació s'executa en mode pantalla completa sortirà directament al apretar ESC).

● Un cop finalitzem la tasca podrem continuar movent-nos lliurement per l'entorn virtual.

84

Diàleg de confirmació de sortida

Tasques en un món virtual - UPC Universitat Politècnica...

Documents

Transcript of Tasques en un món virtual - UPC Universitat Politècnica...