Hacer Proyecto - Español

DEPARTAMENT D'INFORMÀTICA
UNIVERSITAT JAUME I
E80
PROYECTOS INFORMÁTICOS
INGENIERÍA INFORMÁTICA
Curso 2005-2006
Memoria Técnica del Proyecto
VISITA VIRTUAL INTERACTIVA

A LA UNIVERSITAT JAUME I
Proyecto presentado por el Alumno:
Emilio José Molina Cazorla
Dirigido por Óscar Belmonte
Castellón, a 22 de Septiembre de 2006

E80-Proyectos informáticos 22/07/2006
1
2
RESUMEN
Este documento técnico explica la implementación de una visita virtual interactiva a la

Universitat Jaume I sobre el motor de juegos de Blender, ampliado con scripts en Python
para aumentar sus funcionalidades.
El objetivo es obtener una representación medianamente detallada del exterior de la
Universidad y del interior de alguno de sus edificios, por la que se pueda navegar
interactivamente. Parte de la interactividad consiste en poder seleccionar con el ratón una
serie de ítems de información dispuestos a lo largo de los escenarios, que nos permitirán
acceder a una página web con contenido relacionado (información institucional, del
profesorado, etc.).
A partir de la recogida de material gráfico de la Universidad, y de información acerca
de Python y del motor de juegos de Blender, se creará un mundo virtual resultante de la
integración del modelado de la Universidad con la ampliación de las características del
motor de juegos que su interfaz con Python nos permite.
Los resultados han sido completamente satisfactorios bajo un entorno GNU/Linux,
obteniendo un sistema con una gran potencialidad de expansión en futuros proyectos.
PALABRAS CLAVE
Blender, Game Engine, Visita Virtual, Interactividad, web
3
4
ÍNDICE
1. Introducción general. 7
1.1. Objetivos del proyecto. 7
1.2. Descripción del entorno general del proyecto. 7
2. Descripción del proyecto. 11
2.1. Introducción. 11
2.2. Descripción técnica del proceso del proyecto. 12
2.2.1. Información inicial. 12
2.2.2. Estimación de recursos. 13
2.2.3. Planificación de tareas y temporal. 15
2.2.4. Procesos y actividades intermedios. 19
2.2.5. Resultado final. 20
2.2.6. Aplicación práctica. 21
3. Conclusiones. 23
4. Posibles extensiones del proyecto. 25
5. Referencias. 27
Anexo A. Estructura global 29

Anexo B. Scripting 34
B1. VerRaton 34
B2. leearchivo 35
B3. PonSensor 36
B4. Navega 38
B5. Pos 39
Anexo C. Requerimientos y bugs conocidos 40
5
6
1. INTRODUCCIÓN GENERAL.
En este primer apartado aportaremos una visión global acerca de la propuesta de este
proyecto. ¿Por qué una visita virtual (otra más) a la UJI? ¿Por qué con Blender [dBW]? ¿Por
qué con su motor de juegos [dGN]?
1.1. OBJETIVOS DEL PROYECTO.
El principal objetivo de este proyecto es servir como proyecto base para futuros
programas independientes o incrustados en navegadores que permitan visitar virtualmente
la Universidad Jaume I de forma interactiva y para cualquier plataforma informática, y
obtener información vía web acerca de los edificios, los laboratorios, el profesorado, etc.,
así como almacenar información web propia.
Como comentaremos más adelante, las ventajas de este proyecto con respecto a
otros son su capacidad multiplataforma (Blender y Python tienen versiones para las más
diversas plataformas) y su facilidad de extensión por personas sin conocimientos de
programación. En otras palabras, su mayor accesibilidad.
1.2. DESCRIPCIÓN DEL ENTORNO GENERAL DEL PROYECTO.
Hoy en día existe un amplio abanico de herramientas con las que construir recorridos
virtuales interactivos: podemos recurrir al lenguaje VRML, a Java, o utilizar motores de
juegos como Crystal Space, OGRE o similares.
Los dos primeros nos ofrecen la ventaja de su posible integración en un navegador
mediante plugins. Los últimos, sus potentes características gráficas.
¿Por qué, entonces, elegir el motor de juegos de Blender?
Para comenzar, habría que hacer una breve introducción a la historia de uno de los
programas insignia del Software Libre. Después de que la Free Software Foundation
comprara sus derechos a la quebrada compañía de videojuegos Not A Number para liberar
7
sus fuentes, Ton Roosendall, su programador original, continuó liderando su desarrollo en
una comunidad de cada vez más usuarios que lo elegían por sus amplias prestaciones y
bajos requisitos (la versión liberada, la 2.25, condensaba herramientas de modelado,
animación, texturizado, renderizado y composición básicas, además del motor de juegos,
todo esto multiplataforma, en apenas 2MB).
Su evolución se disparó, comenzando a ofrecer una cada vez más seria alternativa a
costosos programas estándar de la industria infográfica de la talla de 3DStudio Max o Maya.
A día de hoy, se están llevando a cabo varias producciones cinematográficas que lo
utilizan en parte o la totalidad de su producción, a raíz de las mejoras aportadas por el
proyecto “Orange”. Y su historia apenas acaba de comenzar.
El motor de juegos de Blender (llamado Ketsji), pese a llevar con el programa desde
sus inicios, no ha tenido tanta atención, desafortunadamente. A diferencia del resto de
motores de juegos del mercado (a excepción del VirTools [dVW]), no requiere
necesariamente de una sola línea de programación para poder utilizarlo. Su sistema de
“ladrillos lógicos” permite conectar como en un “une con flechas” tres columnas de
sensores, controladores y actuadores, respectivamente, para cada objeto de la escena.
Cuando se “juega”, cada objeto evaluará los eventos que recibe (los detallaremos con
mayor profundidad más adelante) y llevará a cabo un determinado acto. Pero como añadido
a este uso minimalista, se pueden ampliar infinitamente sus prestaciones con su integración
[dGLD] con el lenguaje de Python [dPW], que permite controlar cualquier aspecto del juego.
Por si fuera poco, existe un plugin [dCP] (descontinuado durante un tiempo) que permite
“jugar” desde un navegador.
Considerado durante mucho tiempo como una característica más que ya cumplía con
su función y cuyo desarrollo no era prioritario (ni debía incidir negativamente en el peso del
programa, para mantener su livianez), ha estado estancado (e incluso en ocasiones dejado
de lado) a lo largo de su historia reciente.
Pero como se aprecia en la Figura 1, una de las transparencias de la presentación de
las novedades del programa en el Siggraph 2005, las cosas iban a empezar a cambiar. Las
últimas implementaciones dejan al motor de juegos con las siguientes características [dBN]:
8
● sistema de visualización simple por frustrum culling

● soporte programación de píxel shaders [dGL]
● posibilidad de crear pantallas divididas
● biblioteca de físicas ODE (dinámicas, colisiones, simulaciones físicas...)
● uso de esqueletos y materiales nativos de Blender
● múltiples canales UV
● posibilidad de dividir la pantalla en varias
● iluminación por los dos lados de una cara
● ordenación de caras para alpha testing
● uso de sonido 3D (surround y efecto Doppler)
● múltiples sensores, controladores y actuadores
Figura 1. Presentación de las novedades de Blender en el Siggraph 2005
9
Acerca de la elección de una visita virtual, son bastantes los proyectos que se han
centrado en ella. Las ventajas de utilizar el motor de gráficos de Blender es que, para
modificar tanto los escenarios como la lógica, no se necesita un programa de modelado
distinto del que exportar objetos (ni, como decíamos antes, se necesita saber programación
para realizar cambios simples). Todo lo necesario está en la misma herramienta, con lo que
el flujo de trabajo se vuelve más ágil y asequible a casi cualquiera con mínimos
conocimientos de grafismo.
Dado que la Universidad forma parte de un entorno cambiante, el proyecto también es
en cierta forma abierto, inconcluso, permitiendo la aportación de cualquiera que quiera
expandir los escenarios (o adaptarlos para utilizarlos en juegos, por ejemplo).
10
2. DESCRIPCIÓN DEL PROYECTO.
A continuación haremos un repaso pormenorizado a la implementación del proyecto,

explicando su composición, los requerimientos de recursos logísticos y temporales, cómo se
ha llevado a cabo finalmente, y cuál ha sido el ajuste del resultado obtenido con respecto al
esperado. Además, se plantean entornos de uso prácticos para el mismo.
2.1. INTRODUCCIÓN.
El proyecto se trata la visualización de un escenario (bien incrustado en un navegador,

bien como aplicación “stand alone”, o incluso como archivo de Blender cargado desde el
mismo programa) que representa la Universidad Jaume I. Además, mientras se pasea
interactivamente por el exterior (y el interior de alguno de sus edificios), permite seleccionar
con el ratón determinados ítems de información dispuestos sobre el escenario, que
provocan la apertura de una página web con contenido relacionado.
Esta información puede ser genérica de la universidad, relativa a cada edificio en
concreto, o centrarse en información específica (profesorado, actividades, ocio...). Cada
escenario distinto tiene su propio grupo de ítems, que se almacenarán físicamente en un
archivo por cada uno de los escenarios.
Dichos ítems no son necesarios para la navegación por el escenario, de forma que
aún se puede disfrutar de un simple recorrido si se prescindiera de los archivos con la
información.
Como ejemplo de uso en una situación normal, en la Figura 2 observamos la entrada
de la Escola de Tecnologia i Ciències Experimentals. Al pulsar sobre una “i” palpitante (el
ítem que nos indica que es una zona con información), se nos abre un navegador con la
dirección http://www.estce.uji.es.
11
Figura 2. Vista de la entrada de la ESTCE.
2.2. DESCRIPCIÓN TÉCNICA DEL PROCESO DEL PROYECTO.
El desarrollo del proyecto ha tenido diversos contratiempos desde sus inicios hasta su
finalización (aunque, como ya quedó dicho, no hay finalización como tal). En los siguientes
apartados se desglosa la evolución del proyecto.
2.2.1. INFORMACIÓN INICIAL.
La idea del proyecto surgió en septiembre de 2004. Tras utilizar durante casi un año
Blender como suite 3D, en el ya extinto foro de Blender en castellano “Nicodigital” me
sugirieron utilizar el motor de juegos (parte que no había investigado antes) para realizar
una visita virtual.
Como aliciente, pretendía poder distribuir por el escenario puntos en los que se
pudiera obtener información adicional. Al no tener apenas contacto con Python, ni siquiera
era consciente de si la integración del lenguaje con el motor me permitiría la apertura de
navegadores, ni de cómo funcionaban, en general, los elementos del motor para trabajar
con ellos.
12
Sabía que necesitaría la construcción de un “walktrough” básico al estilo VRML, con

colisiones, movimientos, cambio de escenarios (para permitir entrar en uno de los edificios,
a efectos de demostración), un sistema de lectura de información desde un fichero y de
distribución de la información en tiempo real sobre objetos de Blender.
Esto implicaba de forma secundaria cómo plantearse el problema del modelado de la
universidad, de dónde obtener la información necesaria de malla, texturas, etc. (más
adelante veremos cómo se resolvieron estos aspectos).
Y, por supuesto, implicaba aprender Python.
2.2.2. ESTIMACIÓN DE RECURSOS.
Los recursos necesarios para acometer el proyecto se estimaron en:

● material de referencia necesario para aprender el uso básico Game Engine
● ídem con el lenguaje de programación Python
● información acerca de la Universidad (tanto para el modelado como para los
enlaces que se asignarán a los ítems)
● tiempo para todo lo anterior y resolver las posibles complicaciones
Para estimar el tiempo, hice dos supuestos en función de la densidad de materias del
curso 2004-2005:
1. Preparar el sistema de navegación del proyecto a comienzos del curso 2004-
2005, preparar el modelo a lo largo de dicho curso, y dar por finalizado el modelo
para pasar a los ajustes finales en agosto de ese mismo curso.
2. Preparar el sistema de navegación del proyecto a comienzos del curso 2004-
2005, preparar el modelo a lo largo de dicho curso y del siguiente, y dar por
finalizado el modelo para pasar a los ajustes finales en agosto de 2006.
En cuanto al equipo necesario, la mayor parte del peso del proyecto corre a cuenta de
la tarjeta gráfica. Mi equipo personal (AMD 1'2GHz, 500MB RAM, NVIDIA GFORCE4
13
MX440 64MB corriendo sobre GNU/Linux) sería suficiente, dadas las bajas exigencias de
Blender.
El software necesario sería el editor de imágenes GIMP para la preparación de

texturas, Blender para todo lo demás (modelado, texturizado, iluminación, animación,
creación de la lógica del motor de juegos y escritura de programas en python), el navegador
web Mozilla (o Mozilla Firefox), y las librerías de Python (>=2.3) y SDL (>=1.2).
El abordaje de un proyecto de esta magnitud es comparable a la de “E69 - Sistemas

Basados en el Conocimiento” o “E79 - Procesadores de Lenguaje”. De esta última
asignatura, además, me vendrían muy bien los conocimientos acerca del parseado de
archivos con formato, del uso de Python, y de la profundización en la programación
orientada a objetos (vista en “E28 - Lenguajes de Programación II”, y puesta en práctica en
“E54 - Estancia en Prácticas II”). De Sistemas Basados en el Conocimiento (y también “E31
- Robótica”) podría reutilizar los conocimientos de sensores y reactores, y el paso de
mensajes en un sistema distribuido.
“E17 - Diseño y Fabricación Asistida por Ordenador”, “E26 - Informática Gráfica” y
“E75 - Tratamiento de imágenes” suponen la base imprescindible sin la cual el proyecto
sería casi insondable. Informática Gráfica, por todo lo relacionado con el funcionamiento
interno del visualizador del motor, y de lo que es viable manejar en un proyecto así; Diseño
y Fabricación, por el desarrollo de las habilidades en la lectura de planos y la visión
tridimensional de las construcciones arquitectónicas. Tratamiento de imágenes, por los
conceptos a la hora de obtener y retocar el material de referencia. “E50 - Análisis y Diseño
de Sistemas de Información II”, “E77 - Gestión de Recursos de Información” y “E79 -
Ingeniería del Software” para todo lo relacionado con la planificación, diseño del sistema y,
en especial, por las bases para inventarme un nuevo modelo de diagrama de Gantt algo
más ameno que el usual.
14
2.2.3. PLANIFICACIÓN DE TAREAS Y TEMPORAL.
La lista de problemas a resolver y tareas que realizar es la siguiente:

● modelado de la universidad (búsqueda de referencias y modelado en sí)
● aprendizaje del motor de juegos de Blender
● aprendizaje de Python (y de su API para el motor de juegos)
● implementación de pruebas
● ajustes de navegación
● creación de la documentación
El cuello de botella del proyecto está en el modelado de la Universitat Jaume I. Las

dos posibilidades existentes eran utilizar algún modelo ya existente, o modelar desde cero
el escenario. La primera opción supone utilizar mucho tiempo en “limpiar” una malla
probablemente poco preparada para un motor no demasiado potente en cuanto a
visualización (recordemos que sólo cuenta con “frustrum culling” como técnica de
aceleración). La segunda, encontrar las referencias y el material necesarios.
Mientras se buscan las referencias, se comienza con la búsqueda de referencias
acerca del API [dMH] de Python para Blender (es decir, cómo utilizar la extensión de
Python), y de Python per se.
Una vez conseguido esto, se implementan pruebas del sistema básico de navegación,
posicionamiento e interactividad en algún escenario simple, integrando los avances en un
escenario en desarrollo.
Dos meses y medio antes del tiempo marcado como tope, comienza la “cuenta atrás”:
se recopila la documentación generada en el desarrollo para confeccionar la memoria, y se
agota el tiempo disponible hasta la presentación para avanzar el estado del escenario y
ajustar el sistema de navegación a estos cambios.
Aunque el escenario no quede completamente finalizado, es un entorno cualquiera en
el que ensayar el sistema y que otra gente puede reconstruir desde cero con mejores
resultados. De cualquier forma, en el transcurso del tiempo estimado, la UJI sufriría
15
bastantes cambios (la biblioteca nueva, el nuevo centro de la FUE, las reformas del Ágora,
etc.), así que no es muy cabal preocuparse por ser totalmente fiel a la realidad en este
proyecto: basta con dar una idea de las posibilidades.
Dispuesto en forma de grafo, la distribución temporal de las tareas e hitos sería la
siguiente:
2004 2005/2006
SEP OCT NOV JUL AGO SEP
1 2 3 4 1 2 3 41 2 3 4 1 2 3 41 2 3 4 1 2 3 4
1- Aprendizaje del Game Engine 6- Ajustes del sistema de navegación

2- Aprendizaje básico de Python 7- Revisión del escenario principal
3- Implementación de pruebas 8- Mejora del modelado final
4- Documentación del proyecto 9- Entrega de la memoria del proyecto
5- Búsqueda de material gráfico Cerezas: presentación del proyecto
Figura 3. Distribución de tareas e hitos.
La discontinuidad representa la posibilidad de expansión temporal del proyecto según

las densidad del quinto curso de la carrera (consistirá en el posible empleo de un año extra).
Cada bola mágica representa un hito relacionado con la “calle” de su tarea, que a
continuación se detallan:
1. Aprendizaje del Game Engine: búsqueda de documentación acerca del
funcionamiento del motor de juegos, archivos de ejemplo, tutoriales, etc. Su hito
representa la implementación de la lógica básica del juego en el escenario
16
(movimiento, copia de objetos, cambio entre escenas, finalización, etc.).

2. Aprendizaje básico de Python: búsqueda de documentación sobre el lenguaje
de programación y tutoriales, seguido de la búsqueda de documentación del API de
Python del motor de juegos. Su hito representa la implementación de la lógica
avanzada del juego en el escenario (lectura y escritura de texto con formato desde
un fichero, modificación de propiedades de objetos en tiempo de ejecución, apertura
de un navegador, etc.).
3. Implementación de pruebas: desde el arranque del proyecto (simbolizado por
Pacman), y después de comprobar que el proyecto es viable (primer hito que
aparece), aplico a un escenario básico los conocimientos de Python y del motor de
juegos a medida que son adquiridos. Éste se irá convirtiendo en el modelo final a
medida que avance la tarea 5 (la búsqueda de material gráfico de la UJI). A partir de
la consecución del hito de la tarea 5, se seguirá desarrollando el modelo de la UJI
hasta llegar al segundo hito: el comienzo de la “cuenta atrás”. En lo sucesivo, el
modelado irá añadiendo mejoras a raíz de las nuevas referencias proporcionadas
por la tarea 7 (la revisión del escenario principal). El proceso “termina” con la
presentación del proyecto, si bien en realidad puede extenderse hasta el infinito.
4. Desde la comprobación de viabilidad del proyecto, hasta dos semanas antes de
la presentación del proyecto, se va llevando un registro de las actividades realizadas
y los contratiempos surgidos. Su hito relacionado es la consecución de esta
memoria.
5. La búsqueda de material gráfico (e información institucional para los ítems)
consiste en la recolección de referencias para el modelado y texturizado (o en la
búsqueda de un modelo ya hecho de la UJI) y en la recopilación de direcciones de
internet de cada edificio y parte del profesorado para asociar a los ítems de
información. Su hito relacionado es la recopilación de material suficiente para
comenzar con el modelado básico de la universidad.
6. Los ajustes del sistema de navegación son una consecuencia de la tarea de
mejora del escenario que se ejecuta en paralelo. Consiste en recolocar los ítems de
17
información donde deberían estar (por posibles cambios en la elevación del terreno),
las puertas, las animaciones que determinan las posiciones de salida de dichas
puertas...
7. La revisión del escenario principal es otra tanda de recogida de material gráfico
que sirva de referencia para un modelado más adecuado de algunas partes (rampas
de acceso, Ágora, escaleras...) que no estén suficientemente detalladas en las
referencias usadas para el modelo básico.
8. Como comentamos, a partir del punto de “cuenta atrás”, dedicaremos todo el
tiempo posible a mejorar el modelado para pulirlo visualmente, a partir de las
referencias que encontremos en la tarea 7.
9. Finalmente, tras la entrega de la memoria del proyecto, sólo quedará la
preparación de la presentación y los ajustes finales del modelado.
Los fantasmas hacen referencia a la alta posibilidad de encontrarme con algún tipo de
problema al hacer esa tarea:
● El fantasma cyan (Inky) representa las posibles complicaciones a la hora de
obtener, o bien el modelo de la universidad, o las referencias necesarias para
modelarlas.
● El fantasma rojo (Blinky) supone el retraso que la carga de todo quinto de
carrera y Procesadores puede acarrear en la realización del proyecto.
● El fantasma rosa (Pinky) representa los problemas que pueden aparecer al
buscar referencias para convertir el modelo básico en uno más apurado.
● Y el fantasma naranja (Clyde), que son las dificultades (principalmente por
tiempo, pero también por dificultades técnicas) que pueden surgir durante la
implementación de dicho modelado.
18
2.2.4. PROCESOS Y ACTIVIDADES INTERMEDIOS.
Se pueden resumir en los siguientes:

1. Aprendizaje del funcionamiento de la lógica del motor
2. Aprendizaje de Python
3. Búsqueda del material gráfico
La primera tarea fue entender el funcionamiento de los ladrillos lógicos del motor de
juegos. Como ya comentamos, este sistema permite conectar como en un “une con flechas”
tres columnas de sensores, controladores y actuadores, respectivamente, para cada objeto
de la escena. Cuando se “juega”, cada objeto evaluará los eventos que recibe (los
detallaremos con mayor profundidad más adelante) y llevará a cabo un determinado acto.
El resumen del funcionamiento es el siguiente:
● La columna de sensores consta, por mencionar algunos de los más
importantes, de sensores de teclado, ratón, colisiones, intersección con un rayo
lanzado y mensajes recibidos.
● La columna de controladores permite efectuar operaciones booleanas simples
(AND, OR) con las entradas de los sensores, expresiones complejas con dichas
entradas combinadas con propiedades del objeto, o lanzar scripts de Python que
manejen a más bajo nivel los parámetros de los sensores y permitan acciones
avanzadas.
● La columna de actuadores son los que ejecutarán la acción asociada a los
eventos: mover un objeto, crearlo, modificarlo, reproducir una animación, un sonido,
cambiar de cámara, de escena, modificar propiedades del objeto, enviar mensajes a
otros objetos...
De forma paralela, el aprendizaje de Python fue compartido con la asignatura de
Procesadores, que resultó más que suficiente para manejarme con desenvoltura por el
sistema de clases, métodos, instancias y propiedades de los objetos del motor, amén del
parseado de ficheros con los datos necesarios.
19
En cuanto a la búsqueda del material gráfico, desde el departamento de gráficos se
me propuso establecer contacto con un alumno que tenía un modelo en CAD de la UJI.
Aunque Blender es capaz de importar dicho formato de forma nativa, la estructura
resultante suele estar bastante “sucia”, y para un motor poco potente sería deseable contar
con el mínimo número de polígonos posible.
Durante la Jornada de Puertas Abiertas de 2004, pude hacerme con un recortable de
la UJI que el Servei de Comunicacions había publicado. Parecía factible escanear las
páginas y “reconstruir” el recortable directamente en 3D, utilizando las ilustraciones como
textura, de forma que me decidí por esta vía. A buen seguro necesitaría material adicional si
intentara conseguir una representación más fidedigna (la maqueta no recogía, por ejemplo,
los desniveles del terreno), pero relegaría esta fase a un punto más avanzado del proyecto,
si tenía el tiempo suficiente.
También necesitaría el plano con información de la distribución de la segunda planta
del edificio de despachos. Fue bastante complicado obtenerlo, por alguna extraña reticencia
de la secretaria que lo custodiaba clavado en su corcho, pero tras varias llamadas
conseguiría hacerme con él.
Llegado al punto en el que necesitaría más información de la que me ofrecía el
recortable y mi propia memoria, utilizaría una cámara de vídeo propia y haría algo de
trabajo de campo para recoger referencias de toda la Universidad (y en particular de la
segunda planta del edificio de despachos, de la que no tenía ninguna textura para usar).
2.2.5. RESULTADO FINAL.
No sólo aparecieron todos los fantasmas que se esperaban, sino que hubo uno extra.
Como ya he comentado, fue complicado obtener las primeras referencias, el proyecto se
demoró a causa de las otras asignaturas (y Procesadores), fue complicado obtener las
referencias para mejorar el modelado, no tuve tiempo de incorporar todas las mejoras, y
durante tres semanas de agosto de 2006, Telefónica no me permitió el acceso a internet.
Aún así, las pruebas con el modelo básico han acabado siendo perfectamente
20
funcionales. Podemos navegar con fluidez (si se dispone de aceleración OpenGL por
hardware) por el escenario principal (la parte externa de la Universidad), y entrar por las
puertas laterales del edificio de despachos para acceder a su interior. En ambos escenarios,
al pinchar sobre los elementos de información, se abrirá una página web que apunta al
enlace deseado.
Al tener por separado los archivos con la información de la posición y enlaces web, se
puede gestionar de forma simple la información, para tenerla actualizada.
Como extra, se incorpora una vista de pájaro, y se ha dejado habilitada la posibilidad
de incorporar puntos de control donde el usuario quiera, ejecutándolo desde consola y
pulsando “i” (la consola pedirá la dirección web a la que se quiere hacer referencia).
Figura 4. Vista de pájaro.
Se ha detectado que, en ocasiones, los eventos disparadores se activan por error más
de una vez (por ejemplo, al pulsar la “m” para activar el mapa), sin conseguir una solución
“limpia” para evitarlo.
2.2.6. APLICACIÓN PRÁCTICA.
La visita virtual interactiva con posibilidad de acceder a información web puede

permitir, por ejemplo, que cualquier persona que quiera conocer el aspecto y las
capacidades de la Universidad pueda acceder a ellas de forma intuitiva y entretenida. Se
21
puede entregar a comienzo de curso a los alumnos, para que conozcan los distintos
departamentos y edificios, laboratorios y profesorado. O, una vez que avance el plugin para
web, exponerlo directamente en la web de la universidad, como servicio multimedia extra.
22
3. CONCLUSIONES.
Éste ha sido, con diferencia, el proyecto de mayor magnitud en el que me he

embarcado. Como novato en estas lides, he cometido algunos errores de diseño y de
realización, de los que espero haber aprendido.
Empezar de cero el modelado de la UJI, no siendo éste el objetivo del proyecto, me ha
ocasionado dolores de cabeza y pérdidas de tiempo totalmente evitables, amén de
quedarme con el mal regusto de no haber sacado todo el jugo que podría habérsele sacado
a las texturas y al modelado.
Pero no todos los problemas han sido para mal; durante el proceso, descubrí y reporté
[dBT] un bug del Game Engine que afectaba a todas las versiones de Blender posteriores a
la 2.36 (con la que me vi obligado a realizar el proyecto), consistente en que el sensor
“Mouseover” (que se activa cuando el ratón está por encima del objeto que tiene dicho
sensor) no funcionaba con objetos duplicados desde otras capas (en mi caso, el objeto con
forma de “i” para representar la información). Al parecer, ha sido resuelto en la reciente
2.42.
Si comenzara de nuevo el proyecto, colaboraría más cercanamente con el equipo de
Gráficos de la Universidad, para utilizar algún modelo que ya existiera y estuviese pensado
para un motor de juegos. O, si me decantara por modelarlo de nuevo, lo haría de forma que
se pudieran reutilizar las texturas (es el grueso del peso en megabytes del programa).
Al final, Procesadores me ha dejado como subproducto una visión de Python y de la
orientación a objetos que me ha resultado imprescindible para el proyecto. De hecho, la
parte informática ha sido la más llevadera del proyecto y estuvo lista en pocas semanas.
También he podido constatar que la falta de constancia (con grandes periodos de
inactividad entre momentos de desarrollo) es muy perjudicial para el estado anímico con
respecto al proyecto. Los ánimos decaen casi exponencialmente con el tiempo. Creo que
hubiera sido mejor para mí el concentrar todo el esfuerzo en dos meses exclusivos de
desarrollo.
23
24
4. POSIBLES EXTENSIONES DEL PROYECTO.
Sin duda, ésta es la parte más interesante. A pesar de lo limitado de la puesta en

práctica de la idea, su potencialidad es inmensa.
Aparte de la obvia extensión de la actualización y adición del exterior e interior de
todos los edificios, hay incontables mejoras gráficas que pueden añadírsele, sin repercutir
en las necesidades gráficas de la máquina. Por ejemplo:
● Simulación de iluminación global, por trazado de rayos incorporada en la
textura (con el plugin para Blender BrayBaker [dBB]) o por radiosidad en la
información de Vertex Color (o ambas)
● Efecto de animación del agua de las fuentes con una animación de su textura.
● Remapeado del modelado para reutilizar más texturas de mayor calidad.
Con un modelado más ajustado a la realidad, se podría utilizar incluso para que una
persona en silla de ruedas pudiera estudiar la viabilidad de acceso a los distintos edificios
(dónde están situados los escalones, rampas, ascensores...).
En cuanto a la parte de programación, el proyecto se puede ampliar incorporando
funciones de búsqueda, para que nos indique por dónde se va a un determinado edificio o
despacho.
Podemos convertir con pocos cambios este proyecto en un videojuego de carreras, de
disparos, en un “Survival Horror” (alumnos persiguiendo a profesores con motosierras o
viceversa)...
Figura 5. Escape from the UJI.
25
También se pueden crear muy fácilmente recorridos de cámara que guíen al
espectador a los lugares que deseemos, manteniendo la interacción pero limitando el
movimiento. Esto puede servir para presentaciones de todo tipo, para indicar el típico “cómo
llegar” a un lugar durante un evento y similares.
26
5. REFERENCIAS.
[dBB] Blender Raytrace Baker. Web de descarga del plugin. http://alienhelpdesk.com/index.php?id=22. Website.
[dBN] Blender News. Web de actualizaciones de Blender. http://www.blender3d.org/cms/Blender_2_41.731.0.html. Website.
[dBT] Blender Bugtracker. Web de reporte de errores de Blender.
http://projects.blender.org/tracker/?func=detail&atid=306&aid=4522&group_id=9. Website.
[dBW] Blender Website. Página principal de la Blender Foundation. http://www.blender3d.org. Website.
[dCP] ContinousPhysics. Web del plugin ActiveX. http://continuousphysics.com/Blender2.42Webplugin.html. Website.
[dGL] GL Shader Reference. Web de documentación para la programación de shaders de OpenGL para el motor.
http://download.blender.org/documentation/242GE_Docs/glsl.html. Website.
[dGLD] Game Logic Documentation. Documentación de los módulos del motor de juegos de Blender.
http://www.blender.org/documentation/pydoc_gameengine/PyDoc-Gameengine-2.34/index.html. Website.
[dGN] Game Blender News. Web oficial de noticias del motor. http://www.gameblender.org/modules/news/. Website.
Documentación oficial del motor de juegos de Blender.
http://www.blender3d.org/documentation/intranet/docs/develop/gameengine_high_level/index.html. Website.
[dMH] Module Hierarchy. Vista de la jerarquía de módulos del motor de juegos de Blender, y su interfaz con Python.
http://www.blender.org/documentation/pydoc_gameengine/PyDoc-Gameengine-2.34/trees.html. Website.
[dPW] Python Website. Página oficial del lenguaje de programación de Python. http://www.python.org/. Website.
[dVW] VirTools Website. Página de la empresa VirTools. http://www.virtools.com/. Website.
27
28
ANEXO A. Estructura global.
El fichero de blender se compone de dos escenarios (el exterior de la Universidad y el

interior del edificio de despachos). Para el buen funcionamiento del sistema, es necesario
que las partes del escenario visible estén en la capa 1 (las demás se reservan para
acciones especiales). Además, cada escenario deberá contar con:
● El objeto que represente la información en la capa 2, con una propiedad de tipo
String llamada “direccion”. No necesita estar inicializada, aunque en el modelo se ha
hecho a la dirección www.uji.es. Tiene asociado un actuador de animación (que
reproduce en ping-pong un cambio de tamaño) y dos sensores de ratón que activen
el script “Navega” (véase el Anexo B4) al hacer click sobre el objeto.
● Un “empty” (un objeto sin representación) con:

○ una propiedad de tipo Int llamada “pos” e inicializada a cero. Esta propiedad
almacenará el número de “i” añadido.
○ un sensor de tipo “always” que se ejecutará una vez por ciclo, con un
controlador que llama al script “PonSensor” (véase el Anexo B3) y conectado a
un actuador de tipo Edit Object, con sus parámetros preparados para que el script
pueda usarlo para añadir objetos de tipo “i” en las posiciones adecuadas.
● Necesitaremos un objeto por cada puerta (en el proyecto he utilizado planos

con la opción “invisible” marcada en su modo de dibujado UV), con un sensor de
colisión enlazado a un controlador simple, y éste enlazado a dos actuadores:
29
○ uno de tipo “Scene”, que hará un “Set Scene” del escenario al que
queramos ir (en nuestro caso, EdificioX si estamos en Ujiland, o Ujiland si
estamos en EdificioX).
○ uno de tipo “Message”, para enviar a todos los receptores la información de
por qué puerta entramos (al cargar la escena nueva, se colocará la cámara en la
posición oportuna).
● Un “empty” (que será el usuario principal) emparentado a una cámara (para

que se mueva con el usuario) con los siguientes enlaces (a continuación se
desgranan por secciones, pero primero ofrezco una vista completa):
○ En sus propiedades tendrá que estar marcado “Actor” (ya que será un
objeto móvil al que queremos que afecten las físicas) y Dynamic (para habilitar
físicas avanzadas, como gravedad o fricción). Los parámetros de masa, gravedad
y fricción han sido estimados por ensayo y error.
○ Una propiedad booleana llamada “mapa” e inicializada a False, que indicará
internamente si el mapa está activado o no.
○ Una propiedad de tipo Int llamada “pos” inicializada a cero, que indicará a la
30
lógica en qué posición del escenario se ha de colocar (usada al volver de otros

escenarios).
○ Un sensor de tipo Always enlazado a los controladores de script “VerRaton”
y “leearchivo” (véase los Anexos B1 y B2) que se activará una única vez al
cargarse la escena.
○ Sensores de teclado para el movimiento, enlazado a sendos controladores y

actuadores. En dichos actuadores, el movimiento se ha transformado en fuerzas
de torsión o de empuje, en lugar de simples desplazamientos o rotaciones, con
objeto de obtener movimientos más fluidos (de nuevo, con valores
experimentales).
31
○ Sensores de teclado para otras acciones como salir de la visita, ver el mapa
o insertar un nuevo ítem de información. El sensor para insertar ítems sólo
necesitará conectarse a un controlador de tipo Python, que llamará al script “Pos”
(véase el Anexo B5). El actuador para el mapa modificará la propiedad llamada
“mapa”, de forma que necesitaremos sensores adicionales para gestionar esta
propiedad de forma adecuada:
○ Sensores de recepción de mensajes y de parámetros para colocarnos en el

lugar adecuado; el objeto puerta con el que colisionemos en el escenario será el
que envíe el mensaje al usuario en este escenario, al que asociaremos un valor
para la propiedad “pos” del usuario. Para colocarnos en el lugar adecuado,
ordenaremos al actuador adecuado que reproduzca un frame de animación
determinado, que previamente habremos preparado (insertando un keyframe en
dicho frame) colocando al usuario con la posición y rotación deseadas.
32
● Por último, cada escena necesitará una cámara para una vista de mapa con el
nombre que le hayamos asignado en el actuador correspondiente del usuario (el
nombre de la cámara de usuario también deberá corresponder con el nombre
asignado en el otro actuador).
33
ANEXO B. Scripting.
B1. VerRaton
Este simple script importa el módulo de rasterizado del Game Engine y activa la
opción de mostrar el ratón:
import Rasterizer
Rasterizer.showMouse(1)
34
B2. leearchivo
Este script se encarga de leer un archivo de una o más líneas con el formato:
'posición_en_X, posición_en_Y, posición_en_Z', 'ruta_de_dirección_web'\n
y crea en el módulo de lógica una lista de tuplas (posición, información).

Se ejecutará cada vez que se inicie una escena, buscando un fichero de información
cuyo nombre coincida con el de la escena de Blender.
import GameLogic as GL
GL.informacion=[]
try:
f=open(GL.getCurrentScene().getName(),"r")
a=f.readline()
while (a!=""):
a=a[:-1].replace("'","").split(",")
GL.informacion.append( [ [ float(a[0]), float(a[1]), float(a[2]) ] , a[3][1:] ])
a=f.readline()
f.close()
except:
pass
#Si no existe el archivo, no hacemos nada
35
B3. PonSensor
Al iniciarse la escena, un objeto (en nuestro caso, un “empty”) activará durante los
primeros ciclos un script para que todos los objetos de información se distribuyan por la
escena. El script se desactivará (desactivará el sensor que lo activa, para ser exactos)
cuando todos los objetos estén distribuidos. A continuación se amplía la explicación.
Cont = GL.getCurrentController()
Own = Cont.getOwner()
Sens = Cont.getSensors()[0] #primer sensor devuelto por la lista de sensores del objeto
Act = Cont.getActuators()[0] #ídem con los actuadores
pos=Own.pos
try:
max=len(GL.informacion)
if pos < max:

Own.setPosition(GL.informacion[pos][0])
GL.addActiveActuator(Act,1) # Activa el actuador
else:
Sens.setUsePosPulseMode(0) # Desactiva el sensor
LastObj = Act.getLastCreatedObject()
if LastObj:
LastObj.direccion=GL.informacion[pos-1][1]
LastObj.num=pos
Own.pos+=1
except:
pass
#Si no existe GL.informacion, no hacemos nada
Este script recuperará la información del diccionario de GL, que “leearchivo” (véase
Anexo B2) había creado, y activa el actuador para que se cree una copia del objeto
36
asociado (en nuestro caso, el modelo de la “i” para la información).

Dado que en un mismo ciclo no se puede acceder a los atributos del último objeto
creado, montamos un contador (con la ayuda de una propiedad “pos” en el “empty”) que se
incremente por ciclos.
Reiteradamente, colocaremos el objeto “i” en la posición deseada, crearemos una
copia, y asignaremos al objeto creado en la iteración anterior el atributo de dirección web
correspondiente de la lista de tuplas.
37
B4. Navega
Este script se encarga de abrir un navegador con la dirección web que el objeto de
información tuviera en su atributo “direccion” al pulsar sobre dicho objeto (es decir, cuando
sus sensores de ratón “Mouseover” y “Mouseclick” estén activos a la vez)
import webbrowser
import GameLogic
cont=GameLogic.getCurrentController()
owner=cont.getOwner()
mouseover=cont.getSensor("Mouseover")
click=cont.getSensor("Mouseclick")
if mouseover.isPositive() and click.isPositive():

webbrowser.open(owner.direccion)
38
B5. Pos
Este script se invocará cuando el usuario desee añadir sus propios ítems de
información.
En concreto, añadirá con el formato adecuado la información de la posición actual
(más un valor constante en el eje Z para que el objeto aparezca en el aire) y la dirección
web a un archivo que tenga el mismo nombre que la escena actual de Blender (o lo creará,
si no existe).
import sys
controller=GL.getCurrentController()
owner=controller.getOwner()
i=owner.getPosition()
i[2]=i[2]+1.5
sys.stdin.flush()
print "posicion: ",i
print "web: ",
sys.stdin.flush()
web=sys.stdin.readline()
if web[:-1]!="":
f=open(GL.getCurrentScene().getName(),"a")
i=str((str(i)[1:-1], web[:-1]))
f.write(i[1:-1])
f.write('\n')
print i
f.close()
39
ANEXO C. Requerimientos y bugs conocidos.
Se recomienda tener instalado Python y las librerías SDL, si bien se pueden

proporcionar individualmente. En concreto, se hace uso de los archivos python32.py,
webbrowser.py, y SDL.dll.
También es necesario tener una tarjeta gráfica con aceleración OpenGL por hardware.
El programa se ha testeado bajo GNU/Linux y bajo Windows, con dos bugs conocidos:
● En ocasiones, un sensor lanza señales de activación demasiado rápidas,
generando que un actuador se ejecute muchas veces. Por ejemplo, al tratar de
activar el mapa (bajo Linux y Windows) o al pinchar sobre un ítem de información
(sólo bajo Windows), en ocasiones cambia de cámara varias veces, o abre varios
navegadores con la dirección web.
● En algunos momentos, es posible atravesar partes supuestamente sólidas del
escenario.
Dado que ambos problemas son potestad del Game Engine, no se puede hacer
demasiado por solucionarlos.
40

Hacer Proyecto - Español

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Hacer Proyecto - Español

Diunggah oleh

Hak Cipta:

Format Tersedia

DEPARTAMENT D'INFORMÀTICA

Memoria Técnica del Proyecto

VISITA VIRTUAL INTERACTIVA

Proyecto presentado por el Alumno:

Emilio José Molina Cazorla

Dirigido por Óscar Belmonte

Castellón, a 22 de Septiembre de 2006

Este documento técnico explica la implementación de una visita virtual interactiva a la

Blender, Game Engine, Visita Virtual, Interactividad, web

Anexo A. Estructura global 29

1.1. OBJETIVOS DEL PROYECTO.

1.2. DESCRIPCIÓN DEL ENTORNO GENERAL DEL PROYECTO.

● sistema de visualización simple por frustrum culling

Figura 1. Presentación de las novedades de Blender en el Siggraph 2005

2. DESCRIPCIÓN DEL PROYECTO.

A continuación haremos un repaso pormenorizado a la implementación del proyecto,

El proyecto se trata la visualización de un escenario (bien incrustado en un navegador,

2.2. DESCRIPCIÓN TÉCNICA DEL PROCESO DEL PROYECTO.

2.2.1. INFORMACIÓN INICIAL.

Sabía que necesitaría la construcción de un “walktrough” básico al estilo VRML, con

2.2.2. ESTIMACIÓN DE RECURSOS.

Los recursos necesarios para acometer el proyecto se estimaron en:

El software necesario sería el editor de imágenes GIMP para la preparación de

El abordaje de un proyecto de esta magnitud es comparable a la de “E69 - Sistemas

2.2.3. PLANIFICACIÓN DE TAREAS Y TEMPORAL.

La lista de problemas a resolver y tareas que realizar es la siguiente:

El cuello de botella del proyecto está en el modelado de la Universitat Jaume I. Las

1- Aprendizaje del Game Engine 6- Ajustes del sistema de navegación

Figura 3. Distribución de tareas e hitos.

La discontinuidad representa la posibilidad de expansión temporal del proyecto según

(movimiento, copia de objetos, cambio entre escenas, finalización, etc.).

2.2.4. PROCESOS Y ACTIVIDADES INTERMEDIOS.

Se pueden resumir en los siguientes:

2.2.5. RESULTADO FINAL.

Figura 4. Vista de pájaro.

2.2.6. APLICACIÓN PRÁCTICA.

La visita virtual interactiva con posibilidad de acceder a información web puede

Éste ha sido, con diferencia, el proyecto de mayor magnitud en el que me he

4. POSIBLES EXTENSIONES DEL PROYECTO.

Sin duda, ésta es la parte más interesante. A pesar de lo limitado de la puesta en

Figura 5. Escape from the UJI.

ANEXO A. Estructura global.

El fichero de blender se compone de dos escenarios (el exterior de la Universidad y el

● Un “empty” (un objeto sin representación) con:

● Necesitaremos un objeto por cada puerta (en el proyecto he utilizado planos

● Un “empty” (que será el usuario principal) emparentado a una cámara (para

lógica en qué posición del escenario se ha de colocar (usada al volver de otros

○ Sensores de teclado para el movimiento, enlazado a sendos controladores y

○ Sensores de recepción de mensajes y de parámetros para colocarnos en el

'posición_en_X, posición_en_Y, posición_en_Z', 'ruta_de_dirección_web'\n

y crea en el módulo de lógica una lista de tuplas (posición, información).

if pos < max:

asociado (en nuestro caso, el modelo de la “i” para la información).

if mouseover.isPositive() and click.isPositive():

Se recomienda tener instalado Python y las librerías SDL, si bien se pueden

Anda mungkin juga menyukai