S we b 3 D in te ra c tivo p a ra - ujaen.es

Escue

la P

olitécn

ica

Sup

erio

r de

Jaé

n

Gra

do e

n In

geni

ería

Info

rmát

ica

UNIVERSIDAD DE JAÉN Escuela Politécnica Superior de Jaén

Trabajo Fin de Grado

Desarrollo de prototipo

web 3D interactivo para

la gestión y difusión de

patrimonio natural

Alumno: Guillermo Garrido Luque Tutor: Prof. D. Juan Roberto Jiménez Pérez

Prof. D. Francisco Javier Cardenal Escarcena

Dpto: Informática

Junio, 2018

Guillermo Garrido Luque Desarrollo de prototipo web 3D interactivo para

la gestión y difusión de patrimonio natural

2

Escuela Politécnica Superior de Jaén

Universidad de Jaén Escuela Politécnica Superior de Jaén

Departamento de Informática

Don Juan Roberto Jiménez Pérez y Don Francisco Javier Cardenal Escarena, tutores del Proyecto Fin de Carrera titulado: Desarrollo de prototipo web 3D interactivo para la gestión y difusión de patrimonio natural, que presenta Guillermo Garrido Luque, autorizan su presentación para defensa y evaluación en la Escuela Politécnica Superior de Jaén.

Jaén, Junio de 2018



3


Agradecimientos

Me gustaría dedicar este apartado de este documento a agradecer las

orientaciones y ayudas de los tutores de este proyecto, Juan Roberto Jiménez Pérez

y Francisco Javier Cardenal Escarcena.

También destacar que parte de los trabajos realizados han sido financiados por

el Centro de Estudios Avanzados en Ciencias de la Tierra (CEACTierra). Además,

por otro lado, la Consejería de Medio Ambiente y Ordenación del Territorio de la

Junta de Andalucía (Delegación Territorial de Jaén) ha facilitado los accesos al área

de trabajo del sector del Paraje Natural de la Cascada de La Cimbarra de la cual se

han extraído los modelos y datos sobre los cuales se ha trabajado.



4


Índice

1. Introducción .................................................................................................................... 14

1.1. Descripción de gráficos en la web ............................................................................. 15

1.2. Metodología ............................................................................................................... 17

1.3. Objetivos del proyecto ............................................................................................... 17

1.4. Resultados esperados ................................................................................................. 17

1.5. Estructura del documento .......................................................................................... 18

2. Análisis de perfiles de usuarios ..................................................................................... 19

3. Gestión y planificación ................................................................................................... 24

3.1. Metodología incremental ........................................................................................... 24

3.1.1. Definición metodología incremental .................................................................. 24

3.1.2. Ventajas de una metodología incremental ......................................................... 25

3.1.3. Aplicación de metodología incremental sobre el proyecto ................................ 26

3.2. Planificación temporal ............................................................................................... 27

3.2.1. Diagrama de Gantt ............................................................................................. 29

3.2.2. Diagrama Pert ..................................................................................................... 36

3.3. Gestión de costes ....................................................................................................... 37

3.3.1. COCOMO .......................................................................................................... 37

3.3.2. Recursos ............................................................................................................. 42

3.3.3. Conclusión de los costes necesarios ................................................................... 46

4. Análisis ............................................................................................................................. 48

4.1. Análisis de requisitos ................................................................................................. 48

4.1.1. Requisitos funcionales........................................................................................ 49

4.1.2. Requisitos no funcionales................................................................................... 54

4.1.3. Requisitos del cliente ......................................................................................... 55

4.1.4. Requisitos del servidor ....................................................................................... 56

4.1.5. Requisitos de rendimiento .................................................................................. 57

4.1.6. Requisitos de escalabilidad ................................................................................ 57

4.1.7. Requisitos de internacionalización ..................................................................... 58

4.2. Tecnologías basadas en WebGL................................................................................ 58

4.2.1. WebGL puro ....................................................................................................... 59

4.2.2. ThreeJS ............................................................................................................... 59

4.2.3. BabylonJS........................................................................................................... 60

4.2.4. WebGL con Unity3D ......................................................................................... 61

4.2.5. 3DHOP ............................................................................................................... 62

4.2.6. Otras ................................................................................................................... 63

4.2.7. Comparativa ....................................................................................................... 63



5


4.3. Solución escogida (3DHOP) ..................................................................................... 64

4.3.1. Descripción del software .................................................................................... 65

4.3.2. SpiderGL ............................................................................................................ 67

4.3.3. Preparación de modelos para 3DHOP ................................................................ 72

4.3.4. Nexus .................................................................................................................. 74

4.4. Web estática vs Web dinámica .................................................................................. 74

4.5. Responsive vs Adaptive............................................................................................. 77

4.5.1. ¿Porqué usar un diseño “adaptive web”? ........................................................... 78

4.5.2. ¿Porqué usar un diseño “responsive web”?........................................................ 79

4.5.3. Solución adoptada para este proyecto ................................................................ 79

4.6. Diagrama de casos de uso .......................................................................................... 81

4.7. Lenguajes de programación, servicios, librerías ....................................................... 83

4.8. Principales funciones a desarrollar en el proyecto .................................................... 84

5. Diseño ............................................................................................................................... 86

5.1. Patrón modelo-vista-controlador ............................................................................... 86

5.1.1. Patrón MVC en una aplicación gráfica .............................................................. 87

5.1.2. Patrón MVC en este proyecto ............................................................................ 88

5.2. Storyboard ................................................................................................................. 90

5.5. Diagrama de clases .................................................................................................... 95

5.7. Diagramas de actividad ........................................................................................... 101

5.7.1. Diagrama de actividad transformaciones geométricas ..................................... 102

5.7.2. Diagrama de actividad etiquetado informativo ................................................ 103

5.7.3. Diagrama de actividad etiquetado en mapa...................................................... 103

5.7.4. Diagrama de actividad animaciones predefinidas ............................................ 104

5.7.5. Diagrama de actividad interacción panorámica, entre otras............................. 105

5.7.6. Diagrama de actividad visualización con Unity ó ThreeJS + Nexus ............... 105

5.7.7. Diagrama de actividad cambiar modelo ........................................................... 106

5.7.8. Diagrama de actividad herramienta de cálculo de áreas .................................. 107

5.7.9. Diagrama de actividad herramienta creación de animaciones ......................... 107

5.7.10. Diagrama de actividad función añadir modelos ............................................... 108

5.7.11. Diagrama de actividad conversión de modelos para 3DHOP .......................... 109

5.8. Diagramas de secuencia........................................................................................... 110

5.8.1. Diagrama de secuencia transformaciones geométricas .................................... 111

5.8.2. Diagrama de secuencia etiquetado informativo ............................................... 112

5.8.3. Diagrama de secuencia etiquetado en mapa ..................................................... 113

5.8.4. Diagrama de secuencia animación predefinida ................................................ 113

5.8.5. Diagrama de secuencia interacción panorámica, entre otras............................ 114



6


5.8.6. Diagrama de secuencia visualización con Unity ó ThreeJS + Nexus .............. 115

5.8.7. Diagrama de secuencia cambio de modelo ...................................................... 116

5.8.8. Diagrama de secuencia herramienta de cálculo de áreas ................................. 117

5.8.9. Diagrama de secuencia herramienta de creación de animaciones.................... 118

5.8.10. Diagrama de secuencia función añadir modelos .............................................. 119

6. Implementación ..................................................................................................... 121

6.1. Organización del proyecto ....................................................................................... 121

6.2. Herramientas utilizadas ........................................................................................... 121

6.3. Funciones ................................................................................................................. 124

6.3.1. Creación de la escena ....................................................................................... 124

6.3.2. Iteración para la creación de un mapa de Google en la web ............................ 128

6.3.3. Iteración para mostrar información general de los modelos principales .......... 130

6.3.4. Iteración para la realización del sistema de etiquetado .................................... 131

6.3.5. Iteración para la función de cambio de modelo del canvas.............................. 134

6.3.6. Iteración para la función interacción panorámica ............................................ 134

6.3.7. Iteración para función de animaciones predefinidas ........................................ 135

6.3.8. Iteración para la herramienta de cálculo de áreas ............................................ 136

6.3.9. Iteración para etiquetado informativo meteorológico ...................................... 137

6.3.10. Iteración para la visualización con ThreeJS y Nexus y web adaptable ............ 138

6.3.11. Iteración para función de añadir modelos a la web (modo museo) .................. 139

6.3.12. Iteración para el multilenguaje ......................................................................... 140

6.3.13. Iteración para funciones con transformaciones geométricas ............................ 143

6.3.14. Iteración para visualización con Unity ............................................................. 145

6.3.15. Iteración para herramienta creación animaciones ............................................ 148

6.3.16. Iteración para la creación del modo simplificado con información real .......... 149

6.3.17. Otras funciones ................................................................................................. 150

7. Resultados y pruebas .................................................................................................... 152

7.1. Feedback usuarios.................................................................................................... 158

7.2. Opciones para probar la web ................................................................................... 162

7.2.1. Desarrollo local desde el navegador................................................................. 163

7.2.2. Instalación y configuración servidor web local................................................ 164

7.2.3. Instalación y configuración servidor remoto por internet ................................ 165

8. Conclusiones .................................................................................................................. 161

8.1. Aplicaciones de uso ................................................................................................. 171

8.2. Trabajos futuros ....................................................................................................... 172

Bibliografía ........................................................................................................................... 192

Anexo A: Índice de ilustraciones ............................................................................................ 8



7


Anexo B: Índice de tablas ...................................................................................................... 13

Anexo C: Manual de instalación ......................................................................................... 174

Anexo D: Manual de usuario............................................................................................... 177

Anexo E: Github Pages ........................................................................................................ 180

Anexo F: Almacenar información en un prototipo web ................................................... 182

Anexo G: Impresión 3D de modelos 3D ............................................................................. 185

Anexo H: Caché de los navegadores ................................................................................... 188

Anexo I: Prototipo con modelos 3D en OpenGL ES en iOS ............................................ 189



8


ANEXO A: Índice de ilustraciones

Ilustración 1.1- Historia tecnología Flash ................................................................................ 16

Ilustración 3.1- Diagrama metodología por incrementos ......................................................... 25

Ilustración 3.2- Diagrama de Gantt del proyecto ..................................................................... 35

Ilustración 3.3- Diagrama Pert del proyecto ............................................................................ 36

Ilustración 3.4- Diagrama de actividades general del proyecto ............................................... 37

Ilustración 3.5- Coeficientes COCOMO semi-libre ................................................................. 40

Ilustración 3.6- Valores utilizados para el cálculo de costes del proyecto ............................... 40

Ilustración 4.1- Requisito de visualización de modelos 3D en la web ..................................... 49

Ilustración 4.2- Requisito de interacción con modelos 3D en la web ...................................... 50

Ilustración 4.3- Requisito de etiquetado de modelos 3D en la web ......................................... 50

Ilustración 4.4- Requisito de etiquetado con información meteorológica de modelos 3D web

.................................................................................................................................................. 50

Ilustración 4.5- Requisito de realizar zoom in de modelos 3D en la web ................................ 50

Ilustración 4.6- Requisito de realizar zoom out de modelos 3D en la web .............................. 51

Ilustración 4.7- Requisito de cambiar la apariencia de modelos 3D en la web........................ 51

Ilustración 4.8- Requisito de realizar animación de ruta sobre modelos 3D en la web ........... 52

Ilustración 4.9- Requisito de realizar animación eje Y sobre modelos 3D en la web .............. 52

Ilustración 4.10- Requisito de pinchar sobre el modelo y ver las coordenadas del punto ....... 51

Ilustración 4.11- Requisito de medir distancias en modelo 3D en la web ............................... 52

Ilustración 4.12- Requisito de interactuar con el modelo 3D en la web .................................. 52

Ilustración 4.13- Requisito de crear animaciones sobre el modelo 3D en la web .................... 52

Ilustración 4.14- Requisito de medir superficies de modelo 3D en la web .............................. 52

Ilustración 4.15- Requisito de interacción con Unity ............................................................... 52

Ilustración 4.16- Requisito de visualizar el modelo 3D desde varias perspectivas.................. 53

Ilustración 4.17- Requisito de tener varios controles de interacción de modelos 3D en web .. 53

Ilustración 4.18- Requisito de visualización con ThreeJS ....................................................... 53

Ilustración 4.19- Requisito de usar la API de Google Maps .................................................... 53

Ilustración 4.20- Requisito de diferenciar parte de interacción de parte de información ........ 53

Ilustración 4.21- Requisito de gestionar diferentes modos en la web ...................................... 54

Ilustración 4.22- Requisito de no recargar la web cuando se produzca un cambio ................. 54

Ilustración 4.23- Requisito de que la web tenga una interfaz adecuada .................................. 54

Ilustración 4.24- Requisito de que la web use cookies ............................................................ 55

Ilustración 4.25- Requisito de que la web use almacenamiento local en el navegador ........... 55

Ilustración 4.26- Requisito hardware ....................................................................................... 56

Ilustración 4.27- Requisito software ........................................................................................ 56

Ilustración 4.28- Requisito de servidor .................................................................................... 57



9


Ilustración 4.29- Requisito de rendimiento .............................................................................. 57

Ilustración 4.30- Requisito de rendimiento 2 ........................................................................... 57

Ilustración 4.31- Requisito de compatibilidad de la web con diferentes navegadores ............ 58

Ilustración 4.32- Requisito de compatibilidad de la web con diferentes resoluciones ............ 58

Ilustración 4.33- Requisito de internacionalización de la web................................................. 58

Ilustración 4.34- Logotipo WebGL .......................................................................................... 59

Ilustración 4.35- Logotipo ThreeJS .......................................................................................... 59

Ilustración 4.36- Logotipo BabylonJS ..................................................................................... 60

Ilustración 4.37- Logotipo Unity .............................................................................................. 61

Ilustración 4.38- Logotipo 3DHOP .......................................................................................... 62

Ilustración 4.39- Arquitectura aplicación gráfica basada en OpenGL ..................................... 69

Ilustración 4.40- Arquitectura aplicación gráfica basada en WebGL enWindows .................. 70

Ilustración 4.41- Arquitectura aplicación gráfica estándar WebGL ........................................ 70

Ilustración 4.42- Arquitectura librería gráfica SpiderGL ......................................................... 71

Ilustración 4.43- Exportación de modelo 3D en MeshLab ...................................................... 73

Ilustración 4.44- Información uso internet según dispositivo .................................................. 78

Ilustración 4.45- Comparativa “adaptive web” vs “responsive web” ...................................... 78

Ilustración 4.46- Web adaptable imagen 1 ............................................................................... 79

Ilustración 4.47- Web adaptable imagen 2 ............................................................................... 80

Ilustración 4.48- Web visualizada en un móvil ........................................................................ 81

Ilustración 5.1- Esquema MVC ................................................................................................ 87

Ilustración 5.2- Storyboard página inicial ................................................................................ 91

Ilustración 5.3- Estado web tras activar herramienta medir distancias .................................... 91

Ilustración 5.4- Estado web cambio modelo 3D ...................................................................... 92

Ilustración 5.5- Estado web herramienta pick-point ................................................................ 92

Ilustración 5.6- Estado web animación ruta ............................................................................. 93

Ilustración 5.7- Estado web herramienta etiquetado ................................................................ 93

Ilustración 5.8- Estado web visualización Unity ...................................................................... 94

Ilustración 5.9- Estado web tras activar herramientas superficies ........................................... 94

Ilustración 5.10- Estado web etiquetado meteorológico .......................................................... 95

Ilustración 5.16- Diagrama de clases del proyecto .................................................................. 96

Ilustración 5.17- Diagrama de casos de uso del proyecto ........................................................ 97

Ilustración 5.18- Diagrama de actividad general del proyecto............................................... 102

Ilustración 5.19- Diagrama de actividad transformaciones geométricas ............................... 102

Ilustración 5.20- Diagrama actividad etiquetado ................................................................... 103

Ilustración 5.21- Diagrama actividad etiquetado información meteorológica ....................... 104

Ilustración 5.22- Diagrama actividad animaciones predefinidas ........................................... 105



10


Ilustración 5.23- Diagrama actividad de otras visualizaciones .............................................. 106

Ilustración 5.24- Diagrama actividad función cambiar modelo ............................................. 106

Ilustración 5.25- Diagrama actividad herramienta cálculo de áreas ...................................... 107

Ilustración 5.26- Diagrama actividad herramienta creación animaciones ............................. 108

Ilustración 5.27- Diagrama actividad función añadir modelos .............................................. 109

Ilustración 5.28- Diagrama actividad conversión modelos 3DHOP ...................................... 110

Ilustración 5.29- Diagrama secuencia general al cargar la web ............................................. 111

Ilustración 5.30- Diagrama secuencia transformaciones geométricas ................................... 111

Ilustración 5.31- Diagrama secuencia sistema etiquetado informativo.................................. 112

Ilustración 5.32- Diagrama secuencia animaciones predefinadas .......................................... 113

Ilustración 5.33- Diagrama secuencia interacción panorámica .............................................. 115

Ilustración 5.34- Diagrama secuencia de la visualización de Unity ...................................... 116

Ilustración 5.35- Diagrama secuencia cambio de modelo...................................................... 117

Ilustración 5.36- Diagrama secuencia herramienta cálculo áreas .......................................... 118

Ilustración 5.37- Diagrama secuencia herramienta creación animaciones ............................ 119

Ilustración 5.38- Diagrama secuencia herramienta añadir modelos ...................................... 119

Ilustración 6.1- Creación de instancias (modelos) en la escena 3DHOP ............................... 126

Ilustración 6.2- Creación de spots (etiquetas) en la escena 3DHOP ...................................... 126

Ilustración 6.3- Creación de un control en la escena 3DHOP ................................................ 128

Ilustración 6.4- Limitaciones de uso de una clave gratuita de Google Maps......................... 129

Ilustración 6.5- Obtención clave gratuita Google Maps ........................................................ 129

Ilustración 6.6- Creación mapa de Google con código JavaScript ........................................ 130

Ilustración 6.7- Código JS 3DHOP para controlar eventos del sistema etiquetado ............... 131

Ilustración 6.8- Método onPickedInstance en 3DHOP .......................................................... 132

Ilustración 6.9- Etiqueta en el método onPickedSpot de 3DHOP.......................................... 132

Ilustración 6.10- Código JS de la función de etiquetado en el método actionToolBar de

3DHOP ................................................................................................................................... 133

Ilustración 6.11- Código JS para reiniciar el canvas de la web.............................................. 134

Ilustración 6.12- Código JS de la función que controla los eventos de teclado en la web..... 135

Ilustración 6.13- Código de la función predefinida en el eje Y del modelo .......................... 136

Ilustración 6.14- Código de etiqueta de área en la función setInfoAnnotation de Cimbarra.js

................................................................................................................................................ 137

Ilustración 6.15- Código de inicialización de MeasureTool para Google Maps .................... 137

Ilustración 6.16- Código para acceder a la API openWeatherMap ........................................ 138

Ilustración 6.17- Código JS para crear alerta para insertar nombre de modelo a añadir en la

web ......................................................................................................................................... 140

Ilustración 6.18- Código JS para la insercción de un modelo gracias a cookies del navegador

................................................................................................................................................ 140



11


Ilustración 6.19- Código JS para actualizar el desplegable encargado de mostrar modelos

disponibles en la web ............................................................................................................. 140

Ilustración 6.20- Código JS para dividir las cadenas de texto para que se inserten

correctamente las cookies....................................................................................................... 141

Ilustración 6.21- Código JS para resetear y borrar las cookies del navegador ....................... 141

Ilustración 6.22- Árbol de objetos DOM HTML webpage .................................................... 142

Ilustración 6.23- Código JS para cambiar de texto de elementos HTML en una web ........... 142

Ilustración 6.24- Código JS para acceder al texto de un idioma ............................................ 143

Ilustración 6.25- Código JS función setScalingFactorInstanceModelByName ..................... 144

Ilustración 6.26- Código JS función setRotationFactorInstanceModelByName ................... 145

Ilustración 6.27- Editor Unity abierto con el proyecto de la Cimbarra en Unity ................... 146

Ilustración 6.28- Código JS para guardar elementos en el almacenamiento local del navegador

................................................................................................................................................ 148

Ilustración 6.29- Código JS para acceder a elementos en el almacenamiento local del

navegador ............................................................................................................................... 148

Ilustración 6.30- Resultado de la web en el servidor CEACTierra con información real ...... 149

Ilustración 6.31- Código JS para el método onEndMeasure de 3DHOP ............................... 150

Ilustración 6.32- Código JS para el método onEndPick de 3DHOP ...................................... 151

Ilustración 7.1- Mapa de Google de la web del proyecto....................................................... 152

Ilustración 7.2- Prototipo web con la zona informativa remarcada ....................................... 153

Ilustración 7.3- Prototipo web con la zona informativa remarcada 2 .................................... 153

Ilustración 7.4- Prototipo web cambiando de modelo principal ............................................ 154

Ilustración 7.5- Herramienta de cálculo de superficies sobre modelo en la web ................... 155

Ilustración 7.6- Prototipo web con el sistema de etiquetado con información meteorológica

................................................................................................................................................ 156

Ilustración 7.7- Protipo web con la visualización para ThreeJS y Nexus .............................. 157

Ilustración 7.8- Protipo web con la visualización para Unity ................................................ 157

Ilustración 7.9- Gráfico primera pregunta formulario ............................................................ 158

Ilustración 7.10- Gráfico segunda pregunta formulario ........................................................ 159

Ilustración 7.11- Opciones tercera pregunta formulario ........................................................ 159

Ilustración 7.12- Gráfico tercera pregunta formulario ........................................................... 160

Ilustración 7.13- Gráfico cuarta pregunta formulario ............................................................ 160

Ilustración 7.14- Gráfico quinta pregunta formulario ............................................................ 161

Ilustración 7.15-Opciones sexta pregunta formulario ............................................................ 161

Ilustración 7.16- Gráfico sexta pregunta formulario .............................................................. 162

Ilustración 7.17- Ventana de máquina virtual del proyecto en Proxmox en la web .............. 167

Ilustración 7.18- Filezilla aplicación accediendo al servidor del CEACTierra para editar los

archivos de la web .................................................................................................................. 168

Ilustración 7.19- Instrucción ssh para acceder a la dirección del servidor ............................. 168



12


Ilustración 7.20- Acceso al contenido de la web en el servidor por medio de conexión ssh

desde la terminal de MacOS................................................................................................... 169

Ilustración 7.21- Estadísticas de la máquina virtual del proyecto de Proxmox en la web ..... 170

Ilustración 0.1- Github con el proyecto en la web ................................................................. 181

Ilustración 0.1- Modelo 3D de la Cimbarra sin modificar con Cura...................................... 185

Ilustración 0.2- Modelo 3D de la Cimbarra por debajo ......................................................... 185

Ilustración 0.3- Modelo 3D extruido en el eje –Y con Blender ............................................. 186

Ilustración 0.4- Modelo modificado en Cura ......................................................................... 186

Ilustración 0.5- Modelo modificado en Cura con opciones de impresión ............................. 187

Ilustración 0.1- Storyboard vistas de la aplicación para Iphone ............................................ 190

Ilustración 0.2- Resultado app iOS ........................................................................................ 191



13


ANEXO B: Índice de tablas

Tabla 1.1- Comparativa entre WebGL y Flash ........................................................................ 13

Tabla 3.1- Tabla con las actividades que se han realizado en el proyecto con sus duraciones y

tiempo ....................................................................................................................................... 13

Tabla 3.2- Costes totales del proyecto ..................................................................................... 13

Tabla 4.1- Comparativa de frameworks para la realización de gráficos en la web.................. 13



14


1. INTRODUCCIÓN

Este trabajo de fin de grado trata de desarrollar un prototipo de portal web para la

visualización e interacción con modelos geométricos de elementos naturales o

históricos obtenidos mediante escaneo o fotografía para difundir información sobre

ellos, llegando a ser etiquetados.

El reto principal que existe con el prototipo producto de este proyecto es

proporcionar una herramienta para la documentación, almacenamiento, análisis y

difusión de elementos significativos de patrimonio natural de la provincia de Jaén,

que aunque un futuro desafío es adaptarlo a cualquier lugar o monumento que

tengamos representado con modelos 3D, en nuestro caso, dado que el prototipo

será utilizado por el CEACTierra (Centro de Estudios Avanzados en Ciencias de la

Tierra) de la Universidad de Jaén, será para difusión de información de la zona de

La Cimbarra. Dicha información debe ir acompañada de la visualización gráfica de

los modelos 3D que representan el lugar u objeto de interés.

El proyecto surgió a raíz del deseo de sustituir la escasa información tanto

general como más específica (geológica o histórica) de la zona de La Cimbarra en la

página web de la Junta de Andalucía, que además es idéntica a la que aparece en

los carteles de las rutas que hay “in situ” en dicha localización. De esta forma,

cualquiera con interés en la zona puede consultar la información a través de internet

desde cualquier dispositivo, añadiendo más información tanto textual como con

contenido multimedia, además de la posibilidad de interactuar y observar la zona

representada gráficamente con diversas funcionalidades.

Además, la motivación de este Proyecto es poder cargar, interactuar y etiquetar

modelos geométricos 3D de gran resolución en un navegador desde cualquier

dispositivo con una calidad y en un tiempo aceptables.

El resultado obtenido con este trabajo de fin de grado estaría enfocado a

cualquier página web que con contenido gráfico se aportaría un valor añadido para

facilitar al usuario la visualización e interacción con el contenido de la misma, como,

por ejemplo, difundir patrimonio de cualquier tipo, vender cualquier tipo de productos

que son representados mediante modelos gráficos 3D, … Todo ello teniendo en



15


cuenta la adaptación del prototipo dependiendo del objetivo a cumplir, ya que con

opciones como una animación personalizada depende del modelo 3D cargado en la

web.

1.1. Descripción de gráficos en la web

Actualmente, salvo que usemos plugins de terceros y tecnología flash (en

desuso), cualquier gráfico interactivo en una página web se realiza con WebGL, una

librería gráfica equivalente a la popular librería OpenGL pero para el contenido web.

Indiscutiblemente es la librería que domina el mercado actualmente, aunque es muy

común no programar con WebGL a bajo nivel, sino usar frameworks o marcos de

referencia muy similares, que están basados totalmente en WebGL y facilitan

algunas tareas. Los frameworks más populares son ThreeJS, BabylonJS, entre

otros.

WebGL (Web Graphics Library) de acuerdo a la definición que da el libro “WebGL

Programming Guide” es una API implementada en JavaScript para la renderización

de gráficos 3D en un navegador web. No precisa del uso de complementos o

aplicaciones adicionales que agregan nuevas opciones a una herramienta (plugins)

en cualquier plataforma que soporte OpenGL 2.0 u OpenGL ES 2.0. WebGL está

integrada completamente en todos los estándares web de los navegadores,

permitiendo la aceleración hardware de la GPU y el procesamiento de imágenes y

efectos como parte del lienzo o "canvas" de la página web. Los elementos de

WebGL se pueden combinar con otros elementos HTML y estar compuestos con

otras partes de la página o del fondo de la página. Los programas WebGL consisten

en un código de control escrito en JavaScript que permite usar la implementación

nativa de OpenGL ES 2.0, un lenguaje similar a C o C++, que se ejecuta en una

unidad de procesamiento gráfico (GPU) en cualquier navegador (es multiplataforma).

WebGL está diseñado y gestionado por el consorcio de tecnología sin ánimo de

lucro Khronos Group, propiedad de la fundación Mozilla.

Actualmente tenemos la versión 2.0 de WebGL que se basa en OpenGL ES 3.0 y

es muy similar a la primera versión de WebGL que se basaba en OpenGL ES 2.0

además de ser compatible con esta. Las diferencias son principalmente el soporte



16


de más formatos de imagen en webgl 2.0 y a su vez más formas de cargarlos, así

como mejoras en los shaders.

WebGL es una tecnología relativamente joven, su lanzamiento inicial fue a

principios de 2011. Debido a esto, antes de esa fecha, para insertar gráficos 3D en

una página web tenías que recurrir a la tecnología Flash. Hoy en día

afortunadamente Flash está en decadencia y es cuestión de tiempo que a corto

plazo desaparezca, es más, navegadores tan importantes como Safari ni siquiera lo

soportan actualmente. He dicho “afortunadamente” porque WebGL soluciona

muchos problemas de Flash y mejora la integración y calidad de los gráficos 3D en

navegadores, por lo que WebGL es el presente y el futuro de este tipo de

tecnologías, al menos a medio plazo.

La siguiente tabla muestra porqué se habla tan bien de WebGL respecto a su

predecesor, Flash, tanto que prácticamente podría ser una tabla de ventajas de

WebGL respecto a Flash:

WebGL(con HTML5 y CSS) Flash

No se basa en un Plugin Sí se basa en un plugin

Se ejecuta directamente en el

navegador Algunos navegadores no lo traen instalado

por defecto y habría que instalar software

adicional

Las posibilidades son infinitas, aunque

es complejo de aprender (a bajo nivel) No tiene soporte actualmente en los

principales navegadores (Chrome, safari,

firefox) y su uso seguirá en descenso Al tener más posibilidades implica

mayor consumo energético y necesidad

de un mejor hardware

Los gráficos no requerían grandes equipos

al ser únicamente 2D

Tabla 1.1- Comparativa entre WebGL y Flash

En definitiva, la evolución de Flash a lo largo del tiempo de vida que ha tenido se

describe gráficamente en la ilustración 1.1:

Ilustración 1.1- Historia tecnología Flash



17


Cualquier información gráfica es mucho más atractiva y se puede entender con

más facilidad, de ahí la importancia de los gráficos. Además, en este caso al ser en

la web, es sinónimo de universalidad y de ser usado desde cualquier dispositivo en

cualquier momento y en cualquier lugar.

1.2. Metodología

• Búsqueda y análisis de herramientas para el desarrollo de modelos

interactivos web 3D.

• Análisis de los perfiles de usuarios de la herramienta.

• Análisis y especificación de requisitos.

• Diseño de software para la edición, interacción y visualización web de los

modelos geométricos 3D e información adicional.

• Implementación y pruebas. Evaluación del prototipo.

• Elaboración de la memoria del trabajo.

1.3. Objetivos del proyecto

• Identificación, uso y desarrollo de estructuras de datos y herramientas

adecuadas para la interacción web de modelos geométricos 3D.

• Definición de mecanismos de interacción tanto para usuarios finales del

museo interactivo como para editores que incorporan nuevos modelos y los

etiquetan.

• Definición de técnicas de etiquetado de modelos geométricos y de

representación visual en la web.

• Identificación, uso o desarrollo de técnicas para adecuar los modelos

geométricos procedentes del escaneado o fotografiado a la interacción y

visualización en la web.

1.4. Resultados esperados

Tras finalizar este proyecto, se deben haber obtenido los siguientes resultados:

• Estudio detallado sobre gráficos en la web. Creación, configuración,

interacción, etiquetado, …, de modelos 3D en la web.

• Desarrollar una plataforma web que cumpla con los objetivos

propuestos.



18


• Documentación del desarrollo llevado a cabo.

1.5. Estructura del documento

El documento se estructura de la siguiente manera:

La primera parte del documento tras este capítulo de introducción es el análisis

de los perfiles de usuario.

El capítulo 3 describe la gestión y planificación del proyecto, en la cual se

documenta como se organizará el desarrollo del proyecto y los costes que supondrá.

Posteriormente, en la parte de análisis del proyecto, se hablará de los requisitos

del mismo, las tecnologías usadas, el análisis de la decisión argumentada del estilo

que la web debe tener de forma que sea “responsive” o “adaptive” y dinámica o

estática, así como las funciones a desarrollar para el correcto funcionamiento del

proyecto, y los casos de uso del prototipo.

A continuación, en la parte de diseño, se desarrollarán los distintos diagramas de

las funciones de la web.

Luego en la implementación se explicarán con detalle todo el desarrollo

realizado, centrándonos en el código.

A continuación, se exponen los resultados y las pruebas realizadas con el

software, para finalmente hablar de las conclusiones obtenidas con este proyecto,

así como futuros trabajos, aplicaciones en las que sería útil, y la retroalimentación de

algunos usuarios que han utilizado la herramienta.

Además, finalmente también hay un apartado para la bibliografía, junto con

diversos anexos que complementan el proyecto. Los anexos que hay son los índices

de ilustraciones y tablas usadas para esta memoria, así como los manuales de

instalación y de usuario. También hay anexos de diferentes tareas que se han

llevado a cabo durante el proyecto y han sido vitales para este, como son el uso de

github pages, opciones para almacenar información en una web, impresión 3D de

modelos 3D, información sobre la caché de los navegadores, y un prototipo

adaptado para dispositivos móviles.



19


2. Análisis de perfiles de usuario

Una parte esencial de la fase de análisis es tener en cuenta el diseño centrado

en el usuario porque proporciona detalles sobre quién puede llegar a usar el

prototipo. Este análisis identifica roles y define las características del usuario que

puede potencialmente manejar nuestro prototipo, dependiendo de las características

de accesibilidad del software y de la experiencia de uso de los usuarios con software

similares. Para este análisis se ha consultado este libro referenciado en la sección

de bibliografía del proyecto.

Este análisis es vital para que nuestro prototipo sea aceptado y usado

satisfactoriamente por el público hacia el que va dirigido.

Los perfiles de grupos de usuarios describen las características de los usuarios o

personas que usan el producto para el cual está realizando el análisis.

En el caso que nos concierne, el prototipo web para la interacción con modelos

geométricos 3D, las características definidas para los grupos de usuarios para

que puedan utilizar el producto deben incluir los siguientes aspectos:

• Hardware del equipo en el que se consulte la web, ya sea móvil,

ordenador de sobremesa, portátil o tabletas, teniendo en cuenta la

capacidad del procesador, la resolución, …

• Software: sistema operativo y principalmente en nuestro caso el

navegador usado para ejecutar la web y la versión de este, además de

tener activada la compatibilidad con WebGL. Si no se satisfacen estas

características, el usuario no podrá visualizar correctamente todo el

contenido del prototipo.

• Factores demográficos: aunque el prototipo web desarrollado puede

servir para visualizar e interactuar con cualquier modelo 3D, ha sido

implementado centrándose en una zona natural llamada “La Cimbarra” en

la provincia de Jaén (España), puesto que servirá de apoyo a la difusión

de esa zona.

• Frecuencia de uso del producto: lo normal es que tenga más uso

concentrado en una época del año, los meses de primavera e inicio del



20


verano, que son los más prolíficos para viajar y visitar dicha zona natural,

lo que implica el deseo de conocer más información sobre el lugar.

• Conocimiento de la tarea con la que van a interactuar: este punto es

estudiar hasta qué punto los usuarios que van a usar el prototipo

comprenden la tarea que están realizando.

• Experiencia en software similares: el uso de una aplicación web tal y

como sucede en este caso, aunque puede ser confuso al comienzo por los

iconos de funcionalidades que aparecen en la propia web, tras unos

pequeños instantes de tiempo usando la plataforma se sabrá usar sin

ningún problema sea el usuario que sea. Si bien hay que destacar que un

usuario con experiencia en la manipulación de modelos geométricos 3D

comprenderá más rápidamente el propósito de la web.

A continuación, se definen los grupos de usuarios que estarían interesados

en utilizar el prototipo:

Al ser una aplicación web para interactuar con modelos 3D y obtener información

a partir de estos, se pueden dar los siguientes perfiles de usuario que abarcan casi

cualquier posibilidad debido a que el contenido de una web es global y deberá ser

totalmente accesible:

Usuario esporádico que usa la web de forma ocasional para consultar

información de la zona por cualquier motivo, ya sea porque tiene interés, porque

desea visitar el lugar en cuestión y quiere conocer más la zona, porque tiene interés

en la parte de gráficos de la web o por cualquier otro motivo. Este tipo de usuario no

conoce la zona representada en la web (“La Cimbarra” de Jaén).

Usuario que conoce la zona a la perfección y visita la página web por motivos

de investigación mayormente por el contenido informativo que esta pueda ofrecer.

Este tipo de usuario visita el prototipo con más frecuencia que el anterior y puede

colaborar en los contenidos que se incluyen en la aplicación.

El tipo de usuario más común en visitar la herramienta web es el esporádico que

normalmente va a acceder a ella porque desea conocer información sobre la zona.



21


Para ambos grupos descritos hay que tener en cuenta características de

usabilidad (calidad del sitio web según la perciben los usuarios que acceden) y

accesibilidad (que el mayor número de usuarios pueda acceder con éxito al sitio

web), ya sean para usuarios de avanzada edad o usuarios con algún tipo de

discapacidad en menor o mayor grado.

Debido a que hay que tener en cuenta las necesidades del cliente, junto a

características de que la web sea lo más usable posible teniendo en cuenta que no

es un objetivo primordial del proyecto, se sigue una metodología por incrementos tal

y como se explica en el apartado correspondiente, algo muy útil para limar errores

en cada iteración.

Por tanto, la web debe tener unas características generales para la interfaz, el

control de la web, los iconos estandarizados, colores adecuados, tamaño de letra, …

Tal es el punto de importancia de la accesibilidad hoy en día que las páginas web de

administraciones públicas deben tener un mínimo grado de accesibilidad desde una

legislación de 2007. Es decir, según la Iniciativa de Accesibilidad Web hay 3 niveles

de accesibilidad: básico, medio o doble A, y alto o triple A, y una web de una

administración pública debe tener el nivel doble A. Por tanto, dado que el prototipo

que hay que desarrollar en este proyecto será enlazado a la página web del Centro

de Estudios Avanzados de la Tierra de la Universidad de Jaén, debe tener dicho

nivel de accesibilidad o al menos aproximado ya que no es un objetivo del proyecto y

por falta de tiempo no se puede dedicar excesivo tiempo a estas características,

aunque obviamente es un trabajo futuro muy importante.

Una web con accesibilidad doble A debe satisfacer los requisitos de las

prioridades 1 (todos los grupos de usuarios deben poder utilizar documentos web) y

2 (eliminar importantes barreras en cuanto al acceso a documentos web). Las

características de accesibilidad y diseño adecuado de web que se muestran a

continuación han sido extraídas del libro “HTML5 y CSS3: domine los estándares de

las aplicaciones web”, y la web correspondiente a estándares web.

Los puntos a tener en cuenta con la prioridad 1 son:



22


• Descripción textual de todos los elementos no textuales de la web (imágenes,

gráficos, botones, animaciones, …).

• Asegurarse de que el texto y los elementos gráficos de la web se entienden

cuando no tienen ningún código de color y asegurarse de que haya una

diferencia de contraste entre el color de fondo y el más superficial de forma

que sea visible para alguien con deficiencias visuales o cuando se ven en una

pantalla en negro o blanco.

• Uso natural del lenguaje en los elementos HTML.

• En las tablas HTML identificar en el código entre columnas y filas.

• Para tablas HTML con 2 o más columnas asociar las celdas de la fila y las

cabeceras de las columnas.

• Organizar los documentos de la web de forma que sea posible leer el

documento HTML cuando se renderice sin necesidad de las hojas de estilo

asociadas.

• Asegurarse de que la web es usable sin los scripts asociados. Y en caso de

ser imposible, prever otra solución accesible.

• La interfaz de la web debe ser independiente del dispositivo/s con el que se

utilice.

• Etc

Los puntos a tener en cuenta con la prioridad 2 son:

• Existencia de márgenes con elementos estructurales correspondientes.

Controlar la presentación con hojas de estilo antes que con elementos de

presentación y atributos.

• No usar tablas para el diseño de la página web a menos que nos

aseguremos de que tiene sentido en el propósito del sitio.

• Que los eventos a los que responden los teclados sean independientes del

dispositivo, es decir, que funcione con cualquier teclado por ejemplo y no con

una marca en concreto.

• Asegurarse de que el contenido dinámico de la página web sea accesible en

todo momento. Por ejemplo, no abusar de los frames de HTML.

• Etc



23


En conclusión, para este proyecto se debe cumplir en la manera en que sea

posible con los requisitos de accesibilidad y usabilidad de la WWW que se han

nombrado anteriormente, aunque no sean un objetivo explícito del proyecto, de

forma que cualquier tipo de usuario pueda utilizar la web minimizando al máximo el

número de inconvenientes que pueda tener. Estos requisitos están especificados tal

y como se puede observar en el análisis de requisitos del proyecto en el capítulo

correspondiente.



24


3. Gestión y planificación

En este capítulo se describe la metodología de desarrollo seguida durante la

realización del TFG.

Los apartados de este capítulo se distribuyen principalmente en los siguientes:

• Metodología incremental

• Planificación temporal

• Gestión de costes

3.1. Metodología incremental

El modelo de proceso de desarrollo software seguido para este proyecto es el

incremental o iterativo donde los requisitos y soluciones evolucionan con el tiempo

según la necesidad del proyecto. En cada iteración se realiza un prototipo totalmente

funcional centrado en alguna opción, y en la cual se incluye una planificación, un

análisis de requisitos, el diseño, la codificación, las pruebas y la documentación.

Teniendo gran importancia el concepto de "Finalizado", ya que el objetivo de cada

iteración no es agregar toda la funcionalidad para justificar el lanzamiento del

producto al mercado, sino incrementar el valor por medio de un "software que

funciona" (sin errores). La información sobre esta metodología se ha sacado del libro

aquí referenciado.

3.1.1. Definición de metodología incremental

La metodología seguida ha sido incremental. Este modelo de desarrollo iterativo

y creciente, no es más que un conjunto de tareas agrupadas en pequeñas etapas

repetitivas (iteraciones). Este es uno de los modelos de desarrollo más utilizados en

los últimos tiempos por los buenos resultados que proporciona consiguiendo un

producto final de calidad (véase la bibliografía).

Este tipo de desarrollo consiste en entregar el producto por incrementos en lugar

de entregar el producto en su totalidad, de forma que cada entrega sea un producto

operativo pero incompleto. Cada incremento, como se ha comentado anteriormente

pasa por una serie de fases que se ven representadas en la ilustración 3.1 extraída

del libro de “Gestión de proyectos informáticos”.



25


Así, cada incremento se estructura de modo que los primeros incluyen los

requisitos más importantes del TFG. Además, cada prototipo de cada iteración debe

haber sido planificado en un periodo de tiempo previamente determinado y lo más

breve posible.

Este tipo de desarrollo indica que, una vez iniciado el desarrollo de un

incremento, no se modifican sus requisitos hasta que haya sido finalizado. Esta

característica es fundamental, pero se puede tener cierto grado de flexibilidad debido

a que durante el desarrollo en ciertos momentos pueden surgir pequeñas ideas que

dan lugar a cambios.

Ilustración 3.1- Diagrama metodología por incrementos

3.1.2. Ventajas de una metodología incremental

• Los clientes pueden usar un software con las características esenciales

del prototipo final en fases tempranas del desarrollo.

• Los primeros incrementos se pueden y se suelen usar como prototipos

para obtener información de los mismos.

• El riesgo de que el proyecto falle se reduce con respecto a un modelo en

cascada en el que cada “fase” depende al 100% de lo hecho

anteriormente y no existe esa división por funciones o prototipos o

incrementos.



26


• Los incrementos prioritarios del sistema al ser los antes desarrollados,

son los que más se prueban.

• Facilidad para estimar la predicción de tiempos de cada tarea.

Si bien tiene algunos problemas este tipo de metodología, como la dificultad

para especificar los requisitos de cada incremento, es el tipo de desarrollo ágil más

adecuado para este proyecto basado en una continua interacción entre el

desarrollador y el cliente final del prototipo. Obteniendo una mayor productividad y

calidad en el diseño final debido a la mejor distribución del tiempo y la realización de

un mayor número de pruebas durante las iteraciones.

3.1.3. Aplicación de la metodología incremental sobre el proyecto

Primero, hay que destacar porqué se ha seguido este tipo de metodología y la

razón es que el prototipo que hay que desarrollar para este TFG se usa en una web

real para difusión de patrimonio de la provincia de Jaén, por tanto, la forma más

adecuada de que el cliente, el Centro de Estudios Avanzados en Ciencias de la

Tierra (CEACTierra), la vea por partes totalmente operativas o incrementos que

representan funcionalidades individuales del prototipo final.

Para la aplicación de una metodología incremental en este proyecto se debe dividir el

tiempo de duración del mismo en iteraciones. El primer día de cada una de las iteraciones

se realiza una reunión con el cliente. Estas reuniones son obligatorias realizarlas puesto

que debe haber un contacto directo con el cliente, y este debe ser el que especifique los

objetivos detallando los primordiales en todo momento, ya que estos deben ser

desarrollados en etapas más tempranas del desarrollo.

Así en cuanto a la planificación de cada iteración, cuando se digan las tareas después de

cada reunión se planifican viendo el tiempo necesario para cada objetivo dentro de una

iteración, y los desarrolladores se comprometen a tenerlos preparados en el tiempo

especificado, y con el esfuerzo y valor detallado.

En cuanto a la ejecución de la iteración planificada, al no ser un grupo de desarrollo,

sino una única persona, no se han tenido reuniones diarias, sino normalmente cada



27


semana o dos semanas dependiendo de la dificultad de la iteración. Estas se realizan para

discutir los puntos y tareas durante esa semana, así como los avances realizados,

analizando también las posibles interrupciones y o inconvenientes que puedan surgir.

Finalmente, el último día de cada iteración, se realiza otra reunión para analizar los

resultados y revisar el trabajo elaborado, demostrando y analizando los problemas que

pueda haber para posteriores implementaciones. Estas reuniones han sido la última de

cada iteración y la 1ª de la siguiente para aprovechar que el equipo se ha reunido (los

tutores y el alumno).

3.2. Planificación temporal

El periodo de tiempo en el que se desarrolla este proyecto va desde el 4 de

Septiembre de 2017 hasta el 24 Mayo de 2018, es decir, ha durado 262 días,

durante los cuales se ha trabajado entre 10 y 15 horas semanales. Contando que el

proyecto ha durado 34 semanas, el total aproximado de horas ha sido 340 horas

redondeando a la baja, eligiendo 10 horas por semana y sin contar varias horas de

reuniones y de orientación en tutorías, por lo que se ha superado con creces las 300

horas de trabajo de trabajo del estudiante dispuestas en la guía docente de la

asignatura de “Trabajo de Fin de Grado” y en la bibliografía recomendada por esta.

Para este proyecto se sigue una metodología incremental tal y como se ha

explicado en el apartado 3.1. Por tanto, el proyecto se ha subdividido en sub-

problemas más sencillos, cada uno de ellos forma un incremento. Cada uno tendrá 3

fases diferentes tal y como veremos en el posterior diagrama de Gantt, que son

análisis, diseño e implementación y pruebas del software desarrollado en esa

iteración.

En la tabla 3.1 se puede apreciar la distribución de las iteraciones y tareas a

desarrollar en el proyecto, así como su duración y fechas. Cabe destacar que al

contrario que en el diagrama de Gantt, no se han puesto en la tabla las horas de las

fases de análisis, diseño e implementación por simplificación, aunque en cada

iteración siempre se tarda un poco más de tiempo en la implementación por norma

https://uvirtual.ujaen.es/pub/es/informacionacademica/catalogoguiasdocentes/p/2017-18/4/133A/13316001/es



28


general. Además, es importante aclarar también que en las tareas principales

aparecen la media de tiempos de sus sub-tareas.

Tarea Duración (días)

Horas diarias

Duración total(horas)

Fecha de inicio

Fecha de fin

Búsqueda herramientas 7 1.5 10.5 4/09/17 10/09/17

Análisis herramientas 7 1.5 10.5 11/09/17 17/09/17

Elección herramienta 16 2,1562 34.5 18/09/17 2/10/17

Instalación WebGL 1 2 2 18/09/17 18/09/17

Implementación de pruebas

15 2.3125 34.6875 19/09/17 2/10/17

WebGL puro 3 3 9 19/09/17 21/09/17

ThreeJS 3 4 12 22/09/17 24/09/17

Otro software 3 2 6 25/09/17 27/09/17

Primeras pruebas con 3DHOP

6 1.5 9 28/09/17 2/10/17

Análisis de los perfiles usuario

10 0.75 7.5 3/10/17 12/10/17

Desarrollo 192 1.6111 309.33 13/10/17 22/04/18

Iteración 1: preparar modelos

3 2 6 13/10/17 15/10/17

Iteración 2:cargar modelos 3DHOP

7 1 7 16/10/17 22/10/17

Iteración 3: opciones avanzadas 3DHOP

10 1.25 12.5 23/10/17 2/11/17

Iteración 4: Estilo web 13 1.5 19.5 3/11/17 16/11/17

Iteración 5: Google maps 6 1.5 9 17/11/17 22/11/17

Iteración 6: cargar varios modelos

4 1 4 23/11/17 26/11/17

Iteración 7: Mostrar información general

4 1 4 27/11/17 30/11/17

Iteración 8: Herramienta etiquetado informativo

4 2 8 1/12/17 4/12/17

Iteración 9: función cambio de modelo

3 2 6 5/12/17 7/12/17

Iteración 10: Función interacción panorámica

3 1.5 4.5 8/12/17 10/12/17

Iteración 11: Etiquetado en mapa

4 2 8 11/12/17 14/12/17

Iteración 12: Animaciones predefinidas

3 1.5 4.5 15/12/17 17/12/17

Iteración 13: Herramienta de cálculo de áreas

6 2 12 18/12/17 23/12/17



29


Iteración 14: Herramienta de creación de animaciones

10 2 20 24/12/17 2/01/18

Iteración 15: Visualización con ThreeJS y Nexus

8 2 16 3/01/18 10/01/18

Iteración 16: función de añadir modelos a la web

6 2 12 11/01/18 17/01/18

Iteración 17: responsive web

11 2 22 18/01/18 28/01/18

Iteración 18: Internacionalización

9 1.25 11.25 29/01/18 6/02/18

Iteración 19: Transformaciones

geómetricas modelos secundario

7 2 14 7/02/18 13/02/18

Iteración 20: Transformaciones

geómetricas modelos principales

7 1 7 14/02/18 20/02/18

Iteración 21: Visualización con Unity

7 2 14 21/02/18 27/02/18

Iteración 22: Probar web en distintos

dispositivos/navegadores

12 1 12 28/02/18 11/03/18

Iteración 23: Creación modo museo

7 2 14 12/03/18 18/03/18

Iteración 24: Creación modo simplificado

7 2 14 19/03/18 25/03/18

Iteración 25: Información real en web

7 2 14 26/03/18 1/04/18

Iteración 26: Subir web servidor CEACTierra

7 1 7 2/04/18 8/04/18

Iteración 27: Depuración errores

14 1 14 9/04/18 22/02/18

Documentación 217 0.15 32.55 4/09/17 8/04/18

Elaboración memoria 45 3.5 157.5 9/04/18 23/05/18

Fin proyecto 1 1 1 24/05/18 24/05/18

Total 262 1.5209 398.4790 4/09/17 24/05/18

Tabla 3.1- Tabla que muestra las tareas realizadas en el proyecto con sus duraciones y tiempos

3.2.1. Diagrama de Gantt

En este apartado veremos las tareas del proyecto distribuidas en el tiempo

gracias al diagrama de Gantt junto a una explicación de en qué consiste cada tarea.



30


• Búsqueda de herramientas: búsqueda de herramientas para el desarrollo de

modelos interactivos web 3D.

• Análisis de herramientas: análisis de herramientas para el desarrollo de

modelos interactivos web 3D.

• Elección de herramientas:

o Instalación WebGL: instalación de WebGL para poder usarlos en los

navegadores usados para el desarrollo y el testeo (Firefox, Safari,

Chrome).Además, habilitar WebGL en los navegadores implica que

puedes ejecutar software de visualización 3D para la web sea del

framework que sea, no tiene porqué ser WebGL puro.

o Implementación de pruebas: pequeñas implementaciones de pruebas

con los diferentes softwares hallados en la búsqueda y el análisis con

el objetivo de decidir cuál será el más adecuado para la realización del

proyecto.

▪ WebGL

▪ ThreeJS

▪ Otros softwares: BabylonJS, Sketchfab, SceneKit en iOS,

OpenGL ES en Android, …

▪ Primeras pruebas con 3DHOP

• Análisis de los perfiles de usuario: analizar las características de los

usuarios que van a usar el software desarrollado, detallando cómo se pueden

manejar explicando inconvenientes que puedan tener, así como el propósito

del uso dependiendo del usuario que lo use.

• Desarrollo:

o Iteración 1 (preparar modelos 3D): Preparar los modelos 3D del

proyecto para su uso eficiente en la web.

o Iteración 2 (cargar modelos en 3DHOP): Cargar mis modelos 3D en

"3DHOP basic environment" en el que simplemente los cargue en la

web de uno y uno comprobando que aparecen y podemos interactuar

con ellos con un control básico (mover modelo y hacer zoom).

Básicamente es un inicio en el entorno 3DHOP con los modelos

usados para el TFG.



31


o Iteración 3 (opciones avanzadas 3DHOP): se empiezan a probar

algunas opciones más avanzadas de 3DHOP con mis modelos 3D.

Las opciones probadas son:

- Varios controles de interacción

- Sistema de etiquetado con alertas por defecto de js

- Sistema de medidas de distancias básico y sin datos

reales

- Sistema de saber las coordenadas del punto 3Dsobre el

que se ha clickado el modelo

Para realizar estas opciones correctamente se debe transformar el

modelo 3D de la posición por defecto (con MeshLab) o con

transformaciones geométricas de escalado, rotación y traslación

gracias a funciones de la librería spiderGL basada en webGL, entre

otras configuraciones que me he ido dado cuenta sobre la marcha que

no funcionaban.

o Iteración 4 (CSS + 3DHOP): crear un estilo para la web que pueda

combinar una zona de canvas en la que aparezca y se interactúe con el

modelo 3D, y otra en la que se muestre información y una descripción

del modelo.

o Iteración 5 (Implementar mapa de Google)

o Iteración 6 (cargar varios modelos 3D): cargar más de un modelo 3D

con el que interactuar (no los modelos de esfera para el sistema de

etiquetado) y posibilidad de poder cambiar entre ellos.Nota: Para

realizar esto correctamente se tuvo que hacer uso de la propiedad de

visibilidad modificando 3DHOP...

o Iteración 7 (Mostrar información de modelos 3D): mostrar información

únicamente textual e inventada de los modelos cargados con el estilo

adoptado para la web creada en una iteración anterior.



32


o Iteración 8 (Herramienta de etiquetado completa): con un modelo 3D

de una bandera se indica el punto de interés en el modelo 3D principal,

y tras seleccionar dicho modelo debe aparecer información tanto

textual, como añadiendo imágenes, vídeos o enlaces.

o Iteración 9 (Función de cambio de modelo principal): herramienta para

seleccionar el modelo 3D (de los disponibles) que queremos que se

visualicen en el canvas. Todo esto acorde a la información

proporcionada en iteración anteriores y reiniciando correctamente todo

el sistema para que no haya solapamientos visuales de modelos o

problemas con la interacción.

o Iteración 10 (Función de interacción panorámica): interacción

panorámica del modelo 3D tanto con teclas (w, a, s, d) como pulsando

y activando el icono correspondiente.

o Iteración 11 (Etiquetado en mapa): aprovechando el sistema de

etiquetado que ya está funcionando desde iteraciones anteriores, se

utiliza para poner una etiqueta en una zona (en este caso en la

Cascada de La Cimbarra) y proporcionar información meteorológica del

momento en el que se ha activado la web gracias a una API llamada

OpenWeatherMap, de forma que si el visitante de la web desea ir

próximamente vea como están las condiciones. Además, con la

posibilidad de añadir un marcador en la zona correspondiente en el

mapa de google para ver la zona desde otra perspectiva.

o Iteración 12 (Animaciones predefinidas): funciones para activar o

desactivar movimiento en el eje Y del modelo 3D (una rotación), o una

animación tipo ruta a través del modelo 3D usando posiciones

diferentes del modelo y la cámara y el control de interacción.

o Iteración 13 (Cálculo de áreas del modelo 3D): tendremos un cubo que

podremos trasladar, escalar y rotar para colocarlo de la forma que

queramos ocupando el área que queramos saber las dimensiones.

Además, teniendo la opción de usar una herramienta de medir

distanciar y áreas en el propio mapa de google.

o Iteración 14 (Herramienta de creación de animaciones): posibilidad de

guardar animaciones creadas gracias al almacenamiento web.



33


o Iteración 15 (Visualización con ThreeJS y Nexus): aprovechando la

eficiencia de uso de modelos 3D de gran resolución en la web que

proporciona NexusJS, se implementa con ThreeJS para que haya más

posibilidades de interacción.En este caso, este prototipo no es de

relevancia para el objetivo del proyecto para el CEACTierra, aunque

puede servir de mucho para mejoras o proyecto similares en el

futuro.Además, en este prototipo se implementó la "generación

automática de código" gracias a jquery, que se ha usado para añadir

modelos 3D en la iteración siguiente.

o Iteración 16 (Añadir modelos 3D a la web): creación de prototipo aparte

a modo de museo interactivo de forma que se puedan añadir modelos

al canvas para cargarlo e interactuar con ellos, utilizando el sistema de

almacenamiento que se crea más adecuado.

o Iteración 17 (Responsive website): gracias a la simplicidad del prototipo

creado en la iteración número 14, implemento con elementos CSS una

página web responsive, es decir, que se adapte al tamaño de pantalla

independientemente del dispositivo. Algo de utilidad para adaptar luego

a la web principal con los inconvenientes que eso conlleva.

o Iteración 18 (Internacionalización)

o Iteración 19 (Funciones con matrices de transformación): 2 funciones

en las que podemos manipular el escalado y la rotación del modelo 3D

secundarios (modelos ‘ply’ de resolución estándar) gracias a una serie

de sliders que aparecen en pantalla.

o Iteración 20 (Aplicar transformaciones geométricas): posibilidad de

aplicar transformaciones geométricas sobre las matrices de escalado,

rotación y traslación del modelo 3D cargado en la web por medio de

unos controles con sliders implementados.

o Iteración 21 (Visualización con Unity)

o Iteración 22 (Probar web en…): probar la web en diferentes

navegadores/dispositivos: para probar habrá que subir la web a mi

algún servidor en internet para que pueda ejecutarla en un dispositivo

móvil.Además de probarla en distintos dispositivos.



34


o Iteración 23 (Creación modo museo): modo museo a raíz de la opción

de añadir modelos implementada anteriormente.

o Iteración 24 (Modo simplificado): modo con las opciones necesarias

para subir la web al servidor del CEACTierra.

o Iteración 25 (Introducción de información real): introducción de

información real en la web, como parte fundamental del proceso de

difusión de patrimonio cultural/natural.

o Iteración 26 (Subir web servidor)

o Iteración 27 (Depuración errores)

• Documentación

• Elaboración de la memoria

• Fin del proyecto

El diagrama de Gantt mostrado en la ilustración 3.2 muestra las tareas

previamente indicadas. Dadas las dimensiones del diagrama, para una mejor

visualización se recomienda abrir el archivo “PlanificacionTFG_Gantt” situado en la

carpeta con el código del proyecto. Dicho diagrama, junto con el diagrama de Pert

de la posterior sección se han realizado con la herramienta “GanttProject”.



35


Ilustración 3.2- Diagrama de Gantt del proyecto



36


3.2.2. Diagrama Pert

Un diagrama Pert permite ver las relaciones entre las tareas o actividades de

un proyecto.

Ilustración 3.3- Diagrama Pert proyecto

En la ilustración 3.3 anterior del diagrama Pert del proyecto se ha simplificado a

las tareas principales, es decir, se han eliminado las sub-tareas de iteraciones que sí

se pueden ver en el diagrama de Gantt de la ilustración 3.2 o en la tabla 3.1. Esto

se ha realizado para que se vea adecuadamente el diagrama en esta memoria, pero

si se desea ver en más detalle con todas las tareas realizadas y sus respectivas

duraciones se ha adjuntado la imagen en formato ‘png’ con el nombre

“PlanificacionTFG_Pert” junto a la carpeta comprimida con el código del proyecto.

En conclusión, lo que se puede observar en el Pert anterior son las tareas

principales, marcadas de rojo las del camino crítico del Pert (tareas de realización

obliatoria), que si sumamos sus respectivas duraciones nos dará el tiempo total que

dura el proyecto. Además, es destacable observar que se han llevado paralelamente

dos tipos de actividades, por un lado el desarrollo del prototipo, y por otro la

documentación del mismo durante dicho desarrollo, que igualmente es una tarea de

realización obligatoria.

A raíz de del diagrama Pert anterior se ha obtenido un diagrama de actividad con

las actividades principales basándonos en los objetivos marcados para el proyecto.

Dicho diagrama se puede ver en la siguiente ilustración 3.4.



37


Ilustración 3.4- Diagrama de actividades generales del proyecto

3.3. Gestión de costes

En este apartado se realiza una estimación de los costes del proyecto.

3.3.1. COCOMO

Aplicando los conocimientos adquiridos durante el grado, se ha decidido aplicar

el modelo COCOMO para hallar el análisis de costes que han sido necesarios para

realizar este proyecto.

El modelo COCOMO (véase libro de “Gestión de proyectos informáticos” y

“Software engineering”) (COnstructive COst MOdel) es un modelo matemático de

base empírica utilizado para estimación de costos de software. Incluye tres sub-

modelos, cada uno ofrece un nivel de detalle y aproximación, cada vez mayor, a

medida que avanza el proceso de desarrollo del software: básico, intermedio y

detallado.

Es un modelo que calcula muy bien los costes relacionados con el personal del

proyecto, pero tiene ciertos inconvenientes que solucionaremos para hallar un coste

total exacto de nuestro proyecto teniendo en cuenta todos los ámbitos. Dichos

inconvenientes son:

• Los resultados no son proporcionales a las tareas de gestión ya que no

tiene en cuenta los recursos necesarios para realizarlas.

o Se tendrán en cuenta otros costes relacionados con los recursos

usados durante el proyecto en la sección posterior a este modelo.



38


• Se puede desviar de la realidad si se indica mal el porcentaje de líneas de

comentarios en el código fuente.

• Es un tanto subjetivo, puesto que está basado en estimaciones y

parámetros que pueden ser "vistos" de distinta manera por distintos

analistas que usen el método.

o Se ha tratado ser objetivo de acuerdo a un criterio lo más neutral

posible.

• Se miden los costes del producto, de acuerdo a su tamaño y otras

características, pero no la productividad.

• La medición por líneas de código no es válida para orientación a objetos.

o No existe este problema al no ser un proyecto cuyo software se

desarrolla con el paradigma de programación orientado a objetos.

• Utilizar este modelo puede resultar un poco complicado, en comparación

con otros métodos (que también sólo estiman).

Hay 3 tipos de proyectos en COCOMO, y debemos averiguar cuál ha sido el

más adecuado para nuestro proyecto:

• Orgánico: se trata de un entorno estable, de poca innovación, con un

tamaño pequeño de <50 KLDC, y se desarrolla en un período de tiempo

breve.

• Empotrado: software con requisitos restrictivos, inestable y sujeto a

cambios, complejo, y de gran innovación técnica.

• Semi-libre: una mezcla entre los dos anteriores.

En el caso de nuestro proyecto, el tipo de proyecto que se ha considerado ha

sido el semi-libre o semi-acoplado. Esto se debe a que el problema a resolver es

único, no tenemos experiencia previa en resolver un problema similar al que se

plantea en este proyecto, no hay una gran cantidad de líneas de código, tiene ciertas

restricciones tal y como se plantean en los objetivos del TFG, y lo realiza un solo

individuo.

Además, COCOMO tiene 3 tipos de modelos, es decir, 3 tipos de

ecuaciones:

https://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_objetos



39


• COCOMO básico: las estimaciones iniciales sobre el proyecto no son muy

precisas, y no hay detalles sobre este. Usa la ecuación básica.

• COCOMO intermedio: usa la ecuación nominal. El esfuerzo no se adapta

al entorno de desarrollo y se ajusta con 15 factores de coste que

corresponden a 6 niveles.

• COCOMO detallado: existe detalle en cada componente del sistema y

permite ajustar factores adaptándose a cada etapa del proyecto.

En nuestro proyecto, se ha optado por un modelo de COCOMO intermedio

para que el cálculo de costes sea más preciso que con el modelo básico. No se ha

elegido el modelo detallado porque no es conveniente reajustar los factores en

etapas de desarrollo del proyecto.

Por tanto, para el cálculo de costes de nuestro proyecto, las fórmulas de

COCOMO necesarias son:

Fórmulas de COCOMO:

E = a KLDCb FAE

T = c Ed

P = E/T

Coste = T P Salario Medio

Donde:

E = esfuerzo medio en persona/mes

LDC = líneas de código (KLDC = miles de líneas de código)

FAE = variable que depende de los 15 factores de la tabla correspondiente

T = tiempo en meses

P = nº de personas necesarias para el proyecto

Coste = coste del proyecto sin contar recursos

(Fórmula 2.1)



40


Junto con las fórmulas anteriores de la fórmula 2.1, en la figura 3.3 usaremos los

coeficientes del tipo de COCOMO semi-libre tal y como hemos dicho anteriormente,

además de que para el cálculo de FAE se usarán los valores que se han

considerado y han sido marcados y se pueden observar en la figura 3.4.

Ilustración 3.5- Coeficientes COCOMO semi-libre

Ilustración 3.6- Valores utilizados para el cálculo de costes del proyecto

Coste calculado con COCOMO:

• FAE = 1 1 1.3 1.3 1 1 1.07 1 0.91 0.86 1 0.91 0.91 1.08

= 1.2656

• Calcular KLDC con Puntos de Función(PF) y Líneas de Código(LDC). El PF

depende del lenguaje usado. Buscando un poco por la red he encontrado que

el PF de JavaScript es 54. Las líneas de código estimadas por PF son 90.

KLDC = PF (LDC / 1000) = 54 (90 / 1000) = 4.86



41


• E = 3.00 4.861.12 1.2656 = 22.3074 personas al mes

• T = 2.5 22.30740.35 = 7.4113 meses es el tiempo aproximado que se debería

tardar en realizar este proyecto sin contar el tiempo de depuración de errores

y documentación

• P = 22.3974 / 7.4113 = 3.0221 personas serían necesarias para realizar el proyecto

• Coste = T P Salario medio = 7.4113 3.0221 1835 = 41099.7607 € en

total

Según el motor de búsqueda de empleo Indeed (Indeed), La información salarial

aproximada a partir de 1.069 fuentes obtenidas directamente de las empresas,

usuarios y empleos en Indeed en los últimos 36 meses. Última actualización: 30 de

marzo de 2018, el sueldo de un analista informático es de 26.364 € de media al año

=> 2197 € / mes

Para un programador según Indeed:

La información salarial es una estimación a partir de 689 fuentes obtenidas

directamente de las empresas, usuarios y empleos en Indeed en los últimos 36

meses. Última actualización: 29 de marzo de 2018

17680€ anuales => 1473€ / mes

Para un ingeniero informático:

La información salarial es una estimación a partir de 275 fuentes obtenidas

directamente de las empresas, usuarios y empleos en Indeed en los últimos 36

meses. Última actualización: 26 de marzo de 2018

22022 € anuales => 1835€ / mes

Como todo el trabajo lo realiza una única persona, se ha realizado la media de

los 3 salarios para tener un resultado de salario medio más creíble:

Salario Medio = (2197 + 1473 + 1835) / 3 = 1835 € / mes



42


En definitiva, los resultados indican que haría falta un grupo de 3 personas

trabajando durante aproximadamente 7 meses para llevar a cabo

correctamente el proyecto.

3.3.2. Recursos

A continuación, se calculan los costes de todos los recursos necesarios para la

realización de este proyecto, a parte de los de personal calculados en el apartado

anterior.

Software y bibliografía utilizada

Todo el software usado para este proyecto es totalmente gratuito o se ha usado

en versiones gratuitas ya sea tanto por licencias para estudiantes como ocurre con

Visual Paradigm o Microsoft Office para Mac, o por versiones gratuitas de un

software de pago como ocurre con la API de Google Maps o Unity3D.

En cuanto a la bibliografía, aunque muchas veces se ha consultado páginas

webs de documentación de WebGL, frameworks, APIs, …, sí que se han consultado

diversos libros que no se pueden encontrar en formato PDF de forma gratuita, por lo

que hay que tener en cuenta sus precios obtenidos en la web de Amazon.

REFERENCIARLOS BIBLIOGRAFIA

• HTML5Y CSS3: domine los estándares de las aplicaciones web => 29.90€

• Computer Graphics with OpenGL 4th edition => 37.84€

• Software Engineering: A Practitioner’s Approach => 49.10€

• Análisis y diseño de sistemas orientados a objetos con UML => 145.98€

• Gestión de proyectos informáticos: métodos, herramientas y casos =>

19.95€

• Head First Design Patterns => 30.75€

• WebGL Programming Guide => 28.54€

En total el coste ha sido 312.16€

https://www.amazon.com/ref=nav_logo



43


Equipo informático

El equipo informático utilizado para este proyecto ha sido un “Macbook Pro” con

pantalla retina de 13 pulgadas de finales de 2013 con un procesador de Intel Core i5

a 2.6 GHz, 16 GB de memoria RAM DDR3, y 250 GB de almacenamiento SSD.

Coste aproximado del equipo: 2000€ teniendo en cuenta el descuento de

Apple por ser estudiante universitario.

Vida útil aproximada: 8 años tal y como se explica en el posterior cálculo de

este apartado.

Depreciación (disminución periódica del valor de un bien material o inmaterial)

del equipo durante el tiempo que dura el proyecto se va a calcular. Calculamos la

depreciación más común y usada que es la depreciación en línea recta, es decir,

dividir el valor del activo entre su vida útil.

Si el valor del equipo es de 2000€ y se adquirió antes de comenzar el primer

curso de carrera hace aproximadamente 4 años, fue en Julio de 2014 y la vida útil de

un Macbook en cuanto a su batería y componentes se suele decir que está en el nº

de ciclos de carga que tenga ese MacBook aunque suele durar más sobretodo si

cambias algún componente que se dañe. En mi caso es de 1000 ciclos de carga, si

lleva 500 ciclos de carga aproximadamente (496 para ser exactos) a principios de

Abril de 2018 cuando se hizo este cálculo, quiere decir que lleva la mitad de su vida

útil prácticamente en:

Julio 2014-Julio 2015-julio 2016-julio 2017 => 3 años + agosto, septiembre, octubre,

noviembre, diciembre 2017, enero, febrero, marzo 2018 => 3 años y 8 meses ==

44meses

Aproximadamente le quedan otros 44 meses, lo que implica:

El Macbook tiene una vida útil de aproximadamente 8 años, para ser exactos

unos 88 meses=7.3 años. => 7.3 365 días que tiene un año = 2664.5 días de vida

útil.



44


Haciendo el cálculo de depreciación: 2000€ / 2664.5 días = 0.7506 €/día se

deprecia.

Si cogemos el cálculo realizado con COCOMO anteriormente del tiempo que

dura el proyecto que son 7.4113 meses ≈ 226 días. Aunque si tenemos en cuenta el

tiempo usado por el ordenador para documentar y realizar la memoria habría que

añadir al menos 1 mes, es decir, 31 días más.

Solución: 0.7506 €/día 226 días = 169.6356 € se ha devaluado el ordenador en

el tiempo que ha durado el proyecto. Por tanto 2000€ que valía el ordenador

menos 169.6356€ que se ha devaluado, da un resultado de 1830.3644€ vale el

equipo actualmente para el análisis de costes.

Tarifa de internet

Se ha usado para el proyecto una tarifa de internet de Orange de 50Mb simétricos, más

una línea de móvil con 6 GB de datos móviles y 300minutos de llamadas gratuitas también

usados para el proyecto y que en total tiene un coste de: 50€ mensuales. Principalmente se

usado dicha tarifa, aunque en ocasiones alguna pequeña parte de desarrollo se ha realizado

en la universidad con la conexión a internet gratuita que eso conlleva.

El proyecto, tal y como se ha calculado en la planificación temporal dura 398

horas, durante aproximadamente 7 meses. Por tanto:

• 50 €/mes 7 meses = 350€ en total de tarifa a los 7 meses (todo el internet,

no el usado en este proyecto)

• 398 horas/mes / 7 = 56.85 horas mensuales se ha trabajado en el proyecto de

media

• Un mes tiene 30 o 31 días, y cada día 24 horas => 30 24 = 720 horas en

total en un mes

• Por una simple proporción, si 720 horas que tiene un mes son el 100%, 57

horas dedicadas al trabajo son 7.92%. El 7.92% de 50€/mes de la tarifa es

3.96€ al mes de internet de la tarifa dedicados al proyecto. Y 3.96€/mes

multiplicado por la duración que son 7 meses es 27.72€ en total gastados.



45


Consumo eléctrico

El consumo eléctrico se divide en varios gastos teniendo en cuenta que el kWh

vale 0.132913 € habiendo mirado la factura de consumo eléctrico del mes de marzo de

2018 que ha llegado a mi casa, y aunque puede fluctuar un poco este valor en el tiempo, lo

tomamos como referencia como valor aproximado de lo que pudiera costar.

• Radiador eléctrico: consume unos 2 kWh y el kWh vale unos 13.2913

céntimos la hora el kilowatio.

1kWH -> 0.132913€ 2kWH -> x

x = 0.265826 € la hora consume el radiador

El uso que le he dado teniendo en cuenta los meses durante los cuales se ha

desarrollado el proyecto, ha sido desde septiembre hasta abril/mayo, teniendo en

cuenta que cada semana se han trabajado aproximadamente unas 12 horas.

(7. 4113 meses según COCOMO ≈> 32 semanas)

12h 32 semanas = 384 horas en total en el proyecto

Si 4 semanas son 1 mes y 12 horas de trabajo semanales 4 semanas que

tiene un mes es 48 horas mensuales de trabajo

Teniendo en cuenta que las horas de trabajo normalmente las distribuyo de

igual forma durante horas de luz y horas de oscuridad, podríamos decir que de las

48 horas que tiene un mes la mitad se ha necesitado el radiador en los meses fríos,

es decir, noviembre, diciembre, enero y febrero.

Por tanto: (48 / 2) * 4) = en 96 horas de las 384 horas totales se ha necesitado

el radiador eléctrico.

96h 0.265826 = 25,52 € gastados en luz por el uso del radiador

• Flexo: consume 1kWh => 0.132913€ cada hora de electricidad



46


Ese dato por el nº de horas usado que coincide con las horas de

oscuridad calculadas en el apartado anterior que se han tomado como las

horas de frío en las que necesitamos el radiador, es:

96h 0.132913 = 12,76 € de luz gastados por el flexo

• Consumo del ordenador:

Dado que el ordenador a pesar de ser portátil, prácticamente siempre se

suele usar conectado a la corriente para consumir menos y desgatar menos

sus componentes. El consumo estándar para un portátil de similares

características es unos 0.100 kWh. Por tanto, dado que el proyecto ha

durado 398 horas:

398 horas 0.1 = 39.8€ gastados por el consumo eléctrico del ordenador

• Consumo servidor CEACTierra: solamente se tendrá en cuenta el consumo

del servidor los días desde que se alojó la web hasta que terminó el proyecto.

Además, de no contar con el coste de adquisición del servidor como es lógico,

debido a que no se ha adquirido este equipo para este proyecto

exclusivamente.

Los días a tener en cuenta este consumo según el diagrama de Gantt van

desde el 2 de Abril de 2018 hasta el 24 de Mayo de 2018. En total 53 días, es

decir, 1272 horas.

1272 días 0.12136 precio del kWh = 154.37 € gastados por el consumo del

servidor utilizado

En total, el consumo eléctrico para el desarrollo de este proyecto es 232.45 €.

3.3.3. Conclusión de los costes necesarios

En resumen, el coste total del proyecto es 43356.52 € tal y como se ve

reflejado en esta tabla resumen 3.2 de todos los gastos que habría que sumar para

hacer frente al lanzamiento desarrollo de este prototipo web:



47


Tabla 3.2- Costes totales del proyecto

Concepto Coste

Software y bibligrafía utilizada 312.16 €

Equipo de desarrollo 1830.3644 €

Tarifa de internet 27.72 €

Consumo eléctrico total 232.45 €

Estimación costes COCOMO 41099.7607 €

Total 43502.4551 €



48


4. Análisis

En este capítulo se estudia detalladamente los requisitos y la solución escogida

para el problema que presenta el proyecto. Este análisis es una de las partes más

importantes a la hora del desarrollo de un producto, en este caso un prototipo de

aplicación web para la interacción con modelos geométricos 3D obtenidos mediante

escaneo y/o fotografía. Se ha consultado para este y el siguiente capítulo de diseño

una referencia bibliográfica sobre análisis y diseño de proyectos.

Los apartados de este capítulo se distribuyen en los siguientes:

• Análisis de requisitos

• Tecnologías basadas en WebGL

• Solución escogida (3DHOP)

• Web estática vs Web dinámica

• Responsive vs Adaptive

• Diagrama de casos de uso

• Lenguajes de programación, servicios y librerías

• Principales funciones a desarrollar en el proyecto

4.1. Análisis de requisitos

Aquí se definen los requisitos que deben cumplirse en este proyecto, es decir, la

lista detallada de todas las propiedades o restricciones que tiene el prototipo

(propiedades específicas y de funcionalidades de la aplicación) y que deben poder

ser comprobables.

El análisis de requisitos es fundamental para el proyecto porque los errores más

comunes y costosos de reparar se dan por haber hecho un análisis erróneo de

requisitos al inicio del proyecto.

Los requisitos de este apartado son imágenes descargadas de las tablas

realizadas con la herramienta de ingeniería del software Visual Paradigm. Estas

tablas tienen un formato basado en los siguientes puntos:

• Nombre del requisito



49


• Descripción del requisito (algunos de los requisitos que a continuación se

muestran no tendrán descripción porque no es necesario debido al nombre

que poseen)

• Identificador del requisito

• Versión del requisito

• Tipo de requisito: podrá ser funcional, de rendimiento o de interfaz.

• Método para verificar si el requisito está correctamente implementado:

análisis, demostración, inspección y test.

• Riesgo o importancia del requisito: puede ser alto, medio o bajo.

• Estado del requisito: cada requisito ha pasado por muchos estados

(aprobado, en desarrollo, …) pero en este análisis se verán todos como

implementados debido a que las capturas de información de las tablas se

hicieron al final del desarrollo.

Los requisitos que se van a mostrar se dividen en varios tipos o apartados:

• Requisitos funcionales

• Requisitos no funcionales

• Requisitos de cliente

• Requisitos de servidor

• Requisitos de escalabilidad

• Requisitos de rendimiento

• Requisito de internacionalización

4.1.1. Requisitos funcionales

Los requisitos funcionales son los diferentes servicios que el sistema debe

proporcionar al usuario. Son los siguientes:

Ilustración 4.1- Requisito de visualización de modelos 3D en la web



50


Ilustración 4.2- Requisito de interacción con modelos 3D en la web

Ilustración 4.3- Requisito de etiquetado de modelos 3D en la web

Ilustración 4.4- Requisito de etiquetado con información meteorológica de modelos 3D en la web

Ilustración 4.5- Requisito de realizar zoom de modelos 3D en la web



51


Ilustración 4.6- Requisito de realizar zoom de modelos 3D en la web

Ilustración 4.7- Requisito de cambiar la apariencia de modelos 3D en la web

Ilustración 4.8- Requisito de realizar animación de ruta sobre el modelo 3D en la web

Ilustración 4.9- Requisito de realizar animación en eje Y sobre el modelo 3D en la web

Ilustración 4.10- Requisito de pinchar sobre el modelo y ver las coordenadas del punto seleccionado



52


Ilustración 4.11- Requisito de medir distancias en el modelo 3D en la web

Ilustración 4.12- Requisito de interactuar con el modelo 3D en la web

Ilustración 4.13- Requisito de crear animaciones sobre el modelo 3D en la web

Ilustración 4.14-Requisitos de medir superficie de modelo 3D en la web

Ilustración 4.15- Requisito de interacción con Unity



53


Ilustración 4.16- Requisito de visualizar el modelo 3D desde varias perspectivas

Ilustración 4.17- Requisitos de tener varios controles de interacción de modelos 3D en la web

Ilustración 4.18- Requisito de visualización con ThreeJS

Ilustración 4.19- Requisito de usar la API de Google Maps

Ilustración 4.20- Requisito de diferenciar la parte de interacción de modelos 3D de la parte que muestra información



54


Ilustración 4.21- Requisito de gestionar diferentes modos de la web

Todos estos requisitos son de servicios que debe proporcionar el prototipo

web, Mayormente requisitos de tipo funcional (ilustración 4.1 – ilustración 4.19),

aunque también hay un requisito de tipo interfaz (ilustración 4.20) que como su

descripción indica entra dentro de este apartado de “requisitos funcionales”. Y un

requisito (ilustración 4.21) de rendimiento para tener varias opciones de web a

decisión del usuario. Además, al ser todos estos requisitos servicios del sistema, su

forma de ser verificados es por medio de demostraciones al cliente siguiendo las

diferentes iteraciones descritas en la planificación temporal.

4.1.2. Requisitos no funcionales

Los requisitos no funcionales son los distintos aspectos del sistema relacionados

con el cumplimiento de los requisitos funcionales.

Ilustración 4.22- Requisito de no recargar la web cuando se produzca un cambio

Ilustración 4.23- Requisito de que la web tenga una interfaz adecuada



55


Ilustración 4.24- Requisito de que la web use cookies

Ilustración 4.25- Requisito de que la web usa almacenamiento local en el navegador del usuario

Estos requisitos complementan a los requisitos funcionales del apartado 4.1.1.

Los requisitos de las ilustraciones 4.22, 4.24, y 4.25 son de tipo rendimiento

porque debido a esas características la web ser más o menos eficiente. En cambio,

el requisito restante de este apartado, el de la ilustración 4.22 es de interfaz porque

tiene en cuenta que visualmente y en cuanto a controles visuales de la misma sean

lo más adecuados posibles. Además, este último se verifica inspeccionando la web

con alguna herramienta de control de accesibilidad o comprobando el manual

correspondiente. Los demás requisitos, por el contrario, se verifican testeando y con

demostraciones de la propia web.

4.1.3. Requisitos del cliente

Los requisitos del cliente pueden ser de 2 tipos. Uno es el requisito hardware

que se necesitan para ejecutar la aplicación correctamente como por ejemplo un

ordenador cualquiera con conexión a internet (ilustración 4.26). Y otro es el

requisito software (ilustración 4.27) como por ejemplo los navegadores compatibles

con JavaScript, gráficos WebGL, y funciones asíncronas, es decir, que la web sea

compatible con alguno de los navegadores más populares y comunes (Chrome,

Firefox o Safari).



56


Ilustración 4.26- Requisito hardware

Ilustración 4.27- Requisito software

La web será compatible con los siguientes navegadores para equipos de

escritorio:

• Google Chrome Versión 66 o posterior

• Safari Versión 11 o posterior

• Firefox Versión 60 o posterior

En cuanto a navegadores para dispositivos móviles, únicamente se podrá testear

con el navegador de Safari bajo la versión de iOS 11.

También es destacable que ambos requisitos de cliente son de rendimiento

debido a que si se realizan correctamente la web funcionará mejor y de lo contrario

su funcionamiento será menos eficiente.

4.1.4. Requisitos del servidor

El requisito de servidor que alberga la web no tiene por qué ser excelentes tal y

como se explica en el posterior de resultados y pruebas. Lo podemos ver en la

siguiente ilustración 4.28.



57


Ilustración 4.28- Requisito de servidor

4.1.5. Requisitos de rendimiento

El único requisito de rendimiento del proyecto es básico, que el funcionamiento

de la web sea el aceptable, es decir, que el usuario reciba una ejecución de la

aplicación web correcta y con tiempos de respuesta aceptables. El requisito de la

ilustración 4.29 se puede probar fácilmente utilizando la web y viendo que no hay

tiempos de espera excesivos. Y en la ilustración 4.30 se expone en otro requisito

que una de las API utilizadas solamente podrá como máximo aceptar 60 peticiones

por minuto, algo que, aunque aceptable podría empeorar el rendimiento si hubiera

mucho tráfico en la web.

Ilustración 4.29- Requisito de rendimiento

Ilustración 4.30- Requisito rendimiento 2

4.1.6. Requisitos de escalabilidad

Los requisitos de escalabilidad básicamente vienen a tratar la necesidad de la

aplicación de que se pueda ejecutar en diferentes plataformas. En definitiva, los

requisitos de las ilustraciones 4.31 y 4.32 son parecidos a los requisitos del cliente y



58


se pueden comprobar con demostraciones de la web funcionando en distintos

navegadores y/o dispositivos.

Ilustración 4.31- Requisito de compatibilidad de la web con diferentes navegadores

Ilustración 4.32- Requisito de compatibilidad de la web con diferentes resoluciones de pantalla

4.1.7. Requisitos de internacionalización

Este requisito de la ilustración 4.33 únicamente trata la posibilidad de que la

aplicación pueda ejecutarse en varios idiomas, en este caso en los dos principales

para nosotros, el español y el inglés. Este requisito, aunque sea una funcionalidad o

servicio, se ha considerado de interfaz por el hecho de que modifica los elementos

de la interfaz de la web.

Ilustración 4.33- Requisito de internacionalización de la web

4.2. Tecnologías basadas en WebGL

En este apartado se va a realizar una descripción escueta de las tecnologías que

se han tenido en cuenta para la realización de este proyecto. Tal y como hemos



59


observado en el apartado de planificación temporal, se han dedicado varios días a

probar y decidir la mejor tecnología para el objetivo del proyecto.

Observando el diagrama de Gantt, se ha dedicado bastante tiempo a analizar las

diferentes opciones de tecnologías con las que se podría haber desarrollado este

proyecto, implementado pequeñas demostraciones de prueba para ver sus

capacidades. Así, las diferentes alternativas analizadas para este TFG han sido:

4.2.1. WebGL puro

Ilustración 4.34- Logotipo WebGL

WebGL es una especificación estándar que define una API implementada en

JavaScript para la renderización de gráficos en 3D dentro de cualquier navegador

web (WebGL).

Todos los framework para gráficos 3D en la web están basados a bajo nivel en

WebGL, igual que sucede con OpenGL en apps de móvil o escritorio.

Al ser la base de los gráficos en la web, las posibilidades son infinitas, el

problema es que ciertas tareas son mucho más complejas al no haber una capa o

framework a más alto nivel que facilite la tarea, por lo que requiere más tiempo, y

posiblemente el uso de shaders, … Además, la optimización de la app que hagamos

depende de nosotros mismos, algo que no ocurre de manera tan notable en los

demás frameworks.

El principal problema sucede con la falta de información para cargar un modelo

3D geométrico en nuestra escena de WebGL, algo vital para este proyecto. Siempre

se recomienda usar un framework.

4.2.2. ThreeJS



60


Ilustración 4.35- Logotipo ThreeJS

ThreeJS es una biblioteca escrita en JavaScript para crear y mostrar gráficos

animados por ordenador en 3D en un navegador Web y puede ser utilizada en

conjunción con el elemento canvas de HTML5, SVG o WebGL.

Las ventajas de usar esta librería son:

• Gran comunidad y muchos ejemplos.

• Facilita el uso de WebGL sin conocer a fondo WebGL.

• Buena para la interacción.

• Es fácil de integrar en una web o con otras librerías que podamos usar.

• “Multipass rendering” u otros efectos que aportan realismo a una escena.

Las desventajas principales:

• El rendimiento puede dejar mucho que desear dependiendo de la complejidad

de la escena, y aumenta si usamos un navegador móvil.

• Modelos JSON van perfectamente, pero cualquier otro tipo, como el wavefront

(‘obj’) que es muy común cuesta cargarlo correctamente, y si el modelo es

complejo el rendimiento decrece notablemente.

4.2.3. BabylonJS

Ilustración 4.36- Logotipo BabylonJS

BabylonJS es un framework JavaScript completo para construir juegos y

experiencias 3D con HTML5, WebGL, WebVR y Web Audio.

Ventajas:

• Aunque menos que ThreeJS, tiene buenos recursos y una buena comunidad.

• Bueno soporte para efectos especiales y post-procesamiento.

Desventajas:



61


• Es un proyecto muy joven cambiante por lo que puede haber problemas de

versiones.

• En cuanto a cargar modelos 3d en vez de crear tus mallas de triángulos, se

puede, pero no hay demasiada información al respecto, un poco como sucede

con ThreeJS, incluso menos.

• Más orientado a juegos.

4.2.4. WebGL con Unity3D

Ilustración 4.37- Logotipo Unity

Unity es un motor de videojuego multiplataforma creado por Unity

Technologies. Unity está disponible como plataforma de desarrollo para Microsoft

Windows, OS X, Linux. La plataforma de desarrollo tiene soporte de compilación con

diferentes tipos de plataformas. A partir de su versión 5.4.0 ya no soporta el

desarrollo de contenido para navegador a través de su plugin web, en su lugar se

utiliza WebGL.

Ventajas:

• Es un motor gráfico completo, con elementos para la interfaz, editor de

texturas, editor de terrenos, sistemas de partículas, …

• Mucha documentación y ejemplos.

• Fácil cargar modelos de Blender, o que tengamos nosotros mismos.

• Tienda de recursos muy completa.

• Mayormente gratuito.

Desventajas:

• Aunque los proyectos se pueden exportar para WebGL y la web, no está

creado para ese propósito, por lo que el rendimiento no es el más adecuado.

Además, no es fácil acceder a elementos del DOM de la web, al contrario de

lo que ocurre con cualquier de las otras opciones nombradas descritas.



62


4.2.5. 3DHOP

Ilustración 4.38- Logotipo 3DHOP

3DHOP (3D Heritage Online Presenter) es un framework de código abierto para

la creación de presentaciones interactivas en la web con modelos 3D, orientado

principalmente al patrimonio cultura. Se basa a bajo nivel en WebGL, aunque con

una librería adaptada que funciona de forma similar llamada “SpiderGL”.

Ventajas:

• Permite cargar sin problemas de rendimiento modelos 3D realmente grandes,

es decir, con mucha resolución, siempre que hagamos una transformación a

un formato específico requerido para el correcto funcionamiento.

• Está orientado a difundir patrimonio, algo vital para nuestro proyecto, porque

tiene implementadas herramientas interesantes como cargar varios modelos a

la vez de forma sencilla usando uno como etiquetado de punto de interés en

el otro.

• Fácilmente añadir elementos del DOM de HTML, así como integrarlo con

otros frameworks similares como ThreeJS mayormente para cargar modelos

3D sin problemas de rendimiento.

Desventajas:

• No es un framework tan completo como puede serlo ThreeJS o BabylonJS,

aunque casualmente para nuestro propósito es ideal.

• Requiere convertir los modelos que tengamos a un formato específico.

• Para entender el framework requiere una curva de aprendizaje mayor que

para comprender por ejemplo ThreeJS.

• Requiere un servidor web para que funcione correctamente, ya sea remoto o

local.



63


4.2.6. Otras

En la fase de búsqueda de herramientas adecuadas se descubrió otras

plataformas menos populares o de pago, que, aunque eran interesantes para

mostrar gráficos en la web, por falta de documentación, funcionalidades y en

definitiva por no ser demasiado populares, se obviaron. Algunas de esas

herramientas fueron SceneJS, Blend4Web, Clara.io, Sketchfab.

4.2.7. Comparativa

Ahora, tal y como se puede ver en la siguiente tabla 4.1, vemos una pequeña

comparativa entre las tecnologías más populares y satisfactorias para la realización

de una web como la deseada para este proyecto, de los cuales se ha búsqueda

información al comienzo del proyecto.

Hay que explicar brevemente en qué consisten las licencias a las que

pertenecen cada una de las siguientes tecnologías:

• MIT: licencia de software libre y permisiva respecto a la distribución.

• Apache License: licencia de software libre y permisiva respecto a la

distribución.

• GNU: libertad de estudiar, usar, compartir, y modificar el software, pero no

apropiarse del mismo.

• Propietario: software privativo que no permite acceder al código fuente y

no se permite su libre distribución ni modificación.

• Comercial: software que se comercializa pudiendo ser libre o propietario.

ThreeJS BabylonJs Unity 3DHOP Blend4Web Clara.io SceneJS Sketchfab

Scripting JS JS C# JS JS JS JS JS

Animaciones Si Si Si Si Si Si Si Si

Importar FBX, OBJ, STL

FBX, OBJ, STL

FBX, OBJ NXS, PLY

Todos los de blender

OBJ, FBX, STL, Blend

OBJ TODOS

Licencia MIT Apache License 2.0

Propietario GNU Comercial Comercial MIT Propietario

Documentación y comunidad (1

mal, 5 muy bien)

5 3 4 3 3 3 2 3

Audio integrado

Si Si Si No Si No No Si

Físicas integradas

No Si Si No Si Si Si No



64


Basado en WebGL

Si Si Si Si Si Si Si Si

Madurez y estado

desarrollo (1 min, 5 max)

5 3 5 4 3 5 3 5

Nota del 1 al 10 para este proyecto

basado en la investigación

8.5 7.5 8 9 4 4 5 7

Tabla 4.1- Comparativa de frameworks para realización de gráficos en la web

4.3. Solución escogida (3DHOP)

Analizando en detalle las opciones posibles, se decidió usar Unity, 3DHOP, y

ThreeJS.

Unity quedó descartado para realizar el proyecto en sí debido a que no está

destinado a producir aplicaciones con gráficos 3D para la web, aunque pueda

hacerlo. Aun así, se ha utilizado a la hora de recrear “La Cimbarra” y un personaje

en primera persona que se mueva por dicha zona para que el usuario pueda

explorar libremente el terreno. Y a pesar de haber hecho un prototipo funcional para

el proyecto, Unity no crea una web eficiente, de ahí que no se haya podido crear

todo el prototipo web de este TFG. También se ha utilizado ThreeJS para un “sub-

prototipo” importante dentro del desarrollo, principalmente porque existe un cargador

de modelos de alta resolución adecuado para los modelos usados en este proyecto,

y la interacción funciona eficientemente.

A pesar de todo eso, la opción que se ha utilizado ha sido 3DHOP, básicamente

porque, aunque tiene pocas opciones, tiene las necesarias para realizar un prototipo

web con el que compartir modelos 3D de patrimonio cultural o natural y hacerlos

interactivos. Además, se puede modificar la API sin mucha dificultad para editar las

opciones existentes o añadir algunas nuevas, sin contar con usar otras librerías de

terceros para ciertas tareas tal y como se clarificará en el capítulo de

implementación más adelante. La información para la siguiente descripción de este

software ha sido extraída fundamentalmente de su web y artículos en ella (alguno se

ha adjuntado junto a esta memoria).



65


4.3.1. Descripción del software

El objetivo de este proyecto es un prototipo web interactivo con modelos 3D, algo

que se puede llevar a cabo con WebGL, o más bien con un framework que facilite

ciertas tareas de cargar modelos como puede ser Three.js.

Pero usar cualquiera de estos frameworks o incluso WebGL a más bajo nivel

tiene varios problemas:

• La optimización del prototipo no es la más adecuada especialmente cuando

interactúan (rotando, haciendo movimientos de cámara, …) con el modelo en el

navegador de tu ordenador, ya que este empieza a ralentizarse, y dependiendo

del equipo, del navegador e incluso de la conexión a internet, se hacía dificultosa

la navegación, siendo aún peor desde un dispositivo móvil. Todo esto se debe en

parte a que los modelos usados para este proyecto son modelos obtenidos por

escaneo y fotogrametría y tienen una gran resolución.

• Una parte vital que debe tener el producto final es el etiquetado de modelos, ya

que al ser un software usado principalmente por modelos geométricos 3D que

representan patrimonio, pues tienen zonas de interés que deben ser destacadas

y explicadas como si de un museo interactivo se tratase.

Estos inconvenientes, que con otro framework de desarrollo de gráficos en la

web darían más problemas, se solucionan usando el framework “3DHOP”, con el

que podremos implementar a más alto nivel nuestro prototipo web teniendo ciertas

opciones avanzadas de una forma más simplificada.

3D Heritage Online Presenter (3DHOP) es un framework de código abierto para

la creación avanzada basada en web de presentaciones visuales de contenido 3D

en alta resolución, orientado principalmente a patrimonio cultural, aunque como

veremos cualquier modelo 3D es perfectamente válido.

Este software está escrito en JavaScript y basado en la librería SpiderGL, una

librería basada en WebGL puro y de muy similar implementación destinada a

operaciones matemáticas, principalmente matriciales necesarias para desarrollar

gráficos por las posiciones de la cámara, de la fuente luminosa, … Además, utiliza

también la librería jQuery.



66


3DHOP se centra en la facilidad de uso y una curva de aprendizaje no muy

compleja que varía dependiendo del uso y el resultado que deseemos obtener

finalmente.

La función clave de 3DHOP (véase también el artículo donde se explica en más

detalle y del cual se ha extraído la información) como se ha comentado

anteriormente es la de manipular mallas 3D o nubes de puntos de gran resolución

usando el enfoque de multiresolución. Mostrar modelos en un navegador no es solo

cuestión de optimizar la velocidad de renderizado, sino que hay que tener en cuenta

también el tiempo de carga y el tráfico de la red causado por transferir gran cantidad

de datos en la red. Mientras WebGL proporciona acceso directo a los recursos de la

GPU, y para cargar un modelo de gran resolución en la web se requiere transferir

una gran cantidad de datos, y esto es impráctico porque el usuario debe esperar y

se ralentiza. Pero con el enfoque de multi-resolución asegura eficiencia en los datos

que transfiere y en los que renderiza. Este esquema divide la geometría en

pequeñas partes, y cada parte tiene varios niveles de detalle. Así, se carga y se

renderizan las porciones del modelo estrictamente necesarias para la generación de

la vista, por lo tanto, es útil tanto para renderizar e interactuar modelos de mucha

resolución, como para mostrar modelos con una conexión de red lenta.

Las ventajas principales de 3DHOP son la carga rápida de modelos y la reducida

conexión de red necesaria para ello, en cuyo caso se cargará el modelo con baja

resolución, e irá mejorando si se pudiera debido a las fluctuaciones de la conexión.

Solamente aparecerán los datos de geometría estrictamente necesarios para la

dependiendo de la distancia, posición de la cámara, … que hayamos configurado.

3DHOP ha sido desarrollado por la gente del laboratorio de informática gráfica de

ISTI-CNR, Italia. Actualmente es usado en diferentes proyectos que redactan en su

propia página web relacionados con el patrimonio y los cuales aparecen algunos en

la sección de galerías de proyectos llevados a cabo con este software.

3DHOP además carga los modelos de la misma forma en la que vienen, es decir,

con el sistema de coordenadas original. Si usamos una herramienta de modelado

adicional como Meshlab, 3DHOP cargará el modelo de igual forma que al cargarlo

en esta herramienta, ya depende del usuario que quiera transformar el modelo a otra



67


posición con un software como Meshlab (en el apartado de preparación de modelos

para 3DHOP) o aplicar transformaciones geométricas con el propio framework hasta

que estemos conformes con la posición. Además, 3DHOP usa el clásico sistema de

la mano derecha en el que el eje Y es el (0, 1, 0).

Cualquier información adicional al respecto, así como para la descarga del

framework se puede consultar desde su página web “3DHOP”.

4.3.2. SpiderGL

SpiderGL es una librería gráfica desarrollada en JavaScript destinada al

rendering de gráficos en la web. Usa rendering con WebGL en tiempo real (véase la

referencia bibliográfica sobre esta librería gráfica).

Si ejecutamos una aplicación gráfica no muy compleja en cualquier navegador

hecha con WebGL puro o con algunos de los frameworks más populares basados en

WebGL como son ThreeJS, BabylonJS, Clara.io, …, observaremos que el ordenador

empieza a saturarse tal y como se ha comentado de pasada en el apartado 4.3.1 de

Descripción del software. Esto se debe a que evidentemente no es lo mismo ejecutar

una aplicación gráfica en un navegador que en una aplicación de escritorio por las

limitaciones que eso conlleva. Aun así, dentro de que cualquier software gráfico en

un navegador tiene ciertas limitaciones, con la librería SpiderGL y la colección de

herramientas Nexus se puede observar que apenas sucede esa ralentización.

Dicha eficacia se debe a que la mayoría de las librerías gráficas actuales

implementan un paradigma de grafo de escena.

Un grafo de escena es un grafo dirigido acíclico de nodos que contiene los datos

que definen un escenario virtual y controlan su proceso de dibujado. Contiene

descripciones de bajo nivel de la geometría y la apariencia visual de los objetos, así

como descripciones de alto nivel referentes a la organización espacial de la escena,

datos específicos de la aplicación, transformaciones, etc. Los grafos de escena

almacenan la información del escenario virtual en diferentes tipos de nodos.

Este paradigma de grafo de escena, aunque representa de forma natural lo que

es una escena, también tiene el inconveniente de que obliga al usuario a recurrir a

http://vcg.isti.cnr.it/3dhop/



68


esquemas complejos siempre que sea necesario más control sobre el flujo de

ejecución, y, por tanto, hay varias situaciones en las que la implementación de los

nodos de un grado de escena no es la más sencilla porque hay que sobre-escribir

métodos y en algunos casos implementar nuevos nodos del grafo. Por tanto, es más

práctico usar un paradigma procedural, tal y como ocurre con SpiderGL.

Este paradigma de programación de SpiderGL ofrece muy buena respuesta con

relación al tamaño de los programas, y en bruto casi no se nota en la velocidad de

ejecución de los mismos (mientras que las variables, constantes o índices

de vector estén en memoria, como suele ser normal, estos se relacionarán entre sí,

sin una carga de memoria considerablemente alta para los procesadores modernos)

aunque es muy complicado conseguir una programación por procedimientos pura.

En definitiva, SpiderGL es una librería que usa WebGL y que, en vez de

proporcionar un grado de escena a alto nivel, SpiderGL provee utilidades,

estructuras de datos, y algoritmos que simplifican la creación de aplicaciones web

3D, y mantiene la posibilidad de usar otro código WebGL en la misma aplicación.

Ahora, procedemos a ver la arquitectura de SpiderGL frente a otras librerías

gráficas:

En el caso de OpenGL, librería para gráficos 3D por excelencia y basada en

Direct3D de Microsoft, envuelve funcionalidad desde aceleradores de gráficos hasta

soporte para hardware moderno. Actualmente, OpenGL ha evolucionado a la versión

moderna y usada actualmente, “Core Profile”, que se basa en la versión móvil más

popular de OpenGL llamada “OpenGL ES 2.0”, que es la base de WebGL.

La arquitectura básica de una aplicación de OpenGL en base a la ilustración 4.39

es:



69


Ilustración 4.39- Arquitectura aplicación gráfica basada en OpenGL

• El módulo de aplicación lo desarrolla el programador.

• Windowing API son las funciones desarrollados para soportar OpenGL y que

manejan eventos de apagado, señales del área de dibujado de OpenGL o

contexto de rendering. Esas funciones pueden estar definidas por el SO o

incluso una librería basada en OpenGL.

• OpenGL API: son las funciones usadas para dibujar y provienen de un driver

de OpenGL activo.

• GLEW: es la utilidad más popular usada con las instrucciones de OpenGL,

también puede haber otras como GLKit en MacOS.

• OpenGL drivers: implementan los detalles de las funciones OpenGL pasando

los datos directamente al hardware 3D y realizando operaciones en la CPU.

En cambio, si escribimos un programa en WebGL, aunque es similar, muchas de

dichas funciones están ocultas para nosotros, de hecho, las llamadas de WebGL

pueden no ser ejecutadas por un driver de OpenGL, y esto varía dependiendo del

SO, ya que en Windows se añade una capa nueva desarrollada por Google llamada

“Angle” usada para trasladar los comandos de la API de WebGL al equivalente de

Direct3D que usa Microsoft.

La arquitectura será por tanto como vemos en las ilustraciones 4.39 y 4.40.



70


Ilustración 4.40- Arquitectura aplicación gráfica basada en WebGL en Windows

Ilustración 4.41- Arquitectura aplicación gráfica estándar en WebGL

Tras haber resumido la arquitectura básica de WebGL, procedo a explicar la de

SpiderGL. Esta librería gráfica está compuesta por 5 módulos, tal y como podemos

observar en la ilustración 4.41:



71


Ilustración 4.42- Arquitectura librería gráfica SpiderGL

• GL: es la parte de la arquitectura que da acceso a las funcionalidades básicas de WebGL puro.

Este módulo contiene una capa muy a bajo nivel que gestiona a bajo nivel estructuras de datos

sin lógica asociada. También posee una capa a más alto nivel compuesta por objetos y

propiedades matriciales.

• MeshJS: es la definición del modelo o modelos 3D y su renderizado. Este módulo proporciona

la implementación de una malla de polígonos, o como es llamada la función de SpiderGL

“SglMeshJS”, que permite al usuario construir y editar modelos 3D y sus imágenes desde la

GPU.

• Async: módulo que permite que SpiderGL pueda cargar contenido de forma asíncrona (suceso

que no tiene correspondencia temporal con otro suceso)

• UI: interfaz de usuario.

• Space: módulo con utilidades geométricas, matemáticas (matriciales especialmente).

En definitiva, las ventajas que esta librería proporciona son:

• Eficiencia: tal y como se ha hablado en la descripción previa de esta librería

JavaScript de WebGL.

• Simplicidad y corto periodo de aprendizaje: un usuario con algo de experiencia

en gráficos por ordenador, y en especial con librerías tan populares como

OpenGL o su versión web WebGL no tendrá problemas en usar esta librería

porque la base es la misma y reutiliza gran parte de la infraestructura.

• Flexibilidad: SpiderGL no intenta ocultar funcionalidades de WebGL ni intenta

re-implementarlas, puesto que son necesarias y funcionan correctamente.



72


Simplemente añade funcionalidades extra y específicas para ciertos ámbitos de

la programación gráfica para la web.

4.3.3. Preparación de modelos para 3DHOP

Antes de empezar a usar este software debemos convertir nuestros modelos al

formato de alta resolución soportado por esa plataforma y que nos permite

interactuar eficientemente con estos. Esto es un proceso que, aunque no

excesivamente complejo, puede llevar a errores no deseados si no se sigue

adecuadamente puesto que no hay mucha información al respecto en la web del

software.

Primero, en mi caso el formato de los modelos es ‘obj’, pero el formato que

soporta este framework es ‘ply’ por lo que debo convertirlo con cualquier software de

modelado, y además debe tener poca resolución (1MB o inferior), una situación que

no se da en mi caso por que manejamos modelos de gran resolución, por lo que

habría que hacer una conversión diferente.

Todo esto se debe a que 3DHOP soporta 3 tipos de modelos 3D:

• Modelos 3D de poca resolución que tal y como hemos indicado no deben

superar 1MB aproximadamente para que se pueda renderizar en la escena

correctamente.

• Nubes de puntos y modelos 3D de mucha resolución: deberán ser

convertidos al formato ‘nxs’ con el software adecuado para ello que se detalla

más adelante.

Si queremos usar modelos de poca resolución los tenemos que transformar al

formato ‘ply’ junto con las texturas que tengan. Para ello, usamos la herramienta

Meshlab, creada por el mismo equipo de desarrollo que el framework que usamos

para este proyecto. El proceso a seguir es el siguiente:

1. Se carga el modelo en Meshlab, con la opción pertinente para ello, o

simplemente arrastrando el modelo 3D a la ventana principal del programa

(cualquier formato es válido para que Meshlab sea capaz de interpretarlo).



73


2. Exportamos el modelo 3D a ‘ply’ marcando las opciones que se ven en la

ilustración nº 4.38 para que nos exporte el modelo con la textura cargada. De

esta forma al cargarlo en nuestra web no tendremos que cargar las imágenes

por un lado y el modelo por otro, simplemente cargamos el modelo que ya

incluye todo.

Ilustración 4.43- Exportación de modelo 3D en Meshlab

Si de lo contrario, necesitamos usar modelos de mucha resolución y que

obviamente ocupan más de 1 MB, necesitamos transformarlos a un formato especial

llamado ‘nxs’.

Los pasos a seguir para convertirlos a ese formato son:

1. Igual que antes se convierte a ‘ply’ con Meshlab y se exporta el modelo.

Aunque si los modelos están en formato ‘obj’ no es necesario convertirlos,

ambos son válidos.

2. Nos descargamos “Nexus”, una herramienta de código abierto diseñada por el

mismo equipo de desarrollo que los anteriores softwares nombrados y que

está disponible para JavaScript y C++ y con la que podemos visualizar

modelos 3D de gran tamaño en OpenGL y WebGL. El link de descarga de

Nexus: Adaptive 3D.

http://vcg.isti.cnr.it/nexus/




74


3. En la descarga, nos aparecerán unos ejecutables ‘exe’ que solamente

podremos probar en una máquina con Windows. Así, arrastramos nuestro

modelo 3D en formato ‘ply’ o ‘obj’ al ejecutable llamado “build.exe” y nos

convertirá ese modelo a un modelo de gran resolución que ocupa menos

tamaño y que será mucho más eficaz para cargarlo con el framework elegido.

A pesar de realizar esto, es posible que no funcione la conversión, por lo que

habría que seguir los estos pasos:

a) Colocar el modelo 3D en la misma carpeta en la que esté el ejecutable.

b) Abrir la consola e ir al directorio donde esté el modelo y el ejecutable.

c) Poner en la consola “nxsbuild nombreModelo.ply -o

nuevoNombreModelo.nxs”.

d) Esperamos unos segundos y se habrá creado y guardado el nuevo

modelo 3D en el directorio en el que estamos.

Si tuviéramos modelos que son nubes de puntos, ya sean de gran formato o no,

el proceso es idéntico a las 2 opciones anteriores, dependiendo de nuestro modelo.

4.3.4. Nexus

Nexus es una colección de herramientas para la visualización de mallas de

triángulos o modelos 3D y nubes de puntos en OpenGL. La principal funcionalidad

de este conjunto de herramientas es la librería para visualizar y realizar rendering

interactivo con modelos de gran resolución. El algoritmo encargado de esto consiste

en separar el modelo en “parches”, los cuales los iniciales representan los niveles

más altos de detalle de la representación de multi-resolución. El número de

triángulos de cada parche se reduce a la mitad, y los parches adyancentes se unen,

así se mantienen más o menos uniformes el número de triángulos por parche. Los

distintos niveles de detalle se logran iterando de abajo a arriba. Y cuando toque

renderizar el sistema decide cuales son los mejores parches para mostrar el objeto

en el menor tiempo posible y con el menor error de geometría.

Nexus para realizar el renderizado de modelos con multi-resolución debe

convertirlos por medio de una herramienta de esta colección de herramientas tal y



75


como se ha dicho en el apartado anterior. Además, también debemos destacar que

Nexus tiene más opciones, algunas de las cuales nos serán de utilidad en este

proyecto, como se ve en la “visualización con ThreeJS y Nexus” explicada mejor en

el apartado correspondiente de la implementación.

Las características de este software son las siguientes:

• Conversión de modelos de mucha resolución.

• Compresión de modelos.

• Es una librería de WebGL.

• Integración con Three.js: permite cargar modelos de ala resolución de forma

muy sencilla en Three.js, uno de los frameworks más populares y con más

documentación para gráficos basados en web.

• Integración con 3DHOP.

4.4. Web estática vs Web dinámica

Es esencial saber la diferencia entre estas dos modalidades de páginas webs

para diseñar e implementar la que mejor se adapte a las necesidades y el propósito

de nuestro proyecto (véase la referencia correspondiente).

En resumen, se puede decir que una web estática es aquella cuyo contenido no

puede ser editado o cambiado sin que el desarrollador cambie el código fuente.

Mientras que una web dinámica puede mostrar diferente contenido a partir del

mismo código fuente con diferentes opciones y funciones de la propia web.

Web estática

Este tipo de web contiene un nº fijo de formatos y contenido para la web los

cuales pueden ser fruto de conversaciones con el cliente. Es un diseño que

muestran la misma información siempre sin importar quién sea el visitante.

Este tipo de páginas web no tienen por qué ser texto plano, sino que pueden

contener multimedia. Sin embargo, cada usuario que visita la web recibirá el mismo

texto o contenido multimedia cada vez que la visite, salvo que alguien cambie el

código fuente de la web.



76


Obviamente, la web de este proyecto no puede tener un diseño estático tal y

como se ha pensado y descrito en el storyboard.

Web dinámica

En este caso, la web puede cambiar su contenido dinámicamente mientras la

página sigue ejecutándose en el navegador del cliente. Esto es gracias a usar una

programación cliente-servidor con lenguajes como PHP, JavaScript, Asp.NET, …

para modificar el contenido en tiempo de ejecución. Usan scripts en el lado cliente

para preparar un diseño dinámico y un código cliente-servidor que maneje los

eventos, las cookies, almacene datos de una base de datos, …

La gran mayoría de las webs que normalmente podemos visitar en internet, como

por ejemplo una red social, son ejemplos de web dinámicas.

Las páginas web dinámicas son incluso capaces de producir diferente contenido

según los diferentes usuarios que visitan la web, y siempre a partir del mismo código

fuente. Es decir, estas webs pueden mostrar contenido diferente basándose en el

SO, el navegador, el dispositivo o el visitante que la use.

Una web dinámica no necesariamente es mejor que una estática, son para

propósitos diferentes.

Actualmente, se suele preferir una web dinámica por los beneficios de producir

contenido de calidad con muchas más opciones. Y a pesar de las ventajas, existen

los inconvenientes de ser más costosas de mantener porque hay que corregir mayor

número de errores, adaptarse a actualizaciones de seguridad conlleva más tiempo,

un mayor coste de desarrollo por tener un código más complejo, y la necesidad de

usar algún hosting web que soporte bases de datos, la complejidad del uso de

lenguajes de programación dinámicos,

En cuanto a nuestro proyecto, utiliza una web dinámica por todos los

cambios que con diversas funciones van sucediendo en la web gracias a todo el

código JavaScript implementado, junto al uso de cookies del navegador para



77


guardar ciertos datos, el uso de un servidor web, entre otras opciones que se

explican en detalle en el capítulo de la implementación.

4.5. Responsive vs Adaptive

Después de ver en las ilustraciones del storyboard cómo es estéticamente la

web, hay que explicar la diferencia entre dos conceptos de diseño web, explicando

con cual de ambos nos hemos quedado para nuestro prototipo y el porqué.

Hay un importante debate a la hora de desarrollar una web, y los desarrolladores

dudan de qué opción es mejor para su propósito puesto que hay una diferencia entre

web que responde a tamaños de pantalla o dispositivos, y web que se adapta a

cambios de dispositivos, es decir, “responsive web design” frente a “adaptive web

design”. Todo esto dejando a un lado el rudimentario diseño de una web

completamente estática.

A continuación, se describen las características de estos dos tipos de diseño de

páginas web (véase la referencia correspondiente).

La diferencia entre ambos modelos de desarrollo es:

“Responsive design” o diseño adaptativo es aquel diseño que es fluido y que se

adapta al tamaño de pantalla sin importar el dispositivo que sea. Para realizar esto,

estos diseños utilizan “media querys” de CSS que cambian los estilos en base al

dispositivo en el que se esté usando, según sea el ancho y el alto de su tamaño de

pantalla.

En cambio, un diseño más estático o “adaptive design” es aquel que detecta el

tamaño de pantalla y carga el diseño adecuado, por lo que generalmente el

desarrollador debe crear un diseño adecuado para varios tamaños de pantalla que

normalmente son 6 tipos de resoluciones (320, 480, 760, 960, 1200, 1600).

Además, hay otros diseños que no tienen en cuenta el tamaño de los dispositivos

en los que se ejecutará la aplicación. Desarrollan el producto obviando la variedad

de dispositivos. Esta limitación es excesivamente severa dada la diversidad que

existe en el mercado (véase la ilustración 5.11).



78


Ilustración 4.44- Información uso de internet según el dispositivo

A simple vista parece que el diseño “adaptive” requiere más trabajo porque

habría que diseñar para diferentes tipos de dispositivos. Sin embargo, las

responsivas pueden llegar a ser más complejas por las “media queries” y pueden

provocar errores en el rendimiento. Otra dificultad en el “response design” es la

ordenación de elementos en base al tamaño de pantalla, ya que errores en la

reordenación perjudican la experiencia de usuario.

Otro factor a tener en cuenta es el rendimiento, una “response web” conlleva

menos trabajo que adaptar a muchas resoluciones nuestra web, de ahí que sea lo

más demandado actualmente, aunque ofrece peor rendimiento (véase la ilustración

5.12).

Ilustración 4.45- Comparativa “adaptive web” vs “responsive web”

4.5.1. ¿Porqué usar un diseño “adaptive web”?

Este diseño es útil cuando queremos añadir funcionalidad a un sitio web para

que sea “mobile friendly”, es decir, que sea posible usarlo en dispositivos móviles y

tablets. Esto permite tomar el control por completo y desarrollar específicamente

para un tamaño de viewport (un tipo de resolución) específico, el que deseemos en

un instante, por lo que tenemos más control que si realizásemos un diseño

responsive.



79


4.5.2. ¿Porqué usar un diseño “responsive web”?

Actualmente es el más usado por ser más sencillo para desarrolladores y

diseñadores menos experimentados, en especial si se usa con un CMS (content

manager system o sistema de gestión de contenidos que permite crear una

estructura o framework del contenido de una web) como Drupal, Wordpress, …

Este diseño no ofrece tanto control como el anterior, pero evita un trabajo

extra en cuanto a construcción y mantenimiento, además de ser más fluido.

4.5.3. Solución adoptada para este proyecto

Durante todo el proceso de desarrollo del proyecto se han llegado a implementar

ambas opciones, aunque finalmente para el prototipo web se ha optado por una

versión adaptable.

El prototipo realizado para la visualización con ThreeJS y Nexus al tener menos

código y muchas menos funcionalidades, sí que se creó totalmente adaptable, tal y

como podemos observar en las siguientes ilustraciones capturadas (5.13, 5.14) de

un prototipo destinado a probar este diseño y la función de añadir modelos. Por

tanto, no importa el tamaño al que ajustemos el navegador en el cual carguemos el

prototipo web.

Ilustración 4.46- Web adaptable imagen 1



80


Ilustración 4.47- Web adaptable imagen 2

El inconveniente de dicha implementación a pesar de lo favorable que a priori

parece es que en el prototipo final no hay tan pocos elementos en pantalla, y por

tanto habría que controlar la jerarquía de estos cuando se redimensionase la

ventana, algo que dificulta la implementación del diseño adaptable, pero que resulta

más cómodo que adaptar la web a diferentes tamaños de pantalla de distintos

dispositivos.

Por tanto, la solución adoptada para la parte principal del prototipo, ha sido hacer

la web adaptable según el dispositivo, pero no de forma tan notable como en el

prototipo mostrado en las ilustraciones anteriores, sino con estructuras de CSS que

se añaden a los elementos de la web y que funcionan con porcentajes, es decir, por

ejemplo, de ancho ocupa el 50% del viewport. Esto implica que la web siempre

tendrá el mismo aspecto sea cual sea el dispositivo donde se ejecute, aunque se

vea con más dificultad al tener menos tamaño un dispositivo móvil, por ejemplo

(ilustración 5.15). Estas estructuras junto con la opción de JavaScript de re-

dimensionar el canvas son suficientes para nuestro propósito, ya que hacerla

totalmente adaptable sería más lógico al desarrollar una web con un CMS desde

cero, algo que queda fuera del alcance del proyecto.



81


Ilustración 4.48- Web visualizada en un móvil

En la ilustración anterior 5.15. se puede ver que para probar el prototipo en un

dispositivo móvil antes de que la web estuviera subida a un servidor físico, se tuvo

que utilizar un sistema que permitiera alojar la web en algún repositorio.

Dicha tarea se ha hecho con “Github Pages”, un servicio estático de hosting. En

definitiva, GitHub pages está diseñado para ser un host personal para organizar

mejor tus repositorios. Y cabe destacar que no soporta código servidor tal y como

ocurre con ruby, python o php al ser servicios estáticos de hosting. Para más

información, ver el anexo que explica el proceso de subida de un proyecto a esta

plataforma.

4.6. Diagrama de casos de uso

Los diagramas de casos de uso representan cómo un actor o usuario puede

operar con un sistema de desarrollo. Por tanto, en el caso de este proyecto,

solamente se ha desarrollado un único diagrama de casos de uso porque solamente

un usuario va a interactuar con el sistema en un instante.

La relación entre los actores en este caso es de un único actor, el usuario que

interactúa con la web y el sistema que controla la web. Esta relación se describe



82


mediante modelado UML con un diagrama de casos de uso general del proyecto, es

decir, con los objetivos esenciales del proyecto.

En definitiva, la ilustración 5.12 podemos observar de forma general las

relaciones entre los casos de uso del software desarrollado, el actor o usuario, y el

sistema. Podemos ver que el prototipo web está formado por una serie de funciones

independientes unas de otras que pueden ser activadas o desactivadas por el

usuario en cualquier momento.

Ilustración 4.49- Diagrama de casos de uso del proyecto

Tal y como se puede observar en el diagrama anterior, el usuario puede:

- Interactuar con el modelo 3D cargado: moverlo, rotarlo, realizar

transformaciones geométricas sobre él, hacer zoom, movimientos de Pan.

- Cambiar el modelo 3D para cargar otro disponible en la web.

- Añadir modelos 3D a la web a forma de museo en una de las funcionalidades

implementadas para uno de los prototipos.

- Modificar la transparencia con la que se ve el modelo 3D cargado en el canvas

de la web.

- Cambiar idioma de la web (implementada con español e inglés).



83


- Realizar una animación prefijada de ruta sobre el modelo 3D principal del

prototipo.

- Medir distancias entre dos puntos colocados sobre el modelo 3D.

- Activar animación constante en el eje Y.

- Consultar información descriptiva de puntos de interés del modelo con etiquetas

sobre este.

- Descargar modelo 3D.

- Medir superficies del modelo 3D.

- Herramienta de creación de animaciones sobre el modelo 3D con posibilidad de

almacenamiento.

- Ver ayuda de la web.

- Ver visualización con Unity3D del modelo 3D.

- Observar la zona del modelo principal de la web en GoogleMaps con

características añadidas de interés (medir distancias, superficies, …).

- Visualización con ThreeJS y Nexus de la web.

- Cambiar las perspectivas con las que se observa el modelo 3D.

4.7. Lenguajes de programación, servicios, librerías

El lenguaje del proyecto es JavaScript (JS web), porque es el lenguaje que todos

los framework para gráficos en la web utilizan.

También es el lenguaje usado por API’s usadas como la de GoogleMaps (véase

referencia) o OpenWeatherMaps (véase referencia). Además, al ser una web se ha

usado también HTML5 y CSS.



84


En la parte que se ha implementado en Unity, el código ha sido creado en C#,

puesto que es la única opción que soporta este motor, aunque luego lo exportamos

al formato deseado, en este caso a WebGL y HTML5.

Las librerías que se han usado para este proyecto y que complementan el

prototipo basado en 3DHOP han sido:

• JQuery: es una biblioteca multiplataforma de JavaScript, que permite

simplificar la manera de interactuar con los documentos HTML, manipular el

árbol DOM, manejar eventos, desarrollar animaciones y agregar interacción

con la técnica AJAX a páginas web como en la función de etiquetado con

información meteorológica implementada en el prototipo.

• SweetAlert: una librería JavaScript para la creación de todo tipo de alertas

en una web de forma agradable estéticamente, adaptativas, personalizables

y accesibles. Se ha usado en múltiples funciones para cambiar de modelos,

añadir modelos, entre otras funciones (véase la documentación de su web).

• Google Maps: tal y como se ha comentado anteriormente para datos

geográficos se ha usado la API de Google Maps.

• Measure tool for google maps: una librería JavaScript que permite realizar

medidas sobre distancias seleccionadas en un mapa de Google Maps. Se

ha usado para complementar la herramienta de áreas implementada.

• Open Weather Map: tal y como se ha comentado anteriormente, se ha

usado esta librería de JavaScript que proporciona datos meteorológicos

sobre una localización. Se ha usado para complementar la funcionalidad de

etiquetado con datos geográficos y meteorológicos.

• Librerías necesarias para 3DHOP: SpiderGL y Nexus, explicadas en el

apartado 4.3.3 y 4.3.4.

4.8. Principales funciones a desarrollar en el proyecto

El proyecto debe tener, tal y como se especifica en los objetivos, una serie de

funciones vitales que no deben faltar para cumplir satisfactoriamente con los

objetivos mínimos. Dichos objetivos se han ido realizando por medio de prototipos

siguiendo una metodología incremental. Por tanto, el prototipo final producto del

desarrollo debe tener al menos:

https://es.wikipedia.org/wiki/Multiplataforma



85


• Creación de un entorno web en el que se puedan cargar modelos 3D de

gran resolución y se pueda interactuar con ellos de forma eficiente.

• Adaptar la web estética y funcionalmente para poder documentar los

modelos 3D cargados, es decir, que se puedan documentar o dar

información sobre dichos modelos.

• Creación de etiquetado informativo interactivo sobre el modelo 3D.



86


5. Diseño

En este capítulo se analizan en detalle las características del prototipo. Algo

fundamental para una correcta implementación.

Para realizar este estudio se utiliza la herramienta Visual Paradigm Standard

Edition versión 14.2.

Así, en este capítulo se mostrarán diagramas en UML (lenguaje unificado de

modelado) que representan como implementar el prototipo, y un primer vistazo de

cómo será la aplicación que finalmente se implementará, además de un pequeño

estudio del patrón MVC (Model-View-Controller) seguido para el desarrollo.


• Patrón Modelo-Vista-Controlador

• Storyboard

• Diagrama de clases

• Diagramas de actividad

• Diagramas de secuencia

5.1. Patrón Modelo-Vista-Controlador (MVC)

El patrón MVC (Model-View-Controller) es el usado para el desarrollo del

prototipo debido a que se puede dividir la aplicación en 3 partes fundamentales. Es

muy común el uso de este patrón en lenguajes de desarrollo web como JavaScript,

tal y como sucede en este proyecto.

Mucha información sobre este patrón de diseño se encuentra en el libro Hear

First Design Patterns.



87


Ilustración 5.1- Esquema MVC

Ventajas de este patrón:

• Se separa la lógica de negocio del diseño, se independiza la interfaz de

usuario, la lógica y los datos, haciendo el proyecto más escalable.

• Separación modelo y vista, lo que implica separar los datos de su

representación visual.

• Muchos frameworks MVC incluyen librerías de JavaScript, como por

ejemplo Jquery, muy usada en el proyecto.

• Facilita el manejo de errores al haber más control y organización.

• Posibilidad de añadir múltiples representaciones de los datos.

Desventajas de este patrón:

• Hay que manejar más archivos y aumenta la complejidad.

5.1.1. Patrón MCV en una aplicación gráfica

Un programa interactivo que sigue el patrón MVC debe tener esos 3 aspectos,

y el caso del framework de desarrollo gráfico usado para este proyecto no podría ser

menos. Así, orientando las 3 partes de esta arquitectura a un programa gráfico, son:

• El modelo consiste en la descripción de la geometría, el posicionamiento

en la escena, es decir, la apariencia en general junto a la iluminación. Lo

normal es cargar todo esto desde un único archivo.



88


• La vista consiste en las llamadas al rendering de OpenGL para lanzar el

contesto gráfico, interpretar el modelo/os y enviar todo para que sea

dibujado.

• El controlador normalmente es un conjunto de funciones que el

programador escribe para responder a eventos vía la ventana de la app,

es decir, eventos de ratón, de teclado, o de cualquier periférico hardware

externo.

Por tanto, el modelo y la vista estarán acoplados mutuamente, y tendremos

algunas variables para controlar la inicialización de la escena y controlar a la propia

escena en sí.

También hay que tener en cuanto que todo programa gráfico con OpenGL o

su variante para móviles o web responde al menos a 2 eventos principales:

• SetUp

o Adquirir el contexto gráfico para renderizar, y dependiendo de cómo

consigamos esto, se determinará como será nuestra ventana.

o Configuración de la escena inicial en OpenGL: es necesario cargar,

compilar y activar un o varios programas shaders para llevar a cabo

el dibujado. Y también es una buena opción precargar algunos

objetos que deseemos dibujar en el bufar de datos y conectarlos al

programa shader directamente.

• Rendering

5.1.2. Patrón MCV en este proyecto

Modelo: es el componente central del patrón. Se encarga de manejar los datos,

la lógica y las reglas de la aplicación, y es independiente de la interfaz.

En el proyecto, el modelo es lo correspondiente al archivo “cimbarra.js” puesto

que se encarga de la gestión de estructuras de datos asociadas a la

aplicación. Además, hay que recalcar que no se puede reducir el modelo a un

único archivo, ya que “cimbarra.js” hace uso de varios archivos como el que

controla la estructura de datos de internacionalización, la librería



89


“MeasureTool” para medir distancias en GoogleMaps, la API de “open

weather map”, …

Vista: representa lo que el usuario puede ver, y se encarga de recolectar los

datos que el modelo le envía.

En el proyecto, la vista está claro que es el archivo “index.html”, que es lo que

el usuario verá, la interfaz con todas las opciones de interacción, es decir, la

parte visual de la web. Esta capa de la vista (interfaz) será informada por

eventos de ratón de las interacciones que el usuario en la web, y está definida

por varios elementos:

- Columna izquierda de la tabla que representa el canvas con botones y

posibilidad de interactuar con modelo 3D cargado.

- Columna de la derecha de la tabla que mostrará información sobre el

modelo 3D y en la que aparecerán opciones de interacción como

botones, vídeos, … Además, hay que detallar que esta columna se

divide en 3 partes a las que accederemos con diferentes etiquetas

mediante jQuery. Estas sub-partes son el título, la descripción (ocupa la

mayor parte del espacio y posee una barra de “scroll” para bajar en

caso de que haya mucho texto), y una parte llamada extra para añadir

cualquier tipo de información que se considere necesaria.

- Mapa de google.

Controlador: responde a las interacciones del usuario en la aplicación y avisa al

modelo de las acciones realizadas por el usuario en la vista. Además, al igual que el

controlador avisa al modelo de cambios en la vista, también avisa a la vista de

cambios en el modelo.

En el proyecto, el controlador está formado por varios archivos como son el

“init.js” para los elementos gráficos cambiantes de las funcionalidades del

canvas de la web, y el archivo “presenter.js” para controlar la parte gráfica de

la web.



90


Por lo tanto, cuando el usuario de la web realiza una función con alguno de los

botones del canvas, con el mapa de Google, o con algún otro elemento de la web

como puede ser los “radio buttons” de cambio de idioma, lo realiza sobre la vista, de

forma que esas interacciones serán enviadas al controlador de la web que para

realizar la función que corresponda los enviará al modelo o si no es necesario los

realizará sin más.

Además, tal y como se ha descrito anteriormente, el modelo y el controlador de la

web disponen de varias capas, es decir, varios archivos forman parte de respectivas

entidades.

5.2. Storyboard

En este apartado se tiene en cuenta cómo será la interfaz de usuario en el

prototipo una vez pensado el objetivo y las funcionalidades que deberá tener la web

y con las que el usuario podrá interactuar.

A continuación, se muestra un storyboard a partir de un prototipo en papel. El uso

del storyboard es útil para saber cómo quedará de manera aproximada la web, sirve

para tener una primera visión. Para su realización se ha usado la herramienta de

storyboard de Visual Paradigm, con la cual se puede ir modificando cualquier

elemento del diseño en cualquier momento del desarrollo del prototipo, ya que

aunque el storyboard describe cómo será el prototipo, está sujeto a cambios que

puedan surgir durante la implementación del mismo.

En la página inicial de la web aparecerá una tabla de dos columnas y una única

fila, en la que a la izquierda aparece el canvas con el modelo 3D y las opciones

disponibles, y a la derecha información dependiendo de la opción que se esté

ejecutando en un instante. Además, abajo aparecerá un mapa de google que

aportará funcionalidades extra.



91


Ilustración 5.2- Storyboard página inicial

De la página de inicio de la ilustración 5.2 aparecen más ilustraciones dependiendo del

botón con el que interactuemos en la web.

Una de las opciones del canvas es la de medir distancias, que tras seleccionar la opción

correspondiente permitirá hacer click en dos puntos del modelo para medir las distancias

entre ellos. Esta funcionalidad se puede ver en la ilustración 5.3.

Ilustración 5.3- Estado web tras activar herramienta de medir distancias



92


Otra de las opciones es la de interactuar con otro modelo cambiándolo con un

desplegable que aparece en una alerta, seleccionado otro modelo de los disponibles, e

interactuar con él de nuevo en el canvas tal y como se observa en la ilustración 5.4.

Ilustración 5.4- Estado web cambio modelo 3D

De forma muy parecida a la función de medir distancias se realiza la función para saber

las coordenadas donde se hace click en un punto del modelo 3D (ilustración 5.5).

Ilustración 5.5- Estado web herramienta pick-point



93


Otra opción reflejada en el storyboard es la de animación predefinida de ruta, que

también es válida para la rotación continua en el eje Y. Simplemente se seleccionaría esa

opción y observaríamos el resultado. Esta opción aparece activada en la imagen 5.6.

Ilustración 5.6- Estado web animación ruta

En cuanto a la función de etiquetado, tras seleccionarla, deberemos pulsar sobre

la etiqueta deseada dependiendo de la información del lugar que queramos conocer.

Además, tras pulsar la etiqueta se realizará una animación personalizada a dicha

zona. Todo esto se puede ver representado en la parte del Storyboard que aparece

en la ilustración 5.7.

Ilustración 5.7- Estado web herramienta etiquetado



94


En cuanto a la opción de Unity, tras seleccionarla se nos abrirá otra pestaña en el

navegador con la visualización realizada en Unity de la zona de interés del proyecto,

La Cimbarra. Se puede ver el proceso en la ilustración 5.8.

Ilustración 5.8- Estado web visualización Unity

Otra opción es la del cálculo de áreas, en la que aparecerá un modelo de un

cubo que podemos escalar, trasladar y rotar para posicionarlo donde y con las

dimensiones deseadas y calcular el área de la zona que abarca dicho cubo en el

modelo principal de la web.

Ilustración 5.9- Estado web tras activar herramienta superficies

Y finalmente, la opción de etiquetado con otro tipo de información es muy similar

a la de etiquetado explicada anteriormente, con la diferencia de que en lugar de



95


mostrar información textual o con contenido multimedia de cómo es la zona, las

características que tiene, …, muestra información meteorológica actualizada al

instante en al que se ha seleccionado la opción.

Ilustración 5.10- Estado web etiquetado meteorológico

5.3. Diagrama de clases

En esta sección se muestra el diagrama de clases que describe la estructura del

sistema mostrando las clases del sistema, sus atributos, operaciones o métodos, y

las relaciones entre los objetos.

En este caso al ser una aplicación web no son clases en sí, si no que se han

diferenciado según el tipo de función que realizan, ya que, además, en la práctica

están separadas en diferentes archivos.

El diagrama de clases que se puede observar en la ilustración 5.16 dadas sus

dimensiones no se ve excesivamente bien, por lo que se recomienda ver el archivo

“Diagrama de clases del TFG” adjuntado junto al código del proyecto para ver la

imagen en mejor calidad.



96


Ilustración 5.11- Diagrama de clases del proyecto

Por tanto, tal y como vemos en la ilustración 5.16, disponemos de una clase

principal llamada “index.html” que es la que crea la página web en sí, es decir,

donde se crea la interfaz de la web y se controlan los eventos que puede realizar el

usuario. Esta clase se comunica prácticamente con todos los archivos u otras clases

encargadas del funcionamiento de la aplicación.

Se comunica con el archivo “init.js” para la inicialización de los elementos

gráficos del canvas donde se presentan los modelos 3D y que es creado desde la

clase principal index.

En esta clase principal se crea inicialmente el mapa de la web, por lo que se

comunica con la API de GoogleMaps.

Además, al ser creada la web desde dicho archivo principal, necesita acceder a

muchas clases para adoptar los estilos de la web. Por tanto, hace uso de

SweetAlert.js, CustomScrollBar.css, CimbarraStyle.css, 3dHOP.css.



97


Y en cuanto al funcionamiento más específico de la web, necesita acceder a la

clase donde se almacena la matriz que controla el cambio de idioma para la

internacionalización de la web (“DataStructureLenguage.js”), así como a la clase

“presenter.js” encargada de inicializar el funcionamiento de 3dhop, junto a

cimbarra.js para inicializar el funcionamiento de las diferentes funciones y textos

informativos que acompañan al canvas en la web.

La clase index.html posee los siguientes métodos principales:

- initMap(): inicializa el mapa de la web en la zona correspondiente a La Cimbarra.

- changeLenguageFunction(): se encarga de cambiar de idioma todos los

elementos internacionalizables de la web accediendo a la estructura de datos

adecuada para ello.

- setup3dhop(): inicializa el contenido del canvas cargando los modelos 3D

disponibles para la web, así como sus posiciones iniciales, y las etiquetas que

poseen.

- onPickedInstance(id): se encarga de mostrar la información dependiendo de la

etiqueta seleccionada siempre y cuando la opción de ver etiquetas esté habilitada.

- onPickedSpot(id): se encarga de realizar animación sobre la etiqueta

seleccionada para observar la zona de interés mejor.

- onEndMeasure(measure, p1, p2): se encarga de calcular y visualizar el cálculo

de la distancia entre dos puntos seleccionados en el modelo 3D con la

funcionalidad correspondiente activada.

- onEndPick(point): muestra las coordenadas geométricas del punto seleccionado

en el modelo 3D.

- actionsToolbar(action): función encargada de responder a las acciones del

usuario sobre las opciones del canvas de la web, básicamente activa las funciones

disponibles en la web.



98


- rotationYAxisFunction(): función que realiza una animación continua en el eje Y

del modelo cuando se activa la función correspondiente de la web.

- refreshAnimation(): función que realiza una animación personalizada de ruta

sobre el modelo cuando se activa la función correspondiente en la web.

- helpSwitch(): función encargada de mostrar una alerta con la ayuda de la web.

- changeModelFunction(): función encargada de mostrar una alerta con un

desplegable para seleccionar el modelo 3D que deseamos visualizar.

También, del diagrama de clases de la ilustración 5.16 anterior hay que destacar

que algunas de las clases o archivos conectados con la principal, también se

comunican con subclases. Es el caso de “presenter.js”, que para crear

correctamente el entorno 3DHOP debe comunicarse con otros ficheros como son

SpiderGL.js (librería gráfica basada en WebGL), TrackBall.js (interacción con

modelos) y Nexus.js (cargar modelos de alta resolución en la web).

En cuanto a la clase “cimbarra.js”, los métodos que tiene son:

- changeStringToHTMLString(texto): función que, dada una cadena de texto

normal en español, la transforma a una cadena de texto apta para ser

representada en html, es decir, añade el código de tildes que usa html.

- openGeologicalCimbarraInformation(currentLenguageSelected): función

que, dependiendo del idioma seleccionado para la web, al utilizar una de las

etiquetas que muestra información geológica sobre La Cimbarra, la abre en otra

pestaña del navegador, en otro fichero con formato ‘html’.

-openMoreTrilobitesInfo(currentLenguageSelected): función que,

dependiendo del idioma seleccionado para la web, al utilizar una de las etiquetas

que muestra información sobre unas rocas de la Cimbarra, la abre en otra

pestaña del navegador, en otro fichero con formato ‘.html’.

- openRipplesImages(): función que muestra una alerta con varias imágenes

sobre la sección de ripples del modelo 3D de la Cimbarra cuando se selecciona

el botón adecuado dentro de las etiquetas implementadas.



99


- selectionOfTrilobitesVideo(): método encargado de activar o desactivar uno

de los dos vídeos informativos colocados en una de las etiquetas implementadas.

- setInfo(model, currentLenguageSelected): función encargada de mostrar la

información correspondiente en el idioma adecuado del modelo 3D activo en el

canvas en un instante. Dicha información puede ser textual, o gráfica en forma de

imágenes y/o vídeos.

- setInfoAnnotation(annotation, currentLenguageSelected): función

encargada de mostrar la información correspondiente en el idioma adecuado de

la etiqueta seleccionada sobre el modelo tras haber activado la función

correspondiente. Dicha información puede ser textual, en forma de vídeo o

imágenes, e incluso información meteorológica de la zona (gracias a una API

externa de JS usada) o información geográfica de dimensiones de la zona

seleccionada o incluso añadiendo un marcador de un punto de interés específico

en el mapa de google de la web.

- addMarker(latilongi, map, letter): función encargada de añadir un marcador al

mapa de Google de la web con una latitud y longitud, el nombre del mapa y el

nombre del marcador pasados como parámetro todos.

- addMeasureToolToMap(): función encargada de activar la herramienta de

medir distancias/áreas sobre el mapa de Google de la web gracias al uso de otra

API externa de JS.

- weatherInfoOfMap1HotSpot(): función encargada de obtener la información

con Ajax (Asynchronous JavaScript And XML) de unas coordenadas introducidas

gracias a la API de JS de Open Weather Map.

- setInfoAnimationTool(currentLenguageSelected): función que muestra

información para poder utilizar la herramienta de creación de animaciones

implementada, además de los controles correspondientes para crear, guardar,

eliminar y ejecutar animaciones.



100


- InsertCookieWithPos(): función encargada de guardar las posiciones de una

animaciones realizada con la herramienta de animación. Estos datos se guardan

en una cookie del navegador.

- ResetAllCookieWithPos(): función que resetea todos los datos de

animaciones guardadas previamente.

- mySelectAlertAnimations(): función encargada de mostrar una alerta con un

desplegable para seleccionar qué animación ejecutar entre las guardadas en la

herramienta de animaciones.

- errorMessageSpanish(): función encargada de mostrar un mensaje de error

cuando algo ha fallado en la herramienta de creación de animaciones.

- setUnity(model, currentLenguageSelected): función que dependiendo del

modelo 3D activo en el canvas, tras activar la funcionalidad del visualizado con

Unity del modelo 3D principal de “La Cimbarra” permitirá abrir la app web

realizada con Unity.

- openUnityViewerEnOtraVentana(): función que tras activar la opción de Unity

con el método “setUnity(…)” permite abrir en otra pestaña del navegador la web

de Unity tras haber pulsado el botón correspondiente.

Cabe destacar que algunos de los métodos de la clase “cimbarra.js” utilizan

jQuery para simplificar la programación en el lado del cliente de HTML (crear

botones para ciertas funciones, abrir pestañas del navegador con otras direcciones

de web, …).

Métodos de la clase encargada de la internacionalización de la web:

- getLenguage(lenguage): función encargada de devolver el array del idioma

correspondiente, es decir, la fila correspondiente de la matriz de elementos

internacionalizados.

Métodos de la clase encargada de la clase init.js:



101


- init3dhop(): método encargado de inicializar los elementos y tamaño del

canvas donde se visualiza el contenido 3D de la web.

-Diversos métodos para controlar la activación o desactivación de los botones

que habilitan diferentes opciones en la visualización en 3DHOP. Son funciones

JavaScript que gracias a jQuery podemos implementar código CSS en ellas de

forma que se encargan de cambiar el icono dependiendo de si una funcionalidad

está o no activa.

- Funciones para resetear los valores por defecto de las funcionalidades que

tengan algún tipo de ‘slider’ u otro componente en un desplegable que aparece

tras activar la funcionalidad. Esto sucede en las funciones de área, de

transparencia, y de transformaciones geométricas.

Métodos de otras clases:

Se han creado otros métodos necesarios en otras clases tal y como se puede ver

en el diagrama de clases anterior, y se describirán en el apartado de implementación

ya que no son vitales para el entendimiento general de la aplicación.

5.4. Diagramas de actividad

A continuación, se muestra los diagramas de actividad del proyecto y sus

funcionalidades. Estos diagramas son muy útiles para mostrar cómo funciona un

software y las posibilidades tiene, así como los estados por los que pasa cuando

ejecutamos ciertas tareas.

Primero es interesante mostrar un diagrama de actividad en el que se muestren

las actividades que se han realizado en el proyecto (ilustración 5.13). Dado su

tamaño se adjunta este diagrama junto con esta memoria con el nombre de

“Diagrama actividad de la app”.



102


Ilustración 5.12- Diagrama de actividad general del proyecto

Ahora, se describen los diagramas de actividad de las funciones

implementadas en el prototipo web de este proyecto:

5.4.1. Diagrama actividad transformaciones geométricas

Aquí se muestra el diagrama de las actividades por las que pasa el prototipo web

cuando un usuario desea utilizar la función para realizar las transformaciones

geométricas de escalado y rotación sobre el modelo 3D cargado.

Ilustración 5.13- Diagrama actividad transformaciones geométricas



103


5.4.2. Diagrama actividad etiquetado informativo

Este es el diagrama de actividades de la función de etiquetas informativas en el

modelo principal de la web.

Ilustración 5.14- Diagrama actividad etiquetado

5.4.3. Diagrama actividad etiquetado en mapa

Este es el diagrama de actividades de la función de otras etiquetas informativas

en el modelo principal de la web, que, aunque funcionan de forma idéntica a las

informativas del diagrama de actividad anterior, proporcionan otro tipo de

información como veremos en la parte de implementación.



104


Ilustración 5.15- Diagrama actividad etiquetado información meteorológica

5.4.4. Diagrama actividad animaciones predefinidas

En este diagrama de actividad se muestran las actividades a realizar cuando

usamos la función de animación de ruta o de rotación continua en el eje Y.



105


Ilustración 5.16- Diagrama actividad animaciones predefinidas

5.4.5. Diagrama actividad interacción pan, “measure tool”, zoom in/out, botón de inicio, “pick point”

Este diagrama no se ha adjuntado debido a que es exactamente idéntico al

anterior de la ilustración 5.22 sustituyendo la actividad de “Ver información y

animación” por la de “interactuar con el nuevo control panorámico”.

El mismo diagrama de actividad es válido para varias funcionalidades del

prototipo. Y para utilizarlo basta con activar la función pulsando el botón y utilizar las

diferentes herramientas.

5.4.6. Diagrama actividad visualización con Unity ó ThreeJS + Nexus

El siguiente diagrama muestra las actividades necesarias de realizar para

estando en la web principal del prototipo, usar la funcionalidad de ver la visualización

de “La Cimbarra” abriendo otra pestaña del navegador y ejecutando Unity y WebGL

o la visualización de ThreeJS con el cargador de modelos de Nexus de 3DHOP.



106


Ilustración 5.17- Diagrama actividad de otras visualizaciones

5.4.7. Diagrama de actividad cambiar modelo

Este diagrama representa las actividades que suceden cuando se desea cambiar

el modelo cargado en el canvas, con otro de los que haya en ese instante añadido a

la plataforma.

Ilustración 5.18- Diagrama actividad función cambiar de modelo



107


5.4.8. Diagrama de actividad herramienta cálculo áreas

Este diagrama es algo más largo que los anteriores por el simple hecho de que

esta funcionalidad es más compleja de entender a priori.

Ilustración 5.19- Diagrama actividad herramienta cálculo de áreas

5.4.9. Diagrama de actividad herramienta creación animaciones

En este diagrama de actividad muestra la herramienta de creación de

animaciones con todas las variantes que tiene, ya que se puede crear alguna

animación, o utilizar alguna de las existentes guardadas previamente.



108


Ilustración 5.20- Diagrama actividad herramienta creación de animaciones

5.4.10. Diagrama de actividad función añadir modelos

Para añadir modelos cambiaría el diagrama de actividad realizando más

actividades en la parte del sistema que en la del usuario.



109


Ilustración 5.21- Diagrama actividad función añadir modelos

5.4.11. Diagrama de actividad conversión de modelos para 3DHOP

Este diagrama es mucho más largo que todos los demás de actividad, debido

a que hay muchas condiciones que dependiendo de cuales se cumplan, ocurrirán

unas u otras actividades. Este diagrama de actividad se entiende mejor si

previamente se ha leído lo explicado en el apartado de preparación de modelos para

3DHOP descrito anteriormente.



110


Ilustración 5.22- Diagrama actividad conversión modelos 3DHOP

5.5. Diagramas de secuencia

Ahora se explicarán los diagramas de secuencia realizados para cada una de las

opciones de la web, de forma que se entienda el orden en el cual los scripts son

ejecutados y las interacciones entre estos dependiendo de la funcionalidad.

Un diagrama de secuencia muestra la interacción de un conjunto de objetos en

una aplicación a través del tiempo y se modela para cada caso de uso. A menudo es

útil para complementar a un diagrama de clases, pues el diagrama de secuencia se

podría describir de manera informal como "el diagrama de clases en movimiento",

por lo que ambos deben estar relacionados entre sí.

Primero se muestra el diagrama de secuencia general que tiene lugar cada vez

que un usuario pone la dirección de la web en un navegador compatible (ilustración

5.29).



111


Ilustración 5.23- Diagrama de secuencia general al cargar la web

5.5.1. Diagrama de secuencia transformaciones geométricas

A continuación, se muestra el diagrama de secuencia que muestra las funciones

y archivos JavaScript que se ejecutan cuando el usuario de la web pone en

funcionamiento la opción de realizar transformaciones geométricas de escalado y

rotación sobre el modelo principal de la web. Para realizar esta función simplemente

se deben mostrar los archivos que aparecen en la ilustración 5.30.

En este diagrama se tiene en cuenta como si el usuario entrase a la web, es

decir, la cargase, y a partir de ahí realizase la función que especifica el diagrama.

Ilustración 5.24- Diagrama de secuencia de trasnformaciones geométricas



112


Para más información al respecto de cómo se ha creado esta funcionalidad ir a la

parte correspondiente del capítulo de implementación.

5.5.2. Diagrama de secuencia etiquetado informativo

Este diagrama básicamente viene a mostrar que después de hacer “click” sobre

una etiqueta en el modelo, aparecerá la información en el idioma adecuado y se

realizará una animación sobre el modelo para ver mejor la zona de la etiqueta

seleccionada.

En la ilustración 5.31 se puede ver el proceso de funciones por las que va

pasando. Además, el diagrama está realizad para activar la visibilidad con 3

etiquetas, que eran las que se predijeron en un inicio, aunque posteriormente se han

añadido más.

Ilustración 5.25- Diagrama de secuencia etiquetado informativo





113


5.5.3. Diagrama de secuencia etiquetado en mapa

Este diagrama es igual que el anterior, por eso no se ha adjuntado. La

diferencia es el nombre de las etiquetas que aparecen y son posibles seleccionar.

Así, la información que aparecerá será de otro estilo, es decir, más información

meteorológica con posibilidad de ver la zona en el mapa de Google, de ahí el

nombre del apartado.

Para más información al respecto de cómo se ha creado esta funcionalidad ir

a la parte correspondiente del capítulo de implementación.

5.5.4. Diagrama de secuencia animación predefinida

Este diagrama que aparece en la ilustración 5.32 es válido para dos

funcionalidades que se implementarán en la web, la de animación de ruta

predefinida a través del modelo de “La Cimbarra”, y la animación predefinida de giro

constante sobre el eje Y del modelo principal de “La Cimbarra”.

También hay que tener en cuenta en este diagrama las funciones que muestran

información sobre el modelo para que aparezca durante las animaciones.

Ilustración 5.26- Diagrama de secuencia de animaciones predefinidas



114




5.5.5. Diagrama de secuencia interacción pan, “measure tool”, zoom in/out, botón de inicio, “pick point”

En ilustración 5.33 se muestra el proceso a seguir para la funcionalidad de

una interacción con un control panorámico, pero es igualmente válida para

cualquiera de las opciones nombradas en el título de la sección cambiando el

nombre del método de activación de cada una. En el caso de las otras herramientas

del título de la sección, se muestran los métodos exactos que usan en sustitución de

los de “panoramic” de la ilustración 5.33 por los que se desean ver en el código

adjuntado junto a esta memoria:

• Herramienta de medidas: measureSwitch() y enableMeasureTool()

• Herramienta “pick points”: pickpointSwitch() y enablePickPointTool()

• En el caso de las herramientas para volver a la posición inicial y para

hacer zoom, solo tendría un método, el ‘1.6’ siguiendo el diagrama que

iría desde el “index.html” hasta el controlador “presenter.js”. Se llaman

resetTrackball() o zoomIn()/zoomOut().

En el siguiente diagrama también se muestra los métodos desde que se carga la

web.



115


Ilustración 5.27- Diagrama de secuencia de interacción panorámica



5.5.6. Diagrama de secuencia visualización con Unity o ThreeJS+Nexus

En el diagrama de secuencia de la ilustración 5.34 se diseña cómo será la

función de visualizar con Unity o con ThreeJS y Nexus, los métodos por los que

deberá pasar. Como en otros casos se ha descrito desde que se carga la web, por lo

que hasta el ‘1.6’ en la imagen no comienzan realmente la funcionalidad.

Estas herramientas consisten en activar la funcionalidad y cambiar la parte donde

se muestra información en la web. Ocurrirá lo mismo con cualquiera de las

visualizaciones nombradas.



116


Ilustración 5.28- Diagrama de secuencia de la visualización con Unity


parte correspondiente del capítulo de implementación para ThreeJS y para la

visualización con Unity.

5.5.7. Diagrama de secuencia cambio de modelo

Este diagrama de secuencia muestra los pasos para la realización de la función

que cambia de modelo en la web después de cargar la web.

Se puede observar en la siguiente ilustración 5.35 se ha realizado con los 2

modelos que se tienen disponibles para esta función en este proyecto. Si tuviésemos

más pues sería seguir el mismo proceso.

Destacar que en las flechas de devolución llamadas “new model on canvas”

habría que cargarlo y reiniciar el canvas con los métodos adecuados según 3DHOP,

algo que se explicará mejor en la parte correspondiente del posterior capítulo de

implementación.



117


Ilustración 5.29- Diagrama de secuencia cambio de modelo

5.5.8. Diagrama de secuencia herramienta de cálculo de áreas

En este diagrama de secuencia se explican los pasos a seguir a la creación de

una herramienta de cálculo de áreas adecuada para el diseño y la web que se ha

planteado.

En la ilustración 5.36 se puede ver con claridad las opciones de la herramienta

después de cargar la web y los métodos que hay. Hay que tener en cuenta que el

diagrama se ha realizado con las etiquetas que se han creído convenientes, es

decir, el nº en el prototipo final puede variar.

Además, aparte de interactuar con el modelo secundario en forma de cubo que

aparece para medir la superficie del modelo principal de “La Cimbarra”, también, tal

y como se ve al final dl diagrama, tenemos la opción de medir distancias y

superficies con una herramienta que se activa en el mapa de Google de la web.



118


Ilustración 5.30- Diagrama de secuencia herramienta cálculo de áreas



5.5.9. Diagrama de secuencia herramienta de creación de animaciones

En este diagrama de secuencia (ilustración 5.37) podemos observar que, tras

cargar la página web, si quisiéramos utilizar esta funcionalidad, sucederían los

métodos que se muestra en la siguiente imagen. Hay que destacar que el método

“makeAnimation” deberá encargarse de la inserción de los valores de la animación

en algún sistema de almacenamiento para poder ser ejecutados más tarde.



119


Ilustración 5.31- Diagrama de secuencia herramienta cálculo de áreas



5.5.10. Diagrama de secuencia añadir modelos

En la ilustración 5.38 se observa el diagrama de secuencia de la herramienta

de añadir modelos para el prototipo del “modo museo” de la web tras ser cargada.

Tal y como aparece en dicha ilustración, para añadir un modelo se adjuntará el

nombre en una alerta y se cargará en la web, de forma que para poder interactuar

con los nuevos modelos añadidos deberemos utilizar la herramienta de cambio de

modelo descrita en un diagrama anterior.

Ilustración 5.32- Diagrama de secuencia herramienta añadir modelos



120






121


6. Implementación

En este capítulo está destinado a explicar cómo se han implementado las

soluciones adoptadas para los problemas analizados y diseñados en los capítulos

anteriores de una forma más técnica y con mayor profundidad.


• Organización del proyecto

• Herramientas utilizadas

• Funciones

6.1. Organización del proyecto

El proyecto está subdividido en diferentes archivos organizados por carpetas

según su función:

• “js”: aquí están todos los archivos que hacen funcionar la web, todo el

código JavaScript de la misma.

• “models”: carpeta con los modelos que vamos a cargar en la web.

• “assets”: carpeta con todos los elementos estéticos usados en la web,

imágenes de iconos, imágenes informativas, vídeos, y fondos.

• “stylesheet”: carpeta con los ficheros de estilo usado en la web, es decir,

los ficheros en formato ‘css’.

• “index.html”: archivo principal de la web.

• “UnityWebGL”: carpeta con el contenido necesario para la visualización

con webGL.

• “OtraVisualizacion”: carpeta con el contenido necesario para la

visualziación con Nexus y ThreeJS.

6.2. Herramientas utilizadas

Para el desarrollo del proyecto se han usado las siguientes herramientas:

• HTML (HyperText Markup Lenaguage): lenguaje de marcado para la creación

de páginas web. Es un estándar del W3C (World wide web consortium) que

sirve de referencia del software que conecta con la elaboración de páginas

web en sus diferentes versiones, define una estructura básica y un código

https://www.w3.org/



122


para la definición de contenido de una página web, como texto, imágenes,

videos, juegos, entre otros. Lenguaje usado para los elementos de la

interfaz de la web.

• CSS (Cascading Stylesheets): lenguaje de diseño gráfico para definir y crear

la presentación de un documento estructurado escrito en un lenguaje de

marcado como HTML. Lenguaje usado para la estética de la web.

• JavaScript: lenguaje de programación orientado a objetos, basado en

instancias y clases, y dinámico. Se utiliza principalmente en su forma del lado

cliente, implementado como parte del navegador web permitiendo mejoras en

la interfaz de usuario y webs dinámicas, aunque existe también una forma de

JavaScript en el lado servidor. Su uso en aplicaciones externas a la web,

como por ejemplo en documentos PDF.

Todos los navegadores modernos interpretan el código JavaScript integrado

en las páginas web. Para interactuar con una página web se provee al

lenguaje JavaScript de una implementación del Document Object

Model (DOM). Y Actualmente es ampliamente utilizado para enviar y recibir

información del servidor junto con otras tecnologías como AJAX

(Asynchronous JavaScript And XML, es una técnica de desarrollo web para

crear aplicaciones interactivas). Lenguaje principal de desarrollo de la

plataforma web.

• C#: lenguaje de programación orientado a objetos propiedad de Microsoft.

Usado para el código realizado en el prototipo de visualización en

Unity3d.

• SublimeText: editor de texto y código fuente usado para el desarrollo de todo

el código de la web.

• Xcode y Swift: IDE y lenguaje de programación (respectivamente) de MacOS

usado para un pequeño prototipo desarrollo al principio para cargar

modelos en dispositivos móviles, en este caso la plataforma iOS.

• Unity3D: motor de videojuegos usado para desarrollar otro modo de

visualización e interacción.

• MonoDevelop: editor de texto y código de Unity3d.

https://es.wikipedia.org/wiki/Aplicaci%C3%B3n_inform%C3%A1tica

https://es.wikipedia.org/wiki/World_Wide_Web



123


• GoogleDrive: es un servicio de alojamiento de archivos en la nube propiedad

de Google. Usado para guardar los modelos 3D y información que los

tutories de este proyecto me proporcionaban.

• Proxmox: entorno de virtualización de servidor de código abierto. Utilizado

para alojar la web en el servidor de CEACTierra.

• Xampp: paquete de software libre que consta de un sistema de gestión de

bases de datos MySQL, servidor web Apache, e intérpretes para lenguajes de

script PHP y Perl. Utilizado

• Meshlab: software de procesamiento de modelos/mallas. Utilizado para

convertir los modelos 3D usados en el proyecto a otros formatos y con

otro sistema de referencia en el espacio.

• Cura: aplicación de código abierto para preparar modelos 3D para la

impresión 3D. Utilizado para la impresión del modelo principal del

proyecto.

• GanttProject: programa de código abierto para la administración de

proyectos usando diagramas de Gantt y Pert. Usado para la realización del

diagrama de Gantt y Pert de la planificación temporal de este proyecto.

• Visual Paradigm: herramienta de creación de diagramas UML. Utilizado

para la creación de todos los diagramas explicados en el capítulo del

diseño de la documentación de este proyecto.

• VirtualBox: software de virtualización. Ha sido necesario para la

conversión de modelos en formato ‘obj’ al formato ‘nxs’ necesario para

Nexus y 3DHOP, debido a que el conversor está únicamente para

plataformas con sistema operativo Windows.

• Filezilla: aplicación de código abierto utilizada para subir archivos al servidor

web por medio de ftp (file transfer protocol).

• Git: software de control de versiones pensado en la eficiencia y la

confiabilidad del mantenimiento de versiones de aplicaciones

• ThreeJS: biblioteca escrita en JavaScript para crear y mostrar gráficos

animados por ordenador en 3D en un navegador Web y puede ser utilizada

en conjunción con el elemento canvas de HTML5, SVG o WebGL. Utilizada

para varios prototipos implementados en este proyecto.



124


• 3DHOP: framework (marco de referencia) sobre el que se ha desarrollado

principalmente la web. Es un paquete software para la creación de

presentaciones web interactivo para la manipulación de modelos 3D de alta

resolución orientados principalmente a la difusión de patrimonio cultural o

natural.

• WebGL: estándar que define una API implementada en JavaScript para la

renderización de gráficos en 3D dentro de cualquier navegador web.

• SpiderGL: es una librería de gráficos en JavaScript orientada a la creación de

aplicaciones web y que usa WebGL para el rendering en tiempo real. Es el

núcleo del framework 3DHOP.

• BabylonJS: framework JavaScript apra la construcción de juegos y

experiencias 3D con HTML5, WebGL, WebVR y Web Audio.

• Blender: programa informático multiplataforma, dedicado especialmente al

modelado, iluminación, renderizado, animación y creación de gráficos

tridimensionales. Utilizado únicamente para la modificación del modelo 3D

principal del proyecto para realizar una correcta impresión 3D del mismo (una

extrusión del modelo).

• QuickTimePlayer: aplicación para la grabación del vídeo demostrativo del

proyecto.

• También se han utilizado otros softwares para la creación de la memoria,

editar alguna ilustración y hacer la presentación del proyecto como son Word,

PowerPoint, Vista Previa, o iMovie para la edición del vídeo de demostración.

6.3. Funciones

A continuación, se explican las diferentes funciones implementadas, comenzando

por la creación de la escena para después ir explicando las funcionalidades

implementadas en cada iteración de las que aparece en la planificación temporal.

6.3.1. Creación de la escena

Para activar todos los elementos gráficos de la web hay que activar el

“presenter” de la API de 3dhop, es decir, la creación de la escena, además de

asociarlo con el elemento ‘canvas' de HTML creado en la interfaz de la web.



125


Para crear una escena deberemos llamar al método “setScene” de 3DHOP, el

cual tiene varias formas de creación dependiendo del uso y la complejidad de

nuestra web. En nuestro caso, se utiliza la opción con más posibilidades. Por tanto,

para ello se llama a dicho método pasándole los datos correspondientes que se

dividen en varios apartados:

a. Mallas o modelos: se debe crear los nombres de todos los modelos que

vayamos a usar en nuestra aplicación asociándolos a una URL dentro de

los “assets” del proyecto de forma que se puedan cargar posteriormente.

En el caso de querer realizar una función de añadir modelos de forma

dinámica a una web tal y como se hizo en una iteración implementada

para este proyecto, se deberá crear el nombre del modelo asociándole una

URL o cadena de texto vacía.

El formato es el siguiente:

meshes: {

“nombreModelo”: {“models/nombre.ply”}

}

b. Instanciación de modelos: para cada modelo cargado anteriormente se

debe crear una instancia de dicho modelo con las características

correspondientes. Dicha instancia debe estar asociada con el nombre de

la malla, se le debe aplicar una transformación geométrica, se le añade

una etiqueta para asociarla a un grupo de modelos en el caso de que

queramos cargar muchos en la plataforma, y se decide si queremos que

se vea transparente y con qué porcentaje de transparencia. Además,

también hay que añadir la opción de si deseamos que la instancia creada

sea o no visible, algo muy útil porque cargamos todas las instancias en la

web, pero a modo de setters podemos renderizar y hacer visibles unos u

otros modelos 3D, una opción usada para cambiar de modelo en el canvas

de la web.



126


Ilustración 6.1- Creación de instancias (modelos) en la escena de 3DHOP

c. Creación de “spots”: en el caso de que deseemos usar un sistema en el

cual se cargan modelos “poco pesados” (de baja resolución, <= 1MB) que

pueden ser seleccionados, es decir, tienen un evento asociado, algo útil

para el sistema de etiquetado utilizado. En el caso de esta web, se utilizan

dos tipos de modelos para esta labor, una esfera y una bandera.

Además, igual que en la instanciación de modelos, esta creación de

“spots” es una instanciación de otros modelos que se han debido cargar al

crear las mallas y modelos en el apartado ‘a’, y también tienen las mismas

características.

Ilustración 6.2- Creación de spots (etiquetas) en la escena 3DHOP

d. Control de interacción sobre los modelos: la propia API de 3DHOP

proporcionan varios controles de interacción para los modelos. El más

completo, que es el usado para nuestra web, es el que tiene un control de

“trackball” (similar al de un trackpad de un ordenador al seleccionar un

elemento) con posibilidad de control “pan” (movimientos panorámicos).

Para poder usar esta funcionalidad debemos iniciar todas las

características de configuración que deseemos usar tal y como se observa

en la ilustración 6.3:

- StartPhi: el valor con el cual el modelo empezará a rotar en el eje

vertical al interactuar con él. Por defecto está a cero, lo que significa que

se ve de frente.



127


- StartTheta: el valor inicial con el que empezará el movimiento de tilt

(movimiento de cámara de arriba hacia abajo, en el eje Y) si se realiza al

interactuar con el modelo. Por defecto está a cero.

- StartDistance: La distancia a la que está la cámara del modelo. Por

defecto está a 2 unidades, aunque se ha aumentado un poco debido a

las dimensiones del modelo principal y del canvas donde se renderiza la

escena.

- startPanX, startPanY, startPanZ: valores con los que se inicia el

movimiento de pan sobre el modelo, es decir, donde queremos que se

sitúe la cámara. Por defecto serán 0.

- minMaxPhi: límite de la rotación alrededor del eje vertical con respecto

a la vista frontal. Si [-180.0, 180.0], el objeto puede rotar de forma

continuada sin límites. El valor por defecto es [-180.0, 180.0], lo cual es

igual a una rotación continua.

- minMaxTheta: límite hacia arriba y abajo de la vista tilt. El valor por

defecto es [-80.0, 80.0].

- minMaxDist: límite hacia rriba y abajo de la distancia o profundidad. Por

defecto el valor es: [0.2, 4.0].

- minMaxPanX, minMaxPanY, minMaxPanZ: los límites con los cuales

podemos realizar el movimiento de pan con la cámara que enfoca a la

escena. Se fue probando para averiguar los límites adecuados para el

tamaño de nuestro modelo teniendo en cuenta las transformaciones

geométricas realizadas en este ya sean con código JS o con Meshlab.



128


Ilustración 6.3- Creación de un control en la escena de 3DHOP

Además, se han creado 3 funciones capaces de cargar la escena que deseamos

mostrar. Todas ellas son iguales a excepción del control de interacción del modelo, que,

aunque el descrito es el más completo, el usuario puede querer una interacción diferente

como puede ser el control esférico, o el control únicamente con Tilt.

Para añadir más modelos o instancias cargadas en la web, así como más etiquetas,

habría que repetir el mismo proceso visto en las ilustraciones 6.1 y 6.2 tantas veces como

deseemos.

6.3.2. Iteración para la implementación de un mapa de Google en la web

Para añadir un mapa de Google en una web es necesario usar la API que google

proporciona a los desarrolladores y trabajar en JavaScript. Para ello, hay que

conseguir una clave “Google Maps” con una cuenta de Google. Dicha clave al ser

gratuita tiene ciertas limitaciones del número de veces que permite que se cargue el

mapa diariamente, aunque es más que suficiente para el uso que tendrá la web ya

que difícilmente va a albergar ese uso diario a pesar de que está subida y sea de

acceso público.



129


Ilustración 6.4- Limitaciones de uso de una clave gratuita de Google Maps

Así, la clave se obtiene accediendo a la consola de google (ilustración 6.5):

Ilustración 6.5- Obtención clave gratuita de Google Maps

Y para añadir el mapa hay que basarse en la especificación de la

documentación de Google (documentación GoogleMaps). Se crea especificando el

zoom, las coordenadas donde se centra, el tipo de mapa que queremos que se

muestre, y en este caso se crea un marcador indicando el punto de interés más

relevante del mapa. Este código (ver ilustración 6.6) será añadido en el “index.html”

cuando se especifique la creación de un mapa al cargar la web.

https://developers.google.com/maps/documentation/javascript/?hl=es-419



130


Ilustración 6.6- Creación mapa de Google con código JavaScript

6.3.3. Iteración para mostrar información general de los modelos principales

Tal y como ya se sabe, la web posee una tabla con dos columnas, en la que a

la izquierda está el canvas donde está toda la información de gráfica, y a la derecha

aparece la información descriptiva dependiendo de la acción que se lleve a cabo en

la web. Por defecto, aparecerá información sobre el modelo 3D principal cargado en

el canvas, información que aparecerá nada más cargar la web o al cambiar de

modelo 3D con la opción pertinente. En cualquier caso, la función encargada de esta

información se resume en el siguiente pseudocódigo (setInfo(name, lenguage)):

INICIO

SI idiomaActual IGUAL español

Switch(nombreModelo)

Case ‘a’: añadirInfoModeloA()

Case ‘b’: añadirInfoModeloB()

Default: mensajeError()

SI NO

SI idiomaActual IGUAL inglés


Case ‘a’: addInfoModelA()

Case ‘b’: addInfoModelB()

Default: errorMessage()

SI NO


Case ‘a’: añadirInfoModeloA()

Case ‘b’: añadirInfoModeloB()

Default: mensajeError()

FIN



131


6.3.4. Iteraciones para la realización del sistema de etiquetado

El sistema de etiquetado consiste en pre-cargar modelos geométricos 3D de

poca resolución y en formato ‘ply’, es decir, de 1MB o menos peso, y posicionarlos

en ciertas posiciones del modelo 3D principal del canvas, de forma que respondan a

un evento de ser clickados con el ratón para que se enlacen con información de

algún tipo en la web ya se por medio de una alerta de JavaScript, o como en nuestro

caso, más información en la parte de la web destinada para ello.

Los modelos usados para las etiquetas, también llamados “spots” o puntos de

interés, han sido un modelo de una bandera cuya preparación es con Meshlab para

convertirla en un modelo en formato ‘ply’ (se descargó en ‘obj’) y un modelo de

esfera. Estos se cargan y se le aplica un color, un porcentaje de transparencia, … tal

y como se ha visto en el apartado anterior 6.2.1 de creación de la escena.

Después de la creación de los modelos encargados del etiquetado, debemos

añadir las funciones correspondientes de 3DHOP para controlar los eventos de ratón

en caso de seleccionar una instancia o una etiqueta (ilustración 6.7).

Ilustración 6.7- Código JS 3DHOP para controlar eventos del sistema de etiquetado

Las dos líneas de código de la imagen anterior se encargan de activar los dos

métodos que se encargan de realizar lo que sucede tras seleccionar uno de dichos

puntos de interés:

1. onPickedInstance(id): función encargada de añadir la información

correspondiente haciendo los cambios necesarios los elementos de la web

dependiendo del “id” de la etiqueta que se haya seleccionado, del idioma

activo en la web en ese instante, y del modelo principal cargado en la web.

Además, almacena un identificador entero dependiendo de la etiqueta que se

haya seleccionado para saber cuál esta visible en cada momento, algo

utilizado para solucionar errores como cuando se cambiaba de idioma en

medio de la activación de este sistema de etiquetas. Obviamente, esta

función ha sido rediseñada completamente de cómo venía en el ejemplo

básico en la web del framework, debido a que no se muestra una simple



132


alerta con una frase informativa, si no que se pretende que haya mucha

información real sobre el punto de interés de diversas formas. La función es

tal y como se observa en la ilustración 6.8.

Ilustración 6.8- Método onPickedInstance de 3DHOP

2. onPickedSpot(id): tiene el mismo mecanismo de funcionamiento de la

función anterior, con la diferencia de que realiza para cada “spot” una

animación personalizada, es decir, cuando por ejemplo seleccionas una

etiqueta en una zona se hará un zoom hacia ese punto de interés, siempre

que se haya programado la etiqueta con una animación. Ver ilustración 6.9.

Ilustración 6.9- Etiqueta en el método onPickedSpot de 3DHOP

Para la realización de la animación se crea un array con 6 valores que

representa la nueva posición exacta o punto de vista a la que la cámara debe

ir para ver mejor el modelo, así como un tiempo de animación. Todo eso para

llamar a la función correspondiente del presenter (controlador de la web).

Los valores del array son los siguientes: [anguloEjeX, anguloEjeY, panX,

panY, panZ, distancia]

También, tal y como se ha mostrado en la ilustración 6.8, y de forma similar al

cambio de información entre modelos principales del apartado anterior, existe

una función que se encarga de la manipulación de la información

correspondiente a cada etiqueta (setInfoAnnotation(name, lenguage)). La

función responde al mismo pseodocódigo escrito anteriormente en el apartado



133


6.2.3, pero esta vez con mucha más información tanto textual, como de

vídeos e imágenes.

Posteriormente, en la función encargada de gestionar la activación y

desactivación de las opciones del canvas (iconos) dependiendo de la acción

activada según el identificador del icono que se haya activado en un

determinado instante. La función es “actionToolBar(action)” y el código para el

control de la función de etiquetado que corresponde a este apartado es el que

se ve en la ilustración 6.10.

En el caso de la herramienta de etiquetado, para el correcto funcionamiento

se ha tenido que realizar mucho código para controlar las etiquetas que se

activan en un determinado momento, el cambio de icono para saber su

estado, y muchas variables booleanas para controlar que está activado por si

sucede un cambio en la web como por ejemplo un cambio de idioma mientras

estamos leyendo la información de una etiqueta seleccionada.

Ilustración 6.10- Código JS de la función de etiquetado en el método actionToolBar de 3DHOP



134


6.3.5. Iteración para la función de cambio de modelo del canvas

Cuando se activa el icono correspondiente del canvas para activar está

acción, en el método encargado (actionToolBar) simplemente se llama a la función

changeModelFunction(), la cual consiste en la activación de una alerta personalizada

con la API de JavaScript “SweetAlert” añadiendo un desplegable que permite

seleccionar el nombre del modelo que queremos cargar entre los disponibles. El

pseudocódigo de esta función es:

value =entero que marca la posición del desplegable del string con el nombre de un

modelo

INICIO

SI “cimbarraModel” IGUAL value

identificadorModelo = 1

resetearCanvas()

hacerVisible(“cimbarraModel”)

información(“cimbarraModel”, “idioma”)

activarFuncionesEspecificas(“cimbarraModel”)

SI NO

identificadorModelo = 2

resetearCanvas()

hacerVisible(“ripplesModel”)

información(“ripplesModel”, “idioma”)

activarFuncionesEspecificas(“ripplesModel”)

FIN

El código de “resetearCanvas()” que aparece en el pseudocódigo anterior es

realmente el que aparece en la ilustración 6.11.

Ilustración 6.11- Código JS para reiniciar el canvas de la web

6.3.6. Iteración para función interacción panorámica

Si activamos el botón de esta función llamaremos a dos funciones realizadas en

el “presenter.js” aprovechando las funcionalidades del control trackball que trae el

framework usado por defecto.

Simplemente, al activar el botón de esta opción se pondrá a verdadero un

booleano, o a falso si se desactivase. Este booleano lo que hará será que cuando



135


tratemos de mover el modelo con el ratón, el método que está controla dicho evento

es uno método específico de JavaScript llamado “onDrag”, se mueva con

movimientos panorámicos de cámara en caso de que el booleano sea verdadero, y

con movimientos de rotación de cámara si no lo fuera.

Destacable también que, gracias a este método, también se añadió una variante

con la cual podemos usar las típicas teclas de movimiento de los juegos para

ordenador (‘w’, ‘a’, ‘s’, ‘d’) para realizar movimientos de pan en las direcciones

adecuadas (‘w’ para arriba, ‘a’ para la izquierda, ‘s’ para abajo, ‘d’ para la derecha).

Esto se hace con otra función de JavaScript llamada “onKeyDown”, que como su

nombre indica, controla los eventos de teclado en la propia web. Una parte de este

método se puede ver en la siguiente imagen, sabiendo que la variable “resetDone”

es cuando la posición en la que está el modelo es la inicial, de ahí que si no lo es

haya que coger la posición actual para realizar el movimiento de pan correctamente.

El método “onKeyDown” se puede ver como se forma en la ilustración 6.12.

Ilustración 6.12- Código de la función JS que controla los eventos de teclado en la web

6.3.7. Iteración para función de animaciones predefinidas

Estas animaciones se dan principalmente en dos funciones del prototipo web.

Esta característica se basa prácticamente en la función “setInterval(function,

time)” de JavaScript. Consiste en llamar a una función cada cierto tiempo (en

segundos milisegundos) de forma indefinida hasta que se desactive con

“clearInterval()”.

En la función (“function”) a la que llamamos de forma repetida controlaremos las

veces que se ha entrado con un contador. Y con condicionales iremos realizando

unas u otras acciones dependiendo de la repetición en la que estemos. En el caso

de la función que realiza una animación de ruta, en cada vuelta se moverá la cámara



136


a una posición diferente, además de ir activando ciertas etiquetas. En la siguiente

imagen 6.13 podemos observar la función encargada de la rotación en el eje Y.

Ilustración 6.13- Código de la función de rotación predefinida en el eje Y del modelo

6.3.8. Iteración para la herramienta de cálculo de áreas

Esta funcionalidad consiste en que tras ser activada aparece un modelo de un

cubo semi-transparente que podrá ser trasladado, rotado y escalado según unos

límites impuestos de forma que tras situarlo dónde y cómo el usuario desee, los

seleccionaremos y nos aparecerá la información con la superficie de “La Cimbarra”

que ocupe el modelo de cubo en la zona de la web adecuada para ello. Además,

también aparecerá tras este proceso un botón que activará una herramienta de

medir distancias y superficies en el mapa de Google de la web.

El modelo de cubo modificable funciona de la misma forma que una etiqueta

en cuanto a ser posicionado y seleccionado, de ahí que el método que controla la

activación de estas opciones del canvas, “actionToolBar”, sea similar a la

herramienta de etiquetas explicada anteriormente.

Cuando se hace “click” sobre el cubo, la parte donde se muestra la

información en la web será modificada llamando al método

setInfoAnnotation(spotName, lenguage) igual que en casos anteriores, con las

diferencias del cálculo de la superficie como podemos observar en la ilustración

6.14.



137


Ilustración 6.14- Código de etiqueta de área en la funcion setInfoAnnotation de Cimbarra.js

Y habrá que inicializar la herramienta de medidas para la API de Google Maps

(ilustración 6.15).

Ilustración 6.15- Código de inicialización de measureTool para GMaps

6.3.9. Iteración para etiquetado informativo meteorológico

Esta opción sigue utilizando igual que en casos anteriores, el gran sistema de

etiquetado de 3DHOP modificado. La diferencia es que la información en este caso

no es texto plano, imágenes o vídeos, sino que se usa la API de “open weather map”

(https://openweathermap.org/api) para poner información meteorológica de la zona

con la etiqueta seleccionada gracias a saber las coordenadas de la misma.

La información se obtiene con una petición Ajax mediante jQuery (petición http

asíncrona) de obtener la información e formato JSON (formato ligero de intercambio

de datos) de la URL introducida. Las informaciones obtenidas serán valores de

temperatura, humedad, viento y descripción general del tiempo (ilustración 6.16).

Esta información es muy útil dado el propósito de la web, que es informar de la zona

por si se desease visitar.

Hay que aclarar que como máximo se podrán hacer 60 llamadas por minuto a

la API de “open weather map” porque se está usando la versión gratuita. Aunque

para el propósito del proyecto y el tráfico que se prevé que tendrá la web, no habrá

ningún problema.

https://openweathermap.org/api)

https://jquery.com/



138


Ilustración 6.16- Código para acceder a la API de open weather map

6.3.10. Iteración para la visualización con ThreeJS y Nexus y web adaptable

Esta iteración consiste en crear una web con el framework de WebGL

ThreeJS. Para ello debemos crear una zona de canvas donde irán los elementos

gráficos y cualquier otra opción que deseemos con código html. En el canvas lo

inicializaremos tal y como se inicializa en ThreeJS:

• Creando una cámara y asociándole una posición.

• Creando unos controles de interacción y configurándolos.

• Creando la iluminación deseada.

• Finalmente, creando un elemento escena al que le añadiremos los

demás elementos y el renderer con sus características como en

cualquier programa con contenido gráfico 3D, con la diferencia de que

deberemos añadir a la escena un objeto “NexusObject” que se

encargará de renderizar el modelo 3D cuyo nombre añadamos, siempre

en el formato multi-resolución ya comentado, ‘nxs’.

Hacer que este prototipo sea adaptable ha sido gracias a código CSS

encargado de adaptar el viewer/canvas de la web. El resultado y la explicación se

pueden ver con más detalle en la sección anteriormente explicada de cómo sería

una web adaptable.

El resultado de esta otra visualización aparecerá en la web más completa tras

pulsar el botón “Otro modo de Visualización”. La ventaja de haber realizado este

sub-prototipo en una iteración son las ventajas que puede proporcionar cargar



139


modelos de gran resolución de forma eficiente gracias a Nexus, en un framework

con tantas posibilidades como ThreeJS en casos en los que se desee hacer una

simulación más que difusión de patrimonio, ya que, en este último caso, tal y como

ocurre en este proyecto, es más eficaz 3DHOP.

6.3.11. Iteración para función de añadir modelos a la web (modo museo)

Este modo se implementó para el testeo de la función de añadir modelos 3D a

la web y poder cargarlos en el viewer de la misma. Básicamente, este modo consiste

en una web que mayormente es una zona para mostrar el contenido gráfico. Pero,

también tiene la opción de multi-lenguaje implementada en otra iteración, así como

un desplegable con los modelos 3D disponibles para ser cargados en el canvas, que

se irá actualizando conforme vayamos añadiendo más modelos con la opción

correspondiente.

No se posee acceso a ninguna base de datos que pueda guardar los modelos

que queramos usar y por tanto podamos acceder a ella cuando queramos,

principalmente porque los modelos ocupan mucho espacio de almacenamiento y

habría que contratar un servicio de pago. Por tanto, lo que se ha hecho es

almacenar los modelos 3D que queramos utilizar en la web a la carpeta de modelos

dentro del servidor (ya sea localmente con Xampp o en un servidor real). De esta

forma, cuando se activa el botón correspondiente para esta funcionalidad, aparecerá

una alerta personaliza en la pantalla, la cual nos pedirá que introduzcamos el

nombre del modelo que deseamos cargar. Tras introducir el nombre se comprobará

que es correcto (el formato adecuado) y se guardará la cadena de texto del nombre

en una “cookie” del navegador, ya que es la forma más eficaz que se ha encontrado

de guardar esta información. Para saber más al respecto, consultar el anexo

adecuado.

Así, tras guardar todas las cadenas de texto, se actualizará el desplegable

(combo-box) para poder seleccionar los modelos 3D.

Nada más activar la función de añadir modelos se activará la siguiente función

“sweetAlertToInsertModelName” para introducir el nombre del modelo que queramos



140


cargar en el formato “nombre.nxs”. Esto se observa a continuación, en la ilustración

6.17.

Ilustración 6.17- Código JS para crear una alerta para insertar el nombre de un modelo a añadir en la web

Posteriormente, se inserta el modelo, es decir, se guarda el nombre en una

cookie del navegador con la fecha deseada (ilustración 6.18). Esa cookie será del

formato que se ve en la siguiente imagen, es decir, tendrá un nombre que será el

que se mostrará en el desplegable, y luego la cadena de texto con su nombre y

formato que será a la que accederemos para cargar el modelo.

Cabe destacar que si se borra la caché del navegador donde se haya

guardado alguna cookie, obviamente habrá que repetir el proceso.

Ilustración 6.18- Código JS para la insercción de un modelo gracias a las cookies JS del navegador

A continuación, actualizamos el desplegable teniendo en cuenta las separaciones

de los nombres de las “cookies” dichas anteriormente (ilustración 6.19 y 6.20).

Ilustración 6.19- Código JS para actualizar el desplegable encargado de mostrar los modelos disponibles en

la web



141


Ilustración 6.20- Código JS dividir las cadenas de texto para que se inserten correctamente en las cookies.

Además, obviamente también podemos borrar todas las cookies ejecutando

las siguientes funciones (ilustración 6.21). No está implementado de forma gráfica en

la interfaz de este prototipo web, pero bastaría con llamar a esta función al cargar la

web, por ejemplo.

Ilustración 6.21- Código JS resetear y borrar las cookies del navegador.

6.3.12. Iteración para el multilenguaje

Cuando pulsamos los “radio buttons” correspondientes de la parte superior de

la web para cambiar de idioma la web, se ejecuta una función nombrado en el

apartado de diseño del software, “changeLenguageFunction()”. Esta función se

encarga de cambiar de idioma todos los elementos de la web gracias al DOM

(Document Object Model) y la estructura de datos de la web.

El “Document Object Model” es un lenguaje independiente de la interfaz de la

aplicación que trata un documento HTML, XHTML o XML como una estructura de

árbol en al cual cada nodo es un objeto que representa una parte del documento.



142


Estos objetos pueden ser manipulados y cualquier cambio visual que ocurra como

resultado puede ser reflejado en el documento.

Cuando una página web es cargada, el navegador crea un DOM de la web, el

cual es una representación de objetos del documento de HTML y actual de interfaz

entre JavaScript y el propio documento permitiendo la creación de webs dinámicas.

• JS puede añadir, cambiar y borrar todos los elementos y atributos de la

página web.

• JS puede cambiar todos los elementos de estilo CSS de la página web.

• JS puede reaccionar a todos los cambios existentes en eventos de la

página web.

• JS puede crear nuevos eventos en la web.

El árbol de objetos del DOM es el mostrado en la ilustración siguiente nº 6.22:

Ilustración 6.22- Árbol de objetos del DOM HTML webpage

Y en este caso, debido a que queremos cambiar el idioma, accedemos al texto

de los elementos de la web tan que así (ilustración 6.23).

Ilustración 6.23- Código JS para cambiar el texto de elementos HTML de una web

Todo esto es posible con archivo dedicado a devolver un array, es decir, una fila

de una matriz en la que devuelve los elementos de la web en el idioma seleccionado

(texto, imágenes, …).

En nuestro caso la matriz dispone de dos filas porque la web está implementada

para traducir al español y al inglés. Por tanto, en cada casilla de una fila de la matriz



143


está la internacionalización (texto, imágenes, ...) en el idioma correspondiente a esa

fila, y para devolver toda esa información de forma que sea accesible para el DOM

se realiza con una simple función que devuelve un array (una fila) dependiendo del

idioma activo (ilustración 6.24):

Ilustración 6.24- Código JS para acceder al texto de un idioma

6.3.13. Iteración para funciones con transformaciones geométricas

Estas funciones se han realizado para ser aplicadas tanto a modelos principales

de gran resolución, como a modelos secundarios con un nº de triángulos reducido

como puede ser un modelo de un cubo.

Las transformaciones implementadas son las de escalado y rotación. La

traslación no se ha implementado porque no aportaría nada trasladar el modelo a

una posición en la que no sea captado por la cámara.

Ambas funcionalidades poseen unos elementos en la interfaz cuando se activan,

debido a que necesitan varios controles para rotar o escalar en cada uno de los ejes.

Así, se ha optado por tres sliders en cada caso, un “slider” para cada uno de los

ejes.

Si se está realizando una transformación sobre un modelo principal como puede

ser “La Cimbarra”, se desactivarán todas las etiquetas y en la parte donde se

muestra información se mostrará sobre el modelo principal del canvas en ese

momento.

Luego se llamará a la función correspondiente del controlador “init.js” encargada

de gestionar los cambios que sufren los “sliders” cuando el usuario modifica su valor.

Y básicamente se llamará a una función del “presenter.js” para controlar la parte

gráfica y en este caso la matricial del modelo cargado. La llamada a dicha función



144


será mandando los valores obtenidos de los controles correspondientes de cada eje,

el nombre de la instancia asociada al modelo sobre el cual se están realizando los

cambios, y si queremos que se redibuje o no (booleano).

Presenter.setTransformFactorInInstance(modelName, valueX, valueY, vlaueZ,

true)

En cuanto a la función de escalado, se irá recorriendo el array con los

nombres de las instancias de los modelos hasta encontrar la adecuada para así

cambiarle la matriz de transformación en este caso únicamente la parte del escalado

(ilustración 6.25).

Ilustración 6.25- Código JS función setScalingFactorInInstanceModelByName

Y para la rotación el funcionamiento es similar al anterior (ilustración 6.26),

con la diferencia de que hay que controlar el modelo cargado puesto que podemos

cambiar de modelo con la herramienta que proporciona esa opción, y no se deben

mezclar ambas matrices porque a diferencia de cómo es en el escalado o en una

supuesta traslación, la rotación está personalizada para cada modelo debido a que

ambos comienzan con un sistema de referencia puesto que tienen un tamaño

diferente.



145


Ilustración 6.26- Código JS función setRotationFactorInInstanceModelByName

6.3.14. Iteración para visualización con Unity

Para simular la zona de la Cascada de “La Cimbarra” de Jaén, modelo 3D con

el que principalmente se ha trabajado, se ha desarrollado también un prototipo en

HTML 5 y WebGL con el motor gráfico Unity, para que se vea el terreno del modelo

en concreto y podamos interactuar y movernos sobre él gracias a los controles

implementados.

Unity es un motor de videojuego multiplataforma creado por Unity

Technologies. Está disponible como plataforma de desarrollo para Microsoft

Windows, OS X, Linux.

Primero, se debe explicar por qué este prototipo se ha decidido desarrollar con

Unity.

A dicha pregunta se responde debido a 3 factores diferentes:

1. Aunque el prototipo sea para divulgación de información del área en

cuestión, y no un videojuego en sí, que es para lo que está destinado



146


Unity, las mecánicas y en definitiva el objetivo es simular puesto que se

necesitan unos controles para interactuar y movernos por un terreno de La

Cimbarra, por lo que es idéntico a tener un jugador que se mueve por el

terreno de un videojuego.

2. Hay muchos motores para desarrollar este tipo de software, y aunque el

número de motores gráficos mayormente gratuitos es más reducido, Unity

es elegido entre todos ellos por ser multiplataforma (Mac, Windows, Linux)

y permitir desarrollar para móviles, plataformas de escritorio, y lo que nos

interesa en este proyecto, para la web.

3. Unity además, es el software seleccionado para la tarea porque aunque se

ha hecho uso de tutoriales y foros e internet para la elaboración de este

prototipo, la documentación principal que me ha permitido el desarrollo ha

sido extraída de la asignatura de desarrollo de videojuegos, en la cual

estudiamos a fondo este motor gráfico.

Ilustración 6.27- Editor Unity abierto con el Proyecto de La Cimbarra en Unity

Podemos ver como es el editor de Unity en la ilustración anterior número 6.27.

En cuanto a lo implementado para este prototipo:

Lo primero es que el terreno debía ser la zona de la Cimbarra, por lo que

modelar dicha zona a mano con la herramienta de edición de terrenos de Unity sería

largo y complejo. Por tanto, había dos opciones, o irse a la zona deseada en Google

Maps e importar con alguna herramienta de un tercero un mapa de alturas de dicha



147


zona que posteriormente convertiríamos a un terreno de Unity con un script, o la

opción por la que se ha optado, que es convertir un modelo 3D a un terreno con

otro script de un tercero. Se ha optado por la segunda opción, porque para el caso

que nos concierne es más precisa, ya que exportar un mapa de alturas de la zona

fue imposible debido a que es un área muy reducida y varios softwares encontrados

para la tarea no tenían tanta precisión y no podían hacer tanto zoom en el mapa, por

lo que de haberlo exportado hubiera salido mucha más área que no forma parte de

la zona deseada y el terreno hubiera sido mucho más grande y por consiguiente

erróneo para la tarea de informar sobre la Cascada de La Cimbarra, y se tendría que

haber realizado un trabajo de edición mucho mayor. A pesar de que haya 2 opciones

a priori diferentes, la 2ª está ligada a la 1ª tal y como veremos a continuación.

Básicamente, el script que convierte un modelo 3D, en este caso en formato

‘obj’, lo que realiza es una conversión de la malla de triángulos del modelo a un

“height-map” o mapa de alturas para poder generar posteriormente un terreno de

Unity. Además, usa “RayCasting” en vez de conversión de archivos, por lo que

funciona con cualquier malla de cualquier objeto.

Una vez se ha generado el terreno, se ha editado añadiéndole texturas, así

como árboles, luz, skybox, así como suavizando ciertos puntos en los que había un

terreno muy escarpado, ya que se añadió un carácter en primera persona para

poder controlarlo y movernos y observar el terreno.

También se ha añadido agua para simular la zona del río que provoca la

cascada de “La Cimbarra” (véase el tutorial seguido para ello), la cual ha sido

representada por medio de múltiples sistemas de partículas formando una jerarquía

(más de un sistema de partículas cada uno creado con distinto nivel de emisión

durante distinto tiempo y con partículas diferentes para darle un efecto más realista

simulando el agua que cae, el agua que salpica, y las olas que forma el agua de la

cascada al impactar con el agua estancada en la parte inferior).

Además, aprovechando uno de los sistemas de partículas, se han creado otro

efecto que funciona de forma similar y representa una bandada de pájaros volando

que se ve a lo lejos al principio de la ejecución.



148


Y finalmente, se han implementado dos puntos de interés que representan lo

mismo que los “hotspot” del prototipo basado en WebGL realizado con 3DHOP, para

demostrar que de forma sencilla se puede añadir información que aparece en

pantalla cuando pasamos por la zona indicada.

6.3.15. Iteración para herramienta creación animaciones

Esta función consiste en guardar las posiciones en la que se encuentre el modelo

3D en un determinado momento, y posteriormente realizar una animación a esa

posición guardada.

Cuando activamos esta función, en la parte derecha de la web donde se muestra

la información, aparecerá una breve descripción de cómo funciona la herramienta,

además de mostrar los controles necesarios para su funcionamiento.

Cuando insertamos la posición a la que queremos realizar una animación

pulsando el botón correspondiente, se guardará la posición de la siguiente manera,

guardando los 6 valores correspondientes a una posición del modelo (ilustración

6.28).

Ilustración 6.28- Código JS para guardar elementos en el almacenamiento local del navegador

Luego, para acceder a las animaciones previamente guardadas en el

desplegable es tal y como se muestra en la siguiente imagen (ilustración 6.29).

Ilustración 6.29- Código JS para acceder a elementos guardados con el almacenamiento local del navegador

Para más información al respecto de este tipo de almacenamiento, ir al anexo

correspondiente.



149


6.3.16. Iteración para la creación del modo simplificado con información real

En esta iteración se implementa la web que finalmente se hará pública porque se

subirá al servidor del CEACTierra. Esta web se le ha llamado “simplificada” porque

tiene las funcionalidades que se han considerado imprescindibles para los usuarios

que puedan utilizar la web.

Además, tras implementar los archivos necesarios para este modo más

simplificado, se añadió toda la información real necesaria para la web. Esta

información es específica de la zona de “La Cimbarra”, el modelo 3D en torno al cual

gira todo el proyecto. Añadir esta información ha significado tener que cambiar

algunos controles en la parte donde se mostraba la información en la web tal y como

se verá mejor en la demostración en vídeo del proyecto. Estos cambios consisten en

añadir botones para cambiar entre vídeos, imágenes, enlaces a nuevas pestañas en

el navegador en las cuales sale más información, e incluso alertas personalizadas

con más información, por lo que la web se ha quedado mucho más completa. Toda

esta información ha sido obtenida con técnicas de escaneo y fotogrametría (técnica

para obtener mapa y planos de un terreno) de la superficie de “La Cimbarra” en una

visita “in situ” que hicimos el desarrollador y el cliente.

A simple vista, nada más cargar la web aparecerá tal y como se ve en la

siguiente ilustración 6.30:

Ilustración 6.30- Resultado de la web en el servidor CEACTierra con información real



150


6.3.17. Otras funciones

Hay otras funciones utilizadas en la web que 3DHOP proporciona de forma

básica:

• Zoom: se puede realizar con el ratón/trackpad o con los dos botones del

canvas destinados a esa función. Y simplemente consiste en llamar a la

función encargada de realizar el zoom en el controlador (“presenter.js”), es

decir, cambiará la matriz de visión en un factor dependiendo de cuantas

veces le hayamos dado al botón o al ratón. También se puede realizar el

zoom in o out con las teclas ‘1’ y ‘2’.

• Measure: 3DHOP por defecto traía una herramienta que tras activarla marcas

dos puntos en el modelo 3D principal del canvas, y se forma una línea entre

los 2 puntos mostrando la distancia entre ellos. Para adaptarlo a las

distancias reales que representa el terreno se ha tenido que cambiar la

función adecuada para ello, además de distinguir entre los modelos cargados

en la web, en nuestro caso 2 (modelo de “La Cimbarra” y el modelo de la

sección de “ripples”) debido a que cada uno tiene una escala.

Ilustración 6.31- Código JS para el método onEndMeasure de 3DHOP

Además, tal y como podemos observar en la imagen anterior 6.31, también se

ha modificado el método para pasarle los puntos que se han seleccionado

para mostrarlos utilizando el código de la siguiente función de esta lista.

• PickPoint: simplemente sirve para hacer click sobre una parte del modelo y

aparecen las coordenadas de ese punto. Realmente es una herramienta útil

para el desarrollo para saber ciertas posiciones para animaciones, colocar

etiquetas, … pero no demasiado para un prototipo final. Ver siguiente

ilustración número 6.32.



151


Ilustración 6.32- Código JS para el método onEndPick de 3DHOP



152


7. Resultados y pruebas

En este capítulo se van a observar los resultados de las pruebas (que puedan ser

mostradas por medio de imágenes) realizadas en cada una de las iteraciones, y que

fueron explicadas en el capítulo de implementación. Al haber seguido una

metodología incremental, en cada iteración, tal y como aparece en el diagrama de

Gantt de la planificación temporal, hay un apartado de pruebas justo después de la

implementación de cada prototipo creado. Por tanto, en este capítulo se expondrán

esas pruebas para ver los resultados obtenidos, además de las opciones que se han

realizado para poder ejecutar el prototipo web y ver los resultados que aquí se

explican, junto con una retroalimentación de los usuarios que han probado la web.

Prototipo para la creación de un mapa de Google Maps

Se ha creado un mapa de google totalmente funcional en la web. El mapa está

centrado en la posición de interés del proyecto, con el zoom adecuado y con un

punto de interés añadido en el lugar relevante. Ver la siguiente imagen 7.1.

Ilustración 7.1- Mapa de Google de la web del proyecto

Prototipo para mostrar información general de modelos principales

La web está dividida en dos mitades, la de la izquierda donde estará la parte

gráfica para interactuar con los modelos, y la parte de la derecha donde habrá todo

tipo de información. Por defecto, en esta parte donde está cualquier tipo de

información, estará la información del modelo principal cargado en el canvas



153


(ilustración 7.2), salvo cuando se active alguna funcionalidad que necesite mostrar

algo de información en ese lugar.

Ilustración 7.2- Prototipo web con la zona informativa remarcada

Prototipo para el sistema de etiquetado informativo

Al activar esta funcionalidad aparecerán en el modelo principal del canvas

pequeños modelos de banderas simulando puntos de interés dentro del modelo

principal. Dichos modelos de banderas son seleccionables, de forma que aparecerá

información de la zona de interés que representen (ilustración 7.3).

Ilustración 7.3- Prototipo web con la zona informativa remarcada



154


Prototipo para el sistema de cambio de modelo del canvas

Esta función simplemente activa una alerta en la que aparece un desplegable

con los modelos 3D principales disponibles para cargar en el canvas y

seleccionaremos uno, se realizarán los cambios necesarios y se mostrará

(ilustración 7.4).

Ilustración 7.4- Prototipo web cambiando de modelo principal

Prototipo para la herramienta de cálculo de áreas

Este prototipo ha creado una herramienta de forma que realizando

transformaciones geométricas sobre un modelo secundario (cubo) se situará dónde

y cómo el usuario desee de forma que cuando se seleccione el cubo, aparecerá

información del área que abarca el cubo. Además, de un botón que activará en el



155


mapa de Google una herramienta similar para realizar la medición con más

precisión. Todo se puede ver con claridad en la ilustración 7.5.

Ilustración 7.5- Herramienta de cálculo de superficies sobre modelo en la web

Prototipo el sistema de etiquetado con información meteorológica

El funcionamiento es idéntico que el etiquetado informativo porque se usa el

mismo sistema. La diferencia es la información que se muestra, que en este caso

hay que acceder a través de internet a información del tiempo y de las coordenadas

geográficas exactas del punto del cual se está mostrando dicha información.

También se puede añadir un punto de interés de la zona cuyas coordenadas se han

mostrado en el mapa de Google de la web. Ambas características se observan en la

ilustración 7.6.



156



Prototipo para la visualización con ThreeJS y Nexus

Visualización expuesta en ilustraciones añadidas en el capítulo de análisis

cuando se explicó las características de una web dinámica y adaptable.

Prototipo para función de transformaciones geométricas

Se pueden realizar funciones de rotación y escalado del modelo principal de la

web por medio de sliders (controles) implementados para ello tal y como se ve en la

ilustración 7.7.



157



Prototipo para la visualización con Unity

Después de activar esta función aparece la posibilidad de abrir en otra pestaña

del navegador, una visualización del modelo principal hecho con Unity.




158


El resto de funciones que no se han mostrado en este capítulo por medio de

ilustraciones, se pueden ver en el video de demostración adjuntado junto a esta

memoria.

7.1. Feedback de los usuarios

Una vez se tiene el prototipo web accesible desde internet, se ha creado un

formulario con la herramienta que Google proporciona para ello, y se ha enviado a

unos cuantos usuarios que no tienen ninguna relación con el proyecto, para así

recoger las sensaciones o retroalimentación de los usuarios que podrían utilizar la

herramienta, para así sacar conclusiones adecuadas.

El formulario se ha enviado a once diferentes personas con conocimientos de

diferentes campos, no solamente de informática, y las preguntas que han respondido

después de haber probado en detalle el prototipo web alojado en el servidor del

CEACTierra junto a los resultados obtenidos han sido:

• ¿La web es lo que se imaginabas con la descripción previa de la misma?

A esta respuesta mayoritariamente se ha respondido positivamente tal y como

se observa en la siguiente ilustración 8.1 del gráfico generado por la herramienta

de Google, siendo la descripción previa el título del TFG.

Ilustración 7.9- Estadísticas primera pregunta formulario Google TFG

• ¿Cree que estéticamente es correcta la web dado el propósito de la

misma?

Esta pregunta es muy importante cuando se realiza cualquier tipo de

aplicación, y aunque no ha sido uno de los objetivos principales del proyecto por

falta de tiempo, sí que se ha tenido en cuenta. El resultado de esta pregunta



159


entre los usuarios de forma similar al gráfico anterior, ha sido positivo (ilustración

8.2).

Ilustración 7.10- Estadísticas segunda pregunta formulario Google TFG

• ¿Cuáles han sido los obstáculos principales que ha tenido a la hora de

usar el prototipo web?

Esta pregunta es muy importante para saber cuáles son las opciones que hay

que mejorar en la web en futuras versiones, para adaptarse a las sugerencias de

los usuarios. En este caso, las respuestas si han sido más dispersas entre las

diferentes opciones planteadas (ver ilustración 8.3).

Ilustración 7.11- Opciones tercera pregunta formulario Google TFG

Y los resultados, aunque han sido más dispersos, el más votado fue con 4

votos el de “dificultad o falta de información para entender y usar algunas

opciones”, algo claramente mejorable en algunos casos, por lo que habría que

mejorar la documentación y ayuda que proporcionar la web. La siguiente opción

por orden es la de “demasiadas opciones” con 3 votos, los mismos que la opción

de “ningún obstáculo”. Por tanto, la conclusión que se puede sacar de esta

pregunta es que depende de cada usuario particular, ya que algunos no han

tenido problemas y otros algunos, pero en definitiva habría que principalmente

mejorar la explicación de las opciones más complejas, un trabajo futuro esencial



160


para este proyecto. Todo esto se observa con más detalle en la siguiente

ilustración 8.4.

Ilustración 7.12- Estadísticas tercera pregunta formulario Google TFG

• ¿Recomendaría la web a alguien que por cualquier motivo necesite

información de la zona que se muestra?

El resultado de esta pregunta es positivo dado el objetivo del proyecto. En la

ilustración 8.5 se puede ver.

Ilustración 7.13- Estadísticas cuarta pregunta formulario Google TFG

• ¿Cree que la interacción en la web y las opciones que tiene son

adecuadas dado el propósito de la web?

En esta pregunta sí que hay una respuesta mayoritariamente afirmativa y

satisfactoria, pero dado el porcentaje negativo, hay un claro trabajo futuro de

mejorar la interacción y opciones del prototipo web. En la ilustración 8.6 se

observa lo dicho.



161


Ilustración 7.14- Estadísticas quinta pregunta formulario Google TFG

• Opción/es que le hayan parecido más útiles

Aquí comprobamos cuáles son las opciones más llamativas para los usuarios de

entre las posibles propuestas planteadas en la pregunta (ilustración 8.7), que

prácticamente abarcan las opciones esenciales de la web.

Hay varias opciones que han tenido más votos, pero todas las posibilidades han

sido seleccionadas, lo que denota que, aunque depende de opiniones subjetivas de

cada usuario, todas las opciones son útiles.

Ilustración 7.15- Opcioens sexta pregunta formulario Google TFG

Las opciones más llamativas para los usuarios han sido “la interacción con el

modelo 3D”, “la posibilidad de cambiar de modelo 3D”, y la información y el sistema

de etiquetas de la web.

• Opción/es que desearía ver mejoradas

De las anteriores opciones de la ilustración 8.7 las que se quieren ver mejoradas

(trabajos futuros del proyecto) según los usuarios encuestados son sin duda la de



162


“información que aparece relacionada con el modelo” y “las opciones con el mapa de

GoogleMaps”, aunque hay diversidad de opiniones entre las demás opciones.

• ¿Qué nuevas opciones le gustaría que tuviera el prototipo web en un

futuro?

Las opciones más votadas para futuros trabajos con este proyecto son las de

añadir alguna funcionalidad con realidad aumentada y el mapa de Google, visualizar

los modelos con realidad virtual, e interactuar con nuevos modelos de otros lugares

ajenos a la zona de “La Cimbarra”. Se pueden observar las diferentes opciones en la

ilustración 8.8.

Ilustración 7.16- Opciones sexta pregunta formulario Google TFG

• Sugerencias

Las sugerencias escritas de forma voluntaria por algunos usuarios han sido que

en general les ha gustado, aunque habría que mejorar la estética de la web, así

como refinar las funcionalidades existentes. Además, de ser muy útil la opción de

internacionalización.

7.2. Opciones para probar la web

En esta sección se va a explicar las opciones que tenemos para poder ejecutar el

prototipo web desarrollado, o poder realizar modificaciones sobre este y ejecutarlas,

así como probar cualquier ejemplo realizado con el framework 3DHOP

principalmente.

Como es lógico el desarrollo del prototipo se ha realizado de forma local en un

dispositivo debido a que es mucho más cómodo. Por tanto, la tercera opción solo ha



163


sido posible al finalizar el proyecto cuando el prototipo estaba prácticamente

totalmente funcionando de forma adecuada.

7.2.1. Desarrollo local desde el navegador

Esta posibilidad no es la más adecuada en cuanto a un desarrollo profesional ni

en cuanto a funcionamiento más óptimo porque se pierde la seguridad que

proporciona el navegador. Sin embargo, se intentó por ser la más sencilla y la que

menos tiempo llevaba, ya que no había necesidad de instalar algún software

adicional.

El desarrollo local desde el navegador significa literalmente cargar archivos

localmente en un navegador. En este caso la prueba se ha realizado con Google

Chrome. Esta opción nos permitiría evitar instalar un servidor web, ya que

podríamos cargar páginas webs directamente desde nuestro ordenador local.

Todos los navegadores tienen una opción para acceder a archivos locales de

nuestro ordenador, pero por seguridad siempre está desactivada.

Necesitamos forzar al navegador a aceptar archivos locales, en el caso de

Chrome es irnos con la terminal al directorio donde esté instalada la aplicación y

poner la siguiente instrucción.

“ --allow-file-access-from-files ”.

En un principio se trata de desarrollar bajo esta modalidad debido a la sencillez y

la ausencia de software adicional como xampp, pero no funcionó en ninguno de los

navegadores en los que se probó, por lo que aunque en la propia documentación del

framework elegido “3DHOP” o incluso de otros como “Three.js” sale como opción, no

se ha conseguido llevar a cabo, aunque tampoco ha sido considerado ningún

inconveniente porque a pesar de ser la opción más sencilla, también es la que crea

un problema de seguridad importante en el navegador en el cual se desactive dicha

opción.



164


7.2.2. Instalación y configuración de un servidor web local

Durante todo el desarrollo del proyecto, salvo la parte final en la que se terminó

de refinar en un servidor físico de un grupo de la universidad… (septiembre a marzo,

ver diagrama Gantt), se ha realizado con un servidor web local de apache.

“Apache HTTP server” es uno de los softwares de servidores web más usados a

nivel mundial. Su instalación no es difícil, pero se simplifica aún más con una

solución como es XAMPP (página web xampp).

Un servidor http Apache es la solución ampliamente más usada en estos casos.

Se puede hacer de muchas formas, pero la más posiblemente más sencilla y la que

se ha elegido es instalar una solución de web server en un paquete. Este paquete es

la herramienta gratuita, de código abierto y multiplataforma, XAMPP.

XAMPP es un servidor web de plataforma, software libre, que consiste

principalmente en el sistema de gestión de bases de datos MySQL, el servidor web

Apache y los intérpretes para lenguajes de script PHP y Perl. Se puede descargar

aquí.

Tras instalar esta solución, nos dirigimos a la carpeta donde están todos los

archivos que se han descargado con Xampp, entramos en la “sub-carpeta” llamada

“htdocs” y ahí ponemos el código de la web de 3DHOP. A partir de ahora

desarrollaremos desde ahí, para ello, simplemente abrimos la aplicación “manager”

de Xampp, activamos el servidor Apache y en nuestro navegador ponemos la ruta

“http://localhost” y ya podremos probar nuestra web. Si se hace exactamente como

se ha descrito, la ruta variará dependiendo de donde se encuentre el fichero

principal html, en mi caso es: “http://localhost/index.html”.

Para desarrollar debemos añadir los ficheros necesarios de la web a la carpeta

htdocs de xampp.

El uso de un servidor web local para el desarrollo del prototipo no es demasiado

complejo, y es la forma de más confianza para desarrollar páginas webs. A pesar de

esto, requiere cierta configuración, de ahí que haya otras soluciones más simples

como la anterior 7.1.

https://www.apachefriends.org/es/index.html



165


7.2.3. Instalación y configuración de un servidor remoto por internet

Este desarrollo remoto con internet es la solución más profesional y la optada en

las fases finales de desarrollo cuando la web se tuvo que subir de forma oficial a un

servidor físico, al final de del desarrollo del proyecto.

La idea es sencilla, los archivos se suben a un servidor, ya sea físico o remoto, y

se accede a ellos a través de un ordenador cliente con un navegador web

introduciendo la dirección correspondiente.

El framework utilizado para el desarrollo, y prácticamente casi cualquier

alternativa, funcionan de la misma manera, es decir, no necesitan ningún servidor

web especial, simplemente se necesita algo de espacio para alojar los archivos

necesarios para alojar nuestra página web.

El servidor al cual se han subido los archivos es el del “Centro de estudios

avanzados de la Tierra de la Universidad de Jaén”, el cual hará uso del software

implementado en este caso para difundir información sobre “La Cimbarra” de la

provincia de Jaén, y en un futuro para cualquier modelo 3D que se desee cargar en

la web.

Primero hay que explicar cómo se usa el servidor, es decir, como se ve y se

configura lo que alberga. Esto se hace con “Proxmox”, un sistema de virtualización

de servidores de código abierto (véase referencia correspondiente).

Las características de Proxmox son:

• Administrador web HTML5: Proxmox proporciona un interfaz Web para

configurar los servidores físicos, clúster (conjunto de ordenadores unidos

por una red de alta velocidad que funcionan como una super-

computadora), máquinas virtuales, backups (copias de seguridad),

restauración de backups, snapshots (instantáneas del sistema). No es

necesario instalar aplicaciones clientes.

• Virtualización para la mayoría de Sistemas Operativos.

• KVM (Máquina virtual basada en el núcleo) es una solución para

implementar virtualización sobre Linux.



166


• Copias de seguridad y restauración de máquinas virtuales.

• Snapshot Live: le permite hacer copias instantáneas de máquinas virtuales

incluyendo el contenido de la RAM, su configuración y el estado de los

discos virtuales.

• Clúster de alta disponibilidad: si uno de los servidores físicos o nodo está

sobrecargado, este transfiere automáticamente a otro servidor físico o

nodo con menos carga. Este ejemplo es una regla de balanceo de carga

entre nodos.

• Firewall: cortafuegos para más seguridad.

• Autenticación con usuarios y contraseñas.

El porqué de usar Proxmox está muy claro, porque es totalmente libre y gratuito

sin ningún tipo de limitación.

No fue necesario ningún tipo de instalación debido a que era la forma en la que

los técnicos encargados de mantener dicho servidor.

En segundo lugar, para acceder al servidor introducimos su dirección en un

navegador y nos aparecerá la página de Proxmox para introducir el usuario y la

contraseña para así acceder.

Tras acceder hay varias máquinas virtuales creadas para controlar todo lo que

alberga el servidor. Por tanto, se crea una máquina virtual para este proyecto, para

esta web. Al crearla necesitaremos un usuario y una contraseña que deberemos

añadir, así como el espacio de almacenamiento, la memoria RAM, los puertos

asociados, …, que queramos asociarle dado el propósito de la web que vamos a

alojar.

Y tras crearla podemos un resumen de la máquina, así como todas las

opciones posibles (ilustración 7.1). Hay que destacar que la siguiente ilustración se

hizo cuando ya llevaba unos días en funcionamiento la web en el servidor del

“CEACTierra”.



167


Ilustración 7.17- Ventana de máquina virtual del proyecto en Proxmox en la web

Una vez creado el espacio correspondiente en el servidor para la web,

procedemos a subir los archivos necesarios para el funcionamiento de la web. Para

ello hay varias opciones:

1. Filezilla: es la solución más común para la práctica que se desea

realizar.

Filezilla es una aplicación FTP (el protocolo de transferencia de ficheros

es un estándar usado para compartir archivos desde los archivos de un

ordenador cliente a un ordenador servidor por medio de una red)

multiplataforma y gratuita para transferir archivos desde un cliente

(filezilla client) u ordenador hasta un servidor.

Para subir los archivos debemos abrir la aplicación Filezilla, y una vez

abierta introducir los datos para poder acceder al servidor:

La dirección del servidor: sftp://x.x.x.x, el nombre de usuario y la

contraseña de la máquina virtual donde queremos subir los archivos

dentro del servidor, y el puerto destinado para ello (en este caso hay dos

puertos, el 8015 para subir archivos, y el 8014 para acceder a la web).

Una vez entremos, simplemente iremos al directorio correspondiente

para subir una web var/www/html, y ahí añadir todo lo necesario para

que se ejecute la web correctamente.



168


Ilustración 7.18- Filezilla aplicación accediendo al servidor del CEACTierra para editar los archivos de la web

2. Otra opción es acudir a la terminal del dispositivo cliente. Una solución

quizás algo más compleja debido a que no tenemos una interfaz gráfica

que nos facilite el proceso.

Esta solución es acceder por ssh (protocolo seguridad de red muy

utilizado en especialmente para acceso remoto a un servidor) al

servidor, algo muy sencillo si la terminal es en UNIX como s este caso al

usar un Macbook.

Accederíamos con la siguiente instrucción a la máquina virtual

correspondiente en el servidor:

Ilustración 7.19- Instrucción ssh para acceder a la dirección del servidor

Nos autenticaríamos con el nombre de usuario y la contraseña y ya

accederíamos al directorio dicho en la opción anterior con los típicos

comandos como “cd directorio”, y añadiríamos y borraríamos archivos

por terminal con ‘rm’, entre otros comandos típicos de la consola Unix.



169


Esta solución se llevó a cabo la primera vez para comprobar que

funcionaba por ssh y todo estaba correctamente, posteriormente en la

depuración de errores se realizó instalando Filezilla puesto que es muy

más amigable la interfaz y permite un mayor y más sencillo control.

Ilustración 7.20- Acceso al contenido de la web en el servidor por medio de conexión ssh

desde la terminal de MacOs

Además, en cualquier momento podemos suspender la máquina virtual desde la

interfaz de Proxmox en caso de que queramos cambiar mucho la web o no

queramos que sea accesible al público.

También desde proxmox podemos diferentes gráficas del uso que se está dando

a nuestra web (ilustración 7.13):



170


Ilustración 7.21- Estadísticas de la máquina virtual del proyecto en Proxmox en la web

La web actualmente se puede ver en la dirección http://150.214.174.64:8014

http://150.214.174.64:8014/



171


8. Conclusiones

La propuesta de este trabajo de fin de grado surgió a partir de que el Centro de

Estudios Avanzados en Ciencias de la Tierra se pusiera en contacto con el tutor

principal de este proyecto, Juan Roberto Jiménez Pérez, por la necesidad de

creación de una plataforma web que pueda cargar modelos 3D para difundir

patrimonio de la provincia de Jaén, en este caso de la zona de “La Cimbarra”. Tras

hablar con Roberto, decidí elegir este proyecto debido a que es un proyecto de fin de

grado interesante por ser un proyecto muy recurrente a día de hoy, ya que

actualmente los gráficos 3D en la web son muy utilizados para todo tipo de utilidades

(véase sección de aplicaciones). Además, de ser un proyecto que se encuadra

dentro de la mención de gráficos, la cual yo como alumno he querido cursar, por lo

que complementa aún más mis conocimientos sobre informática gráfica, y sin duda

es un proyecto muy interesante que puede servir de base para futuros trabajos.

Este proyecto me ha permitido entender cómo funcionan los gráficos 3D en la

web, además de haber ampliado conocimientos en otros campos:

• Conocer numerosos recursos para la renderización de gráficos 3D en la web.

• Adquirir un elevado conocimiento sobre JavaScript, un lenguaje de

programación esencial en aplicaciones web, y que hasta antes de este

proyecto, nunca lo había utilizado.

• Mejorar en el desarrollo de aplicaciones web integrando diferentes APIs en el

mismo proyecto, realizando la parte de diseño de la interfaz junto al contenido

de esa interfaz, …

• Iniciarme en el mundo de la impresión 3D.

• Aprender como editar modelos 3D con diferentes herramientas software,

• Aprender cómo se realiza la captura de información de un terreno para la

creación de modelos 3D geométricos.

• Aprender cómo desarrollar un proyecto de gran envergadura de principio a fin,

teniendo reuniones periódicas, y realizando una estimación de costes,

planificación temporal, …

• Tener en cuenta diferentes aspectos de accesibilidad para hacer la web del

proyecto lo más usable y accesible posible.



172


Muy destacable también la satisfacción de los usuarios con el prototipo web,

obteniendo mayoritariamente unas valoraciones satisfactorias, dejando constancia

de que el prototipo es adecuado tanto estética como funcionalmente par asu

propósito. Todo esto se puede ver más en detalle viendo las preguntas del

cuestionario a las que los usuarios respondieron, en la parte de feedback de los

usuarios del capítulo de resultados y pruebas.

8.1. Aplicaciones

Los casos de uso en los cuales se puede aplicar el proyecto realizado o variantes

del mismo son muy diversos.

• Difusión de patrimonio cultural o natural por medio de modelo 3D

geométricos, o de cualquier otro tipo de modelos 3D.

• Museo interactivo de modelos 3D.

• Simulaciones con gráficos 3D en la web de cualquier índole (simulación de

rutas en terrenos o ciudades, simulación médica con algún modelo de un

órgano, por ejemplo, simulación para la venta de algún elemento como una

casa, animaciones, …).

• Creación de algún tipo juego con gráficos 3D.

• Enseñanza de gráficos 3D en la web y sus posibilidades.

8.2. Trabajos futuros

A continuación, se indican una serie de características que han quedado fuera

del alcance del presente proyecto.

• Este proyecto es un prototipo por lo que un trabajo futuro básico es seguir

depurando errores imprevistos que puedan suceder en la aplicación para

hacerla más robusta y eficiente. Es decir, convertir la aplicación en un

producto preparado para ser lanzado al mercado en una versión inicial.

• Adaptar el proyecto a cualquier otra área de interés diferente de La Cimbarra

u utilizarlo con otros modelos 3D no implicaría demasiado esfuerzo.

• Mejorar la accesibilidad de la web, estudiando y corrigiendo todos los

inconvenientes que posea.



173


• Añadir funcionalidades adicionales, ya sea con el framework 3DHOP o con

ThreeJS y Nexus. Algunas de las funcionalidades que se han pensado que

podrían ser de interés son herramientas de edición de modelos 3D al estilo

Meshlab en la web, una herramienta de alturas sobre modelos de terrenos

como el de La Cimbarra (en formatos específicos como por ejemplo el TIN),

…

• Visualización de la web compatible con realidad virtual.

• Utilizar la realidad aumentada para proporcionar información sobre La

Cimbarra si detectáramos que estuviéramos en la zona. Todo esto orientando

el prototipo a dispositivos móviles.

• La herramienta de saber las coordenadas de un punto donde se ha clickado

en el modelo podría modificarse para que mostrase las coordenadas

geográficas de google maps para enlazar un modelo de un terreno (en este

caso La Cimbarra) con la información adicional que pueda aportar google

maps.

• Contactar con los creados de 3DHOP para que utilicen el proyecto enlazado

en la propia web de su software para difundirlo.

• Realizar animaciones más complejas en la web añadiendo opciones de

curvas, cinemáticas, …, siempre que los modelos sean adecuados para ello y

tenga una gran resolución.

• Realizar demostraciones de algoritmos geométricos en la web.

• Peticiones de los usuarios, tal y como se puede ver en el siguiente apartado

de feedback de los usuarios.



174


ANEXO C: Manual de instalación

En este manual se explica el proceso que hay que llevar a cabo para ejecutar la

web desarrollada en este proyecto. Se indican los pasos a seguir.

1. Habilitar WebGL en el navegador

Siempre que queramos ejecutar una página web que contenga código JavaScript

destinado a la renderización (proceso de generar una imagen realista o no a partir

de un modelo 2D o 3D) de gráficos 3D (gráficos que utilizan una representación

geométrica en 3 dimensiones), debemos habilitar las opciones correspondientes del

navegador sobre el cual queramos ejecutarla para que funcione dicha web de forma

adecuada, o de lo contrario no veremos el contenido gráfico. Por tanto, para ejecutar

este proyecto, no va a ser diferente debido a que utiliza una librería de creación de

gráficos 3D que se basa en WebGL.

A continuación, se describe como configurar los navegadores más populares en

la actualidad y sobre los cuales se ha probado este proyecto.

Antes de nada, debemos comprobar si funciona WebGL en el navegador que

deseamos realizando los pasos 2 y 3 antes de comenzar con este o visitando:

https://get.webgl.org/ . Lo normal es que en cualquier navegador venga activada la

opción por defecto y funcionen los gráficos 3D de cualquier web.

a. Firefox

Los pasos a seguir son:

➢ Escribir en la barra de direcciones about:config y pulsar enter. Nos

aparecerá probablemente un aviso de que hay riesgo debido a que

ahí están las configuraciones más delicadas del navegador, pero

aceptamos sin problemas.

➢ Buscamos webgl.disabled y asegurarse de dejarlo a false.

b. Google Chrome


https://get.webgl.org/



175


➢ Escribir en la barra de direcciones chrome://settings

➢ Haga clic en el + para Mostrar la configuración avanzada.

➢ La opción Uso de la aceleración hardware debe estar disponible y

activada.

➢ Escribir en la barra de direcciones chrome://flags

➢ La opción deshabilitar WebGL debe estar desactivada.

c. Safari


➢ Ir a preferencias de Safari.

➢ Seleccionar la opción Avanzada.

➢ Mostrar menú de desarrollo en la barra de menús.

➢ Nos vamos al menú desarrollo que habrá aparecido y buscamos la

opción de activar WebGL. Esta opción estará en funciones

experimentales.

2. Ejecutar versión simplificada de la web en el servidor

Introducimos en cualquier navegador compatible, preferiblemente los 3

nombrados con los cuales se ha probado, la dirección de la web:

http://150.214.174.64:8014

3. Ejecutar versión completa de la web de forma local

Se debe ejecutar utilizando un servidor web de forma local. La opción

recomendada y que se ha utilizado durante el desarrollo, es un servidor Apache

gracias a la aplicación Xampp.

Pasos a seguir:

➢ Descargar la aplicación Xampp: Este link

➢ Instalamos Xampp.

http://150.214.174.64:8014/

https://www.apachefriends.org/es/download.html



176


➢ Vamos a la carpeta de la aplicación, buscamos la sub-carpeta llamada

“htdocs”, y dentro de esta añadimos todos los ficheros y carpetas del

proyecto.

➢ Abrimos la aplicación instalada con Xampp (“manager”), y activamos el

servidor apache.

➢ Abrimos un navegador compatible y ponemos la ruta correspondiente del tipo:

o http://localhost/Proyecto/index.html



177


ANEXO D: Manual de usuario

En este anexo se va a realizar una explicación para saber cómo se controla la

web que hay subido en el servidor del CEACTierra.

En primer lugar, debemos visitar la página web. Su página inicial es la que se ha

visto en ilustraciones anteriores de esta memoria como pueden ser la ilustración

6.30. A continuación, veremos la distribución de la página en un formato de tabla con

2 columnas, en la parte de la izquierda aparece la zona con el canvas de la web

donde aparecerá el modelo 3D y las opciones de interacción con el mismo, y en la

parte de la derecha está la información asociada al modelo 3D visualizado. Además,

de un mapa de Google en la parte inferior de la página que da un valor añadido para

algunas opciones de interacción disponibles.

Nada más cargar la web aparece el modelo de La Cimbarra de Jaén cargado en

la zona correspondiente, junto a información asociada en la que hay enlaces de

interés a otras páginas webs. Si deseamos interactuar con el modelo 3D

simplemente tenemos que seleccionarlo en el canvas y moverlo, además de poder

realizar zoom también con el ratón. También existen diferentes opciones que se

activan y desactivan por medio de diversos botones en el canvas:

• Pulsando el botón “Inicio” se resetea la posición del modelo y vuelve a su

posición inicial, la posición que tenía al cargar la web.

• Pulsando los botones “Mas zoom” o “Menos zoom” se realiza zoom sobre la

cámara que enfoca al modelo 3D sin que el usuario tenga que realizarlo

manualmente con el ratón.

• Pulsando el botón “Mostrar rotación modelo 3D” aparecen 3 controles de

slider (eje X, eje Y, eje Z) de forma que podamos realizar transformaciones de

rotación sobre la matriz del modelo de La Cimbarra simplemente arrastrando

la barra del slider del eje deseado.

• Pulsando el botón “Mostrar escalado modelo 3D” aparecen 3 controles de

slider (eje X, eje Y, eje Z) de forma que podamos realizar transformaciones de

escalado sobre la matriz del modelo de La Cimbarra simplemente arrastrando

la barra del slider del eje deseado.



178


• Pulsando el botón “Activar Animacion” el usuario simplemente observa cómo

se realiza una animación de ruta sobre el modelo de la Cimbarra mientras

aparece información sobre dicha zona.

• Pulsando el botón “Activar rotación en Y” el usuario observa como se hace

una animación sobre el eje Y del modelo de La Cimbarra.

• Pulsando el botón “Mostrar Etiquetas” aparecen diversos modelos 3D en

forma de banderas que representan puntos de interés sobre el modelo de La

Cimbarra. Estos modelos responden a la acción de hacer click sobre ellos

para mostrar información del lugar de interés que representan, realizando una

animación para acercar la cámara a dicho punto.

• Pulsando el botón “Mostrar Etiquetas en mapa” sucede lo mismo que con la

opción de “Mostrar Etiquetas” explicada anteriormente con la diferencia de

mostrar otro tipo de información.

• Pulsando el botón “Activar herramienta de medida” aparece una caja en la

que aparecerá la distancia tras seleccionar dos puntos del modelo 3D. El

usuario deberá realizar click sobre dos puntos del modelo de La Cimbarra

para que se calcule la distancia entre ellos a escala real.

• Pulsando el botón “Mostrar Vista panorámica” nos permite interactuar con el

modelo del canvas con movimientos panorámicos en cualquier dirección.

• Pulsando el botón “Mostrar herramienta superficies” aparece unos controles

en forma de sliders para escalar, trasladar y rotar un modelo 3D en forma de

cubo que aparece sobre el modelo de La Cimbarra. El usuario debe situar

como crea correcto el cubo ocupando la zona de La Cimbarra de la cual

quiera saber la superficie, algo que sabrá cuando pulse sobre dicho modelo

seleccionable de cubo. Además, tras hacer click para informarnos de la

superficie de una zona, aparecerá otra opción llamada “Ver en mapa” que si

pulsamos sobre ella nos iremos al mapa de Google de la web, que tras hacer

click derecho sobre este podremos medir la superficie con más precisión en el

mapa.

• Pulsando el botón “Activar Unity View” aparece un botón con el texto “Mostrar

La Cimbarra en Unity”. Tras pulsarlo se nos abrirá otra pestaña en el

navegador en la cual se cargará la visualización de la zona de La Cimbarra

realizada con Unity de forma que cuando termine de cargar podremos



179


controlar en primera persona el movimiento sobre este terreno. El movimiento

es con las teclas w,a,s,d para movernos hacia delante, a izquierda, atrás y

hacia la derecha respectivamente, orientándonos con el ratón.

• Pulsando el botón “Cambio de modelo” aparece una alerta con un

desplegable en el cual aparece el nombre de los diferentes modelos

disponibles para ser visualizados en la web, se seleccionar el deseado.

• Hay unos botones debajo del canvas que cambian la perspectiva en la que

vemos el modelo cargado.



180


ANEXO E: Github Pages

Cuando tenemos un proyecto web con GitHub (github pages) podemos subir

nuestra página a un host para poder consultarla como si de una web de internet se

tratase, es decir, desde cualquier dispositivo y en cualquier lugar. Así para realizar

este proceso hay que seguir los siguientes pasos:

1. Iniciar sesión en GitHub y crear un nuevo repositorio.

2. El nombre del repositorio es algo especial, ya que debe tener el siguiente

formato para nuestra web: "username.github.io".

3. Una vez creado el repositorio, por medio de comandos de git, o con

herramientas gráficas como “Smartgit” o la propia de GitHub “Github

Desktop” procedemos a clonar el repositorio.

4. Tras clonarlo copiamos todos los archivos de nuestro proyecto web a

excepción del ‘html’, es decir, copiamos los assets, las librerías, …, en

nuestra carpeta colgada, en nuestro repositorio. Posteriormente procedemos

a realizar un “commit” de esos cambios realizados en nuestro repositorio (con

comandos o las apps anteriormente nombradas) en la rama que deseemos,

aunque obviamente finalmente debe estar en la master.

5. Nos volvemos a ir a nuestra cuenta de GitHub que tenemos abierta en

nuestro navegador y procedemos a crear un nuevo archivo que llamaremos

index.html y en el cual copiaremos el código del ‘html’ de nuestro proyecto.

Esto se debe hacer para que GitHub sepa cuál es el archivo que debe

ejecutar como nuestra web. Tras copiar el código confirmamos los cambios

en nuestro repositorio.

Así, nuestro repositorio deberá quedar como en la siguiente captura (ilustración

0.1):



181


Ilustración 0.1- Github con el proyecto de la web

Y tal y como aparece en la captura del apartado de responsive website donde

aparece un móvil utilizando el prototipo, la dirección que debemos poner en un

navegador compatible con WebGL es: https://guillegarrido.github.io. Aunque hay que

aclarar que esa dirección se probó realizando este anexo durante el desarrollo del

proyecto, y actualmente al estar subida al servidor del CEACTierra no está activa.

https://guillegarrido.github.io/



182


ANEXO F: Almacenar información en un prototipo web

Hay varias opciones para almacenar datos de una web durante más tiempo a

priori indefinido. Esta información es interesante saberla porque es algo que

prácticamente siempre que hagamos un proyecto basado en la web vamos a

necesitar para una u otra tarea, tal y como hemos podido ver en las herramientas de

añadir modelos a la web o de creación de animaciones.

Las opciones principales para almacenar información son las 4 siguientes que

definimos a continuación:

• HTML Web Storage: almacenamiento de datos en el navegador. Este tipo de

almacenamiento es más seguro que las cookies, puede almacenar grandes

cantidades de datos, y no afecta negativamente al rendimiento de la página.

Información al respecto de esta característica tal y como aparece en la referencia

correspondiente de la bibliografía.

o Local Storage: los objetos de almacenamiento local almacenan datos sin

fecha de expiración, es decir, los datos almacenados no serán borrados

cuando se cierra el navegador, y estarán disponibles tanto tiempo como

queramos hasta que los borremos.

o Session Storage: es idéntico al almacenamiento local, con la diferencia

de que los datos sí que tienen fecha de caducidad cuando se cierra la

pestaña del navegador de la web donde se almacenaron.

• Cookies: objetos con datos en pequeños archivos de texto. La información al

respecto de estos objetos ha sido extraída de aquí.

• BD: en una base de datos se puede almacenar como sabemos cualquier dato

con un almacenamiento, qué, aunque depende del servicio que usemos, es en

teoría ilimitado.

Aunque principalmente las posibilidades sean las anteriores, debemos

empezar descartando la opción de almacenamiento de sesión por el hecho de que

no guarda la información cuando se cierra el navegador, por lo que no tendría

ningún sentido guardar información medianamente relevante esperando que un

usuario deje el navegador abierto mucho tiempo.



183


En cuanto a la opción de la base de datos, es quizás la opción más común, y

aunque sus usos son muy diversos dependiendo de la aplicación, hay que

compararla con las demás para valorar realmente cuando debe usarse, al igual que

ocurre con las cookies del navegador. Por tanto:

Local Storage vs DataBase

La diferencia principal es que una base de datos se usa si queremos que los

datos sean permanentes y estén “siempre” guardados, ya que el almacenamiento

local del navegador es temporal, aunque pueda durar bastante tiempo. En definitiva,

una base de datos debe ser usada antes que cualquier otra opción cuando

necesitamos almacenamiento permanente de datos principalmente porque los datos

son demasiado valiosos y se van a usar en futuras referencias. Aunque cabe

destacar que no usar una base de datos abaratará la aplicación web y evitará cierta

ralentización a al ahora de acceder a los datos, algo que no sucede con el

almacenamiento local o las cookies.

Por lo tanto, no se usado la base de datos porque las dos funciones que usaban

almacenamiento no necesitaban ni gran espacio de almacenamiento, ni se usan

datos que necesitase un guardado permanentemente (son datos más esporádicos).

Local Storage vs Cookies

El tamaño máximo de almacenamiento que puede ocupar una cookie es 4 kb.

Esto se debe a que suelen utilizarse para almacenar un identificador o algún nombre

únicamente, de ahí que si queremos almacenar más contenido no nos sirvan. En

cambio, el almacenamiento local en el navegador es entre 5 y 10 MB.

Otro inconveniente de las cookies es que la información de estas es enviada

siempre en cada petición al servidor, algo que normalmente no tiene utilidad. Esto no

sucede en el almacenamiento local.

Las cookies son temporales, desaparecerán cuando se cierre el navegador, lo

cual puede o no ser un problema. En nuestros casos, sí que puede llegar a ser mejor

el almacenamiento local debido que no tiene caducidad.



184


Conclusión

El almacenamiento local en el navegador permite almacenar datos con un

almacenamiento aceptable, además de ser ideal para guardar de forma indefinida

datos no sensibles que pueden ser fácilmente editados con código JavaScript.

Las cookies cuando queremos almacenar algo por un periodo finito y breve de

tiempo son bastante útiles.

Para el proyecto se han necesitado dos sistemas de almacenamiento,

preferiblemente diferentes para no mezclar diferentes tipos de datos. Por tanto, para

el prototipo de añadir modelos se han usado las cookies porque únicamente había

que almacenar el nombre de los modelos por lo que necesitábamos poco espacio de

almacenamiento, además de que podíamos poner fecha en la que expirasen los

modelos, siempre teniendo en cuenta que es un prototipo de usarlo, cargar los

modelos deseados, interactuar y verlos y cerrarlo para la siguiente vez empezad de

nuevo probablemente con otros modelos. Es decir, como su nombre indica es un

modo museo, que, siguiendo la analogía con este lugar, los modelos que cargamos

en una sesión sirven para una exposición, pero las exposiciones son cambiantes,

por lo que las cookies han sido ideales.

Por el contrario, para la herramienta de creación de animaciones se ha usado

almacenamiento local en el navegador por el hecho de que por cada animación hay

que almacenar más información de la posición del modelo, es decir, un vector con 6

posiciones.



185


ANEXO G: Impresión 3D de modelos 3D

Durante el desarrollo del proyecto, debido a la realización de las prácticas de

empresa en el grupo de informática gráfica de la universidad de Jaén, se tuvo

acceso a una impresora 3D con la que se imprimió el modelo 3D principal de “La

Cimbarra de Jaén” entorno al que se desarrolla todo este TFG.

Si nos hubiéramos descargado un modelo 3D preparado para ser impreso, sería

suficiente con abrir la aplicación usada para la impresión 3D que explicaremos a

continuación en el pipeline típico de impresión 3D de modelos. El problema es que el

modelo de “La Cimbarra” usado para este proyecto no estaba preparado para ser

impreso, tal y como se puede observar en la ilustración 0.1 del modelo abierto con

un programa de impresión 3D llamada “Cura”. Esto se debe a que el modelo es

hueco (parte de abajo del modelo 3D se observa en la ilustración 0.2), es decir, no

tendría ningún tipo de soporte sobre el cuál empezar a construir el objeto durante la

impresión y no terminaría de formarse correctamente.

Ilustración 0.1- Modelo 3D sin modificar en Cura

Ilustración 0.2- Modelo 3D por debajo



186


Para solucionar dicho inconveniente, se realizó una extrusión con la

aplicación gráfica Blender, es decir, se editó el modelo 3D de “La Cimbarra”.

La extrusión es de las herramientas más utilizadas y sencillas que se pueden

hacer con Blender, y consiste en crear paralelepípedos a partir de aristas y/o

vértices de una malla de triángulos (nuestro modelo 3D) seleccionándolos. Así, el

resultado obtenido del modelo es el mostrado en la siguiente ilustración 0.3.

Ilustración 0.3- Modelo 3D extruido en el eje –Y con Blender

Ahora, exportamos el modelo con Blender a un formato como el típico ‘obj’ y

lo abrimos con Cura (ilustración 0.4), el programa para la impresión 3D con la

impresora disponible, una Bq Prusa i3 Hephestos.

Ilustración 0.4- Modelo modificado en Cura

Tal y como se ve en la imagen 0.4 debemos de seleccionar el material del que

disponemos para imprimir, en este caso plástico PLA, así como rotarlo a nuestro

antojo y adherirlo a la base de la impresora con la opción “Lay Flat” dentro de la



187


parte de rotación en el menú de la izquierda de la interfaz o de lo contrario saldrá

mal porque se intentará hacer en el aire, que por absurdo que parezca sucede.

Además, otra opción importante que siempre debemos tener en cuenta para

ver cómo se irá formando nuestro modelo durante la impresión y observar que es la

forma adecuada, algo que se puede comprobar con la vista de las capas que va a

tener el modelo (ilustración 0.5). Esta opción es una reconstrucción que hace el

propio software para que veamos si durante el proceso de impresión va a haber

algún imprevisto que provoque imperfectos en nuestro objeto final. Si vemos en esta

pre-visualización de la impresión que alguna parte no va a salir bien, debemos tratar

de arreglarlo con el propio software Cura, o en otro caso modificando el modelo con

un software de modelado 3D como Blender.

Ilustración 0.5- Modelo modificado en Cura con opciones de impresión

Tras chequear que todo es correcto, se manda a imprimir.



188


ANEXO H: Caché en los navegadores

La caché de un navegador es una función de los navegadores más modernos

(Firefox, Safari, Chrome, …) que permite cargar páginas web más rápidamente

guardando en el ordenador parte de la información que previamente se ha solicitado.

Por ejemplo: cuando entras en una página web lo que haces realmente es

conectarte a un ordenador en algún lugar del mundo que tiene las imágenes, los

vídeos y los textos que conforman esa página web. Si esa página tiene vídeos muy

largos o imágenes de gran tamaño es probable que tengas que esperar bastantes

segundos hasta verla completa. Lo que hace la caché del navegador es guardar

parte de esos vídeos, imágenes y textos en tu ordenador de forma que si 30 minutos

más tarde vuelves a entrar en la misma web ya no tendrás que pedir a ese

ordenador lejano todos los archivos porque gran parte han quedado guardados

previamente en tu equipo y tendrás la sensación de que la página carga más rápido.

La ventaja obviamente es la velocidad de carga de las webs, y la desventaja

es que la caché puede llegar a ocupar mucho espacio de almacenamiento, de ahí

que se pueda vaciar.

Este anexo viene a que varias de las opciones de la web dependerán de la

limpieza de la caché que podamos hacer en el navegador donde ejecutamos la web.

El almacenamiento local en el navegador o la creación de cookies para guardar

posiciones (las funcionalidades de la herramienta de creación de animaciones o

añadir modelos a la web) seguirán almacenados en el navegador del ordenador del

usuario siempre que no borre la memoria caché de este.

Hay mucha más información en internet al respecto de esta característica de los

navegadores, e incluso información más específica de cada navegador. Una de las

páginas que se ha consultado ha sido esta.



189


ANEXO I: Prototipo con modelos 3D en OpenGL ES en iOS

Al comienzo del desarrollo, se realizó un prototipo de prueba en Swift con

Xcode para iOS. Esta aplicación se hizo en un principio para comprobar si llegaba a

funcionar la carga de modelos 3D en un dispositivo móvil de forma eficiente para

desarrollar sobre esa base el proyecto. El resultado no fue el esperado, ya que

consumía muchos recursos del dispositivo y era muy ineficiente y lenta la

interacción, además de que el cliente especificó que su necesidad era una web que

funcionase de forma eficiente. Por tanto, este prototipo no ha sido relevante a la hora

del prototipo final implementado.

La implementación de este prototipo se dio en la fase de búsqueda de

herramientas con las que era posible llevar a cabo el proyecto, tal y como se puede

ver en la planificación temporal del mismo.

El prototipo se ha desarrollado en Swift con el framework SceneKit cuya

información aparece muy bien explicada en la página web oficial de Apple (aquí).

SceneKit es una API de gráficos 3D de Apple basada en OpenGL, mantiene una

estructura de grafo de escena, junto a un sistema de físicas, sistema de partículas y

herramienta de creación de animaciones.

Así, en las vistas que aparecerán en el dispositivo móvil se ha añadido los

elementos necesarios para cargar un modelo 3D de los disponibles (se han añadido

a la carpeta del proyecto), junto con la creación del canvas para la escena tal y como

vemos en la ilustración 0.1.

https://developer.apple.com/documentation/scenekit?changes=_1



190


Ilustración 0.1- Storyboard vistas de la aplicación para iphone

Y en cuanto al código realizado, se crea una escena (SCNView) a la que se le

añaden nodos con los modelos que se han seleccionado desde la interfaz. Un nodo

poseerá el modelo ‘obj’ junto a su textura. Además, a la escena hay que añadirle la

cámara en una posición, la iluminación deseada, el control de la cámara, el color del

canvas, estadísticas, …

También es esencial la creación de una función que controle los eventos que

el usuario realiza de forma táctil tocando la pantalla para mover el modelo cargado.

Esto se realiza cambiando el punto de vista dependiendo de la posición de la

pantalla donde se haya detectado la pulsación.

En definitiva, el resultado es el que se puede observar en la ilustración 0.2.



191


Ilustración 0.2- Resultado app iOS



192


Bibliografía

ThreeJS, https://threejs.org , visitada el 24 de junio de 2018.

ThreeJS, https://thefiveplanets.org/blog/book01/, visitada el 24 de junio de 2018.

BabylonJS, https://www.babylonjs.com/, visitada el 24 de junio de 2018.

WebGL, https://www.khronos.org/webgl/, visitada el 24 de junio de 2018.

Webgl Programming Guide book, http://uniguld.dk/wp-

content/guld/DTU/webgrafik//0321902920_WebGL.pdf, visitada el 24 de junio de 2018.

WebGL, https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API, visitada el 24 de

junio de 2018.

Flash y Webgl, https://www.wired.com/insights/2014/05/flash-dead-long-live-webgl/,

visitada el 24 de junio de 2018.

Henry, S.L y GrossNickle, M. Accesibility in the user centered design process.

Nivel doble A accesibilidad, https://www.w3.org/WAI/WCAG1AA-Conformance.html.es,

visitada el 24 de junio de 2018.

Wikipedia, metodologías de desarrollo,

https://es.wikipedia.org/wiki/Metodolog%C3%ADa_de_desarrollo_de_software#Incremental,

visitado el 24 de junio de 2018.

Proyectos ágiles, metodología Scrum, https://proyectosagiles.org/que-es-scrum/, visitado el

24 de junio de 2018.

Gestión de proyectos informáticos: métodos, herramientas y casos. Edición: [2ª reimpr.]

Autor: Rodríguez, José Ramón. Editorial: Barcelona: Universidad Abierta de Cataluña, 2012.

El proyecto fin de carrera en ingeniería informática: una guía para el estudiante. Edición: -.

Autor: Dawson, Christian W. Editorial: Madrid: Prentice Hallducación, D.L. 2002.

Gantt Project, https://www.ganttproject.biz/, visitado el 24 de junio de 2018.

R. Pressman Software Engineering. A Practitioner’s Approach. 8th Ed. McGraw-Hill, 2014.

Análisis y diseño orientado a objetos de sistemas: usando UML. Edición: 3ª ed. Autor:

Bennett, Simon. Editorial: Madrid: Mac Graw-Hill Interamericana, 2007.

Indeed, https://www.indeed.es, visitado el 24 de junio de 2018.

WebGL, https://webglfundamentals.org/webgl/lessons/webgl-fundamentals.html, visitado el


https://threejs.org/

https://thefiveplanets.org/blog/book01/

https://www.babylonjs.com/

https://www.khronos.org/webgl/

http://uniguld.dk/wp-content/guld/DTU/webgrafik/0321902920_WebGL.pdf

http://uniguld.dk/wp-content/guld/DTU/webgrafik/0321902920_WebGL.pdf

https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API

https://www.wired.com/insights/2014/05/flash-dead-long-live-webgl/

https://www.w3.org/WAI/WCAG1AA-Conformance.html.es

https://es.wikipedia.org/wiki/Metodolog%C3%ADa_de_desarrollo_de_software#Incremental

https://proyectosagiles.org/que-es-scrum/

https://www.ganttproject.biz/

https://www.indeed.es/

https://webglfundamentals.org/webgl/lessons/webgl-fundamentals.html



193


OpenGL insights book: http://people.inf.elte.hu/plisaai/pdf/OpenGL%20Insights.pdf, visitado

el 24 de junio de 2018.

Unity, https://docs.unity3d.com/es/current/Manual/UnityManual.html, visitado el 24 de junio

de 2018.

3DHOP, http://vcg.isti.cnr.it/3dhop/, visitado el 24 de junio de 2018.

Creadores 3DHOP, http://vcg.isti.cnr.it/, visitado el 24 de junio de 2018.

SceneKit, https://developer.apple.com/documentation/scenekit?changes=_1, visitado el

SceneJS, http://scenejs.org, visitado el 24 de junio de 2018.

Sketchfab, https://sketchfab.com, visitado el 24 de junio de 2018.

Blen4Web, https://www.blend4web.com/en/, visitado el 24 de junio de 2018.

Clara.io, https://clara.io, visitado el 24 de junio de 2018.

HTML5 y CSS3: domine los estándares de las aplicaciones web. Edición: Barcelona: Eni,

2011. Autor: Lancker, Luc van.

Computer graphics with OpenGL. Edición: 4th ed. Autor: Hearn, Donald. Editorial: Boston:

Pearson, 2011.

Linkedin, diferencia entre web estática y dinámica,

https://www.linkedin.com/pulse/difference-between-static-dynamic-websites-mangesh-

bulkar, visitado el 24 de junio de 2018.

Jerry Cao, información sobre “responsive” y “adaptive” web,

https://www.uxpin.com/studio/blog/responsive-vs-adaptive-design-whats-best-choice-

designers/, visitado el 24 de junio de 2018.

Visual Paradigm, https://www.visual-paradigm.com/, visitado el 24 de junio de 2018.

Información sobre el patrón MVC: Hear First Design Patterns By Bert Bates, Kathy Sierra,

Eric Freeman, Elisabeth Robson. Editorial: O’Reilly Media.

3DHOP, https://mwf2014.museumsandtheweb.com/paper/an-advanced-solution-for-

publishing-3d-contents-on-the-web/, visitado el 24 de junio de 2018.

3DHOP (SpiderGL), http://vcg.isti.cnr.it/Publications/2010/DPGS10/spidergl.pdf, visitado el


3DHOP (Nexus), http://vcg.isti.cnr.it/nexus/, visitado el 24 de junio de 2018.

3DHOP: 3D Heritage Online Presenter. Marco Potenziani, Marco Callieri, Matteo

Dellepiane, Massimiliano Corsini, Federico Ponchio, Roberto Scopigno. Visual Computing

Lab, ISTI CNR, Pisa Italy. Article.

http://people.inf.elte.hu/plisaai/pdf/OpenGL%20Insights.pdf

https://docs.unity3d.com/es/current/Manual/UnityManual.html

http://vcg.isti.cnr.it/3dhop/

http://vcg.isti.cnr.it/

https://developer.apple.com/documentation/scenekit?changes=_1

http://scenejs.org/

https://sketchfab.com/

https://www.blend4web.com/en/

https://clara.io/

https://www.linkedin.com/pulse/difference-between-static-dynamic-websites-mangesh-bulkar

https://www.linkedin.com/pulse/difference-between-static-dynamic-websites-mangesh-bulkar

https://www.uxpin.com/studio/blog/responsive-vs-adaptive-design-whats-best-choice-designers/

https://www.uxpin.com/studio/blog/responsive-vs-adaptive-design-whats-best-choice-designers/

https://www.visual-paradigm.com/

https://mwf2014.museumsandtheweb.com/paper/an-advanced-solution-for-publishing-3d-contents-on-the-web/

https://mwf2014.museumsandtheweb.com/paper/an-advanced-solution-for-publishing-3d-contents-on-the-web/

http://vcg.isti.cnr.it/Publications/2010/DPGS10/spidergl.pdf




194


Wikipedia, información de modelos en formato ‘obj’,

https://en.wikipedia.org/wiki/Wavefront_.obj_file, visitado el 24 de junio de 2018.

W3School, javaScript, https://www.w3schools.com/jS/default.asp, visitado el 24 de junio de

2018.

“Mrwasd”, cascada en Unity, https://www.youtube.com/watch?v=XhSp8nFLUi4, visitado el


SweetAlert, https://sweetalert2.github.io/, visitado el 24 de junio de 2018.

Google Maps, https://developers.google.com/maps/documentation/javascript/?hl=es-419,


OpenWeatherMap, https://openweathermap.org/api, visitado el 24 de junio de 2018.

Jquery, https://jquery.com/, visitado el 24 de junio de 2018.

AJAX, https://www.w3schools.com/xml/ajax_intro.asp, visitado el 24 de junio de 2018.

CSS, https://www.w3schools.com/Css/, visitado el 24 de junio de 2018.

Xampp, https://www.apachefriends.org/es/index.html, visitado el 24 de junio de 2018.

Stack overflow, https://stackoverflow.com, visitado el 24 de junio de 2018.

Github Pages, https://pages.github.com, visitado el 24 de junio de 2018.

Promox, https://www.proxmox.com/en/, visitado el 24 de junio de 2018.

Proxmox, http://911-ubuntu.weebly.com/proxmox_como_funciona/conoce-como-funciona-

proxmox-y-como-usarlo, visitado el 24 de junio de 2018.

W3Schools, información de almacenamiento en navegadores,

https://www.w3schools.com/HTML/html5_webstorage.asp, visitado el 24 de junio de 2018.

W3Schools, información cookies navegador, https://www.w3schools.com/js/js_cookies.asp,


Facoff, información caché navegador, https://faqoff.es/que-es-la-cache-del-navegador/,


Más información sobre caché de navegadores: https://www.bigcommerce.com/ecommerce-

answers/what-browser-cache-and-why-it-important/, visitado el 24 de junio de 2018.

https://en.wikipedia.org/wiki/Wavefront_.obj_file

https://www.w3schools.com/jS/default.asp

https://www.youtube.com/watch?v=XhSp8nFLUi4

https://sweetalert2.github.io/

https://developers.google.com/maps/documentation/javascript/?hl=es-419

https://openweathermap.org/api

https://jquery.com/

https://www.w3schools.com/xml/ajax_intro.asp

https://www.w3schools.com/Css/

https://www.apachefriends.org/es/index.html

https://stackoverflow.com/

https://pages.github.com/

https://www.proxmox.com/en/

http://911-ubuntu.weebly.com/proxmox_como_funciona/conoce-como-funciona-proxmox-y-como-usarlo

http://911-ubuntu.weebly.com/proxmox_como_funciona/conoce-como-funciona-proxmox-y-como-usarlo

https://www.w3schools.com/HTML/html5_webstorage.asp

https://www.w3schools.com/js/js_cookies.asp

https://faqoff.es/que-es-la-cache-del-navegador/

https://www.bigcommerce.com/ecommerce-answers/what-browser-cache-and-why-it-important/

https://www.bigcommerce.com/ecommerce-answers/what-browser-cache-and-why-it-important/

S we b 3 D in te ra c tivo p a ra - ujaen.es

Documents

Transcript of S we b 3 D in te ra c tivo p a ra - ujaen.es