PROYECTO FIN DE CARRERA - URJC

Universidad Rey Juan Carlos

Escuela Superior de

Ingeniería Informática

PROYECTO FIN DE CARRERA

Motor grá�co para simulaciones de trá�co

sobre una ciudad virtual:

LiveCitySim

Autor: Juan Bayona Beriso

Tutor: Rubén Ortiz Martín

Junio, 2011

Agradecimientos

Quiero dar las gracias a mi hermano José María Bayona y a mi compañero de carrera

Francisco Buitrago por el apoyo que me han dado durante toda la carrera ya que sin ellos

no habría logrado terminar este año. Han sido muchas horas las que hemos pasado juntos

estudiando asignaturas y dándonos fuerzas para seguir adelante.

También quiero agradecérselo a mi padre, que ha estado siempre preocupándose por

mí a lo largo de toda mi vida y ha procurado que no me falte nada. Así como a mi hermana

Sofía que siempre que venía a casa me animaba a seguir estudiando.

Por último, dar las gracias a Rubén Ortiz por guiarnos durante todo el proyecto de �n

de carrera, ha costado trabajo y muchas visitas a su despacho pero �nalmente lo hemos

conseguido sacar adelante entre todos.

Resumen

El proyecto LiveCitySim se trata de un motor grá�co que representa simulaciones de

trá�co realizadas sobre una ciudad virtual creada previamente.

La ciudad virtual está formada a partir de unos parámetros determinados y contiene

una serie de elementos tales como carriles, cruces, semáforos y señales de trá�co, que

condicionan el comportamiento de los vehículos.

La representación de la simulación se lleva a cabo en dos partes, una estática y otra

dinámica: la primera esta formada por todos los elementos que permanecen �jos durante

la misma, tales como carreteras, cruces, señales de stop, edi�cios... la segunda, por el

contrario, contiene la información de los componentes que varían según avanza ésta, como

son los vehículos y los semáforos.

Para poder crear toda la representación se usaron herramientas de modelado como

Blender, que permiten la creación de �guras complejas a partir de la unión de polígonos.

La visualización se apoya también en el motor grá�co JMonkeyEngine3, que facilita

la renderización de objetos 3D haciendo uso de la máquina virtual de Java y OpenGL 2.

Para manejar las distintas simulaciones es necesario hacer la utilización de dos archivos

XML, uno de ellos debe contener toda la información relacionada con la ciudad y el otro,

los datos de los distintos agentes que forman la simulación y su comportamiento a lo largo

de toda ella.

Índice general

1. Introducción 1

1.1. Motores Grá�cos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1. JMonkeyEngine3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. Herramientas de Modelado . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1. Blender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3. Extensible Markup Language . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3.1. XStream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4. Simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Objetivos 5

3. Descripción Informática 7

3.1. Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2.1. Requisitos Funcionales . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2.2. Requisitos de Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2.3. Requisitos No Funcionales . . . . . . . . . . . . . . . . . . . . . . . 11

3.3. Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3.1. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3.2. Diagramas de Estados . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.4. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4.1. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4.2. Diseño de la ontología de la ciudad . . . . . . . . . . . . . . . . . . 17

3.4.3. Diseño del visualizador . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.5. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.5.1. Tecnologías Utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.5.2. Estructura del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.5.3. Detalles de Implementación . . . . . . . . . . . . . . . . . . . . . . 28

I

ÍNDICE GENERAL

3.5.4. Estructura de los archivos XML . . . . . . . . . . . . . . . . . . . . 40

4. Conclusiones 49

Bibliografía 53

A. Manual de Usuario i

A.1. Cargar Archivos necesarios . . . . . . . . . . . . . . . . . . . . . . . . . . . i

A.2. Comenzar Visualización . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii

A.3. Acciones del usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii

II

Índice de �guras

3.1. Fases y �ujos del Proceso Uni�cado . . . . . . . . . . . . . . . . . . . . . . 8

3.2. Diagrama de Casos de Uso. . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3. Diagrama de estados de Importar. . . . . . . . . . . . . . . . . . . . . . . . 14

3.4. Diagrama de estados de Visualizar. . . . . . . . . . . . . . . . . . . . . . . 14

3.5. Diagrama de estados de Recoger Acciones del Usuario. . . . . . . . . . . . 15

3.6. Diagrama de Clases Global. . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.7. Diagrama de clases de ciudad. . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.8. Diagrama de Clases de Visualizador. . . . . . . . . . . . . . . . . . . . . . 19

3.9. Diagrama de Clases relación con JMonkeyEngine3. . . . . . . . . . . . . . 21

3.10. Diagrama de Secuencia del caso de uso Importar Archivos . . . . . . . . . 22

3.11. Diagrama de Secuencia del caso de uso Visualizar. . . . . . . . . . . . . . . 22

3.12. Diagrama de Secuencia del caso de uso Acciones del Usuario. . . . . . . . . 23

3.13. Diagrama de Estructura del proyecto. . . . . . . . . . . . . . . . . . . . . . 26

3.14. Cruce conectando dos calles. . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.15. Stargate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.16. Representación de los vehículos. . . . . . . . . . . . . . . . . . . . . . . . . 30

3.17. Semáforo en rojo, verde y ámbar respectivamente. . . . . . . . . . . . . . . 31

3.18. Composición de una carretera. . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.19. Semáforo dentro de Blender. . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.20. Humo de color azul representando un Stargate. . . . . . . . . . . . . . . . 32

3.21. Representación de los elementos que forman una calle. . . . . . . . . . . . 33

3.22. Representación de un edi�cio. . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.23. Representación de un cruce. . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.24. Representación de vehículo por modelo y por caja azul respectivamente. . . 34

3.25. Representación de un Semáforo. . . . . . . . . . . . . . . . . . . . . . . . . 35

3.26. Botones que forman la interfaz Grá�ca. . . . . . . . . . . . . . . . . . . . . 35

3.27. Interfaz Grá�ca de Usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . 36

III

ÍNDICE DE FIGURAS

3.28. Vértices unidos forman la �gura del semáforo. . . . . . . . . . . . . . . . . 36

3.29. BluePrints de un coche. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.30. Uso de Blue Prints dentro de Blender. . . . . . . . . . . . . . . . . . . . . 37

3.31. Texturizado del coche en Blender. . . . . . . . . . . . . . . . . . . . . . . . 38

3.32. Texturizado del Stop mediante mapeado UV. . . . . . . . . . . . . . . . . . 38

3.33. Movimiento de coches por carriles. . . . . . . . . . . . . . . . . . . . . . . 39

3.34. Cálculo de posición del coche en los cruces. . . . . . . . . . . . . . . . . . . 40

3.35. Estructura de la ciudad en el archivo XML. . . . . . . . . . . . . . . . . . 41

3.36. Estructura de un edi�cio en el archivo XML. . . . . . . . . . . . . . . . . . 42

3.37. Estructura de un cruce en el archivo XML. . . . . . . . . . . . . . . . . . . 43

3.38. Estructura de una calle, primera parte. . . . . . . . . . . . . . . . . . . . . 43

3.39. Estructura de una calle, segunda parte. . . . . . . . . . . . . . . . . . . . . 44

3.40. Estructura de una calle, tercera parte. . . . . . . . . . . . . . . . . . . . . 44

3.41. Partes de una calle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.42. Ejemplo de clases que forman un bucle. . . . . . . . . . . . . . . . . . . . . 45

3.43. Estructura de XML sin usar reference. . . . . . . . . . . . . . . . . . . . . 46

3.44. Estructura de XML usando reference. . . . . . . . . . . . . . . . . . . . . . 46

3.45. Estructura de la simulación en el archivo XML. . . . . . . . . . . . . . . . 47

3.46. Estructura de un vehículo. . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.47. Estructura de un semáforo. . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

A.1. Diseño de la interfaz encargada de cargar los archivos. . . . . . . . . . . . . i

A.2. Ventana con simulación iniciada. . . . . . . . . . . . . . . . . . . . . . . . ii

A.3. Interfaz Grá�ca de Usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . iii

A.4. Camara de seguimiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

A.5. Edi�cios ocultos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv

IV

Capítulo 1

Introducción

El proyecto LiveCitySim consiste en un simulador grá�co sobre el comportamiento de

vehículos en un entorno creado virtualmente y que además debe poder cambiar según las

necesidades del usuario. Como realizar esto una sola persona sería un trabajo muy tedioso,

se decidió dividirlo en dos proyectos con una pequeña parte conjunta y otra individual,

cada una con una función muy especí�ca.

La parte conjunta fue realizada junto con Francisco Buitrago y tenía como objeti-

vo crear la estructura de la ciudad, es decir, toda la ontología que ésta debiese poseer

para luego permitir realizar una simulación sobre ella, y además, poder transformarla

visualmente con un motor grá�co.

Por otro lado, se separaría realizar la simulación y la visualización de ésta en dos pro-

yectos distintos, siendo la última la correspondiente a este proyecto. Para más información

sobre el proyecto encargado de la simulación ver referencia [1].

La visualización consta de dos partes, por un lado debe representar la ciudad entera,

es decir, las calles, edi�cios, señales, aceras... En otras palabras, la parte estática de la

representación. Por otro, el componente dinámico, que es el que afecta al movimiento de

los coches por la ciudad, así como los semáforos que los regulan. Esto hace que el proyecto

de visualización sea dependiente de los otros dos, ya que necesita tanto la ciudad como la

simulación para poder representarlas.

1.1. Motores Grá�cos

Para realizar esta visualización tuvimos que elegir un motor grá�co, que es un sistema

designado para el desarrollo de videojuegos y aplicaciones grá�cas, entre sus funciones

incluye renderización de objetos para grá�cos 2D o 3D, un motor de física o de detección

de colisiones, así como elementos de sonido, animación, inteligencia arti�cial, etc. Entre las

1

CAPÍTULO 1. INTRODUCCIÓN

características que debía poseer era recomendable que ofreciese representación de objetos

3D, fuese de uso gratuito, utilizase un lenguaje familiar y ofreciese compatibilidad a la

hora de cargar archivos de distintos programas de modelado.

1.1.1. JMonkeyEngine3

Se hizo un estudio entre los distintos motores grá�cos disponibles y �nalmente el

elegido fue JMonkeyEngine3 (jme3), cuyas características fundamentales son:

Software libre de código abierto, por lo tanto su utilización es gratuita e incluso se

pueden cambiar sus características y el código si fuese necesario. Lo que hace que

tenga un gran alcance en cuanto al número de usuarios que lo utilizan, de esta forma

posee una gran comunidad activa que puede ayudar a resolver dudas al utilizarlo.

Multiplataforma, los cambios que requiere para usarse en distintos sistemas son

mínimos ya que utiliza OpenGL 2 con la máquina virtual de Java.

Construido con una arquitectura basada en sombreadores, conforme a la próxima

generación de estándares grá�cos.

Completa modularidad, pero con todas las características esenciales para el desa-

rrollo de juegos ya incorporadas.

1.2. Herramientas de Modelado

Además del motor, también era necesario el uso de una herramienta de modelado

grá�co, el proceso de modelado consiste en la creación individual de los objetos 3D que

formarán parte de una escena más adelante. También incluyen la posibilidad de añadir

la iluminación, animación y renderizado del mismo, aunque este último paso no nos será

necesario ya que, como hemos mencionado, usaremos jme3 para esta tarea.

Era imprescindible una herramienta capaz de exportar a algún formato compatible

con jme3, que fuese de uso fácil, tuviese gran cantidad de tutoriales y guías, así como una

base de usuarios activa para poder preguntar en caso de duda.

1.2.1. Blender

Al igual que con los motores, se estudió que herramienta de modelado era la más

adecuada, de entre todas las vistas Blender fue la escogida debido a sus propiedades:

2


Software libre de código abierto, al igual que jme3 nos permite usarlo de manera

totalmente gratuita.

Gran cantidad de documentación, así como de foro on-line que permiten encontrar

respuestas de manera rápida y e�caz.

Capacidad de exportar a archivos compatibles con jme3 gracias al uso de plug-ins.

Entre las características más destacadas a la hora de crear �guras, permite UV

unwrapping, texturizar, animar, etc.

Multiplataforma, se puede usar en cualquier sistema operativo, lo que permite tra-

bajar con él sin tener que alejarnos de nuestro entorno de trabajo habitual.

1.3. Extensible Markup Language

El Extensible Markup Language, más comúnmente conocido como XML, es un lenguaje

desarrollado por elWorld Wide Web Consortium. La tecnología XML busca dar solución al

problema de expresar información estructurada de la manera más abstracta y reutilizable

posible. Tiene las siguientes propiedades:

Es formal y conciso desde el punto de vista de los datos y la manera de guardarlos.

Es extensible, por lo que se puede utilizar en todos los campos de conocimiento.

Sencillo de editar y de leer.

Fácil de implantar, programar y aplicar a los distintos sistemas.

1.3.1. XStream

En el proyecto es necesario guardar varios archivos en �cheros como son el de la ciudad

y la simulación, así que para ello usamos el estándar XML para estructurarlos. Aunque

sea sencillo de leer y escribir, crear un archivo muy largo XML es una tarea bastante

pesada, por eso se decidió utilizar XStream.

XStream es una librería para Java que permite la exportación e importación de archi-

vos XML. Es muy útil ya que sus propiedades son:

Fácil de usar, provee una abstracción de alto nivel que simpli�ca la mayoría de los

usos comunes con este tipo de archivos.

3


Alto rendimiento, no consume mucha memoria y además es rápido.

Produce un archivo XML limpio, no repite información y como resultado el archivo

es más fácil de leer y compacto.

No requiere modi�cación de objetos, exportando toda la información.

Exportación personalizable, permite crear estrategias para la exportación y la im-

portación de como ciertos tipos deben de ser representados en el archivo XML.

1.4. Simulador

Como se ha comentado, el proyecto está dividido en dos partes, la simulación y la

realización del motor grá�co de visualización. La parte de simulación se encarga de hacer

que los coches circulen a través de la ciudad evitando colisiones entre ellos y respetando las

normas de trá�co. Habrá varios tipos de conductores distintos que irán más lento o rápido

dependiendo de su con�guración y también existirán vehículos de tamaños distintos para

hacer la simulación más compleja.

A demás de la circulación de vehículos, los semáforos serán controlados a lo largo de

todo este proceso cambiando su estado paralelamente al movimiento de los coches. Todo

este comportamiento debe ser guardado en un archivo con formato XML ya que el motor

de visualización lo leerá más tarde para representar cada uno de los vehículos y el estado

de los semáforos.

4

Capítulo 2

Objetivos

Lo primero que se debe hacer es �jar los objetivos que debe cumplir nuestro proyecto

ya que a partir de estos se realizará el desarrollo de todo el software. Procedo a explicarlos

separándolos por subproyectos:

Generación de la ciudad:

1. De�nición de los elementos de la ciudad: Se quería que la ciudad estuviese

compuesta por carriles con un sentido de�nido, aceras opcionalmente al lado

de los carriles exteriores, edi�cios, cruces que interconectasen carriles, señales

que regulasen los cruces y puntos de partida y de salida de la ciudad.

2. Creación de una ontología: Una vez visto que elementos vamos a tener, es

necesario la creación de una ontología que de�na bien a cada uno de ellos para

evitar lugar a confusiones y crear una estructura determinada.

3. Posibilidad de crear varias ciudades distintas: Uno de los factores fundamen-

tales es que cada usuario pueda crear su propia ciudad y no tener sólo una

ciudad posible e inalterable.

4. Exportación a un �chero: La ciudad debe poder guardarse en un �chero que

contenga toda la información de su estructura para poder ser cargada desde él

siempre que se quiera.

Visualización de la simulación:

1. Representación grá�ca de la ciudad: Tiene que poder hacerse a través de un

�chero con la información de la ciudad una representación de esta misma, debe

incluir todos los elementos que la forman.

5

CAPÍTULO 2. OBJETIVOS

2. Representación grá�ca de la simulación dentro de la ciudad: A través de otro

�chero con los datos de la simulación, debe poder verse de manera grá�ca a

los vehículos circular por la ciudad ya representada, así como el estado de cada

semáforo, siendo opcional el uso de varios modelos distintos para cada uno de

los vehículos.

3. Interacción con el usuario: La persona que esté utilizando el programa debe

poder realizar acciones como mover la cámara, seguir a los vehículos de manera

automática, parar la simulación para después reanudarla y ocultar elementos

como los edi�cios en caso de que le di�culten la visión.

6

Capítulo 3

Descripción Informática

3.1. Metodología

La metodología usada para hacer el proyecto se basó en el Proceso Uni�cado de Desa-

rrollo de Software más comúnmente conocido como Proceso Uni�cado.

El PU es un conjunto de actividades que transforman los requisitos de usuario en un

sistema software. Se sustenta en componentes, es decir, que el sistema está formado por

componentes software interconectados entre sí mediante interfaces bien de�nidas. Sigue

unos principios básicos que son:

Dirigido por casos de uso: Un caso de uso es una función del sistema que da al

usuario un resultado de valor, por tanto, cualquier interacción del sistema con un

usuario u otro sistema será considerada como un caso de uso y debe recogerse en el

modelo de casos de uso, de esta manera, se capturan los requisitos funcionales que

tendrá el sistema en cuestión.

Los casos de uso dirigen el proceso de desarrollo, ya que a partir de ellos se ge-

neraran los modelos de diseño e implementación, hay que tener en cuenta que son

desarrollados a la par con la arquitectura del sistema, in�uenciándose mutuamente.

Centrado en la arquitectura: El concepto de Arquitectura del Software involucra los

aspectos estáticos y dinámicos más importantes del sistema. Así pues, si entendemos

los casos de uso como las funciones que tiene que cumplir el sistema, entenderemos

la arquitectura como la forma en la que se cumplen cada uno de los casos de uso.

También hay que destacar que la arquitectura se basa en la plataforma en la que se

va a desarrollar el sistema, así como de componentes reutilizables, etc.

Iterativo e incremental: Trata de dividir el trabajo en pequeños proyectos o pasos,

7

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

así cada iteración es plani�cada y controlada y produce un incremento, extendiendo

la funcionalidad y tratando los riesgos más importantes. En cada una de ellas, se

identi�can y se especi�can los casos de uso más relevantes usando la arquitectura

como guía, de esta forma, se implementa el diseño en componentes para después

veri�car que éstos cumplen las funciones de dichos casos de uso.

Utiliza UML para generar los modelos de desarrollo: Durante todo el proceso se

construyen una serie de diagramas UML ya sea para especi�car los casos de uso,

para analizarlos, etc.

El PU se estructura además en cuatro fases, y cinco �ujos de trabajo tal y como se

muestra en la �gura 3.1:

Figura 3.1: Fases y �ujos del Proceso Uni�cado

En la fase de inicio, se establece la visión, el alcance y el plan inicial del proyecto. Lo

más importante es la viabilidad, para ello hay que identi�car y reducir los riesgos críticos.

Además, es necesario elegir una arquitectura a partir del desarrollo de los requisitos claves

recogidos en los casos de uso. También es importante crear una estimación inicial tanto

del coste, el esfuerzo, la calidad y la fecha en la que se acabará el producto dejando un

margen amplio por si surgiese alguna complicación. Por último, hay que hacer un análisis

del negocio, abandonando el proyecto en caso de que no sea económicamente rentable

continuar con él.

En la fase de elaboración, lo fundamental es la capacidad de construir un sistema den-

tro de un marco de trabajo económico. Es necesario la identi�cación y reducción de riesgos

que afecten de manera signi�cativa a la construcción del sistema, especi�car los casos de

8


uso con un porcentaje elevado de funcionalidad, extender la arquitectura candidata hasta

el punto de llegar a una línea base, preparar un plan de proyecto para guiar la fase de

construcción, realizar una estimación con límites su�cientemente ajustados que justi�que

la inversión y terminar el análisis de negocio.

La fase de construcción se basa en crear un sistema con una operatividad inicial para

el usuario, para ello se pasa por una serie de iteraciones que llevan a incrementos y la

viabilidad del sistema es evidente en la forma de ejecutables.

Por último, en la fase de transición se trata de llegar a un sistema con una operatividad

�nal, es necesario solucionar los problemas que no se vieron en fases anteriores y corregir

los posibles defectos que pueda tener nuestro sistema.

Como hemos comentado antes, las iteraciones transcurren a lo largo de los cinco �ujos

de trabajo. Dependiendo de la fase y la iteración en el que se encuentre el proyecto, el

énfasis se pone más en unos �ujos que en otros (ver �gura 3.1). Así pues, los cinco �ujos

de trabajo son:

Requisitos: Se asegura de que los desarrolladores construyan el sistema correcto.

Describe de una manera objetiva y clara para que clientes y desarrolladores se

pongan de acuerdo. Es importante, que el cliente comprenda bien los requisitos.

Análisis: Se encarga de examinar y re�nar los requisitos, hace una comprensión

detallada para el correcto desarrollo y mantenimiento y especi�ca en el lenguaje del

desarrollador.

Diseño: Depura el análisis para que los programadores lo implementen, completar

alguno de los requisitos en caso de que se pueda reutilizar algo ya hecho previamente.

Implementación: Se encarga de implementar y probar el sistema por medio de los

programadores.

Pruebas: Lleva a cabo las pruebas de unidad, integración, producto y aceptación.

9


3.2. Requisitos

Lo primero que se hizo fue hacer una captura de requisitos funcionales y no funcionales

del proyecto. Esto hace que se minimicen los riesgos más importantes que puedan poner en

peligro el desarrollo del mismo y además dejan claros los puntos que tendrá que cumplir

el proyecto para que se vean re�ejados todos los objetivos.

3.2.1. Requisitos Funcionales

Si recordamos los objetivos, tenemos que los requisitos funcionales son crear una re-

presentación visual de la ciudad y de la simulación a través de un archivo para cada una

de ellas. Por lo tanto, si nos �jamos desde un punto de vista del usuario, los requisitos

funcionales serían estos:

El usuario debe ser capaz de elegir mediante una interfaz los archivos de la ciudad

y de la simulación, para poder empezar la visualización.

La ciudad debe estar representada en su totalidad, siendo opcional el uso de dife-

rentes modelos para edi�cios, carreteras, aceras, etc.

Los coches deben representarse y moverse según avance la simulación, debe poder

representarse varios tamaños de coche distintos, creando algún tipo de cubo repre-

sentativo con esas medidas en caso de no disponer de un modelo con el tamaño

adecuado.

Los semáforos deben cambiar su estado según describe el �chero de simulación,

luciendo de distintos colores según el estado.

Deberá haber una interfaz de usuario en la propia simulación para poder pararla

cuando se desee, así como mover la cámara, seguir a algún coche y ocultar los

edi�cios para facilitar la visión.

3.2.2. Requisitos de Interfaz

Si nos �jamos, vamos a necesitar dos interfaces, la primera tiene que cumplir la función

de elegir los archivos antes de la visualización y la segunda interfaz se encuentra una vez

empezada ésta y permite interactuar con ella. Las denominaremos interfaz externa e

interna respectivamente.

10


Interfaz Externa:

• Debe indicar y permitir al usuario elegir un archivo que contenga la información

de la ciudad y hacer lo mismo para el archivo de la simulación.

• Mostrará la ruta elegida de cada uno de los archivos para que el usuario pueda

comprobar que eligió el archivo adecuado.

• Dispondrá de un botón para iniciar la visualización usando los archivos elegidos

por el usuario.

Interfaz Interna:

• Tendrá un botón para parar y reanudar la visualización.

• Deberá poseer un botón para cambiar la cámara a modo seguimiento de un

coche, y si se volviese a pulsar, pasará a seguir a otro coche distinto.

• Facilitará un botón para ocultar y mostrar edi�cios, ocultándolos cuando se

pulse y mostrándolos al pulsarlo de nuevo.

• Contendrá un botón para cambiar la cámara a vista libre desde el aire y per-

mitirá moverse en esa vista pulsando con el ratón y luego desplazándose con

él.

3.2.3. Requisitos No Funcionales

A parte de todos los requisitos funcionales, existen varios requisitos no funcionales que

se describen a continuación y que son igual de importantes:

Es necesario que haya al menos un numero limitado de fotogramas por segundo en

una máquina normal, este número no debe ser nunca inferior a 30 fps.

La velocidad de la simulación debe ser normal, los vehículos deben ir a una velocidad

razonable para que verla no sea demasiado tedioso.

La calidad de la visualización no debe ser muy elevada pero sí que tiene que tener

un cierto nivel de detalle, siendo imprescindible que sea una representación en tres

dimensiones.

11


3.3. Análisis

En esta fase, es crucial identi�car la funcionalidad de nuestro proyecto, para ello crea-

mos un diagrama de casos de uso que representase cada una de las funciones que debe

tener nuestro sistema.

3.3.1. Casos de uso

El Visualizador de LiveCitySim, debe ser capaz de poder hacer una representación

grá�ca de una ciudad, de una simulación dada en un archivo y �nalmente, de recoger

ciertas acciones realizadas por el usuario. La �gura 3.2 muestra el diagrama de casos de

uso que se creó:

Figura 3.2: Diagrama de Casos de Uso.

En ella se distinguen tres casos de uso:

Importar Archivos: Como se ha mencionado, el usuario debe ser capaz de poder

cargar dos archivos necesarios para el funcionamiento del visualizador, éstos son el

archivo que contiene la ciudad y el de la simulación. La funcionalidad de este caso de

uso debe permitir al actor poder escogerlos de una manera grá�ca mediante algún

tipo de interfaz. Está relacionado directamente con el caso de uso de Visualizar,

ya que tendrá que informarle de la ruta de cada uno de estos dos archivos.

12


Visualizar: Es quizás el más importante, se encarga de iniciar la visualización que

está compuesta por dos partes: la primera se centra en dibujar la sección estática de

la simulación, es decir, todo lo que no va a cambiar con el paso del tiempo, en nuestro

caso, la ciudad por completo (edi�cios, aceras, carreteras, señales, etc); la segunda,

es la encargada de la parte dinámica de la visualización, compuesta por todos los

agentes como los coches y semáforos, ya que éstos varían su comportamiento a

medida que avanza la simulación. Está relacionado directamente con los otros dos

casos de uso, ya que utiliza los archivos importados en el caso de uso anterior y

además proporcionará la ventana donde se encontrará la interfaz grá�ca con la que

interactuará el usuario.

Recoger Acciones del Usuario: El actor debe poder relacionarse directamente

con la visualización y ejercer control sobre ella, debe ser capaz de pararla, ocultar

alguno de sus elementos, seguir a algún vehículo y mover la cámara. Está relacionada

directamente con el caso de uso Visualizar, ya que se encarga de realizar acciones

sobre la representación que éste creó.

3.3.2. Diagramas de Estados

Una vez diferenciados todos los casos de uso, el siguiente paso es especi�car cada uno

de ellos para ver como vamos a implementarlos e identi�car el funcionamiento paso a

paso. Para ello, se creó un diagrama de estados por cada uno de los casos de uso:

3.3.2.1. Importar Archivos

El primer caso de uso, aclara que debe haber alguna manera para el usuario de poder

cargar los archivos que contienen tanto la ciudad, como la simulación hecha con cada uno

de los agentes que la componen. Debido a esto, es necesario que empiece con una pantalla

que le indique que debe seleccionar ambos archivos, seguidamente escogerá primero el

archivo de la ciudad y por último, el de la simulación.

13


Figura 3.3: Diagrama de estados de Importar.

3.3.2.2. Visualizar

Como ya se mencionó, este caso de uso implica representar las partes estática y dinámi-

ca de la visualización. Para ello, lo primero será crear la ciudad con todos sus elementos,

es decir, edi�cios, cruces, calles y señales, ya que esta parte se mantiene �ja y no es

necesaria actualizarla a lo largo del tiempo. Una vez hecho esto, se debe proceder a la

parte dinámica, en la que se dibujan los agentes y se actualiza su posición y estado según

avanzamos en la simulación hasta que ésta llega a su �n.

Figura 3.4: Diagrama de estados de Visualizar.

14


3.3.2.3. Recoger Acciones del Usuario

Para �nalizar, el actor debe ser capaz de manipular y realizar ciertas acciones sobre la

visualización, así que una vez recibida una acción hay que identi�car cual es y proceder a

realizarla, el usuario debe poder:

Mostrar/Ocultar Edi�cios: Si los edi�cios están siendo mostrados actualmente esta

acción debe ocultarlos, de la misma forma si éstos estaban ya ocultos se realizará la

acción opuesta, es decir, volverlos a mostrar. Esto facilitará la visualización de los

agentes.

Parar/Reanudar Visualización: Si actualmente la simulación está en marcha y se ve

el progreso de los coches, esta acción los congela dejándolos quietos. Si se vuelve a

realizar, se reanudará la simulación deshaciendo el efecto anterior.

Cámara global: Siempre que el usuario realice esto la cámara debe posicionarse en

un punto aéreo determinado.

Seguir Coche: Permite cambiar la cámara a modo seguimiento de los vehículos, cada

vez que se realice esto debe cambiar a un vehículo distinto (en caso de haber más

de uno).

El usuario debe poder realizar acciones siempre que quiera mientras la visualización

siga activa, es decir, hasta que no se termine el movimiento de los vehículos, por lo tanto

cada vez que se realice una, se volverá al principio a esperar otra.

Figura 3.5: Diagrama de estados de Recoger Acciones del Usuario.

15


3.4. Diseño

En la realización del diseño del proyecto, debemos distinguir dos partes bien claras,

por un lado tenemos el diseño general del proyecto en la que se de�nió los parámetros de

la ciudad y que es usada en ambos subproyectos, tanto el simulador, como el visualizador.

Por otra parte, está el diseño del visualizador, que se encarga de mostrar grá�camente la

simulación así como toda la ciudad al completo.

3.4.1. Arquitectura

LiveCitySim está dividido en tres proyectos distintos pero que dependen entre sí para

su correcto funcionamiento, el primero de ellos, se encarga de de�nir todos los parámetros

de la ciudad por la cual circularán los coches, este proyecto es utilizado por el simulador

a la hora de calcular las rutas y demás y por el visualizador para dibujar las calles y los

coches por los sitios correspondientes. La relación entre ellos se puede ver en el diagrama

de clases de la �gura 3.6. Como vemos disponemos de tres paquetes distintos:

Figura 3.6: Diagrama de Clases Global.

Ciudad: Es el encargado de de�nir todos los parámetros que compondrán la ciudad,

así como de la ontología que se utilizará para formarla. Lo componen todos los

elementos que forman una ciudad como calles, edi�cios, carriles, etc.

Simulador: Su función principal es crear una simulación en la que participen dis-

tintos tipos de agentes y recorran la ciudad siguiendo unas pautas determinadas.

16


Depende directamente del paquete ciudad ya que necesita una instancia de ésta para

poder realizar la simulación.

Visualizador: Su tarea es crear la representación grá�ca de la ciudad y de los

vehículos y semáforos que componen la simulación. Es el paquete más dependiente,

ya que necesita a los otros dos para su funcionamiento debido a que la representación

se hace a partir de una instancia de la ciudad y de la simulación.

3.4.2. Diseño de la ontología de la ciudad

En el diagrama 3.7 de clases particular del paquete ciudad podemos ver su diseño.

Como se aprecia está compuesto por varias clases:

Figura 3.7: Diagrama de clases de ciudad.

Xml: Es la clase que permite importar la ciudad desde un archivo XML, será utili-

zada por el paquete visualizador y por el simulador.

Ciudad: Se trata de la clase que engloba todos los elementos de la ciudad, será la

que este contenida en el archivo XML.

Edificio: Como su propio nombre indica, tendrá las medidas y la ubicación de un

edi�cio.

17


Cruce: Será la clase que una varias calles, podrá tener hasta cuatro calles conectadas

a él. También será el punto de salida y entrada de los coches a la ciudad.

Calle: Estará formada por carriles que podrán ser a favor y/o en contra dirección.

Contendrá la posición de la misma, también podrá tener una señal al �nal y al

principio de la calle. Por convenio, la posición de las calles será siempre de abajo a

arriba o de izquierda a derecha. También poseerá información como el ancho de la

acera, o los cruces con los que está conectada al principio y al �nal de la misma.

Debe estar compuesta al menos por un Carril.

Carril: Será el camino por donde viajen los coches, deberán tener una posición de

inicio y otra de �n.

Senyal: Es la clase de la que heredarán tanto los semáforos como los stops. Se

encuentran al �nal de las calles y regulan los cruces.

Estática: Es un tipo de clase que hereda de Senyal, en este caso la señal de stop

aunque se puede añadir más tipos de señales estáticas si se desea.

Semaforo: También hereda de la clase Senyal, compone el semáforo, con su estado

y sus parámetros.

Agente: Contiene los estados de los posibles agentes, es usada por Semaforo para

de�nir su estado.

Como vemos, la ciudad está compuesta básicamente por calles conectadas mediante

cruces, a parte tiene información como edi�cios y señales para poder hacer una represen-

tación y una simulación más reales.

3.4.3. Diseño del visualizador

El diseño del paquete Visualizador requería recoger toda la información dada por los

otros dos paquetes, como hemos visto, es el paquete más dependiente ya que necesita

la ciudad para poder dibujarla y la simulación para crear los coches y su movimiento.

A parte de todo esto, es necesario transformar dicha información a clases que el motor

grá�co JMonkeyEngine3 (jme3) pueda entender y representar.

3.4.3.1. Diseño general

En el diagrama 3.8 podemos ver la relación de las clases y los paquetes entre sí:

18


Figura 3.8: Diagrama de Clases de Visualizador.

Si nos �jamos, visualizador está dividido en tres paquetes distintos que son �guras,

dibujante y gui:

El paquete �guras se encarga de transformar cada una de las partes de la ciudad en

objetos que se puedan crear grá�camente, se compone de varias clases que heredan

de la ontología de ciudad y son su representación sobre el motor jme3. Alguna de

ellas a destacar es Stargate, que es un cruce especial en el que sólo hay un carril

conectado y es donde empiezan y acaban los vehículos la simulación.

Dibujante es el paquete encargado de leer la ciudad y la simulación y crear �nalmente

toda la visualización tanto de la parte estática (calles, edi�cios, cruces y señales)

como de la dinámica (coches y semáforos).

Esta compuesto por 3 clases:

• Visualizador, se encarga de crear la aplicación grá�ca y de establecer sus

parámetros, como la resolución, el número de fotogramas por segundo máxi-

mo, así como de la interfaz del usuario, a parte de esto, hace una llamada a

DibujaCiudad y otra a DibujaAgente3D aunque esta ultima en un bucle ya

que lo que buscamos es avanzar iterativamente en la simulación.

19


• DibujaCiudad, como su propio nombre indica, es la clase encargada de crear

toda la ciudad, lee el archivo XML con todos los datos de ésta y después crea

poco a poco las calles, edi�cios y demás elementos usando las clases del paquete

�guras.

• DibujaAgente3D, lee toda la información de la simulación y la representa,

básicamente se compone de una función que utiliza un parámetro numérico

que indica la iteración en la que nos encontramos en la simulación y devuelve

el estado de cada uno de los agentes en dicha iteración para después dibujarlos.

Por último, gui genera las ventanas para que el usuario elija los archivos donde

se encuentran la simulación y la ciudad y permite iniciar todo el proceso de vi-

sualización. La clase Final simplemente se encarga de crear la ventana del tipo

VentanaVisualizador que es la que muestra los botones para poder cargar cada

uno de los archivos necesarios que permiten proceder con la visualización.

3.4.3.2. Diseño del motor de visualización: JMonkeyEngine3

Como ya hemos mencionado, es necesario traducir esta información a clases que en-

tienda el motor jme3, así pues, procedo a explicar algunas de ellas que serán vistas en el

diagrama 3.9:

Material/Geometry/Texture: Son tres clases fundamentales a la hora de crear

�guras, Geometry crea la forma del objeto, y Texture y Material se encargan

de darle color. Son las clases más utilizadas para crear todos los elementos en la

representación.

ParticleEmitter: Se utiliza sólo a la hora de representar los Stargate (puntos de

entrada y salida a la ciudad), crea un efecto de niebla o humo.

Spatial: Es parecido a Geometry, sirve para cargar �guras ya hechas con textura

y todo, se puede decir que es una mezcla de Material, Geometry y Texture.

Node: La escena está compuesta por nodos, a los que se les adjuntan �guras, la escena

principal está formada por un nodo raíz que tiene más nodos y �guras adheridas.

SimpleApplication: Es una clase que crea la ventana con el motor en marcha, está

compuesta de varios métodos prede�nidos que permiten actuar sobre la escena.

Como podemos ver en el diagrama 3.9 de clases, la relación que tienen los paquetes con

jme3 es la siguiente:

20


Figura 3.9: Diagrama de Clases relación con JMonkeyEngine3.

La mayoría de las clases del paquete �guras están relacionadas con las clases Geometry,

Material y Texture, ya que son las necesarias para representar sus distintas formas. Sin

embargo, alguna como Stargate utiliza ParticleEmitter ya que no es una forma �ja sino

algo parecido a una nebulosa. Por otro lado, las �guras importadas como los semáforos y

señales de la clase Senyal utilizan un Spatial para su representación.

Finalmente, Visualizador hereda de SimpleApplication ya que debe crear la ven-

tana con el motor grá�co y sus características.

3.4.3.3. Diagramas de Secuencia

En esta fase de elaboración de nuestro proyecto es necesario crear una guía para seguir

después en la implementación. Para esta tarea se crearon varios diagramas de secuencia

que explican detalladamente el funcionamiento de cada clase a la hora de realizar cada

uno de los casos de uso. Recordemos que teníamos tres: Importar Archivos, Visualizar y

Recoger Acciones del Usuario.

Importar Archivos

El usuario debe ser capaz de seleccionar los dos archivos necesarios para realizar la

visualización, es decir, los que contienen la ciudad y la simulación.

La secuencia debe ser la siguiente, la persona interactuará con una instancia de la

clase VentanaVisualizador que mostrará la interfaz grá�ca de usuario, en ella habrá dos

botones para elegir los dos archivos que se necesitan. Cada vez que el usuario seleccione un

archivo, la ruta de éste debe ser mostrada por pantalla para que el actor pueda comprobar

que eligió el archivo adecuado.

21


Figura 3.10: Diagrama de Secuencia del caso de uso Importar Archivos

Visualizar

Esta es la función principal del proyecto, engloba toda la visualización de la simulación

y está compuesta por dos partes, dibujar la ciudad y la simulación. Aquí el usuario debe

Figura 3.11: Diagrama de Secuencia del caso de uso Visualizar.

poder iniciar la aplicación grá�ca a través de la clase VentanaVisualizador una vez que

ya ha cargado los archivos. Para ello, esta clase debe usar la función start() que heredó

Visualizador de SimpleApplication del paquete jme3, esto creará una nueva ventana

con el motor grá�co ya en funcionamiento.

Seguidamente Visualizador debe llamar a la clase DibujaCiudad para que ésta cree

22


todos los elementos de la escena. Cuando se llama a DibujaCiudad con un archivo de

ciudad, ésta procede a leerlo y crea poco a poco toda la ciudad representándola en el

motor grá�co a partir de instancias de las clases del paquete �guras.

Finalmente, en el bucle update() que proporciona SimpleApplication de jme3 se

llama a DibujaAgente3D() con un parámetro que va aumentando en cada iteración, esta

llamada se repite sucesivamente, de esta forma, DibujaAgente3D colocará los agentes en

la escena acorde con dicho parámetro. Según vayan pasando las iteraciones y los agentes

circulen, las llamadas a DibujaAgente3D irán moviéndolos acorde con el archivo XML

que contiene la simulación.

Recoger Acciones del Usuario

Como dijimos, el usuario debe ser capaz de pausar la visualización en cualquier momen-

to, así como de mover la cámara y ocultar algunos elementos para facilitar el seguimiento

de los vehículos.

Figura 3.12: Diagrama de Secuencia del caso de uso Acciones del Usuario.

Este diagrama es bastante simple, el usuario pulsará alguna tecla o botón de la in-

terfaz grá�ca para realizar la acción, esto hará que Visualizador la detecte, reconozca

y �nalmente haga lo que el usuario le pidió. Para ello, cuando la persona pulsa uno de

los botones que requieren una respuesta, hace que salte el método onAction() que se

encuentra en la clase Visualizador, seguidamente, se identi�ca que tipo de acción era y

se realiza. El usuario puede realizar tantas acciones como quiera, siendo la secuencia de

respuesta la misma, lo único que cambia es la acción que se realiza en cada una de ellas.

23


3.5. Implementación

En esta fase ese necesario ver las tecnologías que vamos a tener que utilizar, además de

de�nir una estructura para almacenar los archivos del proyecto y �nalmente, implementar

los distintos casos de uso.

3.5.1. Tecnologías Utilizadas

A lo largo de todo el proyecto hemos tenido que usar diversas librerías así como

programas para realizar las distintas tareas que teníamos como meta:

JMonkeyEngine3 (versión 2011-03-21): Es el motor grá�co usado para generar la

visualización. Es una librería para Java que permite crear objetos en tres dimen-

siones, así como generar luces, emisores de partículas, texturizar, etc. Se eligió ya

que permitía importar modelos usando distintos formatos, utilizaba Java y además

tenía muy buena documentación on-line y un foro activo donde poder preguntar

dudas.

Blender (versión 2.56a): Es una herramienta de modelado grá�co de código abierto,

permite el uso de plugins lo que hace que sea compatible con prácticamente cualquier

cosa que necesites, además, al ser open source tiene una comunidad muy activa con

gran cantidad de tutoriales y recursos a disposición de todo el mundo. Al ser gratis,

potente y compatible con los formatos que permitía importar jme3 fue la elección

perfecta para nuestro proyecto.

XStream (versión 1.3.1): Es una librería para Java que proporciona un uso fácil

de los archivos XML, ya que tiene la capacidad de importar y exportar clases a

archivos con extensión .xml, fue necesaria para guardar la ciudad y la simulación de

una manera limpia y clara.

NiftyGUI (versión 1.2): Permite crear una interfaz grá�ca compatible con jme3, se

hizo para facilitar la visibilidad de las acciones posibles que podía realizar el usuario

y no limitarlas solo al teclado.

Swing (versión 1.1.1): Es la librería de Java para crear ventanas y botones con los

que el usuario puede interactuar, se usa para crear la interfaz que permite importar

los archivos y comenzar la visualización.

24


3.5.2. Estructura del proyecto

Debido a que el proyecto tiene un enfoque grá�co, es necesario almacenar gran cantidad

de archivos para su funcionamiento, estos �cheros pueden ser desde el código fuente, hasta

texturas o modelos. Para su proporcionar una mayor facilidad y claridad, se creó una

estructura de carpetas que facilitan el uso y la adición de nuevos modelos y elementos.

Están representados en el diagrama 3.13.

25


Figura 3.13: Diagrama de Estructura del proyecto.

26


El proyecto tiene dos carpetas principales, por un lado tenemos la carpeta src, que

contiene los archivos fuente de las clases, separadas en distintas carpetas según el paquete

que las que se encuentren, no entraremos en detalle a su estructura ya que se ha explicado

detalladamente en el apartado de diseño.

Por otro lado, tenemos la carpeta bin, ésta contiene todos los elementos que son

necesarios para que el proyecto funcione, como vemos está formada por varias carpetas:

Common: Se encarga de almacenar los materiales distintos que se usan en el proyec-

to, para eso está dividido en dos carpetas distintas, la carpeta MatDefs contiene

las de�niciones de los distintos materiales, por otro lado, Materials contiene los

materiales ya creados a partir de las de�niciones en MatDefs.

Para entender su funcionamiento mejor pongamos un ejemplo, imaginemos que que-

remos añadir una de�nición de un material que sea un color sólido, para ello, debe-

ríamos crear un archivo j3md (un archivo de de�nición de material) con los datos

de este tipo de material. Los archivos j3md especi�can los parámetros que tiene

nuestro material, por ejemplo en el que queremos usar tenemos uno que es Color. Si

cada vez que queremos crear un objeto usando este material no nos apetece poner

todos los parámetros (aunque en este caso sólo tenemos el color) podemos crear

otro archivo de tipo j3m dentro de la carpeta Materials, que use la de�nición que

habíamos creado y ponga el parámetro de color a Blue, por ejemplo. De esta forma,

si queremos crear un objeto con un este Material que sea azul, simplemente debemos

especi�car que use el archivo j3m que está en la carpeta Materials.

Effects: Contiene los archivos usados en efectos especiales, como en el caso del

humo azul que se utiliza para crear los Stargate.

Gui: Las imágenes de los botones utilizados en la interfaz que permite controlar la

visualización de la simulación se guardan aquí. Así que, si se quisiesen agregar más

acciones, las imágenes de los botones irían en esta carpeta.

Models: Los distintos modelos que se crean a partir de los programas de modelado

grá�co van aquí, para ello se crea una carpeta con el nombre del modelo que contiene

todos los archivos que lo forman. En nuestro caso, tenemos alguna ya creada para

los modelos de coches, semáforo y señal de stop.

Textures: Contiene las texturas de los distintos modelos y objetos que se utilizan,

se crea una carpeta con el nombre del objeto que utiliza la textura y dentro se ponen

27


todas las texturas que lo formen. La textura de los edi�cios, aceras y carreteras están

guardadas en este sitio.

XML: Sirve como carpeta donde poder guardar los archivos de ciudad y simulación a

cargar. A parte de esto contiene otro archivo llamado hellojme.xml que proporciona

la información de la interfaz grá�ca de usuario, es decir, botones, ruta de las imágenes

de cada botón, posición y nombre del método a llamar cada vez que se pulse uno de

ellos. Si quisiésemos añadir más botones al menú, deberíamos modi�car este archivo

y agregarlos.

3.5.3. Detalles de Implementación

Durante la etapa de implementación, nos encontramos con varios detalles que di�cul-

taron la realización de la visualización. Procedo a explicar algunos de ellos a continuación:

3.5.3.1. Creación de Cruces

A la hora de representar un Cruce, debemos tener en cuenta de que sólo informan de

las calles con las que están conectados y no tienen coordenadas, para poder representarlo

fue necesario calcular estás coordenadas a partir de las calles colindantes, por lo que para

que un cruce este bien hecho debe tener al menos dos calles que sean perpendiculares,

si este caso no se diera, no tendría sentido colocar un cruce ya que si se uniesen calles

en la misma línea sería lo mismo que tener una calle igual de larga que la suma de las

dos calles conectadas. La única excepción a esto son los cruces de tipo Stargate (puntos

donde empiezan y terminan los coches) que sólo tienen una calle conectada a ellos, pero

éstos tienen un �ag que los marcan como tal y están representados por un �humo azul�.

28


En la imagen 3.14 podemos apreciar un Cruce normal:

Figura 3.14: Cruce conectando dos calles.

En la �gura 3.15, vemos la representación de un Cruce de tipo StarGate:

Figura 3.15: Stargate.

3.5.3.2. Incorporación de nuevos modelos de coche

El proyecto tiene pocos modelos de vehículo, es posible agregar más ya que cuando se

crea un agente de tipo coche tiene asociado un número indicando el modelo grá�co que

le corresponde con una ruta al archivo que contiene dicho modelo. A la hora de crear el

vehículo en la clase Coche3D, se comprueba este número y se carga el modelo asociado a él,

así que para poder incorporar más modelos simplemente habría que añadir otro numero

más y agregar la ruta del nuevo modelo a incorporar. En caso de que el número que tenga

un agente no disponga de ningún modelo de coche asociado, se procederá a crear un cubo

29


con la longitud indicada en la información del agente, esto permite visualizar simulaciones

más complejas sin tener que hacer los modelos 3D de cada uno de los vehículos.

En la imagen 3.16 apreciamos ambos casos, rodeado por un círculo en verde esta un

modelo cargado desde un archivo, y en rojo tenemos un rectángulo azul que representa

un coche del que no disponemos de el modelo.

Figura 3.16: Representación de los vehículos.

3.5.3.3. Semáforos

Son quizás la parte más complicada ya que contienen un componente estático y otro

dinámico, la posición dentro de la ciudad y la orientación son inamovibles, pero las luces

varían con el tiempo, así que para que funcionen al crear la ciudad hay que guardar una

lista con todos los semáforos para que después a la hora de cargar la simulación se pueda

cambiar cada una de las luces acorde con la iteración en la que nos encontramos, ya que

recordemos, una simulación indica la posición de cada vehículo en cada instante, así como

el estado de cada semáforo (rojo, verde o ámbar).

30


Figura 3.17: Semáforo en rojo, verde y ámbar respectivamente.

3.5.3.4. Creación de componentes

Para crear la representación de los componentes que forman la ciudad y la simulación

distinguiremos entre tres tipos diferentes:

Componentes formados por Geometry y Texture: Son la mayoría de los elementos

de la ciudad, están formados por un cubo que tiene adherida una textura, de esta

manera se han creado las carreteras, los edi�cios y las aceras. Para la creación de un

cubo se utiliza la clase Geometry indicándole las dimensiones apropiadas. Y luego a

esa instancia de la clase se le adhiere otra instancia de la clase Texture que contiene

la imagen con la textura que se desea. En la �gura 3.18 vemos un ejemplo.

Figura 3.18: Composición de una carretera.

Componentes creados en herramientas de modelado: Algunos elementos no se pue-

den representar como simples cajas ya que son �guras más complejas, para su crea-

ción se utilizó una herramienta externa de modelado (Blender). De esta forma, sólo

hay que cargar el archivo desde JMonkeyEngine3 y tenemos el modelo con la textu-

ra apropiada. Para poder hacer esto, necesitamos usar una clase de tipo Spatial, y

jme3 creará la �gura automáticamente y la almacenará en la instancia de esa clase.

31


Dentro de este tipo de �guras se encuentran los semáforos, coches y señales de stop,

todas ellas fueron creadas previamente en Blender y más tarde importadas a jme3.

En la imagen 3.19 podemos observar el semáforo visto desde el programa Blender

desde varias vistas distintas.

Figura 3.19: Semáforo dentro de Blender.

Componentes especiales: El último tipo de elementos que forman la ciudad, son

aquellos que no tienen un cuerpo �jo, en este apartado entran los Stargate, que

son nebulosas de color. Para su creación se utilizo la clase ParticleEmitter que

proporciona un efecto de humo. Vemos un ejemplo en la �gura 3.20.

Figura 3.20: Humo de color azul representando un Stargate.

3.5.3.5. Representación de componentes

Como todo el proyecto esta enfocado a ser una representación grá�ca parece apropiado

volver a recordar los componentes que la forman y poner seguidamente su representación

32


en el motor para que a la hora de usar el programa sepamos identi�car sus elementos.

Recordemos que la ciudad estaba compuesta principalmente por Calles, Edi�cios y Cruces:

Calles: Están formadas por carriles, aceras, y opcionalmente, una señal al principio

y al �nal de las mismas. En la fotografía 3.21 vemos una calle con cada uno de sus

componentes marcados.

Figura 3.21: Representación de los elementos que forman una calle.

Edi�cios: Son cubos grandes con una textura adjunta que se repite en las caras

laterales y otra distinta para la superior.

Figura 3.22: Representación de un edi�cio.

33


Cruces: Unen varias calles distintas.

Figura 3.23: Representación de un cruce.

A parte de los elementos de la ciudad, no debemos olvidarnos de la representación

de los agentes que componen la simulación. En nuestro caso tenemos dos, vehículos y

semáforos.

Vehículos: Pueden estar representados tanto por un modelo de un coche, como por

un cubo de color azul. Se mueven por los carriles y cruces a lo largo de toda la

simulación.

Figura 3.24: Representación de vehículo por modelo y por caja azul respectivamente.

Semáforos: Se encuentran al �nal o principio de algunas calles, cambian de ilumina-

ción según trascurre el tiempo.

34


Figura 3.25: Representación de un Semáforo.

3.5.3.6. Interfaz Grá�ca de Usuario

Para cumplir la funcionalidad de que el usuario pudiese manipular de alguna manera

la visualización fue necesario crear una interfaz grá�ca de usuario. Cada botón debía ser

una imagen distinta, y la suma de todas ellas formarían el menú que la persona puede ver

y con el que puede interactuar.

En la imagen 3.26 podemos apreciar los botones que la forman:

Figura 3.26: Botones que forman la interfaz Grá�ca.

35


Quedando como en la �gura 3.27 una vez dentro del motor JMonkeyEngine3 :

Figura 3.27: Interfaz Grá�ca de Usuario.

3.5.3.7. Modelado con Blender

La creación de los modelos complejos que representan los coches y las señales se hizo

utilizando el programa de modelado grá�co Blender. En el proceso de generación de las

mismas podemos distinguir varias fases:

Modelado: Es el proceso de creación de polígonos que formarán �nalmente nuestra

�gura, a la hora de crear �guras sin muchos polígonos como los semáforos, podemos

partir de formas predeterminadas (como esferas, cilindros, etc) y mezclarlas hasta

crear la �gura completamente. En la fotografía 3.28 podemos observar los polígonos

que forman parte del semáforo.

Figura 3.28: Vértices unidos forman la �gura del semáforo.

Para modelar un coche que está formado por muchos más polígonos se emplea otra

técnica, consiste en tener cuatro imágenes (frente, per�l, alzado y posterior) con la

misma medida que representen al coche, estás imágenes se denominan blue prints.

36


Figura 3.29: BluePrints de un coche.

Una vez que se tienen las blueprints, se divide la pantalla en cuatro partes y se pone

cada una de las imágenes de fondo en cada parte, después se procede a crear los

vértices y unirlos en uno de los planos del espacio y más tarde se utiliza otra vista

para colocar los vértices en la coordenada que falta. En la captura 3.30 se aprecia

con más claridad:

Figura 3.30: Uso de Blue Prints dentro de Blender.

Texturizado: Una vez creada la forma de nuestra �gura, el siguiente paso es darle

color, para ello se pueden ir seleccionando varias caras y ponerles un color sólido

hasta haberla pintado entera, esto se hizo así para los semáforos y el coche.

37


Figura 3.31: Texturizado del coche en Blender.

Otro método de texturizado es el mapeado UV, consiste en descomponer todas las

caras de la �gura en un plano y luego dibujar sobre ese plano los colores. Es como

si la �gura estuviese hecha de papel y la desenvolviéramos y pintásemos cada una

de sus caras. Las señales de stop están hechas de esta forma. Si nos �jamos en la

imagen 3.32, podemos ver arriba a la izquierda la señal de stop sin textura, a la

derecha el mapeado UV y a abajo a la izquierda el resultado �nal.

Figura 3.32: Texturizado del Stop mediante mapeado UV.

3.5.3.8. Circulación por carriles

El movimiento de vehículos por carriles se estima a partir de los datos de la simulación.

El archivo de simulación informa para cada vehículo en que calle se encuentra, por que

carril circula y la distancia a la que está del principio de éste. Si sumamos al punto de

inicio del carril la posición donde se encuentra el coche, podemos calcular las coordenadas

exactas donde está situado el vehículo en cada una de sus iteraciones, de esta forma,

38


para realizar el movimiento, lo único que debemos hacer es restar las coordenadas del

punto donde se encuentra el coche en la siguiente iteración a las coordenadas actuales y

obtendremos el vector con el movimiento que debe seguir el vehículo. Vemos un ejemplo

en la �gura 3.33.

Figura 3.33: Movimiento de coches por carriles.

El punto negro son las coordenadas que tenemos actualmente de nuestro coche, al

leer el archivo de simulación calculamos las coordenadas donde debe estar el coche en la

siguiente iteración (punto verde), restamos las coordenadas de ambos puntos y obtenemos

un vector de movimiento que será el encargado de mover el coche en esa dirección y con

una velocidad igual al módulo de dicho vector.

3.5.3.9. Circulación por cruces

Como ya se ha mencionado antes, los cruces carecen de información sobre su posición

y sus dimensiones y solo contienen las calles que conectan. Por este motivo, el archivo de

simulación sólo informa de que un coche se encuentra en un cruce pero no de donde ni de

que cruce se trata. Para poder hacer circular los coches por los cruces lo que se hizo fue ver

el punto por donde el coche entraba al cruce y el punto por donde éste salía del mismo, de

esta forma podemos calcular el vector con la dirección que el vehículo debe seguir. Pero

como no queda bien que el coche cruce en diagonal, se descompuso este vector en el eje X

39


e Y y se hizo que cruzase primero por uno y después por el otro con una velocidad igual

a la distancia que debía recorrer, entre el número de iteraciones que tardaba en salir del

cruce. Se puede apreciar mejor en el ejemplo de la imagen 3.34:

Figura 3.34: Cálculo de posición del coche en los cruces.

El coche entra al cruce por el punto de entrada, en la iteración número 1, el archivo de

simulación nos informa que durante las próximas 20 iteraciones se encuentra en un cruce,

y en la iteración número 21 aparece en el punto de salida. Con esta información calculamos

el vector con la dirección que debe seguir el coche (la resta entre el punto de salida menos

el punto de entrada). Como quedaría poco real que el coche cruzase de manera diagonal

(siguiendo la dirección del vector), descomponemos el vector en sus componentes X e Y,

de esta forma hacemos que el coche recorra toda la componente X primero, luego gire

y recorra después la Y. La velocidad por iteración que debe llevar, será la suma de la

dimensión de ambas componentes dividida entre las iteraciones que tarda en cruzar, en

este caso 20.

3.5.4. Estructura de los archivos XML

Como ya se ha mencionado, para el correcto funcionamiento del programa es necesario

cargar dos archivos XML, uno de ellos debe tener toda la información de la ciudad y el

otro contendrá los datos de la simulación realizada.

40


3.5.4.1. Estructura del archivo XML de ciudad

Los archivos XML con la información de la ciudad deben seguir una estructura ade-

cuada, esta estructura es la misma que vimos en el apartado de diseño y que daba a

entender que la ciudad está formada por edi�cios, cruces y calles. Para crear un archivo

XML correcto debemos usar el formato que se ve en la �gura 3.35.

Figura 3.35: Estructura de la ciudad en el archivo XML.

Obviamente, la �gura 3.35 sólo muestra la estructura externa del archivo, faltando

por ver la estructura de cada edi�cio, cruce o calle. Aunque este archivo se puede escribir

enteramente a mano, hacer esto para una ciudad bastante grande puede llevar muchísimo

tiempo, por ello, se creó una clase dentro del paquete ciudad denominada EscribirCiudad

en la que si creabas mediante código en Java una instancia de la ciudad con todos sus

elementos (tarea mucho más rápida que escribir el archivo XML) al ejecutar su método

main() utiliza XStream para crear el archivo automáticamente.

Estructura XML de los edi�cios

Como ya se ha visto, nuestra ciudad puede contener varios edi�cios, éstos irían situados

en la primera línea de puntos que se ve en la imagen 3.35. Para crear un edi�cio adecuada-

mente, debemos rellenar sus dos propiedades que son sus dimensiones y la posición donde

se encuentra dentro de los tres ejes de coordenadas.

Para entender mejor los ejes de coordenadas debemos saber que la X es la coordenada

horizontal y crece hacia la derecha, la Y es vertical y crece hacia arriba y la Z es perpen-

dicular a ambas y crece hacia fuera de la pantalla. Además el punto (0,0,0) está situado

en la esquina inferior izquierda de la pantalla.

Una vez que sabemos el orden y sentido de las coordenadas, la estructura de un edi�cio

bien construido y su representación serían las que se ven en la imagen 3.36.

41


Figura 3.36: Estructura de un edi�cio en el archivo XML.

Podemos poner tantos edi�cios como queramos, sólo tenemos que repetir esta estruc-

tura las veces que queramos, cambiando los datos de la dimensión y posición para cada

uno de ellos.

Estructura XML de los cruces

Los cruces tienen una id que debe ser única y sólo informan de que calles unen, para

ello utilizan la nomenclatura de los ejes de coordenadas, es decir, si un cruce tiene una

calle a su derecha estará al �Este�, arriba será �Norte�, abajo �Sur� y a la izquierda �Oeste�.

Como no queremos repetir información en el archivo, debemos escribir la información

de la calle una sola vez y si más tarde hay otro objeto que haga referencia a ella, habrá

que enlazarla mediante el comando reference, si no hiciésemos esto al estar conectadas

las calles con los cruces y los cruces con las calles estaríamos repitiendo información y

creando mal el archivo XML en cuestión.

Dicho esto, la estructura de un cruce bien formado con su representación dentro del

motor serían las que se muestran en la �gura 3.37.

Al igual que con los edi�cios podemos repetir esta estructura tantas veces como se

quiera, pero sin olvidar que no debemos repetir información, así que si por ejemplo tenemos

dos cruces en nuestra ciudad, y ambos están conectados por una calle, sólo debemos

introducir la información de la calle una vez en uno de los cruces y usar el comando

reference en el otro.

42


Figura 3.37: Estructura de un cruce en el archivo XML.

3.5.4.2. Estructura XML de las calles

La estructura de las calles es bastante compleja, ya que están formadas por varios

elementos y contienen gran cantidad de información.

Para empezar, tienen un identi�cador con su nombre, la posición de inicio y �n donde

se encuentran y las dimensiones de la acera. En la �gura 3.38 podemos ver un ejemplo.

Figura 3.38: Estructura de una calle, primera parte.

Los campos aceraIzq y aceraDer indican si existe la acera a la izquierda y a la derecha

de la calle. Para entender el posicionamiento hay que saber que las calles verticales se

inician de abajo a arriba y las horizontales de izquierda a derecha.

A parte de lo ya nombrado, están formadas por carriles a favor y carriles en contra.

Cada carril tiene además un punto de inicio y otro de �n y también la calle a la que per-

tenece, como siempre que vayamos a escribir un carril ya habremos escrito anteriormente

la calle, debemos usar el comando reference. En la �gura 3.39 podemos ver un ejemplo.

Finalmente, ya solo queda añadir el cruce de inicio, el cruce de �n, así como las señales

en contra y a favor en caso de que las hubiese. La imagen 3.40 muestra el fragmento de

código.

43


Figura 3.39: Estructura de una calle, segunda parte.

Figura 3.40: Estructura de una calle, tercera parte.

44


En la fotogra�a 3.41 vemos algunos de los datos de manera representada.

Figura 3.41: Partes de una calle.

3.5.4.3. Reference

Como ya se ha dicho, no es posible repetir información en el archivo XML, para no

tener que hacerlo se utiliza el comando reference. Este comando simplemente actúa como

un puntero a donde se encuentra la información escrita y utiliza los niveles de XML para ir

moviéndose de un punto a otro. Si escribimos .. saltamos al nivel superior, y si escribimos

el nombre del nivel nos adentramos en el. Todo esto se entiende mejor con un ejemplo.

Figura 3.42: Ejemplo de clases que forman un bucle.

Imaginemos que tenemos una clase como la representado en la �gura 3.42, en ella

tenemos que un objeto de la clase llamada A, esta compuesta por un objeto de la clase

tipo B que a su vez esta compuesto por otro objeto de la clase llamada C que a su vez esta

compuesto por el primer objeto de la clase A que creamos. Si cada clase además tuviese un

parámetro numérico llamado parA, parB y parC respectivamente, sería imposible escribir

45


un archivo XML con esta secuencia ya que entraríamos en un bucle in�nito del que no

podríamos salir (ver �gura 3.43).

Figura 3.43: Estructura de XML sin usar reference.

Para arreglar el problema de tener que repetir código y este tipo de bucles es necesario

usar el comando reference, cada vez que ponemos .. saltamos a un nivel superior, así que

si escribiésemos ../.. estaríamos saltando dos niveles hacia arriba. Si lo que queremos es

que el objeto de tipo C apunte al primer objeto, el código de nuestro archivo XML usando

reference sería el que se muestra en la imagen 3.44.

Figura 3.44: Estructura de XML usando reference.

3.5.4.4. Estructura del archivo XML de simulación

El segundo archivo a utilizar es el que contiene la información de la simulación. Este

archivo es bastante más sencillo que el de ciudad ya que simplemente se trata de una lista

de lista de agentes. Entendemos por un agente, un vehículo o un semáforo y cada uno

de ellos tiene un identi�cador y un estado entre otras características. En la �gura 3.45 se

muestra su estructura.

46


Figura 3.45: Estructura de la simulación en el archivo XML.

Estructura de los Vehículos

Un vehículo es un tipo de agente que tiene una posición en una calle y carril determi-

nados, así que según avancen las iteraciones estos datos se modi�carán también y la suma

de todos ellos será el recorrido que ha seguido el agente en cuestión.

Si el vehículo se encuentra en una calle su estructura es la que se muestra en la imagen

3.46.

Figura 3.46: Estructura de un vehículo.

Como vemos, esta compuesto por su id, la calle, el carril, la posición, el tipo de coche

y su longitud. El campo semáforo indica si el agente es un semáforo o un coche y el campo

estado aclara la acción que está llevando a cabo (acelerando, frenando, entrando al cruce),

aunque esto a la hora de representarlo no es útil, conviene verlo en caso de que estemos

leyendo el archivo XML sin usar el motor grá�co.

47


Estructura de los Semáforos

El otro tipo de agentes está compuesto por los semáforos, estos deben informar sim-

plemente de que luz está encendida en ese momento. Su estructura en el archivo XML es

la que se muestra en la imagen 3.47.

Figura 3.47: Estructura de un semáforo.

48

Capítulo 4

Conclusiones

Como hemos visto a lo largo de la memoria, para que el proyecto fuese satisfactorio

debía cumplir los objetivos propuestos, tanto los relacionados con la creación de la ciudad,

como los pertenecientes a la visualización de la simulación.

A la hora de crear una ciudad, se pedía que estuviese formada por carriles con un

sentido de�nido, aceras opcionalmente al lado de los carriles exteriores, edi�cios, cruces

que interconectasen carriles, señales que regulasen los cruces y puntos de partida y de

salida de la ciudad. Además, debía poseer una ontología que estructurase estos elementos.

Como se ha visto, se creó un paquete denominado ciudad el cual cumple con ambos

objetivos, generando esta estructura y conteniendo todos los elementos que se pedían.

Otro punto importante, es que se pudiesen crear varias ciudades distintas y éstas tuviesen

la capacidad de plasmarse en un archivo con toda su información. Como ya se ha mostrado,

es posible crear un archivo XML con una estructura bien de�nida que contenga todos los

elementos de la ciudad, pudiéndose crear tantos como ciudades se tengan.

En cuanto a los objetivos relacionados con la generación de la visualización, se pedía

que se pudiese generar una representación visual de la ciudad y de la simulación a partir

de dos archivos XML. Ya se ha mostrado que el paquete visualizador es capaz de esto,

gracias a las clases DibujaCiudad y DibujaAgentes cumple ambas funciones y crea una

ventana con el motor grá�co en marcha con la ciudad representada y los vehículos y

semáforos comportándose acorde con la simulación. Finalmente, también se requería que

el usuario tuviese algún tipo de control sobre la visualización y pudiera pararla, ocultar

los edi�cios y cambiar la vista de las cámaras. La interfaz que ofrece la aplicación engloba

todas estas funciones, pudiéndolas realizar mediante atajos de teclado o haciendo clic en

los botones que se muestran en la parte superior izquierda de la pantalla.

Además, en las pruebas realizadas los fotogramas obtenidos han sido muy positivos (en

torno a 100 fps) y no tiene problemas de �uidez a la hora de cambiar entre las distintas

49

CAPÍTULO 4. CONCLUSIONES

vistas de las cámaras, etc. Por lo que también se cumplen los requisitos no funcionales

que se propusieron.

Para mí el proyecto ha sido una de las cosas más bonitas de la carrera, ha requerido

mucho trabajo y días de esfuerzo buscando la solución a los problemas que se iban plan-

teando según avanzaba en él. Sin duda me parece un ejercicio de superación personal en el

que uno se tiene que buscar la vida pero con la gran recompensa de aprender enormemente

durante todo su desarrollo. Ha tenido muchas di�cultades importantes, por una parte tuve

que aprender a modelar y a usar Blender desde cero, con tan solo la ayuda de Internet y

libros. Por otro lado, el uso de JMonkeyEngine3 era totalmente nuevo y aparecieron más

di�cultades a la hora de importar los archivos de Blender a él de una manera apropiada.

También aprendí mucho de texturizado e iluminación aunque por falta de tiempo no pude

incluir muchas de esas cosas en el proyecto como el mapeado de bollos. La redacción de

la memoria usando LaTeX también ha dado algún que otro quebradero de cabeza debido

a la inexperiencia con este procesador de texto. Realizar junto con Francisco Buitrago la

creación de la ciudad me ha enseñado mucho de trabajo en grupo y aunque ha veces nos

hemos puesto un poco nerviosos ha sido un placer tener su apoyo durante todo el proceso.

Rubén Ortiz me ha ayudado mucho a encaminar el proyecto y a aclarar dudas importantes

así como ofrecer una gran cantidad de sitios en los que podía encontrar información útil

para seguir aprendiendo. En de�nitiva, para mí ha sido una experiencia muy positiva y

que creo que me in�uirá mucho en el futuro a la hora de trabajar en cualquier empresa,

estoy orgulloso de como ha quedado al �nal aunque me gustaría haber tenido tiempo para

añadir alguna funcionalidad extra o efecto visual.

Las utilidades del proyecto son diversas, puede servir en la industria de los videojuegos

siempre que se requiera un entorno grá�co con vehículos, edi�cios y calles; también desde

un punto de vista más cercano a simular comportamiento permite poder ver el �ujo del

trá�co de una manera visual y podría utilizarse para ajustar parámetros como el tiempo

que dura cada disco de un semáforo evitando generar congestiones, etc.

Como líneas futuras o mejoras al proyecto, hay que tener en cuenta que depende mucho

de los otros dos, por lo que si no se mejora la simulación o la estructura de la ciudad los

cambios están limitados al tema grá�co. Comento algunos de los avances que se podrían

realizar en este ámbito:

Añadir más modelos de vehículo: Se podrían utilizar también camiones, furgonetas y

todo tipo de coches, esto haría la visualización mucho más real y llamativa, también

se podría añadir el mismo modelo pero con colores distintos, etc.

Mejorar edi�cios y calles: Incorporar edi�cios como casas y nuevas texturas para

50


una mayor diversidad y realismo, en las calles podría haber varios tipos de acera,

así como carreteras con algún bache o irregulares.

Ampliar la señalización: Usar varios tipos de semáforo y de stop, y además no sólo

limitarlos a la acera sino también en la carretera pintados al �nal de ésta.

Integrar sonidos: Coches que frenan, aceleran, el pitido de los semáforos, sonido am-

biente, etc.

Si quisiéramos hacer cualquier otro tipo de mejora, sería necesario trabajar parale-

lamente con el proyecto de simulación, de esta forma sería posible incorporar rotondas,

movimiento de personas, aparcamiento de coches y básicamente cualquier cosa que se

necesite.

51


52

Bibliografía

[1] Francisco Buitrago. Simulador tra�co rodado en una ciudad virtual: LiveCitySim.

2011.

[2] http://www.kybele.etsii.urjc.es/docencia/IS_GII_V/2010-2011/Material/

GII-V-IS-2010-11.3.ElProcesoUnificadodeDesarrollodeSoftware.pdf.

[3] http://darkscarab.com/resources/archive.php?id=18.

[4] http://jmonkeyengine.org/wiki/doku.php/jme3.

[5] http://www.blender.org/education-help/tutorials/.

[6] http://www.ogre3d.org/tikiwiki/Blender+to+Ogre.

[7] http://www.the-blueprints.com/.

[8] http://es.wikibooks.org/wiki/Blender_3D:_novato_a_profesional.

[9] http://xstream.codehaus.org/.

[10] http://nifty-gui.lessvoid.com/.

[11] http://en.wikipedia.org/wiki/Swing_(Java).

53

BIBLIOGRAFÍA

54

Apéndice A

Manual de Usuario

Para el correcto uso del motor grá�co para representación de simulaciones es necesario

seguir los siguientes pasos.

A.1. Cargar Archivos necesarios

A través de la interfaz grá�ca, debemos seleccionar dos archivos, primero debemos car-

gar el archivo que contiene los datos de la ciudad y después el que contiene la simulación,

en la �gura A.1 podemos ver dicha interfaz:

Figura A.1: Diseño de la interfaz encargada de cargar los archivos.

Como se aprecia, es una interfaz simple pero práctica, con dos botones, uno para cada

archivo y con un texto que nos indica la ruta que hemos elegido donde se encuentra cada

uno de ellos.

i

APÉNDICE A. MANUAL DE USUARIO

A.2. Comenzar Visualización

Lo siguiente es poder empezar la visualización, si observamos la imagen A.1, podemos

ver otro botón grande para esta función. Una vez pulsado se abre una nueva ventana con

la visualización iniciada a través del motor jme3.

Figura A.2: Ventana con simulación iniciada.

A.3. Acciones del usuario

Para �nalizar, también es posible interactuar con la visualización a través de una

interfaz interna con la que el usuario puede parar la simulación, hacer el seguimiento de

un coche o directamente ocultar los edi�cios porque le molestasen para ver a los vehículos.

Dichas acciones pueden hacerse dos maneras, a través de los botones que facilita la interfaz

o pulsando alguna tecla:

En el recuadro rojo de la �gura A.3 se ve claramente esta interfaz, con las funciones ya

mencionadas, en cualquier momento se puede parar la simulación usando el primer botón

y reanudarla volviendo a hacer clic sobre él. También es posible realizar la misma acción

pulsando la tecla P.

ii


Figura A.3: Interfaz Grá�ca de Usuario.

Se consideró interesante, poder seguir a un coche en vista casi de piloto para ver el

recorrido y su comportamiento, si pulsamos el botón seguir coche o pulsamos la tecla C,

se cambia de la vista aérea a una de seguimiento como podemos observar en la imagen

A.4. Si seguimos realizando esta acción a seguir a un coche distinto en caso de existir.

Figura A.4: Camara de seguimiento.

Ocultar los edi�cios también fue implementado ya que muchas veces en la vista aérea

estorban a la hora de poder ver a ciertos coches, así que si pulsamos el botón se puede

apreciar como desaparecen (�gura A.5). La tecla H tiene la misma función.

iii


Figura A.5: Edi�cios ocultos.

Una vez terminada la simulación, se puede pulsar la tecla Escape o el botón con

una x situado arriba a la derecha para cerrar el programa. La ventana para elegir los

archivos seguirá abierta por si se quiere volver a ver o cargar otra simulación y/o ciudad

distinta. Cuando hayamos terminado totalmente, pulsaremos el botón con una x en la

esquina superior del programa o la opción de Salir en el menú Archivo para cerrarlo

completamente.

iv

PROYECTO FIN DE CARRERA - URJC

Documents

Transcript of PROYECTO FIN DE CARRERA - URJC