inquilino vr 1.0 beta
TRANSCRIPT
INQUILINOVR1.0betaElaboracióndesoftwareparalavisualizaciónarquitectónicaenRealidadVirtual
Diplomante:JavierHernándezMorel
Tutor:HaroldDiaz‐GuzmánCasañas
,junio2018
Arquitectura
EstedocumentoesPropiedadPatrimonialdelaUniversidadCentral“MartaAbreu”de
Las Villas, y se encuentra depositado en los fondos de la Biblioteca Universitaria
“ChiquiGómezLubian”subordinadaalaDireccióndeInformaciónCientíficoTécnica
delamencionadacasadealtosestudios.
Seautorizasuutilizaciónbajolalicenciasiguiente:
Atribución‐NoComercial‐CompartirIgual
Paracualquierinformacióncontactecon:
Dirección de Información Científico Técnica. Universidad Central “Marta Abreu” de
LasVillas.CarreteraaCamajuaní.Km5½.SantaClara.VillaClara.Cuba.CP.54830
Teléfonos.:+530142281503‐1419
Resumen
La tecnología de la Realidad Virtual y la estereoscopía es una alternativa novedosa de visualización 3D
que puede ser aplicada a la Arquitectura obteniendo resultados superiores con respecto a formas más
tradicionales de presentación. Aunque a nivel internacional ya se han dado pasos concretos en el
empleo de la visualización arquitectónica en Realidad Virtual, en Cuba todavía no se usa esta tecnología.
El objetivo de esta investigación es crear una herramienta para la visualización de proyectos
arquitectónicos en Realidad Virtual valiéndose de la tecnología móvil, para que sea usada por
profesionales y estudiantes de la Arquitectura en nuestro país.
Fueron analizadas las tecnologías disponibles para la generación de gráficos 3D en tiempo real y para la
visualización de estereoscopía y realidad virtual, así como una relación de las aplicaciones existentes a
nivel internacional que tienen el mismo objetivo que la presente investigación, y con ello se determinó
las características tecnológicas y de uso y el software a emplear para construir la herramienta.
La herramienta creada, llamada Inquilino VR, forma parte del proyecto de más largo alcance Inquilino
para la visualización de la Arquitectura usando la computación, y aprovecha los resultados de una
primera fase de ese proyecto, llamada “Inquilino 1.0 beta” implementada en un proyecto de tesis del
2016. Inquilino VR permite la exploración de proyectos arquitectónicos previamente elaborados en el
software 3ds Max a través de una visualización en Realidad Virtual. La misma es obtenida con el
software Unity 3d en conjunto con el SDK de Cardboard de Google, debido a lo cual la visualización se
ejecuta a través de un smarthphone con sistema Android montado en un casco o gafa tipo smartphone
display. El código de la parte de Unity 3d está completamente programado en el lenguaje C#. La
exportación del modelo desde 3ds Max a Unity 3d para la posterior generación de la aplicación para
Android se hace a través de una aplicación adicional programada en MaxScript.
El desempeño de la herramienta fue probado con el caso específico de un proyecto arquitectónico de un
estudiante de la carrera Arquitectura de la UCLV. El ensayo y análisis del mismo requirió el empleo de
técnicas de optimización del modelo 3d con el fin de facilitar el renderizado 3d en tiempo real en la
aplicación para Smartphone.
Palabras clave: Inquilino, Realidad Virtual, estereoscopía, visualización arquitectónica, Unity 3D, Google
Cardboard, Android, smartphone, apk, 3ds Max, C#, tiempo real, navegación, interactivo.
Abstract
The technology of Virtual Reality and stereoscopy is a novel alternative of 3D visualization that can be
applied to Architecture obtaining superior results with respect to more traditional forms of
presentation. Although at international level concrete steps have already been taken in the use of
architectural visualization in Virtual Reality, in Cuba this technology is still not used. The objective of this
research is to create a tool for the visualization of architectural projects in Virtual Reality using mobile
technology, to be used by professionals and students of Architecture in our country.
We analyzed the available technologies for the generation of 3D graphics in real time and for the
visualization of stereoscopy and virtual reality, as well as a list of the existing applications at
international level that have the same objective as the present investigation, and with this was
determined the technological and use characteristics and the software to be used to build the tool.
The tool created, called Tenant VR, is part of the project of more long-term Tenant for the visualization
of Architecture using computing, and takes advantage of the results of a first phase of that project,
called "Tenant 1.0 beta" implemented in a project of thesis of 2016. Tenant VR allows the exploration of
architectural projects previously prepared in the software 3ds Max through a visualization in Virtual
Reality. It is obtained with the Unity 3d software in conjunction with the Google Cardboard SDK, due to
which the visualization is executed through a smartphone with Android system mounted on a helmet or
smartphone type display. The code of the Unity 3d part is completely programmed in the C # language.
The export of the model from 3ds Max to Unity 3d for the subsequent generation of the Android
application is done through an additional application programmed in MaxScript.
The performance of the tool was tested with the specific case of an architectural project of a student of
the Architecture career of the UCLV. The trial and analysis of the same required the use of techniques of
optimization of the 3d model in order to facilitate real-time 3d rendering in the Smartphone application.
Keywords: Tenant, Virtual Reality, stereoscopy, architectural visualization, Unity 3D, Google Cardboard,
Android, smartphone, apk, 3ds Max, C #, real time, navigation, interactive.
Índice
Introducción 1
Capítulo 1. Análisis de antecedentes teóricos para el diseño
conceptual de la herramienta
9
1.1 Formas novedosas de presentar proyectos de arquitectura 1
1.2 Realidad Virtual 15
1.3 Herramientas disponibles para la presentación de proyectos de
arquitectura en realidad virtual
21
1.4 Hardware para el uso de la realidad virtual 23
1.5 Softwares disponibles para elaborar una herramienta de
visualización arquitectónica en realidad virtual
38
1.6 Optimización de los modelos 3D 42
1.7 Extensión de Inquilino 1.0 Beta 44
1.8 Análisis de los antecedentes relacionados para la
determinación de características de la herramienta
45
Capítulo 2. Características de la herramienta Inquilino VR 49
2.1 Los componentes de Inquilino VR 8
2.2 Herramienta para Unity 84
2.3 Interface de Inquilino VR 45
Capítulo 3. Uso de la herramienta Inquilino VR en un proyecto
arquitectónico real
66
3.1 Ventajas de este proyecto para la presentación en realidad
virtual
32
3.2 Características computacionales del modelo tridimensional
original
46
3.3 Optimización del modelo arquitectónico 3D 63
3.4 Uso de la herramienta Inquilino con el modelo de proyecto
optimizado
31
3.5 Resultados de Inquilino VR con el proyecto a presentar 78
Conclusiones 4
Recomendaciones 9
Bibliografía 45
1
Introducción
El desarrollo actual progresivo de las tecnologías computarizadas el mundo es cada vez
más acelerado. Muchos de los esfuerzos por innovar en el campo de la computación se
hacen en las ramas de la generación de gráficos tridimensionales y en los últimos años
han aparecido numerosas formas cada vez más novedosas de visualización de los
mismos. Dado que la Arquitectura es una disciplina que se beneficia directamente de los
logros tecnológicos de la visualización computarizada, especialmente la 3D, muchas de
estas tecnologías emergentes se están desarrollando teniendo en cuenta un posible
acoplamiento con la industria de la construcción.
Uno de los casos más interesantes es el de la realidad virtual y la visualización
estereoscópica. Estas dos tecnologías, a pesar de haber sido concebidas hace varios
años, no han podido ver un desarrollo pleno sino hasta la presente década por exigir en
el pasado una base material muy compleja y de difícil acceso para la mayoría de las
2
personas. El reciente impulso tecnológico generado por el abaratamiento de los
dispositivos de procesamiento computarizado, los cuales son cada vez más pequeños y
fáciles de producir, ha permitido la implementación y masificación de estas tecnologías
a un punto que se espera que para el próximo quinquenio las mismas sean parte del
repertorio de experiencias estándar de usuarios consumidores de tecnología
computarizadas (Greenberg, 2012).
La realidad virtual ofrece una alternativa interesante para arquitectos y clientes de
exploración de una obra aún no ejecutada para su evaluación y posible modificación. El
hecho de que la mayoría de las aplicaciones de la realidad virtual incluyan además la
estereoscopía, brinda el conveniente adicional de permitir una buena percepción de la
profundidad del espacio lo cual enriquece la experiencia. La realidad virtual es la vía más
clara y precisa de representación arquitectónica para proyectos antes de la fase de
ejecución, y ofrece varias ventajas sobre otras formas de presentación, como la de la
interactividad, la intuitividad y la posibilidad de exploración.
No obstante, existe la aparente traba en la complejidad que implica la elaboración de un
producto de realidad virtual. La idea de que la implementación de la realidad virtual es
un hecho muy fuera del alcance de la mano de una persona (o un equipo de personas)
con un conjunto de conocimientos profundos y a la vez equipamiento sofisticado, es una
idea cada vez menos cierta puesto que la tendencia de los investigadores de esa rama
es orientar el avance a la simplificación de la implementación de la misma, de modo
similar a como ha ocurrido en el pasado con muchas otras ramas de la computación
(Whyte, 2002).
Diferentes firmas y grupos creativos en el mundo están adoptando el uso de la realidad
virtual como elemento competitivo y distintivo. Sin embargo, una característica
importante de varios de los softwares que existen hasta ahora para el empleo de la
realidad virtual en la arquitectura es que son softwares personalizados de uso cerrado
para las compañías que los implementan (in-house software) y no suelen ser distribuidos
libremente a terceros usuarios mediante licencias estándar. Entonces, para la
implementación del uso de la realidad virtual y la estereoscopía en un ámbito nuevo, una
vía posible es la elaboración de un producto de software propio.
3
No se tienen noticias de que la tecnología de realidad virtual haya sido empleada todavía
en Cuba con fines de visualización arquitectónica, lo cual priva a los profesionales
cubanos el consecuente beneficio y progreso que ello puede conllevar, y los ubica en
desventaja en un mundo que ya está dando pasos contundentes en ese sentido.
Antecedentes de la investigación. El proyecto Inquilino.
En el año 2016, el Arq. Harold Díaz Guzmán Casañas, investigador del Centro de
Investigación de Métodos Computacionales y Numéricos para la Ingeniería (CIMCNI)
asociado a la facultad de construcciones, comenzó a realizar un proyecto
multidisciplinario donde se combinan las ramas de la Cibernética (más exactamente, la
programación e implementación de algoritmos) y la Arquitectura con el fin de desarrollar
un software que permita la visualización y exploración de proyectos de arquitectura en
un entorno virtual. Este proyecto tiene el nombre de Inquilino.
El proyecto general de Inquilino es un proyecto a largo plazo y tiene como objetivo futuro,
entre otros, permitir que cualquier proyecto arquitectónico que sea realizado en alguno
de los posibles softwares con los que usualmente trabajan los profesionales y
estudiantes de la arquitectura (AutoCAD, ArchiCAD, Revit, SketchUp, 3ds Max) pueda
ser importado hacia el software (también llamado Inquilino) que es producto de ese
proyecto de investigación donde el usuario tenga varias opciones de visualización, entre
ellas la navegación en primera persona para transitar la construcción proyectada, y la
observación en tercera persona para ver la misma “desde fuera” como si se tratara de
una maqueta. Se desea que el resultado a largo plazo del proyecto Inquilino sea un
software intuitivo y de fácil manejo, de una calidad excelente en visualización 3D con un
nivel de realismo elevado, y dotado de muchas herramientas que puedan dotar al
arquitecto o al cliente de operaciones de análisis como hacer cortes, evaluar iluminación
y asoleaminento, estimar niveles de ruido, evaluar diferentes alternativas de mobiliario,
materiales y color, entre otras. Como se trata de un proyecto de programación de
software de alto nivel de complejidad, el desarrollo del mismo es progresivo y se prevé
su completamiento a través de numerosas fases.
La primera fase de elaboración del proyecto Inquilino fue resultado del trabajo de diploma
de la Arq. Gabriela Leal Carrazana en el mismo año 2016, titulado “Inquilino 1.0 beta.
4
Elaboración de software para el análisis y presentación interactiva de proyectos
arquitectónicos”, que desarrolló un prototipo de ese software con funcionalidades
limitadas. Inquilino 1.0 beta podía cargar de manera semi-automática (es decir, todavía
con una significativa intervención del usuario) modelos arquitectónicos elaborados en el
software 3ds Max con cierto repertorio limitado de características (no se aceptaban
todavía todo tipo de materiales y luces, la geometría no podía ser completamente
arbitraria, algunos modificadores de 3ds Max debían ser descartados en el proceso). Los
modelos arquitectónicos entonces podían ser transitados de forma virtual,
visualizándolos en la pantalla de una PC, de manera similar a un videojuego.
Esta primera versión del software Inquilino solamente era ejecutable en Windows.
Aunque la cantidad de características implementadas fue una fracción muy pequeña de
lo planificado para el proyecto general Inquilino a largo plazo, se estableció un soporte
inicial de visualización 3D y renderizado en tiempo real de alta calidad que debe ser
reusado y extendido en las subsiguientes entregas de nuevas versiones del software. De
esta forma, ya existe una plataforma de visualización 3D en tiempo real propia
(perteneciente a la Facultad de Construcciones, Universidad Central de Las Villas) la cual
puede servir como punto de partida para la elaboración aplicaciones con características
adicionales que también formarán parte de complejo de herramientas que se quiere que
el proyecto Inquilino tenga en el futuro. Una de estas características adicionales,
enunciada desde el mismo comienzo del proyecto general Inquilino, es la implementación
de la visualización en realidad virtual con estereoscopía.
Problema científico
En Cuba no se utiliza actualmente la tecnología de Realidad Virtual en tiempo real para
la presentación conceptual de proyectos y obras de arquitectura.
Objeto
Desarrollo de software
Campo de acción
5
Software de visualización arquitectónica en Realidad Virtual
Usuario destino
Profesionales y estudiantes de la arquitectura cubanos
Objetivo general
Crear una herramienta para la presentación conceptual de un proyecto de arquitectura
que aplique la tecnología de Realidad Virtual para la visualización y exploración del
mismo, teniendo en cuenta las características, necesidades y limitaciones de arquitectos
y estudiantes de arquitectura cubanos.
Objetivos específicos
1. Analizar las tecnologías existentes que estén relacionadas con la elaboración de
herramientas de visualización en Realidad Virtual.
2. Determinar las características de una aplicación para la visualización de proyectos
de arquitectura mediante el uso de la Realidad Virtual con vistas a ser empleada
por profesionales de nuestro país.
3. Definir los algoritmos necesarios para la implementación de una aplicación de
visualización de proyectos arquitectónicos mediante el uso de la Realidad Virtual.
4. Escribir el código de la programación del funcionamiento de los componentes
necesarios para el funcionamiento de la aplicación.
5. Probar el funcionamiento de la aplicación mediante su uso con un proyecto
arquitectónico objetivo elaborado por un arquitecto o estudiante cubano.
Hipótesis
Si se utiliza como punto de partida la tecnología implementada por el proyecto Inquilino
1.0 beta en combinación con las nuevas prestaciones que para la generación de gráficos
tridimensionales y estereoscopía existen en los soportes de programación para móviles,
6
se puede crear una herramienta de Realidad Virtual para la visualización de proyectos
Arquitectónicos que sea utilizada por estudiantes y profesionales cubanos.
Novedad científica
Se creará una herramienta que permitirá introducir en Cuba el uso de la tecnología de
Realidad Virtual para la visualización y análisis de proyectos de arquitectura.
Aportes Prácticos
Brindará la posibilidad de introducir en Cuba el uso de las tecnologías más novedosas
en el campo de la presentación de proyectos de arquitectura.
Se creará una herramienta cubana, de distribución gratuita, que utilice las tecnologías de
Realidad Virtual y Estereoscopía para la presentación de proyectos de arquitectura.
La herramienta brindará la posibilidad de mejorar la calidad de las presentaciones de
proyectos de arquitectura en Cuba y colocarlas a un nivel más competente en el ámbito
internacional.
La herramienta extenderá las posibilidades de estudio del espacio arquitectónico
simulado, permitiendo que con bajos recursos se tenga una experiencia muy interactiva,
con percepción real del espacio y por ende percepción real de la arquitectura en un
entorno completamente generado por ordenador.
Estructura de la Tesis
Introducción
7
Capítulo 1: “Análisis de antecedentes teóricos para el diseño conceptual de la
herramienta”
Se relacionan las tecnologías fundamentales disponibles para la visualización
computarizada 3d en tiempo real, tanto a nivel de software como a nivel de
hardware, así como algunas de las aplicaciones ya hechas a nivel internacional.
De cada uno de esos aspectos se describen las características fundamentales y
procedimientos asociados. Toda esta información es empleada para determinar
varias de las características esenciales que como punto de partida debe tener la
herramienta que se desea construir, el Inquilino VR, en lo relacionado
fundamentalmente con selección de tecnologías a emplear y características
técnicas a implementar.
Capítulo 2: “Características de la herramienta Inquilino VR”
Se describe la herramienta creada, el Inquilino VR, desde el punto de vista de
funcionamiento interno y los elementos tecnológicos que la integran, y se escriben
los procedimientos computacionales que son implementados para la obtención del
producto de software.
Capítulo 3: “Uso de la herramienta Inquilino VR en un proyecto arquitectónico real”
Se emplea un proyecto real de un estudiante de la Facultad de Construcciones de
la UCLV para probar el uso de la herramienta Inquilino VR para la visualización y
exploración del mismo usando Realidad Virtual. Se observan las características
de la ejecución del software para ese caso en concreto y se determinan acciones
de optimización específicas del modelo que contribuyen al mejoramiento del
desempeño de la herramienta.
8
Gráfico Metodológico
9
Capítulo 1 Análisis de antecedentes teóricos
para el diseño conceptual de la herramienta
1.1 Formas novedosas de presentar proyectos de arquitectura
1.1.1 La Realidad Virtual
Facultades de arquitectura y escuelas de diseño están introduciendo en los últimos años
sistemas de realidad virtual para mejorar la formación de sus estudiantes, esto es, los
profesionales del futuro. Sin embargo, los arquitectos no se detienen en ese punto y está
apostando por aplicar esta innovación en la relación con sus clientes. De modo que los
más avanzados trabajan con el siguiente concepto: en lugar de mostrar cómo se
10
materializará un proyecto mediante la representación en papel o en una pantalla, lo ideal
es que sus destinatarios lo vean y lo experimenten en primera persona (Micó, 2017).
Mediante la visualización de proyectos arquitectónicos usando la realidad virtual y
tecnologías afines, el servicio que se le presta al usuario que observa el proyecto, sea
profesional de la construcción o cliente, es mucho más completo, y ello constituye a la
vez una excelente herramienta de marketing. Los diseñadores y arquitectos van mucho
más allá de los planos tradicionales (en dos dimensiones), las representaciones digitales
en perspectiva o los modelos físicos.
Quien experimenta en primera persona un proyecto arquitectónico simulado mediante la
realidad virtual, comprende mejor su escala, tamaño, alcance y entorno al estar el
participante inmerso en los espacios. Debido a esto se puede, además, optimizar el
proceso de interacción con el cliente: las preguntas de aquellos son más precisas, y las
respuestas de los fabricantes o arquitectos son más inteligentes y fundadas. Este
procedimiento requiere una inversión inicial notable debido al costo adicional que tiene
la adquisición de tecnología para la implementación de la realidad virtual sobre el costo
que representa el uso de medios de representación más tradicionales, pero, como
señalan los analistas, permite ahorros considerables en otros aspectos como la
comprensión, la rectificación de errores y la solución de estos.
Por ejemplo, el personal de la Thomas Jefferson High School y del distrito escolar
unificado de Los Ángeles (Estados Unidos) ya se ha beneficiado de este cambio. Ha
podido explorar virtualmente el proyecto de rediseño de su campus, resultado de un
ambicioso proyecto que ha requerido la demolición de más de 50 estructuras. La
modernización integral de esta infraestructura y la eliminación de barreras de acceso.
Los responsables del centro han podido caminar por un área que, físicamente, aún no
existe. Esta experiencia les ha permitido recomendar modificaciones en el edificio de
administración y en un patio. El estudio que se está encargando de la remodelación,
HMC, se vale de estas aportaciones para definir elementos interiores (la iluminación, los
acabados, el mobiliario, etc.) y para conectar espacios diversas, tanto históricas como
de nueva creación.
Micó (2017) en su artículo dice: “Los clientes se sienten más seguros y tranquilos porque
prácticamente pueden tocar las paredes, o, al menos, esa es la sensación que
11
tienen…con facilidad, pueden mover sillas, mesas, armarios o instrumental de un
laboratorio y comprobar el efecto que se consigue… si no les gustan las
transformaciones, las deshacen.”
Por otra parte, las condiciones tecnológicas del lugar en el que están los consumidores
cuando se quiere llevar a cabo una demostración de realidad virtual está dejando de
suponer un gran problema en el presente. Hace algunos años el equipamiento necesario
era costoso y pesado y exigía estar implementado en un local con condiciones
especiales. En la actualidad es cada vez más posible que lo único que se necesite sea
contar con el dispositivo de visualización adecuado, para lo cual existen alternativas muy
al alcance del usuario promedio. Por ejemplo, se están logrando avances significativos
con soluciones tan simples y económicas como la Cardboard de Google y un
Smartphone. (Micó, 2017)
Google Cardboard es una plataforma de realidad virtual desarrollada por Google sobre
la base de cartón plegable, de allí su nombre, que funciona a partir de montar un teléfono
móvil inteligente con Android en ellas.
La premisa de Google Cardboard es la de transformar un smartphone cualquiera con
Android en una plataforma de realidad virtual por menos de $5 gracias a los materiales
utilizados.
Muchos medios están volcando sus trabajos en la realidad virtual hacia la visualización
con gafas de Google, porque saben que llegarán al público promedio que no puede
alcanzar a pagar los cascos de HTC ni los de Oculus. Esto ha generado la aparición de
gran contenido, sobre todo de corte audiovisual en grandes sitios como son Youtube o
Vimeo y la creación de aplicaciones sencillas de visualización ya sea de lugares
históricos, paisajes naturales, o arquitectura, usando el potencial de las imágenes
panorámicas, pero limitándose a tener contenido estereoscópico porque ambos no son
compatibles, o por lo menos de momento. A continuación, algunos ejemplos de
contenidos generados para el uso de smarthphones y gafas Cardboard en realidad
virtual:
Aplicación de Cardboard para Android.
Canales de Videos con contenido 360º.
Sites in VR (aplicación móvil con tours 360º de lugares arquitectónicos famosos).
12
1.1.2 La Estereoscopia
La visión estereoscópica directa es una facultad física que posee el ser humano y varios
animales, que les permite ver en tercera dimensión aquellos objetos que contempla
mediante su visión binocular.
Sobre cada una de las dos retinas del observador se forma una imagen perspectiva del
mismo objeto observado. Cada una de estas dos imágenes simultáneas difieren
ligeramente entre sí, debido a la distinta posición de ambos ojos. El cerebro usa la
diferencia de estas dos imágenes (la cual consiste fundamentalmente en variaciones de
la colocación horizontal de los objetos proyectados), para hacer un estimado de la
profundidad a la que se encuentra cada objeto dentro del campo visual.
Una sola imagen fotográfica no puede suministrar la impresión de relieve o profundidad,
porque todos aquellos puntos que la constituyen se encuentran proyectados sobre el
mismo plano. Al tratarse de una imagen única, el cerebro no es capaz de confirmar la
profundidad de los objetos al no poder comprobar el desplazamiento relativo de la
proyección de los mismos en un par de imágenes simultáneas, puesto que la magnitud
de ese desplazamiento (llamado usualmente disparidad) depende geométricamente de
la distancia del observador al objeto. Por esa razón, se puede trucar la aparente
profundidad de un objeto en la fotografía y el cine tradicional mediante la sola alteración
del tamaño de los objetos. Por ejemplo, antes la aparición de la estereoscopía, era
factible usar maquetas detalladas de edificaciones que, estando en realidad fotografiadas
o filmadas no muy de lejos, podían simular edificios grandes ubicados a una gran
distancia. Sin embargo, no se puede engañar con un truco así a un espectador que esté
mirando la escena en vivo con ambos ojos porque la estereoscopía le revela la distancia
real que hay hacia el objeto observado.
Para obtener un efecto de profundidad en la imagen se deben cumplir ciertas condiciones
que corresponden a las de la visión binocular natural:
Cada ojo debe observar una imagen desde el punto de vista o centro de
proyección distinto al de la imagen observada por el otro.
Las imágenes deben presentarse a los ojos de tal manera que los pares de rayos
correspondientes a puntos homólogos de las dos vistas, se corten.
13
La necesaria convergencia de los rayos luminosos no debe exceder el límite de la
convergencia natural de los ojos, que es de aproximadamente 20°.
La visión estereoscópica directa del ser humano puede ser remplazada en forma artificial
con el empleo de medios ópticos auxiliares, de forma tal que en lugar de ser los objetos
los que se presentan a la vista, sean sus imágenes las que lo hacen. Esto significa que
cualquier medio o dispositivo que se emplee para proyectar hacia cada ojo por separado
una imagen distinta, de forma tal que la diferencia entre esas imágenes consista en la
observación del mismo objeto o entorno desde dos puntos de vista ligeramente
desplazados horizontalmente uno con respecto al otro, logra generar en el cerebro la
sensación correcta de una observación estereoscópica genuina. (Anon., n.d.)
A la obtención del efecto de estereoscopía mediante medios que obliguen la proyección
artificial de imágenes distintas en cada ojo se le denomina visión estereoscópica
indirecta. En casos como el presente estudio, la misma permite observar dos imágenes
generadas computacionalmente y percibir la profundidad del espacio y de los elementos
arquitectónicos deseados. Con esta forma de observar el resultado propuesto para una
obra de arquitectura es posible entender con mayor claridad y eficiencia cómo se
distribuye el espacio diseñado y experimentarlo de una manera más parecida a como
sería experimentado por cualquier persona si se tratara de una obra ya ejecutada.
1.1.3 Los Tour 360
El uso de esta tecnología para presentar proyectos de arquitectura, está estrechamente
vinculado con el avance tecnológico que se ha experimentado en los últimos años de
esta década en esferas como la fotografía y los gráficos computarizados, para capturar
imágenes en 360º de la vida real con cámaras especializadas, o para generar estas
imágenes por ordenador (renders panorámicos).
Las imágenes 360 o también imágenes panorámicas, son imágenes que representan un
entorno, sea real o virtual, como si fuera visto a través de una cámara cuya amplitud de
campo visual es de 360 grados de modo tal que no se deja de registrar en la imagen
ningún fragmento del entorno. Estas imágenes, para ser correctamente observadas,
deben ser proyectadas en una esfera virtual, en el centro de la cual se ubica el
observador. Dado que el campo de visión práctico de un humano no excede, en el mejor
14
de los casos, los 120 grados, las imágenes panorámicas son observadas mediante
dispositivos o softwares que solo permiten la observación de una fracción de ella en un
instante de tiempo dado, y que permite cambiar la orientación de la dirección del
observador para que pueda registrar otras partes de la imagen cuando lo desee,
mediante la aparente rotación del punto de vista.
Un tour virtual es una serie de panorámicas 360° conectadas y entrelazadas en una
misma interface que permite pasar de una panorámica a otra por medio de señales,
botones virtuales (es decir, que se muestran en el espacio virtual), iconos, mapas,
menús, etc.
Para la interacción con la imagen 360, la cual consiste en la posibilidad que se da al
observador de cambiar de punto de vista mediante la rotación de una cámara virtual, el
usuario tiene el control mediante el teclado o el ratón, o a través del contacto con la
pantalla de un dispositivo móvil. En caso de que el emplee un smartphone que cuente
con el sensor giroscopio, se puede combinar con un casco de realidad virtual y este
detectará el movimiento del dispositivo asociándolo al movimiento de la cabeza, de forma
tal que la misma orientación de la cabeza del usuario define la orientación del punto de
vista de observación de la imagen panorámica.
1.1.4 La Realidad Aumentada
La realidad aumentada es la observación (fundamentalmente visual, aunque también
puede ser auditiva y de otros sentidos) de un entorno del mundo real a través de algún
dispositivo que agregue o modifique características de lo observado. Los casos más
comunes consisten en que a la imagen del entorno capturada por la cámara del
dispositivo se le agregue objetos que no existen para formar en tiempo real una imagen
que sea una mezcla de la realidad con gráficos sintetizados por computadora.
A la acción de agregar elementos inexistentes al gráfico del mundo real se le llama
comúnmente “aumentar” la realidad. Es un concepto cuya posibilidad teórica se maneja
desde hace muchos años por los científicos de la computación visual. En 1992, Tom
Caudell acuñó el término.
En 1997 Ronald Azuma define la realidad aumentada como un sistema que:
15
Combina elementos reales y virtuales.
Es interactiva en tiempo real.
Está registrada en 3D.
Las características definidas por Azuma para la realidad aumentada son implementadas
por algoritmos computacionales complejos que permiten determinar la tridimensionalidad
del espacio filmado a través de técnicas de reconocimiento de patrones, y posteriormente
la aplicación de técnicas convencionales de generación de gráficos 3D para añadirlos a
la imagen filmada usando parámetros de ubicación en el espacio provistos por los
mencionados algoritmos.
1.2 Realidad Virtual
1.2.1 Conceptos
El termino realidad virtual (término que frecuentemente aparece en la bibliografía como
VR por sus siglas en inglés: Virtual Reality) es acuñado por Ivan Sutherland, el pionero
de los gráficos por computador, en 1965, cuando afirma que: “La pantalla es una ventana
a través de la cual uno ve un mundo virtual. El desafío es hacer que ese mundo se vea
real, actúe real, suene real, se sienta real” (Correa, 2017).
La realidad virtual es un entorno de escenas u objetos de apariencia real, generado
mediante tecnología informática, que crea en el usuario la sensación de estar inmerso
en él. Dicho entorno es contemplado por el usuario a través normalmente de un
dispositivo conocido como gafas o casco de realidad virtual. Este puede ir acompañado
de otros dispositivos, como guantes o trajes especiales, que permiten una mayor
interacción con el entorno, así como la percepción de diferentes estímulos que
intensifican la sensación de realidad (White, 2002).
La realidad virtual es un sistema computacional usado para generar un mundo artificial
en el cual el usuario tiene la impresión de ser parte del espacio que le rodea, teniendo la
habilidad de navegar a través de este y manipular objetos virtuales dentro del mundo
generado (Anon., 1995)
16
1.2.2 Historia de la Realidad Virtual
El primer exponente del casco de realidad virtual actual es el Estereoscopio de Charles
Wheatstone inventado en 1840. Un dispositivo rudimentario que tenía un visor y dos
imágenes ligeramente desfasadas. Al mirar a través del visor, se captaba cada imagen
con el ojo correspondiente y el cerebro las interpretaba de manera tridimensional
(Correa, 2017).
El primer dispositivo de realidad virtual fue el Sensorama, una máquina ideada en
1956 y construida en 1962 por Morton Heilig. Se introducía la cabeza en la
máquina para aislarse del exterior y mostraba imágenes estereoscópicas,
reproducía sonido estéreo, simulaba el movimiento con vibraciones en su silla,
generaba viento con ventiladores y tenía difusores de olores (Rheingold, 1992).
En 1960, el propio Morton Heilig, patentó el “Telesphere Mask”, con un diseño
similar a las gafas de realidad virtual de la actualidad, del tipo Head Mounted
Display, que ofrecía imágenes estereoscópicas y audio estéreo (Mortonheilig,
n.d.).
En 1961, se desarrolló en Philco Corporation un dispositivo Head Mounted Display
que incluía detector de movimiento de la cabeza para guiar una cámara. Estaba
conectada al visor mediante circuito cerrado. Entre sus usos estuvieron las
simulaciones de vuelo en oscuridad total (Ortega, 2016).
En 1965 Ivan Sutherland escribió “The Ultimate Display”. Artículo que recogía las
bases para una simulación óptima en realidad virtual y los distintos dispositivos de
entrada que servían para interactuar con esta tecnología. Este documento sirvió
de premisa a futuros diseñadores (Worrydream, n.d.).
En 1968 Iván Sutherland junto a su equipo del MIT (Massachusetts Institute of
Technology), construyó “La Espada de Damocles”, un dispositivo muy pesado,
que se sujetaba al techo, del tipo Head Mounted Display y que mostraba gráficos
sencillos generados por ordenador (Álvares, 2011).
En 1975 el científico y artista Myron Krueger desarrolló “Videoplace”, un entorno
que permitía al usuario interactuar con imágenes proyectadas, capturando con
una cámara los movimientos que realizaba y procesándolos para modificar dicha
17
imagen. Este medio es el precursor de sistemas de reconocimiento de movimiento
a través de cámaras en dispositivos como los Kinect de Microsoft y los mandos
de HTC VIVE (Kruger, 1991).
En 1978 un equipo del MIT desarrolla “Aspen Movie Map”. Un sistema que
permitía visitar la ciudad de Aspen, en Colorado usando tres pantallas y un mando
para moverse por la ciudad. Era muy parecido al Google Street View actual.
Incluía características como información de los edificios mostrados, posición
actual dentro de la ciudad en un mapa 2D o la posibilidad de ver las fotos de la
misma posición en distintas estaciones del año. Se usó militarmente para
familiarizar a los soldados con un entorno real sin necesidad de estar físicamente
en él (Lippman, n.d.).
En 1984, Jaron Lanier funda “VPL Research”, una de las primeras en vender
productos de realidad virtual y responsable del “Data Globe”, un guante con
sensor de movimientos que un ordenador procesaba, fue usado en cirugías
remotas. La compañía quebró en 1990 y sus patentes compradas por “Sun
Microsystems” (Khan, 2011).
En 1990 la compañía “Virtuality Group” lanza una serie de máquinas arcade para
jugar con procesado del juego en tiempo real usando un visor y un joystick.
Permitía el modo multijugador a través de otras máquinas conectadas (Fowle,
2015).
En 1991 Antonio Medina diseña el sistema de realidad virtual para controlar
remotamente un robot que se movía sobre la superficie de Marte. Debido a la
distancia entre planetas tenía latencia la orden dada y la acción ejecutada por el
robot (López, 2012).
En 1994 la compañía SEGA lanza al mercado el “SEGA VR-1”, un dispositivo
Head Mounted Display para máquinas. Contaba con detector de movimiento de la
cabeza, sonido estéreo e imágenes estereoscópicas. Tenía un nivel gráfico muy
bueno para la época (Anon., 2016).
18
En 1995, la compañía Nintendo produce el “Virtual Boy”. Una consola con
videojuegos estereoscópicos y gráficos monocromáticos. Contaba con 22 juegos
y un precio de $180. Este proyecto fracasó (Nagata, 2009).
En 2010 la compañía Microsoft lanza “Kinect”, un dispositivo para la consola Xbox
360 que permitía reconocer gestos, comandos de voz, imágenes y objetos. Fue el
competidor del Wii Motion Plus de Nintendo y del Play Station Move, de Sony.
En 2012 la compañía Oculus lanza una campaña de financiación en Kickstarter
para desarrollar unas gafas de realidad virtual muy potentes, las Oculus Rift.
Recaudan 2,5 millones de dólares y realizan la primera versión.
En 2014 Facebook compra Oculus por 1450 millones de dólares y en 2016 salen
a la venta por un precio inicial de $600.
En 2015 Google saca a la venta las gafas de realidad virtual “Google Cardboard”
por un precio de $5. Una plantilla de cartón con dos lentes de aumento se plegaba
para integrar un Smartphone y visualizar e interactuar con contenido en realidad
virtual.
En 2016 Sony saca a la venta las gafas de realidad virtual “Play Station VR” a un
precio de $399. Estas gafas se integran únicamente con la consola Play Station
4.
En 2016 salen a la venta las gafas de la compañía taiwanesa HTC, las HTC Vive
por un precio promedio de $700.
En 2017 Google presenta sus aplicaciones de realidad virtual para Android:
Google VR y sus nuevas gafas “Google Daydream” con mejor acabado que el
cartón y un jostick con varios sensores para interactuar con las aplicaciones; por
un precio de $80 (Robertson & Miller, 2017).
La aplicación de la realidad virtual, aunque centrada inicialmente en el terreno del
entretenimiento y de los videojuegos, se ha extendido a otros muchos campos, como la
medicina, la arqueología, la creación artística, el entrenamiento militar y las simulaciones
de vuelo
19
La realidad virtual puede ser de dos tipos: inmersiva y no inmersiva. Los métodos
inmersivos de realidad virtual con frecuencia se ligan a un ambiente tridimensional
creado por un ordenador, el cual se manipula a través de cascos, guantes u otros
dispositivos que capturan la posición y rotación de diferentes partes del cuerpo humano.
La realidad virtual no inmersiva también utiliza el ordenador y se vale de medios como
Internet, en el cual podemos interactuar en tiempo real con diferentes personas en
espacios y ambientes que en realidad no existen sin la necesidad de dispositivos
adicionales al ordenador.
La realidad virtual no inmersiva ofrece la percepción del entorno virtual a través de una
ventana de escritorio. Este enfoque no inmersivo tiene ventajas sobre el enfoque
inmersivo: el bajo coste y fácil y rápida aceptación de los usuarios. Los dispositivos
inmersivos son de alto costo y generalmente el usuario prefiere manipular el ambiente
virtual por medio de dispositivos familiares como son el teclado y el ratón que por medio
de cascos (a veces pesados) o guantes (Selzer & Arriata, n.d.).
1.2.4 Consecuencias Físicas de la Realidad Virtual
Algunos usuarios experimentan mareos cuando utilizan la realidad virtual. Este mareo,
en inglés motion sickness, es también conocido por su nombre técnico: cinetosis.
El malestar estomacal que se puede sentir en una sesión de realidad virtual es muy
similar a la cinetosis. La razón de este malestar es que el oído interno envía información
falsa al cerebro.
Los humanos tienen en el cuerpo sensores naturales (la piel, los músculos, etc.), siendo
el sistema vestibular del oído el sensor asociado a la sensación del movimiento y el
equilibrio. La información obtenida por estos sensores se envía al sistema nervioso. El
mareo en presencia de la realidad virtual es producto de que los sentidos proporcionan
información contradictoria porque el sensor visual (es decir, los ojos) indican que nos
movemos, pero el sensor de movimiento/equilibrio no confirma esa impresión.
La contradicción entre las informaciones enviadas al cerebro por los diferentes sentidos
es asumida por el cerebro como un posible malfuncionamiento de los mismos. Dado que
tales malfuncionamientos, cuando son genuinos, están asociados a la posible presencia
20
de neuro-toxinas en el organismo, la respuesta del mismo puede llegar a alcanzar, en
casos extremos, el desencadenamiento de vómito.
Para evitar los efectos adversos de la realidad virtual la solución óptima es enviar la
misma información a todos los sensores, que es teóricamente posible con la ayuda de
unas máquinas especiales. Samsung está trabajando en la actualidad en un casco,
llamado Entrim 4D, un casco VR “completo” que tiene como objetivo tanto estimular el
sistema vestibular (es decir, el oído interno) con el fin de dar la sensación de movimiento
mediante el sentido del equilibrio de modo que sea coherente con el movimiento
representado en la pantalla (Pepicq, 2017).
En la práctica, la coordinación entre los estímulos visuales y los estímulos del oído interno
(que incluyen la sensación de equilibrio y movimiento a nivel físico-mecánico) es todavía
muy difícilmente implementable. Por esta razón se han recurrido a otras diversas
soluciones para el problema del malestar producido por la experiencia de VR, como el
uso de medicamentos que combaten las náuseas, y el control de las condiciones
ambientales y temporales en las que la interacción con la realidad virtual tiene efecto,
pero que no serán exploradas en el presente informe porque no son relevantes para este
estudio.
El otro factor que puede aminorar los efectos adversos y las náuseas de la interacción
con la realidad virtual es cumpliendo un conjunto de precauciones que tienen que ver
específicamente con la estereoscopía, la cual es un elemento presente en la mayoría de
las aplicaciones de realidad virtual inmersiva. Existe un grupo de principios que es
recomendable cumplir para que la estereoscopía artificial sea consumida por el humano
sin generar incomodidad, entre los cuales se encuentran el empleo de un framerate
elevado (recomendado 60 fps), que no haya violaciones ni experimientaciones con la
perspectiva correcta, y que no existan objetos que estén ubicados virtualmente
demasiado cerca del observador que a la vez tengan una parte fuera del campo visual
(Tydings 2012)
21
1.3.4 Realidad Virtual y Arquitectura
Según Martín (2016), “…el año 2016 fue el año de la realidad virtual [para la arquitectura].
La tecnología dejó atrás el estado beta, y sus usos son implementados en diferentes
áreas, de manera más accesible a casi cualquier cliente o usuario”.
Diferentes firmas de arquitectos en Estados Unidos han manifestado que la realidad
virtual ha marcado una gran diferencia en la comunicación arquitecto – cliente, lo que
posiciona a estas empresas por delante de sus competidores que no han dado pasos en
el uso de esa tecnología.
Profesionales y clientes se benefician de poder ver los espacios y el mobiliario de las
edificaciones durante su proceso de diseño, y poder hacer las modificaciones necesarias
antes de empezar la ejecución el proyecto (Sanz, 2015).
La realidad virtual en la arquitectura permite tomar decisiones reales tanto para clientes
como a los diseñadores al tener acceso a información que antes era muy difícil dominar,
datos que en el pasado solo se podían constatar con el resultado final construido, o con
muchísimos años de experiencia en el sector (Cruz, 2017).
A pesar de que la implementación de la visualización arquitectónica mediante la realidad
virtual significa una inversión inicial en cada proyecto un poco por encima de lo normal
tanto en términos económicos como en esfuerzo humano profesional, se considera que
su empleo es factible puesto que permite una más certera percepción de las posibles
modificaciones de un proyecto en momentos previos a su ejecución, lo cual puede
abaratar todo el proyecto. Sin herramientas como estas, una vez la obra está terminada,
una posible modificación puede ser muy costosa (Anon., 2016).
1.3 Herramientas disponibles para la presentación de proyectos de arquitectura
en realidad virtual
El Mercado de software enfocado a la Realidad Virtual en manos del usuario promedio o
común es relativamente joven. El mayor acceso a la tecnología de Realidad Virtual
debido a la reducción de los costos de esta y por la simplificación de su uso, ha permitido
que comiencen a surgir aplicaciones para distintos sectores de la sociedad entre ellos la
arquitectura:
22
1.3.2 Iris VR
Datos de Archdaily (2016) reportan que la compañía IrisVR, especializada en generar
contenido arquitectónico para realidad virtual ha desarrollado y lanzado Iris Prospect, un
programa que permite enviar modelos directamente a la realidad virtual con cierta
facilidad. Una versión beta del software está actualmente disponible para su descarga
desde su sitio web, haciendo a la realidad virtual accesible a casi cualquier persona con
conocimientos en técnicas de modelado 3d. El software es compatible con los archivos
de Revit, Sketchup y la extensión .obj. Además de que la experiencia VR soporta varios
dispositivos como Oculus Rift, HTC Vive. Iris Prospect permitirá alternar entre capas y
opciones de diseño, cambiar las condiciones atmosféricas y hacer anotaciones. El
modelo se puede controlar a través del mouse, el teclado o un controlador de juego.
IrisVR también ofrece Iris Scope, una aplicación móvil, que convierte espacios del
modelo visualizado con Iris Prospect en imágenes panorámicas listas para Smartphone.
Es un software de pago que con servicios por internet. Aún se desconoce su costo en el
año 2017 por estar en una fase beta de su desarrollo.
1.3.3 Autodesk LIVE
El Autodesk LIVE, es un software de la famila Autodesk. Permite una visualización
interactiva de los proyectos hechos en Autodesk Revit, y aprovecha las ventajas del
sistema BIM para mejorar la interacción y recibir información de cada elemento del
modelo.
Según la web oficial del software: “Puedes entrar dentro de tu diseño. Con un solo clic,
el servicio Autodesk® LIVE transforma los modelos de Revit en visualizaciones
interactivas que puedes presentar o compartir con otros para que exploren por su
cuenta”.
Autodesk Live exporta el modelo a la nube a través de internet, hace varias operaciones
para optimizarlo, configura opciones de visualización según el resultado deseado y en
poco tiempo devuelve una versión para ser ejecutada en el ordenador con Oculus o HTC
VIVE.
23
Las herramientas de edición de Autodesk LIVE posibilitan una experiencia interactiva
configurable. Permite definir puntos de navegación, ajustar la iluminación según la
ubicación geográfica y elegir diferentes estilos de representación arquitectónica.
Es un software de pago que funciona conectado a internet usando el servicio de la nube.
Es exclusivo para proyectos en Revit y funciona solo con equipamiento para realidad
virtual con altas prestaciones técnicas.
1.4 Hardware para el uso de la realidad virtual
Existen pocos dispositivos de realidad virtual que funcionen de forma autónoma. Para el
resto de los dispositivos, que son la mayoría, es necesario disponer de otro dispositivo
que conectado a las gafas de realidad virtual permitan el uso de las mismas. En el
mercado hay gafas de realidad virtual que funcionan conectadas a diferentes hardware.
Por una parte existen gafas VR que funcionan conectadas a un ordenador (Oculus Rift y
HTC VIVE). Estas utilizan todo el potencial que tiene el PC o Mac al cuál están
conectados.
Por otro lado, existen gafas de realidad virtual que funcionan conectándolas a un
Smartphone (Samsung Gear VR y Google Cardboard, entre otros), utilizando no solo al
teléfono como una CPU, sino que también aprovechan la pantalla de éste, que gracias a
unas lentes bifocales en las gafas producirá el efecto de visión estereoscópica.
También existen gafas destinadas al uso lúdico y optimizadas para videojuegos, en este
caso las gafas se conectan a una consola (PlayStation VR, Nintendo NX, entre otras) y
se sirven de la CPU de ésta para su funcionamiento.
1.4.1 Ejecución
La ejecución del software de realidad virtual es llevada a cabo por un dispositivo con
capacidad de cómputo, por ejemplo un ordenador, un Smartphone, una consola de
videojuegos, etc. La potencia de este equipo, y por ende el rendimiento de la aplicación
de realidad virtual está determinado por sus características, ya sea en cuanto al
procesamiento gráfico o GPU, al procesamiento central o CPU, o a la memoria RAM.
24
1.4.1.1 Ordenador
La herramienta esencial para llevar a cabo proyectos de realidad virtual es un ordenador.
El mismo se emplea, no sólo como soporte para los softwares de visualización en
realidad virtual más potentes, sino que también es el instrumento principal para generar
los entornos virtuales y todo lo necesario para que estos funcionen correctamente, ya
sea crear el modelo tridimensional, generar materiales o shaders necesarios, optimizar
geometría o remapear texturas, así como programar y desarrollar todos los elementos
gráficos.
Trabajar con realidad virtual requiere mucha potencia de cálculo, tanto del procesador
en sí (CPU) como de la tarjeta gráfica, usualmente la configuración más apropiada
coincide con la recomendada para ejecutar los videojuegos de mayor calidad, que
también son exigentes en términos de memoria, cómputo y representación de modelos
tridimensionales. A los ordenadores configurados desde el punto de vista de hardware
para ser usados con videojuegos se les llama gaming PCs. Los diseñadores, arquitectos
e ingenieros suelen emplear equipos similares.
De acuerdo a los dispositivos complementarios que se requieren para la realidad virtual
(gafas, detectores gestuales, etc.) y a las características de los softwares que deben ser
ejecutados para ello, la configuración apropiada es:
CPU: I7-6700K o similar (a 3.1 GHz o superior)
GPU: Compatibles con DX11
NVIDIA GeForce™ GTX 1060 o la AMD Radeon™ RX 480,
Almacenamiento: 256 - 512GB SSD
Almacenamiento
adicional: 1 - 2 TB HDD
RAM: mínimo 16 GB, recomendable 32GB
25
Otros:
Varios puertos USB (3.0 y 3.1 en función de dispositivos, como
podrían ser las MS Kinect)
Puerto de video: HDMI 1.4 2880×1440 @ 60 Hz o HDMI 2.0 o DP
1.3+ 2880×1440 @ 90 Hz
Bluetooth 4.0 para accesorios
Sistema operativo: Windows 8.1, 10
1.4.1.2 Smartphone
Un Smartphone (o teléfono inteligente en español) es un tipo de teléfono móvil construido
sobre una plataforma informática móvil, con mayor capacidad de almacenar datos y
realizar actividades, semejante a la de una minicomputadora, y con una mayor
conectividad que un teléfono móvil convencional.
Según datos de Gartner (2013) del tercer trimestre del año 2013 en cuanto a uso de
sistemas operativos móviles en teléfonos inteligentes en todo el mundo, estos fueron los
resultados:
Sistema operativo % de usuarios
Android 81.9
iOS 12.1
Windows Phone 3.6
BlackBerry OS 1.8
Otros 0.6
26
Cualquier smartphone que se pueda comprar en la actualidad puede ser usado con unas
Gafas VR, pero no todos pueden ofrecer la misma experiencia virtual.
Características que debe tener un Smartphone para ejecutar contenido en realidad
virtual:
Tener sensores como el Giroscopio, el Magnetómetro y el Acelerómetro.
Son los sensores encargados de registrar los cambios en la posición o la rotación
del teléfono móvil. Hacen posible que el movimiento de la cámara de la aplicación
de realidad virtual corresponda con el movimiento natural de la cabeza.
Una buena resolución de la pantalla (alta cantidad de DPIs o Pixeles por Pulgada)
A mayor cantidad de pixeles, mayor resolución tiene el contenido mostrado en
pantalla. Un mínimo de calidad es la resolución HD de 1280x720 píxeles.
Un tamaño de pantalla compatible con la mayoría de Gafas VR del mercado.
El tamaño de la pantalla se suele medir (diagonalmente desde las esquinas) en
pulgadas. Las gafas de Realidad Virtual aceptan un intervalo de medidas en
dependencia del tamaño de su compartimiento o del sistema de agarre que utilice.
Generalmente las medidas estándar oscilan de 4 a 6 pulgadas
Tener un procesador potente.
Tener gran cantidad de memoria RAM
La memoria RAM sirve para almacenar las APPs, videos y videojuegos mientras
se están usando. El procesador se comunica con la memoria RAM para ejecutar
lo que tenga almacenado. A mayor memoria RAM, más información se puede
almacenar en ella y menos veces se necesita buscar dicha información en la
memoria de almacenamiento del dispositivo, que es lo que provoca que se
ralenticen los videojuegos.
Tener buena capacidad de almacenamiento
Los gráficos y recursos usados en realidad virtual son generalmente voluminosos.
Es necesario mayor capacidad de almacenamiento para gestionar la trasferencia
de datos de esa envergadura.
Todas las características mencionadas responden a un smartphone Gama Media-Alta.
27
Lista de algunos smartphones compatibles con realidad virtual:
Samsung Galaxy S7 / S7 Edge
Tamaño del dispositivo: 5.1″
Resolución de la pantalla: 2560×1440 – Quad HD o 2K
Procesador: Octa-Core, de los cuales 4 a 2.3 GHz y 4 a 1.6 Ghz
Memoria RAM: 4Gb
Memoria de almacenamiento: 32Gb
Samsung Galaxy Note 4
Tamaño del dispositivo: 5.7″
Resolución de la pantalla: 2560×1440 – Quad HD o 2K
Procesador: Quad-Core a 2.7 Ghz
Memoria RAM: 3Gb
Memoria de almacenamiento: 32Gb
Google Nexus 6P
Tamaño del dispositivo: 5.7″
Resolución de la pantalla: 2560×1440 – Quad HD o 2K
Procesador: Qualcomm® Snapdragon™ 810 2.1 de 8 núcleos a 2 GHz
Memoria RAM: 3Gb de tipo LPDDR4 (doble de rápido que las normales)
Memoria de almacenamiento: 32Gb
Apple iPhone 6S / 6S Plus
Tamaño del dispositivo: 4.7″
Resolución de la pantalla: 1334×750 – por encima de HD
Procesador: A9 Dual-Core a 2 GHz
Memoria RAM: 2Gb de tipo LPDDR4 (doble de rápido que las normales)
Memoria de almacenamiento: 16Gb, 32Gb, 64Gb, 128Gb
28
Xiaomi Mi5 Pro
Tamaño del dispositivo: 5,16″
Resolución de la pantalla: 1920×1080 – Full HD
Procesador: Qualcomm Snapdragon 820 de 4 núcleos a 2,15GHz
Memoria RAM: 4Gb
Memoria de almacenamiento: 128Gb
1.4.1.3 Consola de Videojuegos
Las consolas son un sistema electrónico de entretenimiento para el hogar que ejecuta
juegos electrónicos contenidos en cartuchos, discos ópticos, discos magnéticos, tarjetas
de memoria o cualquier dispositivo de almacenamiento.
El nivel de procesamiento gráfico de las consolas de octava generación como el Play
Station 4, el Wii U y el Xbox One han permitido incorporar contenido de realidad virtual
en sus videojuegos. El líder en este sector es el Play Station 4 con sus gafas Play Station
VR, aditamento que se agrega a la consola y permite visualizar el contenido de realidad
virtual e interactuar con él.
El Playstation 4 dispone de un microprocesador tipo APU de ocho núcleos x86-64 a 1.6
GHZ fabricado por AMD. Una GPU AMD 7870 [29] con una potencia de procesamiento
de 1,84 Teraflops, que puede dedicarse a diferentes tareas que no sean exclusivamente
gráficas. Cuenta también con una memoria RAM unificada de 8 GB, GDDR5, con un
ancho de banda de 176 GB/segundo.
Tiene una capacidad de almacenamiento de 500GB interno. Su unidad admite Blu-ray
6x y DVD 8x. En materia de conectividad la consola cuenta con Ethernet (10BASE-T,
100BASE-TX, 1000BASE-T), 802.11 b/g/n y Bluetooth 2.1 (con EDR). Además ofrece
puertos HDMI, salida óptica digital y USB 3.0.
Usa como dispositivo de interacción los DualShock 4 así como la cámara de
reconocimiento PlayStation 4 Eye.
29
1.4.2 Visualización
En la realidad virtual, desde el punto de vista del usuario, el aspecto fundamental es la
visualización debido a que la visión es, de los sentidos que tiene el ser humano, el que
más información aporta para el reconocimiento del entorno. Debido a que una de las
metas de la realidad virtual es alcanzar la inmersión de usuario en el mundo que se
quiere representar, (esto es, que el usuario sienta en la medida de lo posible que lo que
está observando es real), frecuentemente la visualización de la misma se realiza a través
de mecanismos que permitan el uso de la estereoscopía, puesto que la visión humana
es por naturaleza estereoscópica. Otra característica deseable para el alcance de la
mencionada sensación de inmersión es la de que la imagen que observa el usuario de
la realidad virtual no aparezca en su mismo campo visual a la vez que imágenes del
entorno real, como ocurre, por ejemplo, con el cine, donde el espectador mira a una
pantalla donde se proyecta la película, pero a la vez puede mirar a su lado y ver al resto
de los espectadores, butacas del cine, etc. lo cual rompe la sensación de inmersión. Por
eso la visualización de la realidad virtual se implementa usualmente a través de gafas o
cascos que cumplen con los dos principios mencionados: por una parte, ofrecen dos
imágenes a la vez, una para cada ojo, para conseguir el efecto de estereoscopía; y por
otra parte impiden que el resto del entorno real sea visto por el usuario durante la sesión
de realidad virtual.
Las gafas o cascos tienen también como objetivo proporcionar un campo similar de visión
que la visión natural y emular la disparidad de los ojos (la diferencia de la posición entre
ellos en el orden vertical). En algunos casos las gafas cuentan con sensores propios,
como el giroscopio, lo cual permite que el mismo dispositivo detecte la orientación de la
cabeza del usuario para generar, en consecuencia, el gráfico del entorno
correspondiente a donde él está mirando. En otros casos las gafas no tienen un sensor
propio, (por lo cual no pueden por sí solas detectar hacia dónde está orientada la cabeza
del usuario) y entonces cuentan con varios trackers o puntos visibles que son leídos por
una o varias cámaras externas las cuales registran el movimiento del dispositivo en el
espacio y emplean esa información para coordinar en tiempo real la visualización del
entorno virtual para que coincida con la posición y orientación de la cabeza del usuario.
Este último método, aunque en aparente desventaja tecnológica, es más factible para
registrar la posición observador (no solo la dirección hacia donde está mirando, a lo cual
30
se limitan la gran mayoría de cascos y gafas que tienen sensores propios) y por esa
razón permiten la característica adicional de que el usuario pueda desplazarse por el
entorno virtual a la vez que camina en el entorno real
1.4.2.1 Tipos de Gafas para Realidad Virtual
Smartphone’s Display:
Esta es la variante más recientemente creada. Consiste generalmente en cascos
sin ninguna circuitería electrónica ni chips de procesamiento, diseñados
meramente para que dentro de ellos se coloque un smartphone estándar de modo
tal que la pantalla queda orientada directamente a los ojos del usuario. El cómputo
de los gráficos, la visualización y el uso de sensores para detectar la orientación
de la cabeza, es completamente procesado en el hardware del Smartphone.
Tiene como ventaja la alta rentabilidad, dado que una gran parte de la población
mundial posee smartphones, y los cascos o gafas son relativamente baratos (en
la mayor parte de los casos no alcanzan los USD 20). Como desventaja tiene las
que se derivan del poder de procesamiento gráfico de los smartphones: por una
parte, dicho poder de procesamiento suele ser muy bajo comparado con el que
puede alcanzar un ordenador con tarjeta gráfica, y por otra parte existe una
variedad muy grande de smartphones con muy diferentes potencialidades
técnicas, lo cual dificulta la estandarización de implementación de algoritmos de
gestión de gráficos.
No obstante, esta alternativa se está convirtiendo en un fenómeno cada vez más
popular y en tiempos recientes los distribuidores fundamentales de aplicaciones
móviles (Google Play, AppleStore y Windows Store) están emitiendo cada vez
más aplicaciones y juegos orientados a estos dispositivos.
Head Mounted Display:
Son dispositivos que cuentan con todo el hardware necesario incorporado. Las
gafas de realidad virtual de este tipo no necesitan de ningún equipo externo para
funcionar.
Head Mounted Display Tethered:
31
Este tipo de gafas está diseñado para trabajar en conjunto con ordenadores y
video-consolas cuentan con su propia pantalla interna que muestra el entorno
virtual. Los gráficos son procesados previamente en el ordenador o en la video-
consola. La conexión entre las gafas y el ordenador o la video-consola se puede
hacer por cable o de forma inalámbrica, y cada una de estas vías tiene ventajas
diferentes. La conexión inalámbrica permite mayor libertad en el movimiento del
usuario, mientras que la conexión a través de cable permite un menor retraso en
la transferencia de datos (es decir, menor latencia) lo cual es preferible para evitar
desfasajes temporales entre los movimientos de la cabeza del usuario y la
consecuente reacción de los gráficos. Ya que la gestión de los gráficos no se
realiza en las gafas, sino en el ordenador o consola, el rendimiento depende
mucho del hardware de estos últimos, sobre todo de la tarjeta gráfica, que debe
ser especialmente compatible para estos fines y de una potencia usualmente
mayor a las tarjetas de gama media.
1.4.2.2 Modelos de gafas para Realidad Virtual
El creciente uso de la tecnología de realidad virtual ha generado recientemente un
aumento de los productos para su visualización. Existe un gran número de compañías
que han desarrollado sus propuestas de productos y esto ha dado como resultado que
exista una gran variedad de alternativas. A continuación, se relacionan los más
empleados, que son, a la vez, los que más presencia tienen en la bibliografía y en
internet:
1.4.2.2.1 Oculus Rift
El Oculus Rift es un dispositivo encadenado o Head Mounted Display Tethered. Se
necesita un ordenador potente para ejecutar juegos, vídeos y aplicaciones de realidad
virtual. La plataforma para descargar estas aplicaciones se llama Oculus Home. El sitio
web oficial de Oculus cuenta con un software de análisis que permite determinar si
cualquier determinado ordenador es compatible o no.
El dispositivo cuenta con micrófono y altavoces integrados. También incluye un sensor
externo, un control remoto sencillo y un par de controles para la interacción, llamados
32
Oculus Touch. Si no se dispone de estos controles, se puede usar un control de XBOX,
que también es compatible.
Características:
Pantalla: OLED
Resolución: 2.160 x 1200 píxeles
Refresh Rate: 90Hz
Campo de visión: 110 grados
Requisitos del ordenador:
NVIDIA GTX 970 / AMD 290 equivalente o superior
Intel i5-4590equivalente o superior
8 GB+ de RAM
Salida de vídeo compatible con HDMI 1.3
2x puertos USB 3.0
Precio:
$600 - $700
1.4.2.2.2 HTC Vive
Las HTC Vive son las gafas de realidad virtual desarrolladas por Valve. Valve es una
compañía desarrolladora de juegos, y son los dueños de la plataforma Steam, que cuenta
con cientos de videojuegos, varios de ellos compatibles con HTC Vive.
HTC Vive ofrece dos controles de interacción y sensores para ser colocados en el
espacio real con el fin de realizar un seguimiento de la ubicación y los movimientos del
usuario. Además, el HTC Vive tiene una cámara frontal que permite la interacción con el
entorno real. Este también es un modelo encadenado (Head Mounted Display Tethered),
que utiliza un ordenador. Como en el caso del Oculus Rift, Valve ofrece una aplicación
que permite determinar si un ordenador es compatible con HTC Vive, disponible a través
de Steam.
33
Características:
Pantalla: OLED
Resolución: 2.160 x 1200 píxeles
Refresh Rate: 90Hz
Campo de Visión: 110 grados
Requisitos del ordenador:
NVIDIA GeForce GTX 970 /Radeon R9 280 equivalente o superior
Intel Core i5-4590 equivalente o superior
4 GB+ de RAM
Salida de vídeo compatible con HDMI 1.3
1x puerto USB 2.0
Precio:
$700 - $900
1.4.2.2.3 PlayStation VR
El Playstation VR es el hardware de realidad virtual de Sony para ser utilizado con su
Playstation 4. Cuenta con sensores propios, pero también trabaja con la Playstation
Camera para rastrear los movimientos de la cabeza. Además del DualShock 4, también
es posible utilizar los controles Playstation Move.
El Playstation VR viene con auriculares con un procesamiento en 3D, lo que permite una
inmersión aún mayor en la realidad virtual.
Características:
Pantalla: OLED
Resolución: 1.920 x 1.080 píxeles
Refresh Rate: 120 Hz
Campo de visión: 100 grados
34
Requisitos del equipo:
Playstation 4
Playstation Camara
Playstation Move (opcional)
Playstation 4 Gamepad
Precio:
$ 330 (Solo el equipamiento para realidad virtual, el Playstation 4 se compra
aparte)
1.4.2.2.4 Google Cardboard
Las Google Cardboard son las primeras gafas de realidad virtual de Google (en 2017
lanzaron al mercado las Google Daydream, que fue el modelo sucesor). Se trata de una
caja formada con piezas plegables de cartón donde se coloca un smartphone con la
aplicación Cardboard instalada. Esta caja cuenta con dos lentes y un par de imanes que
sirven como controlador para que el usuario pueda interactuar con los vídeos y
aplicaciones.
Con un cartón plegable recortado y 2 lentes, es posible montar el teléfono inteligente y
aprovechar las aplicaciones de Android VR. Marca en este sentido su diferencia principal
con otros productos como Oculus Rift o HTC Vive, que requieren de una computadora
potente y un software específico para su uso.
Los lentes están para dar la sensación de profundidad. Los campos de visión para el ojo
izquierdo y derecho están delimitados por una franja de cartón separatoria en el centro
de las gafas. Los cristales crean un efecto lupa, así que es bastante importante que el
teléfono tenga una concentración alta de píxeles por pulgada o DPI (Ripton, 2014)
A pesar de que Google ofrece un molde de forma gratuita para que cualquier usuario
construya su propio Google Cardboard, algunas tiendas de internet venden el cartón ya
montado con las lentes y los imanes.
La versión más lujosa de Google Cardboard son las Gafas VR Box. Es un modelo,
generalmente de plástico, con un par de lentes regulables, correas de soporte para la
35
cabeza y un compartimiento para el Smartphone que deja visible la cámara, para usar
además aplicaciones de Realidad Aumentada. Tienen como ventajas con respecto a las
Google Cardboard que se puede regular la distancia focal y la separación entre los lentes.
(Kerpelman, 2015).
Muchos fabricantes de diversas compañías y países fabrican sus versiones de las gafas
VR Box, las diferencias más notables están en el material, el peso, el compartimiento
para el Smartphone y su forma de maniobrarse, la presencia o no de un botón de
interacción magnético, entre otras.
Requisitos del Equipo:
Un Smartphone de 4 a 6 pulgadas
La aplicación Google Cardboard instalada en el dispositivo.
Un gamepad bluetooth en sustitución del botón magnético
Precio
Google Cardboard: $5
VR Box: $15 - $20
1.4.2.2.5 Samsung Gear VR
Las gafas Samsung Gear VR fueron desarrolladas por Oculus por medio de una
colaboración con la empresa Samsung. A pesar de utilizar el smartphone de la misma
manera que Google Cardboard, el Samsung Gear VR ofrece una usabilidad mejor. Viene
con un control en el lateral para facilitar la interacción del usuario con las aplicaciones, el
cual es un mecanismo más confiable que los imanes de la Cardboard. Por otra parte,
Samsum Gear VR es compatible únicamente con teléfonos Samsung de última
generación.
El dispositivo no cuenta con una pantalla integrada; en su lugar, es el panel del
smartphone el que funciona como tal. Teniendo en cuenta que el dispositivo es
compatible con los últimos modelos de gama alta de Samsung, la resolución será
siempre de 2560×1440 (1280×1440 por ojo). La lista de terminales compatibles con Gear
36
VR se reduce a los tres modelos de Galaxy S6, a los dos de la línea S7 y al Note 5
(Colado, 2016).
Samsung declara que este modelo es ergonómicamente más confortable que el
Cardboard de Google. Pero, de la misma manera que el Cardboard, el rendimiento del
Samsung Gear VR está relacionado con las especificaciones técnicas del Smartphone
de Samsung con que se cuente.
Características:
Resolución: 2560×1440 píxeles
Requisitos del equipo:
Smartphone de Samsung (modelo S6 en adelante).
Precio:
$100
1.4.3 Interacción
Una parte fundamental de la realidad Virtual es la Interacción, con solo visualizar el
contenido que se nos está mostrando, seríamos meros espectadores, sin poder de
decisión, explotando aún más los grados de inmersión que nos brindan los dispositivos
de interacción seríamos verdaderos protagonistas de la historia, teniendo la posibilidad
de movernos por el entorno recreado a nuestro antojo ,interactuando con personajes,
elementos del terrenos y objetos de muchas formas posibles, a la par de obtener
información de estos a través de la interacción con ellos.
En las últimas décadas ha existido mucho interés en el desarrollo de sistemas de realidad
virtual, especialmente en el ámbito de simuladores y en la medicina. En un principio, la
única forma de interactuar con los ambientes virtuales era a través de la vista. Los
usuarios sólo podían ver y apreciar el mundo virtual en el que se los situaba.
Posteriormente se comenzó a incluir sonido, permitiendo que usuarios puedan oír
distintos sonidos provenientes de los objetos virtuales. Luego, se comenzó a incluir el
sentido del tacto para que los usuarios puedan, por ejemplo, navegar a través del mundo
virtual mediante el uso de dispositivos tangibles, como por ejemplo un teclado o un
37
joystick. Se puede notar que cuantos más sentidos estén involucrados a la hora de
interactuar con el mundo virtual, los usuarios sentirán que este mundo se asemeja cada
vez más al mundo real. Se dice entonces que este mundo virtual es cada vez más
inmersivo (Selzer & Arriata, n.d.)
1.4.3.1 Teclado y Ratón
Son los medios tradicionales de interacción con el ordenador y la opción por defecto y
con más posibilidades, ya que se dispone de muchas teclas, (generalmente más de 100),
completamente configurables. En cuanto al ratón, este puede sustituir al giroscopio, es
decir, constituyendo el control primario para determinar hacia donde se está mirando, en
vez de hacerlo a partir de determinar la orientación de la cabeza del usuario, pero esto
reduce la experiencia inmersiva y ralentiza la dinámica de exploración y observación del
entorno.
El principal inconveniente es la dificultad de uso, su poca ergonomía y funcionamiento
poco intuitivo. Si la aplicación tiene distintas funciones que requieren más teclas además
de las de dirección, resulta complicado encontrarlas sin poder visualizar el teclado ya
que las gafas de RV lo impiden.
1.4.3.2 Gamepad Bluetooth
Un gamepad es un tablero con una o varias palancas o crucetas que pueden ser
analógicas o digitales diseñadas para usarse con el dedo pulgar y una serie de botones
generalmente colocados de su lado derecho cada uno con una función específica.
Los gamepad bluetooth son dispositivos de entrada diseñados para funcionar con
móviles u ordenadores con tecnología bluetooth. Son muy fáciles de conectar y de usar,
pero requieren de una batería interna.
Habitualmente, no cuentan con ningún tipo de sensor, (giroscopio, acelerómetro, etc.),
porque smartphone cuenta con sus propios sensores y el movimiento de la cámara es
registrado por el giroscopio del móvil. Este solo recibe la entrada de botones o del joystick
38
del gamepad usados para ejecutar acciones o desplazarse por el entorno (Quinion,
Michael).
1.4.3.3 WiiMote
El WiiMote es el controlador por defecto de la consola Wii. Tiene una serie de sensores
que pueden ser muy útiles para controlar aplicaciones de realidad virtual o aplicaciones
3D en general.
El WiiMote tiene además un acelerómetro de 3 ejes para detectar hacia donde se mueve
el mando en cualquiera de las 3 dimensiones espaciales, un giróscopo para medir la
orientación del dispositivo y junto a una barra de leds un detector de movimiento para
capturar hacia dónde está apuntando el dispositivo (Sheffield, 2006).
Además tiene accesorios como el nunchaku que añade un joystick y más botones para
poder añadir funcionalidades extra.
La principal desventaja que tiene es que no es compatible con dispositivos Android con
una versión superior a la 4.2 (Jelly Bean). Este controlador usa el protocolo L2CAP para
el intercambio de datos, el cual fue eliminado de las API de Android. Además, la conexión
de la barra led para el detector de movimiento tampoco es compatible.
1.5 Softwares disponibles para elaborar una herramienta de visualización
arquitectónica en realidad virtual
1.5.1 Unity 3d
Unity es uno de los motores de videojuegos multiplataforma mejor balanceados en
cuanto a costo combinado con calidad y accesibilidad para cualquier usuario. Posee
requisitos de CPU y de tarjeta de video básicos por lo que cualquier computadora
construida en los últimos tiempos puede manejar fácilmente cualquier aplicación creada
con Unity (Unity System Requirements, n.d.).
Unity posee una versión gratuita para uso no comercial o educacional. Aunque a partir
de ganancias generadas por una aplicación que sobrepasen los 100 000 USD, el usuario
debe licenciar su programa y tiene acceso a la versión Unity Pro (Unity EULA, 2010).
39
El motor de videojuego soporta archivos de un gran número de aplicaciones 3D como
3ds Max, Maya, CINEMA 4D y Blender, lo que significa que no hay casi restricciones
para el tipo de formato que soporta, además de permitir física en sprites 2D. En el otro
lado de la balanza, no posibilita la creación ni edición de modelos dentro del motor
(Anon., 2015).
El Unity posee varias ventajas sobre los dos motores de videojuegos anteriormente
comentados: posee una versión gratuita para uso no comercial; no necesita requisitos
del sistema complejos, puede ser utilizado en casi cualquier computadora de las últimas
generaciones; a través de un plug-in de distribución gratuita puede utilizarse el IDE Visual
Studio para programar en él; puede programarse para él en C#, lenguaje de
programación orientado a objeto ampliamente conocido, y en JavaScript. Además, posee
herramientas para desarrollar contenido para web y un plug-in para instalar en el web
browser que permite la visualización de contenido de Unity a través de la red.
Unity permite importar contenido desde el 3Ds Max utilizando el formato FBX.
Posee SDK de gran cantidad de dispositivos como son Cardboard, Daydream, HTC Vive,
Oculus, etc. y de software de realidad aumentada como Vuforia o Wikitude.
Al ser un software multiplataforma es utilizado para desarrollar videojuegos para PC,
consolas, dispositivos móviles, y páginas web, entre otros. Por lo que brinda la facilidad
de crear aplicaciones para Android con un alto contenido gráfico.
1.5.2 Unreal Engine
UDK es una versión gratuita del motor de videojuegos Unreal Engine 3 desarrollado por
Epic. Ofrece un sistema de iluminación propio (Lightmasssoftware) con una solución de
render de GI que permite la obtención de imágenes cercanas a la realidad en poco tiempo
de render y con una interface de usuario fácil de usar además de soportar el uso de
iluminación HDR (UDK Features, 2011). Posee un grupo de plug-ins que anteriormente
eran independientes pero que han sido añadidos al programa tales como SpeedTree
utilizado para la creación de vegetación, Physx especializado en colisiones y FaceFX
para la creación de animaciones faciales (Porter, 2010).
40
Al igual que CryENGINE 3, UDK posee requisitos de sistema mínimos, pero los requisitos
recomendados por Schroeder (2011) con los que se alcanza la mejor calidad visual son
los siguientes:
Sistema operativo Windows 7 64-bit o superior.
Cualquier CPU multi-core de 2 GHz o de mayor velocidad.
4 GB de RAM o superior.
Tarjeta Nvidia serie 8000 o ATI equivalente, u otra superior a estas con al menos
512 Mb de memoria de video.
UDK puede ser usado gratuitamente bajo una licencia para uso no comercial o
educacional, sin embargo, si se decide comercializar algún producto generado con la
versión gratuita, tiene que pagarse 99 USD de licencia de programa más el 25% de las
ganancias adquiridas después de los primeros 50 000 USD ganados. Si se planea desde
el principio utilizar el producto con fines comerciales, la mejor opción es contactar a Epic
y pagar la licencia del producto con lo cual no es necesario aportar el 25% de las
ganancias posteriores (Schroeder, 2011).
El lenguaje de programación nativo del UDK y el Unreal Engine es el UnrealScript. Es un
lenguaje de programación orientada a objeto similar al Java. En marzo de 2014, Epic
anunció que el Unreal Engine 4 no soportaría más UnrealScript, y en su lugar soportaría
C++. Además permite scripting en Kismet. (Anon., 2014)
El programador, desarrollador de videojuegos y artista 3D Nobel-Jørgensen (2010)
propone en su blog, tras su experiencia con el motor de videojuegos, una lista de las
ventajas y desventajas del UDK:
Ventajas:
Desempeño: posee un muy buen desempeño incluso con escenas con mu-
chos polígonos y materiales avanzados.
Iluminación y render: gracias al sistema de Lightmasssoftware y el soporte
de iluminación HDR.
Editor de programación en Kismet y la herramienta de animaciones Mati-
nee, que facilitan la creación de simples scripts y diseños para usuarios no
programadores.
41
Editor de materiales: posee un editor de materiales visual que permite ver
fácilmente cómo cada shader afecta el resultado final.
Editor de partículas Cascade: sistema propio de sistema de partículas con
una interface de usuario de fácil uso que genera buenos resultados visua-
les.
Desventajas:
No existe el concepto de carpeta de proyecto: No existe una separación
clara entre los archivos del proyecto desarrollado y los archivos de ejemplo
del UDK por lo que el trabajo no puede ser organizado correctamente.
Flujo de trabajo lento: Después de cada cambio en el código de programa-
ción es necesario reiniciar el UDK para que tenga efecto.
Pobre soporte de debugeo (degugging support).
1.5.3 Armory 3d
Armory es un motor de juego en 3D de código abierto con integración completa de
Blender, convirtiéndolo en una herramienta de desarrollo de juegos completa. El
resultado es un flujo de trabajo unificado de principio a fin, que lo hace trabajar más
rápido erradicando los saltos entre diferentes aplicaciones para exportar constantemente
datos de una a otra.
Para definir los materiales, Armory se basa en los nodos Cycles de Blender. Los
materiales se compilan previamente en sombreadores adecuados para la representación
en tiempo real.
Estas son las características graficas fundamentales de Armory 3d:
Materiales fisicamente correctos
Materiales basados en nodos de Cycles
Iluminación global basada en Voxel
Anti-aliasing temporal
Desplazamiento teselado
Raymarcha en espacio de pantalla
Oleoducto HDD
42
Armory está orientado hacia los nodos. Para los materiales, se utiliza un subconjunto de
nodos Cycles estándar. Cada escena creada en Armory es renderizable tal como está
en Cycles usando path-tracing. Esto hace posible el uso de Cycles para baking ligero sin
configuración separada. El rendimiento sigue siendo la prioridad. Para definir el
comportamiento del juego, se desarrolla un sistema de nodos lógicos (Armory3d, 2018).
Para ofrecer una experiencia multiplataforma, Armory 3D utiliza el framework multimedia
Kha y el toolkit Haxe. Su renderizador está basado en los nodos Cycles de Blender y se
apoya en físicas. Además, soporta un pipeline de HDR y es capaz de manejar
características modernas incluidas en los motores gráficos 3D. Permite exportar las
creaciones a Windows, GNU/Linux, Mac, HTML5, Android, iOS, PlayStation 4, Xbox
One y Nintendo Switch, por lo que su soporte multiplataforma es bastante completo
(Medina, 2017)
Este parece ser un prometedor motor de videojuegos, cuenta con muchas características
que lo sitúan al nivel de los demás y es gratuito y de código abierto. Pero aún es muy
joven y todavía está en desarrollo por lo que no cuenta con ninguna versión disponible.
Pero hay que tenerlo en cuenta para el futuro, sobre todo con la fuerte alianza que ha
establecido con Blender que también se va asentando en la preferencia de muchos
usuarios y que está dejando de ser el hermano pequeño de software potentes para
generar gráficos tridimensionales como son 3d Studio, Maya, y otros.
1.6 Optimización de los modelos 3D
Al optimizar los modelos que se han creado, hay que balancear entre dos necesidades
mutuamente excluyentes: por una parte la necesidad de obtener información geométrica
precisa o realista y por otra parte la necesidad de interacción en tiempo real con buen
desempeño. La visualización en tiempo real es prioritaria, por lo que la calidad de la
visualización (y con ello la geometría) se puede simplificar.
Las técnicas de optimización de la visualización incluyen:
uso de mapas de texturas. Los mapas de textura son imágenes que se mapean
en superficies de objetos para mostrar los detalles de sus superficies. Si se usa la
textura para representar en ella geometría adicional que no necesariamente existe
43
en el modelo, se puede dar la impresión de estar representando un modelo con
mayor cantidad de detalle que el que realmente está presente.
uso de primitivas estándar. Los objetos simples, como los sólidos primitivos -
esferas, cubos y cilindros- se pueden usar junto con mapas de texturas para
simplificar los datos geométricos en un modelo, debido a que muchas veces están
expresados en memoria como un juego simple de datos correspondiente a los
parámetros que definen sus características geométricas en vez de registrar las
posiciones de todos los vértices que componen la malla del cuerpo. Por ejemplo,
en muchos sistemas, una esfera se puede almacenar en memoria como un par
simple de datos que la definen completamente: posición y radio; mientras que el
almacenamiento de un objeto de forma arbitraria tiene que obligatoriamente
describir la posición de cada uno de sus vértices (Friedman, 1995)
uso de niveles de detalle dependientes de la distancia (LOD). La geometría más
simple se puede usar para reemplazar la geometría compleja a una distancia
suficiente del observador para que el ojo no perciba la pérdida de detalles.
uso de billboard. Esta técnica consiste en utilizar un plano simple con sus
normales siempre orientadas hacia la cámara. Este plano utiliza una textura 2d
con canal alpha simulando un objeto tridimensional. La silueta cuadriforme del
plano no se conserva y en su lugar se representa la silueta de la textura agregada,
definida por el canal alpha. Esta técnica es comúnmente utilizada en videojuegos
para representar geometría compleja no navegable que vaya a ser
frecuentemente observada desde cierta distancia y con la que el nivel de
interacción sea poco no nulo (Edgar, 1997)
carga selectiva de objetos dentro del modelo dependiendo del punto de vista. Los
sensores de visibilidad se pueden usar para determinar qué parte del modelo se
está viendo y, por lo tanto, qué geometría se debe cargar y representar, y qué
secuencias de comandos de comportamiento deben estar activas (Roehl, 1997).
La optimización permite la visualización en tiempo real reduciendo la información a
procesar y, por lo tanto, reduciendo el esfuerzo de cálculo requerido durante la
simulación. En cualquier sistema, se realizan intercambios entre la cantidad de detalles
geométricos (número de polígonos), el renderizado y la iluminación, y la velocidad a la
que la navegación y la interacción son posibles.
44
1.7 Extensión de Inquilino 1.0 Beta
La herramienta Inquilino 1.0 Beta fue diseñada por Gabriela Leal Carrazana en el año
2016 como parte de su trabajo de diploma. Se diseñó para la plataforma PC y tiene las
características siguientes:
Se puede navegar a través del proyecto en primera persona (similar a un vi-
deojuego tipo shooter) utilizando para la traslación las teclas W/S o flechas
arriba/abajo del teclado, y el mouse para la orientación del punto de visión, durante
este momento el cursor del mouse no se ve en pantalla.
La posición de la primera persona aparece señalada en un plano del nivel en el
que se encuentra, ubicado en la esquina inferior derecha de la panta-lla, junto a
esta aparece señalado el cono de visión del observador.
Pulsando la tecla Alt se congela la vista en la pantalla, se desoculta el cursor del
mouse y se accede al modo Menú de la primera persona. En esta modalidad se
puede:
Hacer clic en un lugar arbitrario del plano en el que esté permitida la
navegación y la primera persona aparece momentáneamente en este
punto (las áreas de navegación son definidas por el arquitecto median-te el
objeto de navegación que se crea y selecciona en el 3ds Max).
Cambiar de nivel utilizando las flechas que hay debajo del plano, siempre
y cuando exista un área en que esté permitida la navegación en la misma
posición donde se encuentra la primera persona pero en otro nivel (si solo
es navegable la primera planta de la edificación o la primera persona está
ubicada en una habitación cuyo puntal abarque otros niveles, no puede
accederse a niveles superiores, en este último caso hay que trasladar a la
primera persona a un punto donde sí exista superficie navegable en el nivel
superior o inferior y luego hacer el cambio de nivel), (scroll).
Hacer capturas de pantalla que se almacenarán en la misma carpeta donde
se encuentra el ejecutable de la aplicación (tecla C).
Cambiar a vista de exploración (o análisis del exterior), (tecla X)
45
El modo de exploración permite panear, hacer zoom y orbitar el modelo y siempre
tiene el cursor del mouse visible.
Es posible cambiar el modo de visualización de la cámara de perspectiva a
ortográfica (tecla Z).
Puede ocultarse la cubierta de la edificación y, si los tiene, ocultarse y des-
ocultarse niveles para permitir el análisis interior del proyecto.
Se mantiene la utilidad de hacer capturas de pantalla de la misma forma que en
la modalidad de primera persona (Leal, 2016)
Esta primera versión tiene algunas deficiencias:
El plugin para 3ds Max es complejo de usar.
El modelo utilizado no está bien optimizado.
La interface gráfica tiene un exceso de textos y es poco atractiva.
El logro fundamental de Inquilino 1.0 beta desde el punto de vista tecnológico es que se
implementaron correctamente los algoritmos computacionales que garantizan la
visualización 3D y navegación en tiempo real logrando efectos como detección de
obstáculos, división de la edificación en niveles y asimilación del juego de datos de
texture baking generados en 3ds Max, todo lo cual puede ser reutilizado y extendido para
adaptarlo a la tecnología de la Realidad Virtual.
1.8 Análisis de los antecedentes relacionados para la determinación de
características de la herramienta
Del estudio que se realiza a lo largo de este capítulo se decide seleccionar para
desarrollar la aplicación de visualización arquitectónica los siguientes elementos:
Uso de la Realidad Virtual con Estereoscopía para la presentación de proyectos.
Es la más abarcadora de todas, presenta gran flexibilidad visual, dinamismo;
interactividad del usuario con el espacio arquitectónico; visualización del proyecto
como un todo; realismo en la presentación gracias a la inmersión; fácil
entendimiento de la propuesta planteada, excelente orientación espacial.
46
Unity 3d como motor de videojuegos.
Este programa ofrece una versión gratuita para uso no comercial, no necesita
requisitos complejos del sistema, cuenta con una gran variedad de paquetes de
desarrollo (SDK) de los distintos visores de realidad virtual. Adicionalmente el
autor del presente estudio tiene experiencia en programación en el lenguaje C#,
que es la alternativa fundamental de programación en Unity 3d.
Smarphone con SO Android para la ejecución de la aplicación.
Casi cualquier usuario tiene un smartphone con Android porque es la plataforma
móvil más difundida y utilizada a nivel mundial y cuenta con muchas facilidades
de desarrollo por ser de código abierto.
Google Cardboard para la visualización del contenido en realidad virtual.
Son las gafas más simples y baratas y solo requieren de un Smartphone.
Gamepad Bluetooth como dispositivo de interacción.
Son baratos, prácticos y cuentan con los controles necesarios para moverse por
el proyecto e interactuar con él.
Al estudiar los principales programas para visualización arquitectónica en tiempo real y
realidad virtual existentes se determina que aplicación como la que se desea crear con
el presente trabajo cuente con las siguientes características:
Permitir una navegación rápida e intuitiva por la edificación.
Posibilitar la navegación en primera persona y por el exterior de la edificación
Lograr una visualidad atractiva y permitir distintos estilos de visualización según
la elección del arquitecto.
Permitir analizar la edificación en distintos momentos del día y bajo diferentes
condiciones de iluminación.
Mostrar información planimétrica del proyecto que demuestre la distribución
espacial de la edificación y que sirva de orientación para el usuario.
Lograr a través de la herramienta una presentación dinámica del proyecto.
El producto final tiene que ser portable (formato de fácil distribución que ocupe
poco tamaño en disco y que no requiera instalación) y de distribución gratuita.
Varios de estos puntos es posible lograrlos usando como punto de partida mucho de lo
implementado en Inquilino 1.0 beta.
47
Conclusiones Parciales:
Las formas más novedosas de presentar proyectos de arquitectura en la
actualidad son la realidad virtual, la estereoscopía, los tours 360 y la realidad
aumentada. Todas ellas brindan una forma más eficiente de comprensión del
proyecto presentado y una mejor visualización del mismo.
De las formas más novedosas de presentar proyectos de arquitectura, la más
atractiva es la realidad virtual. Porque combina la estereoscopía, la visión
panorámica e incluso la realidad aumentada en un mismo medio.
Para la creación de una herramienta para la presentación de proyectos de
arquitectura que utilice tecnología de tiempo real es necesario el análisis de dos
fases: un programa de modelación 3D del cual exportar el modelo, y un motor de
videojuegos para la implementación de la herramienta que emplee el tiempo real.
La tecnología de tiempo real permite la navegación interior y exterior de una
edificación de forma interactiva con una completa percepción espacial del
proyecto, una infinidad de estilos de visualización, la complementación de la
información de la presentación con imágenes fijas como planos o diseños de
conceptualización, y la portabilidad de la información sin necesidad de la
presencia del presentador.
La mayoría de las aplicaciones existentes para la visualización arquitectónica
están en fases muy jóvenes de su desarrollo, son de pago y las que realizan
operaciones previas de optimización requieren una buena conexión a internet.
Los hardwares de realidad virtual tienen marcadas diferencias en relación a la
calidad y el precio de los distintos dispositivos que existen.
Para estudiantes y profesionales de la arquitectura cubanos la mejor opción en
cuanto a gafas de realidad virtual son las de tipo Smartphone’s Display como el
caso del Cardboard de Google; estas son muy baratas, utilizan como soporte un
Smartphone y aprovechan su capacidad de cómputo. Las otras alternativas, como
las gafas de tipo Head Mounted Display tienen gran potencia de representación,
pero su costo es muy elevado y no es accesible para el público promedio.
48
El uso combinado de un smartphone con modelos arquitectónicos bien
optimizados permite lograr grandes escenarios con un alto nivel de detalle y un
rendimiento óptimo.
De los dispositivos de interacción, la mejor opción para visualización
arquitectónica es el gamepad bluetooth, aunque no cuenta con sensores de
movimientos como los más sofisticados, es muy barato y cuenta con los controles
suficientes para este tipo de experiencia.
49
Capítulo 2 Características de la herramienta Inquilino VR
2.1 Los componentes de Inquilino VR
Inquilino VR, es la versión para realidad virtual de Inquilino.
Esta herramienta está dividida en tres partes:
Plugin para 3ds Max
Es una utilidad que se le instala al 3ds Max y permite realizar toda la preparación
previa del modelo arquitectónico de manera automática. Exporta un fichero fbx y
las texturas necesarias para que sea compatible con el motor de videojuegos,
Unity 3d
Herramienta en Unity
Es una escena de Unity 3d lista y optimizada con todos los gameobjects y scripts
necesarios para la generar la aplicación. Recibe el modelo en un fichero fbx que
se incorpora a la escena de manera automática. Compila una aplicación en
formato APK.
50
Aplicación para Android
Es la aplicación resultante de la compilación de la escena en Unity.
Contiene todos los recursos dentro de la APK que se instala, por lo que no
necesita base de datos adicional en formato OBB. No tiene requisitos adicionales
de software y es compatible con todas las versiones de Android a partir de la 4.4.
2.1.1 Características del plugin para 3ds Max
Reconocer cristales en el modelo.
Dividir por niveles la edificación utilizando planos de corte.
Reconocer el norte del proyecto.
Selección del objeto de navegación
Selección de los layers que contienen el mobiliario.
Exportar el modelo en formato FBX.
Generar información geométrica del modelo en formato TXT.
2.1.2 Características técnicas de la herramienta en Unity
Uso de texturas animadas en casos específicos.
Uso de una compresión de texturas con ETC que permite mejoras en el
rendimiento gráfico y soporta texturas con canal alpha. (Mejor visualidad y mejor
rendimiento).
Uso de etiquetas para definir propiedades particulares de los objetos.
Inicialización automática en script de elementos auxiliares como texturas y
documentos de textos.
Uso de interpolaciones en las animaciones.
Transiciones entre los cambios de escena.
Uso de un InputManager avanzado.
Uso de un SoundController avanzado.
Uso de Shaders avanzados programados según las necesidades de la
presentación. Los shaders están basados en los shaders Unlit de Unity.
51
- Inquilino / CutOut: Utiliza una textura. Recorta las zonas con transparencias y
muestra las dos caras del objeto utilizando. Es utilizado en la vegetación.
- Inquilino / UI: Utiliza una textura y siempre muestra el objeto por delante de los
demás objetos rendereados (Sus propiedades ZTest y ZWrite del shader están
desactivadas) para que nada interfiera en la visualización de la información.
Es utilizado en los elementos del menú y en los carteles emergentes de ayuda.
- Inquilino / Glass: Utiliza una textura con canal Alpha, multiplica los valores del
alfa a la visualización del objeto, dando la sensación de semi-transparencia.
Muestra las dos caras del objeto para evitar que el render sea por un solo lado
y no se vea correctamente (Su propiedad Cull del shader está activada). Es
utilizado en los cristales.
- Inquilino / Texture: Utiliza una textura sin canal alpha. Es utilizado en los
materiales del modelo arquitectónico.
2.1.3 Características de la Aplicación para Android
Posee un modo de navegación en Primera Persona.
Posee un modo de navegación en Vista Aérea.
Visualización de cristales en el modelo arquitectónico.
Presencia de cielo, tanto de día como de noche.
Uso de efectos sonoros.
Usa la tecnología de realidad virtual, con imágenes estereoscópicas y entornos
panorámicos.
Posee un menú sencillo e intuitivo.
Permite alternar entre iluminación diurna e iluminación nocturna.
Posibilidad de ocultar o mostrar los diferentes niveles en la vista aérea.
Posee un mapa planimétrico correspondiente a la planta arquitectónica donde se
encuentra el usuario.
Posee un Panel de Ayuda al comenzar la presentación para facilitar el
entendimiento de los controles.
52
2.2 Plugin para 3ds Max
2.2.1 Funcionamiento general
El plugin para 3ds Max de Inquilino es una herramienta encargada de exportar la
información geométrica de un modelo en una escena de 3ds Max, en este caso un
modelo arquitectónico, para que esa información sea posteriormente usada por la
herramienta hecha en Unity (explicada más adelante) para visualizar e interactuar con el
modelo.
Unity 3d importa nativamente modelos tridimensionales generados por 3ds Max, a través
de los formatos .obj, .fbx, .3ds y, bajo ciertas condiciones específicas, incluso el formato
.max. Unity es capaz de interpretar correctamente estos formatos de forma directa, sin
la necesidad de ninguna herramienta gestora o plugin, y por esta razón, en teoría, se
puede exportar un modelo arquitectónico desde 3ds Max para ser usado en Inquilino VR
sin necesidad de ningún plugin adicional. Si se hace esto, el inconveniente consiste en
que el modelo exportado será adecuado para la visualización pero no para la interacción.
El plugin de 3ds Max permite gestionar la exportación de un .fbx con la geometría del
modelo 3d, y de forma adicional la siguiente información, útil para la interacción del
usuario con el modelo en Inquilino VR:
Definición de las áreas transitables. Sin esta información el programa en Unity 3d
no puede determinar por qué parte de la geometría el usuario puede transitar en
modalidad de primera persona. Esto permite que el modelo sea transitable
teniendo en cuenta obstáculos y variaciones en el nivel del terreno. Esta
importación se exporta mediante una malla transitable o de navegación
(navmesh).
Definición de niveles de la edificación. Si un modelo arquitectónico no es creado
en un BIM (Revit, ArchiCAD, etc.) no existe información computacional de qué
objeto modelado pertenece a qué nivel, y esta información es muy difícil de
generar automáticamente usando algoritmos que analicen la geometría del
modelo. Por esta razón, el plugin de 3ds Max requiere, como entrada, que el
usuario le indique explícitamente de dónde a dónde va cada nivel en el eje Z del
mundo de 3ds Max (en este programa el eje Z es el vertical). Esta información se
53
exporta en forma de texto que tiene las coordenadas lineales del límite entre
niveles.
Definición de layers de mobiliario. Si el usuario de 3ds Max tiene layers de
mobiliario en su modelo, puede indicar cuáles son para que Inquilino sea
potencialmente capaz de ocultar y mostrar mobiliario ya en la aplicación generada
en Unity 3d. Esta característica de Inquilino se comenzó a implementar en
Inquilino 1.0 beta pero todavía no se encuentra en estado completamente
funcional en la implementación de la parte de Unity. La información de layer de
mobiliario es exportada directamente como un grupo especial dentro del .fbx.
De manera adicional, el plugin de 3ds Max gestiona, de manera automática, información
adicional que permite una mejora de la visualización en la herramienta de Unity 3D:
Marca, internamente, como “cristales” los objetos que tengan algún material
refractivo y/o con transparencia bastante alta. Esta información es incluida en la
estructura del .fbx para luego emplearla en Unity 3d para asignar shaders de
transparencia simple a esos objetos en vez de usar shaders de refracción
equivalentes a los materiales importados desde 3ds Max.
Detecta, internamente, la dirección del norte con respecto a la construcción, en el
caso de que en la escena de 3ds Max se haya usado algún objeto brújula
(compass). Esto sucede, por ejemplo, en los casos en los que el usuario de 3ds
Max haya incluido un sistema de iluminación solar, el cual trabaja también con
esta información. El objetivo de esto es descartar la iluminación solar de 3ds Max
e implementar una iluminación similar en unity 3d que permita evaluar el
asoleamiento.
Nota: Esta característica está en fase alfa de desarrollo aún y no está expuesta
todavía en la herramienta de Unity 3d para Inquilino. Sin embargo, la parte del
funcionamiento del plugin de 3ds Max para ello ya está completamente
implementada.
Por último, el plugin de 3ds Max permite, además, descartar de manera automática los
elementos de la escena que no sean relevantes para su exportación hacia la herramienta
de Unity 3d para el caso específico de Inquilino. Esto se consigue mediante la
implementación de un preset interno de exportación a .fbx, que excluye:
54
Luces de 3ds Max. Inquilino no implementa, por el momento, iluminación dinámica
en tiempo real.
Splines y Helpers de ningún tipo. Estos objetos generalmente se emplean en 3ds
Max de forma auxiliar en la modelación pero no contribuyen al resultado visual
final generalmente.
Objetos ocultos.
2.2.2 Descripción técnica del plugin
2.2.2.1 Scripts de 3ds Max
Los elementos que componen la herramienta son exclusivamente scripts de MaxScript,
tres de ellos están destinados a la definición de funciones que son llamadas luego en
una función principal que ejecuta todas las tareas y está definida en un cuarto script. Un
quinto script está destinado a la definición de una clase sencilla, contenedora de datos
necesarios para la ejecución de la función principal y el sexto script define el rollout
(elemento encargado de la interface de usuario) y ejecuta toda la aplicación.
Los scripts que componen la herramienta son:
Definiciones de funciones:
• getSceneNodesContentInSpecifiedLayers.ms
• createFurnitureGroups.ms
• createObjectWithDeleteFaces.ms
Definición de la función principal:
• mainScript.ms
Definición de la clase:
• mainObjectClassDefinition.ms
Definición de la interface de usuario:
• 3dsApplication.ms
55
2.2.2.2 Inteface de la herramienta
El plugin de 3ds Max es ejecutado en presencia del modelo terminado (modelación y
texturizado en dependencia de la visualidad que se desee lograr en la presentación final).
Al ejecutar la aplicación aparece ante el usuario una interface simple tipo wizard con tres
momentos:
El primer momento está destinado a la selección del objeto de navegación (lo que
será el navmesh en la herramienta de Unity 3d) para la primera persona. Este
objeto debe haber sido creado previamente en 3ds Max y en este paso es
seleccionado por el usuario. El mismo no será visible en el producto final para
presentar el proyecto. Debe cubrir todas las áreas que el arquitecto desee que
sean navegables, incluyendo rampas y escaleras y excluir toda aquella área que
no sea navegable (tener en cuenta los muros divisorios de habitaciones, puertas
cerradas y ubicación de mobiliario).
Es un objeto simplificado (las escaleras se representan como rampas), todos los
niveles o elementos deben estar contenidos en un mismo objeto de 3ds Max y la
geometría debe ser cuidadosamente creada (que no existan irregularidades en la
modelación como vértices en el mismo lugar que no estén unidos, etc.), para
garantizar el buen funcionamiento de la navegación en primera persona por la
edificación.
Un segundo momento de la interface se dedica a la selección de los planos
horizontales que definirán los límites de los distintos niveles de la edificación.
Ninguno de estos objetos serán exportados desde el 3ds Max al finalizar la
preparación y por lo tanto no serán visibles ni manipulables en la presentación
final del proyecto. Estos planos tienen que ser creados por el usuario utilizando
preferentemente el objeto Plano (primitiva estándar en el panel de creación, Plane
en inglés) y definirán el límite superior de cada nivel, dejando fuera la cubierta
superior de la edificación en el caso de no ser esta navegable
En el tercer momento de la interface se marcan los layers (o capas en español)
que contengan mobiliario, si existen. En la escena pueden existir tantos layers
como se desee, pero deben estar separados los de mobiliario (incluida vegetación
56
o accesorios) y los layers de lo considerado parte de la edificación (muros,
carpintería, herrería, sistemas de cubierta o entrepisos, elementos de circulación
vertical, etc.). Estos elementos necesitan ser separados porque reciben un
tratamiento distinto durante el procesamiento del modelo.
El tránsito entre estos tres momentos de la interface está diseñado para que en cualquier
punto se pueda regresar al momento anterior y rectificar la selección, pero también para
que ninguno de los dos primeros elementos (objeto de navegación y planos límites de
niveles) queden sin ser seleccionados, esta selección es obligatoria. Es posible que el
proyecto no quiera presentarse con mobiliario por lo que la existencia de layers de
mobiliario es opcional.
Una vez seleccionados todos los objetos, el usuario pulsará el botón “Finalizar”, este
cerrará la interface y comenzará el procesamiento del modelo.
2.2.2.3 Procesamiento post-interface
El script 3dsApplication.ms (encargado de la interface), cuando se pulsa el botón
“Finalizar”, crea una instancia de la clase mainObject definida en
mainObjectClassDefinition.ms y almacena en ella toda la información introducida por el
usuario (el objeto para la navegación de la primera persona, los planos de corte y los
layers de mobiliario), llama a la función “main” definida en mainScript.ms y le pasa la
instancia de la clase mainObject creada.
La función “main” llama al resto de las funciones definidas en los otros scripts. Son
separados los objetos contenidos en los layers de mobiliario y los objetos componentes
de la edificación (que no son ni los planos límites entre niveles ni el objeto de
navegación).
A los objetos de mobiliario le aplica la función createFurnitureGroups que separa el
mobiliario de cada nivel teniendo en cuenta la posición de los planos límites entre niveles
y los agrupa por niveles.
A los objetos componentes de la edificación son aplicados la función
createObjectWithDeleteFaces que agrupa la geometría por niveles, dividiéndola según
los planos límites. A estos grupos de geometría de edificación son añadidos el mobiliario
57
de cada nivel con lo que finalmente se obtiene un grupo por nivel (que contiene la
geometría de edificación y el mobiliario del nivel correspondiente).
Se escribe a disco la posición en Z de cada plano límite de cada nivel y luego se eliminan
estos objetos.
El bounding box de la escena es un prisma imaginario que existe en 3ds Max que
contiene todos los objetos de la escena de forma exacta, obteniendo el centro de este
prisma, se obtiene el centro de toda la escena.
Por esta vía se determina este punto medio y esta información se utiliza para trasladar
toda la escena hacia el origen de coordenadas virtual del 3ds Max y se escribe a disco
junto a la información de alto, ancho y profundidad de la escena para ser tomada como
referencia por la aplicación del Unity.
Se pone en marcha la función estimateGlazingCandidateNodes que hace un recorrido
iterativo por todos los objetos de la escena para evaluar el material que tienen con el fin
de detectar cuáles de ellos pueden ser interpretados como objetos de cristal. Si alguno
de ellos presenta un material cuya transparencia sea mayor que 60 (si es en base a 100)
o que 0.6 (si es en base a 1) o cuya opacidad sea menor de 40 (si es en base a 100) o
que 0.4 (si es en base a 1), se le considera como aplicable y se le hace pertenecer a un
grupo de exportación a fbx glazingTaggedObject. El procedimiento considera todas estas
posibilidades de valores debido a que diferentes tipos de materiales en 3ds Max tienen
distintos nombres de parámetros para designar su transparencia, usualmente
“transparency” u “opacity”, significando lo opuesto una a la otra) y los rangos no están
estandarizados, aunque en los casos esperados van de 0 a 1, o de 0 a 100
indistintamente.
Luego se pone en marcha la función getCompassZOrientation que busca en la escena
si existe un objeto brújula (compass), incluso si el mismo es parte de un daylight system,
y guarda en grados su parámetro de azimuth, que expresa la orientación del norte
propuesto en la escena. Si existe más de un objeto brújula en la escena, se guarda
solamente el del primero encontrado, que es el que tenga un InternalIDNumber más bajo.
Finalmente, toda la escena es exportada en formato FBX.
58
2.3 Herramienta para Unity
La segunda parte de la herramienta es realizada en Unity 3d. Toda la información
obtenida del 3ds Studio, como son el modelo tridimensional, las texturas, los materiales,
la información en documentos de texto, entre otras, es leída e interpretada por los
distintos scripts de la herramienta en Unity 3d y compilada a una APK para Smartphone
con sistema operativo Android.
La herramienta en Unity 3d está conformada por varios directorios y archivos que el
desarrollador no debe modificar, a menos que sea necesario. El plugin para 3ds Max
genera el contenido directamente para el directorio Resources de la carpeta Assets del
proyecto en Unity. Estos son los recursos que el desarrollador muestra la aplicación
compilada, como son el modelo, las texturas, etc.
Es requisito indispensable que Unity 3d esté instalado en el ordenador, en este caso se
utiliza la versión 5.6.2p2 porque es de las más recientes actualmente e incluye por
primera vez contenido para interacción en Realidad Virtual en sus configuraciones
generales.
Otros requisitos en el ordenador además de Unity y necesarios para el trabajo con
aplicaciones móviles son los siguientes:
Android Studio o Android SDK
El SDK (Software Development Kit) de Android, incluye un conjunto de
herramientas de desarrollo. Comprende un depurador de código, biblioteca, un
simulador de teléfono basado en QEMU, documentación, ejemplos de código y
tutoriales (Android Developers, 2014).
Según Westfall (2009) Las plataformas de desarrollo soportadas incluyen
GNU/Linux, Mac OS X 10.5.8 o posterior, y Windows XP o posterior. También
puede utilizarse el propio sistema Android para desarrollos utilizando las
aplicaciones AIDE - Android IDE - Java, C++(app) [AIDE - Android IDE - Java,
C++] y el editor de Java. La plataforma integral de desarrollo (IDE, Integrated
Development Environment) soportada oficialmente es Android Studio junto con el
complemento ADT ( Android Development Tools plugin). Además, los
programadores pueden usar un editor de texto para escribir ficheros Java y XML
59
y utilizar comandos en un terminal (se necesitan los paquetes JDK, Java
Development Kit y Apache Ant) para crear y depurar aplicaciones, así como
controlar dispositivos Android que estén conectados ( es decir, reiniciarlos, instalar
aplicaciones en remoto, etc.) (Anon., 2015).
Leslie (2007) resume que una aplicación Android está compuesta por un conjunto
de ficheros empaquetados en formato .apk y guardada en el directorio /data/app
del sistema operativo Android (este directorio necesita permisos de superusuario,
root, por razones de seguridad). Un paquete APK incluye ficheros .dex [5]
(ejecutables Dalvik, un código intermedio compilado), recursos, etc.
Java SE Development Kit
Java Platform, Standard Edition o Java SE (conocido anteriormente hasta la
versión 5.0 como Plataforma Java 2, Standard Edition o J2SE), es una colección
de APIs del lenguaje de programación Java útiles para muchos programas de la
Plataforma Java. La Plataforma Java 2, Enterprise Edition incluye todas las clases
en el Java SE, además de algunas de las cuales son útiles para programas que
se ejecutan en servidores sobre workstations (Anon., n.d.).
Se utiliza la versión 8u141 de Java SE SDK o comúnmente conocido como JDK.
Esta incluye varios paquetes como son Java FX SDK y el paquete de herramientas
Java Mission Control. Además de todo el código base para las clases en java y la
API pública de Java (Anon., 2015).
Cardboard SDK o Google VR SDK para Unity 3d
Esta es una API desarrollada directamente por Google, más específicamente por
el equipo de programadores detrás de los Proyectos Google Cardboard y Goolge
Daydream (Hasta el momento los dos únicos dispositivos de Google para
visualizar contenido VR). Corre legalmente bajo una Licencia Apache, por lo que
su contenido y uso es gratuito. Esta API acumula todo el contenido necesario para
generar el software que será utilizado bajo una de estas dos variantes de gafas, y
cuenta con configuraciones y parámetros, variables y clases para que cualquier
contenido generado en Unity 3d sea correctamente visualizado en el momento de
ejecución (Dougherty, 2015).
60
Se utiliza la versión 0.6 de Google Cardboard SDK del año 2016 por ser sencilla
y reunir todas las características que se requieren para la visualización
arquitectónica e interacción en la aplicación Inquilino VR.
2.3.1 Objetos que integran la herramienta en Unity 3d
La interface de trabajo de Unity está organizada por paneles o ventanas de la siguiente
forma y distribución:
Jerarquía (Hierarchy)
Este panel agrupa todos los objetos presentes dentro de la escena de Unity 3d.
Utiliza una distribución jerárquica (lo que da nombre al panel) para los diferentes
tipos de elementos. En la parte más alta de la jerarquía se encuentran los padres
y dentro, o debajo de estos a los hijos y así sucesivamente.
El objeto básico dentro de Unity 3d se llama en inglés GameObject y es un objeto
que tiene propiedades individuales o componentes. Estos componentes son los
que definen el comportamiento de estos objetos y su papel dentro de la escena.
Escena (Scene)
Es el visor o viewport donde el contenido del proyecto es visualizado. En este
panel se muestran todos los GameObjects con sus diferentes componentes: las
luces, la geometría, las cámaras, los scripts, etc.
Dentro del panel Escena los objetos pueden ser modificados directamente,
alterando su posición, rotación y escala. También se puede panear, rotar o hacer
zoom.
Juego (Game)
Es un visor muy similar al de Escena, se muestran todos los elementos activos de
la Jerarquía, es donde se probará o testeará la aplicación. Se pueden realizar las
mismas operaciones que en el panel de Escena, pero a diferencia de este, cuando
se detiene el botón Play todos los cambios serán revertidos a su estado anterior
a comenzado el test.
Inspector (Inspector)
Este panel muestra y agrupa todas las propiedades o componentes de los
GameObjects y es donde se modifican directamente las configuraciones de estos.
61
Funciona como un stack de modificadores (para los usuarios familiarizados con
3ds Max).
Proyecto (Project)
Donde se ubican todos los recursos del proyecto, se guardan las escenas, las
imágenes, los scripts, los sonidos, los materiales, los shaders, los prefab, los
modelos, etc.
Está relacionado con la carpeta Assets, que es el directorio más importante de un
proyecto en Unity y donde se guardan en el disco duro del ordenador todos estos
recursos en uso.
Elementos existentes en el panel de Jerarquía:
MAIN
El objeto MAIN es el más importante de la jerarquía a nivel de configuración
general de la escena. Contiene varios de los scripts más importante que gestionan
todo el comportamiento de los objetos dentro del software y cómo se relacionan
estos entre sí.
A su vez es padre del objeto MinimapCamera, que es el encargado de visualizar
el modelo arquitectónico desde una vista aérea y generar varias plantas
arquitectónicas que son utilizadas en el minimapa.
El objeto MAIN contiene los scripts Main, Forced Computation Order, Day & Night
Mode, Minimap, Build Minimap, Hide Floors, Floor Controller y Base Sound
Controller.
Export
Este objeto guarda toda la geometría que fue preparada y exportada en formato
FBX desde 3ds Max, agrupa la información por niveles, cada nivel contiene la
geometría correspondiente a esa planta arquitectónica y el mobiliario. Utiliza la
etiqueta (Tag) MODEL para identificar fácilmente estos elementos como partes
del modelo arquitectónico y diferenciarlos del resto de objetos.
FirstPersonSystem
Es el objeto encargado del desplazamiento por el modelo en la vista en Primera
Persona. Contiene el componente NavMeshAgent que permite el movimiento
sobre el objeto NavMesh. EL NavMesh define las áreas por donde se puede
62
avanzar y por donde no, así como las rampas y escaleras. Además, el objeto
FirstPersonSystem contiene el script FirstPersonScript que se encarga de todos
los algoritmos de desplazamiento en este modo.
ThirdPersonSystem
Al igual que el FirstPersonSystem el ThirdPersonSystem es el encargado de la
navegación en vista aérea. Contiene el script ThirdPersonScript que controla la
forma de mirar alrededor, en este caso el observador mira el modelo siempre en
el centro y solo cambia la posición exterior desde donde se mira.
Person
Se puede definir como el usuario, es el objeto que se desplaza directamente por
el modelo. Los dos sistemas anteriores son auxiliares y definen cómo es el
comportamiento del objeto Person en el espacio. Contiene los prefabs (paquetes
de objetos predefinidos) del SDK de Cardboard que permite la visualización
estereoscópica y captura las señales de los sensores del smartphone y los traduce
en la rotación o el desplazamiento de la cámara. Contiene un hijo que es el
CardboardMain, a la vez padre del set de cámaras, los controladores y ayudantes
o helpers propios del SDK.
MENU
Es el objeto que agrupa los elementos y configuraciones del menú. Al inicio de la
ejecución está desactivado, pero se muestra en tiempo de ejecución justo cuando
la tecla de menú sea presionada.
Está compuesto por tres objetos fundamentales:
- MenuRig
Agrupa los seis botones del menú y contiene los scripts para controlarlos y
ejecutarlos cuando sea necesario.
- MenuMap
Agrupa los botones del Mapa las plantas arquitectónicas en imágenes del tipo
RenderTexure y la forma de desplazarse por ellas.
- UI Canvas
Contiene los objetos utilitarios usados por el menú como objetos, transiciones,
efectos visuales y otros scripts secundarios.
63
EventSystem
Es el objeto encargado de capturar todos los eventos que se ejecutan en la escena
de manera simultánea o individual, estos eventos son capturados al presionar una
tecla en el teclado, hacer clic con el ratón sobre determinado objeto o punto de la
escena, presionar una tecla en el gamepad bluetooth, etc.
2.3.2 Funcionamiento de la herramienta
Los objetos de la escena contienen sus propios scripts, que definen el comportamiento
de estos de manera regular o ante situaciones específicas y que toma datos del resto de
los objetos.
Cada uno de estos scripts fue escrito en C#, un lenguaje de programación orientado a
objeto y soportado por el Unity 3d derivado de C++ y que hace uso de muchas librerías
de .Net Framework. Para esta tarea pudo usarse MonoDevelop, el IDE nativo de Unity,
pero fue descartado y usado en su lugar, Visual Studio en su versión del año 2013 por
ser un IDE robusto y brindar facilidades de depuración y generación automática de
elementos repetitivos dentro del código, facilitando el trabajo y mejorando la comodidad.
La siguiente es una lista de todos los scripts usado por la herramienta y almacenados en
la carpeta Script dentro de los Assets del proyecto:
BaseSoundController.cs
Es el script encargado de controlar todos los sonidos que se ejecutan en la
aplicación. Controla el comportamiento de cada sonido, el modo de reproducción
de estos, la posición en la escena donde se ejecutan, el volumen, la envolvencia
(relacionado con el sonido panorámico), entre otros.
Agrupa todos los sonidos como variables, las cuales son usadas por los otros
scripts, principalmente los encargados de la interface de usuario y del menú.
InputManager.cs
64
Captura y procesa las entradas de cualquier dispositivo de interacción externo,
como el teclado, el ratón, gamepad bluetooth, el botón magnético del Cardboard,
etc.
Constantemente se está leyendo los sucedido en cada frame a través del método
Update() de Monobehavior y en caso de que una entrada sea registrada se le
otorga un valor a una variable tipo bool (verdeadero o falso). Esto garantiza que,
en cualquier momento, si una entrada es registrada esta sea enviada a los demás
scripts.
Menu.cs
Es el script encargado del funcionamiento del Menu y toda su interface gráfica.
Define el comportamiento de cada uno de los botones que existen y gestiona las
animaciones de entrada o salida del menú.
MenuButton.cs
Es el script que define la clase MenuButton. Cada botón del menú es una instancia
de esta clase y tiene sus propiedades previamente definidas en la clase, pero con
diferentes valores según su función. Algunas de estas propiedades son:
- name (el nombre del botón)
- description (la descripción del botón)
- iconON (la textura cuando está activo el botón)
- iconOFF (la textura cuando está inactivo el botón)
MenuMap.cs
Se encarga de mostrar el submenú Map, que se encarga de mostrar un mapa (o
una vista en planta) de la edificación. Se auxilia de los datos de entrada en el
documento de texto cameraInfo.txt provenientes del 3ds Max y de las capturas de
los diferentes niveles en planta por el script BuildMinimap.cs; computa varias
operaciones de escala para mostrar estas diferentes plantas en pantalla.
DayNightMode.cs
65
Determina que textura se muestra en cada momento en dependencia del modo
de visualización que se desee, tanto de día como de noche. Usa un algoritmo para
identificar cada geometría en la escena con la etiqueta MODEL y modifica la
variable MainTexture del parámetro Material del componente MeshRenderer.
En este caso se usan solo dos juegos de texturas que responden a la misma
geometría del modelo lo que en un caso con iluminación diurna y en el otro caso
con iluminación nocturna.
FirstPersonScript.cs
Define el movimiento del usuario en primera persona. El objeto Person se mueve
según el comportamiento de este script. Utiliza la información del CarboardHead
para saber la orientación de la vista del usuario y así moverse según esta. Este
script solo se computa cuando el enum ENavigationState corresponde con la
primera persona.
FloorController.cs
Es el encargado de ocultar o mostrar niveles en la vista en tercera persona.
Gestiona los diferentes niveles de la edificación dentro del array de GameObjects
correspondientes a cada uno de los pisos existentes.
ForcedComputationOrder.cs
Este script es auxiliar. Su función es la de determinar el orden de cómputo de las
operaciones, estas necesitan un orden específico para evitar malfuncionamientos,
sobre todo a la hora de calcular las rotaciones en los tres ejes de coordenadas,
ya que requieren respetar un algoritmo.
HeadPosition.cs
Es un script que forma parte del SDK de Google Cardboard. Se encarga de la
rotación de la cabeza (en este caso el set estereoscópico formado por dos
cámaras). Este script fue modificado para tener más control a la hora de definir
que operaciones computar primero, y evitar interpolaciones de movimiento no
66
deseadas y desfasajes en el desplazamiento tanto en primera como en tercera
persona.
States.cs
Este es un script que controla los estados más importantes de la aplicación. Estos
estados definen el comportamiento en cada situación posible. Funciona
principalmente a base de variables tipo bool y tipo enum y definen si una operación
se está realizando o que elemento está activo/inactivo en todo momento. Es un
script usado por todos los demás scripts y en cada frame se chequea si existe
algún cambio en sus componentes para que otros pueden ejecutar sus acciones.
Almacena las siguientes variables:[S1]
- ENavegationState (enum)
- EDayNightState (enum)
- mapIsActive (bool)
- menuIsActive (bool)
- helpPanelActive (bool)
-
SwitchPersonScript.cs
Es el encargado de controlar el cambio entre la primera y la tercera persona,
recibe entradas de teclas o de botones y cambia de un estado a otro (definido en
el script State como ENavegationState). Es también el encargado de definir las
animaciones entre ambas cámaras a la hora de alternar de vista para que el
cambio de estado sea interpolado y suave.
ThirdPersonScript.cs
Define el movimiento del usuario en tercera persona. El objeto Person orbita
alrededor del modelo según la orientación del CarboardHead que responde a la
vista del usuario. Este script solo se computa cuando el enum ENavigationState
corresponde a la tercera persona.
Main.cs
67
Este script es el primero que se lee cuando la aplicación es ejecutada, se encarga
de la preparación inicial. Carga el modelo desde la carpeta Resources en los
Assets y separa los grupos de cada nivel almacenándolos en un arreglo de
meshes; obtiene el objeto NavMesh, le agrega un componente MeshCollider
(utilizado para la detección de niveles) y se oculta el objeto; se lee la información
almacenada en disco por la aplicación del 3ds Max y es utilizada para la ubicación,
la size de la cámara de la que se obtienen los planos de la edificación, las
proporciones de los planos y los valores que determinan los límites de los niveles
señalados por el usuario en la aplicación del 3ds Max.
HideFloors.cs
Este script recibe un arreglo de objetos (los objetos son los niveles de la
edificación que se separan en el script Main.cs) y un entero que indicará cuál es
el último nivel visible (de ese nivel para abajo todos son visibles).
BuildMinimap.cs
Este es un script que se ejecuta en el método Start() del script Main.cs.
Esta clase solo contiene un método que se llama GetMinimaps() al que se le pasa:
- Un gameObject que contiene una cámara, esté es instanciado, la cámara
se cambia a vista ortográfica y se utiliza para la construcción de los mapas,
al final, la instancia se elimina.
- Un arreglo de float de tamaño 4 que contiene: los tres valores de un Vector3
con la posición de la cámara y un cuarto valor para el size de la vista
ortográfica. Con estos datos se garantiza la visibilidad de todas las plantas.
Estos datos se obtienen de la información que se escribe a disco desde el
3ds Max.
- Un arreglo de GameObject con la mesh separada por niveles donde el [0]
es el primer nivel.
- Dos enteros que determinan las proporciones de los mapas (width y
height).
- Este script devuelve un arreglo con los planos en forma de Texture2
ordenados de forma que él [0] es el primer nivel.
-
68
playVideoTexture.cs
Este script carga un fichero tipo VideoClip y lo coloca en el mainTexture (textura
principal) del componente MeshRenderer de un objeto cualquiera de la escena.
Permite renderear una textura animada en lugar de una textura estática.
helpPanel.cs
Este script se encarga de la interacción del usuario con el panel de ayuda.
Configura cuando se debe abrir y cuando cerrar. Bloquea otras funciones cuando
este panel esté en pantalla.
2.3.3 Participación del desarrollador
El desarrollador debe realizar manualmente las siguientes tareas:
Bakear el NavMesh.
Agregar la etiqueta “MODEL” a cada subobjeto del modelo importado.
Agregar la etiqueta “GLASS” a cada subobjeto cristal.
Definir las opciones de compilación de la Aplicación.
2.3.3.1 “Bakear” el NavMesh
El navMesh (que es el objeto utilizado para la navegación de la primera persona) no
puede ser creado vía script, por eso es necesario que el usuario lo genere manualmente.
Cuando el proyecto de Unity es cargado, el panel Project muestra la carpeta de Assets
con la escena; si se da doble click en este archivo, se abre la escena.
En el panel Hierarchy se encuentra el modelo arquitectónico con el nombre export.fbx,
este objeto no es necesario modificarlo, porque es una instancia del fichero existente en
la carpeta Resources y se actualiza automáticamente para cada nuevo proyecto. Junto
al objeto export.fbx en el panel Hierarchy aparece una flecha; si se hace click sobre esta
flecha, se accede a los objetos contenidos dentro de export. El primero de estos objetos
se llama NavMeshPlane.
69
Al seleccionar el objeto NavMeshPlane, en el panel Inspector aparecen sus propiedades;
en la primera línea escrita de propiedades, justo al lado del nombre del objeto, puede
verse un checkbox con el texto Static, este checkbox tiene que estar marcado (Figura
22).
Una vez hecho esto y con el objeto aún seleccionado, se accede al panel Navegation.
Este panel tiene dos pestañas en su parte superior llamadas Objeto y Bake y tres botones
en su parte inferior llamados Reset, Clear y Bake. Primero se pulsa el botón Clear, luego
el usuario se asegura de que los checkboxes con los textos Navegation Static y
OffMeshLink Generation estén marcados, y pulsa el botón Bake (Figura 23). Una barra
de progreso aparece en la esquina inferior derecha de la pantalla con el texto Exporting
Tiles. Al completarse esta barra, desaparece, entonces el objeto de navegación en
primera persona está listo.
2.3.3.2 Agregar Etiquetas
Para facilitar el trabajo del desarrollador. La herramienta Inquilino utiliza un sistema de
etiquetas para nombrar cada elemento de la escena. El código de Inquilino, en la fase de
inicialización de la aplicación para Android, lee la etiqueta de cada objeto, lo clasifica
según el resultado de la lectura y modifica sus propiedades.
Esto se utiliza para asignar los materiales y los tipos de shaders automáticamente, para
cambiar las texturas de los objetos cuando se alterna entre el modo Día – Noche, entre
otros.
El usuario debe asignar manualmente estas etiquetas a los objetos en el orden y de la
forma siguiente:
A cada subelemento del objeto export en el panel Hierarchy se le asigna la
etiqueta “MODEL”
A cada subelemento del objeto export en el panel Hierarchy que sea cristal se le
asigna la etiqueta “GLASS”
2.3.3.3 Configuraciones de Compilación
70
Para exportar la aplicación final para Android en formato APK hay que definir una serie
de parámetros para garantizar el funcionamiento posterior, a la hora de la ejecución.
Unity no permite, después de compilada la aplicación, cargar en la escena modelos que
no se encuentran en los archivos comprimidos, de forma que no puede ser sustituido el
modelo de la edificación. Por este motivo, el arquitecto tiene que compilar manualmente
el proyecto de Unity para cada nuevo proyecto de arquitectura para el que desee realizar
la presentación (la compilación se hará después de creado el navMesh).
Dentro del Unity y con la escena cargada, se accede a File/Build Settings y se añade la
escena a la lista de escenas a compilar (Scene In Build) pulsando el botón Add Current.
Después de añadida la escena, se pulsa el botón Players Settings… y se definen las
configuraciones de compilación siguientes:
Las configuraciones por categoría son las siguientes, las que se mencionan son
obligatorias, las restantes pueden tener el valor por defecto:
Configuraciones generales:
- Texture Compresion: ETC (Default)
- Built System: Internal (Default)
- Company Name: Es el nombre de la compañía que diseña el proyecto de
visualización arquitectónica (en este caso FC por Facultad de
Construcciones)
- Product Name: El nombre del Proyecto diseñado o de la Herramienta en
general (en este caso INQUILINO VR). Este nombre, es el nombre de la
aplicación Android que se mostrará en el smartphone.
Otras configuraciones (Other Settings):
- Color Space: Gama
- Auto Graphics API: ON
- Multithreaded Rendering: ON
- Static Batching: ON
- Package Name: com.Company.ProductName
71
Este campo es obligatorio y define el nombre del paquete de la aplicación.
Es una identificación única para cada aplicación Android.
- Version: Numero de la versión
- Minimum API Level: Es la menor versión del SO Android soportada por la
aplicación. Un valor recomendable es Android 4.4 “Kit Kat” (API Level 19)
porque estadísticamente menor versión que los usuarios de Android tienen
actualmente (Madway, 2015)
Al terminar de definir los parámetros de las configuraciones se procede a compilar la
aplicación presionando el botón Build. Se abre una ventana para seleccionar donde
guardar el proyecto compilado y con qué nombre. Al finalizar, el proyecto es compilado
y se salva a disco la aplicación APK. Esta es instalada posteriormente en el Smartphone.
2.4 Interface de Inquilino VR
La interface gráfica de Inquilino VR está diseñada para ser sencilla e intuitiva.
No posee elementos que carguen la pantalla y utiliza colores neutros para dar
protagonismo al modelo arquitectónico.
Posee tres modos fundamentales:
Navegación en primera persona:
Muestra el proyecto arquitectónico desde la altura del observador (1.75 m
aproximadamente). No cuenta con ningún agregado gráfico para que la
experiencia sea lo más cercana a la realidad posible.
Al comenzar la presentación se muestra en pantalla un panel de ayuda con los
controles fundamentales para facilitar la comprensión del usuario.
El modo de navegación en primera persona permite caminar por el interior y el
exterior del modelo y abrir el menú.
72
Figura 1
Navegación en
Primera Persona
por el modelo de
pruebas
Fuente: Autor.
Vista aérea:
Muestra totalmente el modelo desde una vista superior. El modelo siempre está
en el centro de visión y si se rota la cabeza en 360º se puede observar
completamente desde todas las posiciones. Permite alejar o acercar la vista como
el efecto zoom de una cámara fotográfica. Los niveles se pueden ocultar o mostrar
en este modo para facilitar el entendimiento del espacio interior.
Figura 2
Navegación en
Vista Aérea por el
modelo de
pruebas
Fuente: Autor.
Menú
El Menú es una ventana emergente formada por cuatro botones dispuestos en
una rejilla que pueden ser presionados si la vista del usuario está sobre uno de
ellos y se presiona la tecla B del gamepad.
73
Figura 3
Interface gráfica
del menú.
Fuente: Autor.
Modo Día / Noche:
Permite alternar la forma de iluminación del modelo. Ya sea con
iluminación natural diurna o con iluminación artificial nocturna.
Tipo de Navegación (en primera persona / en vista aérea):
Alterna entre la navegación en primera persona o en vista aérea.
Utiliza una interpolación de movimiento para suavizar la transición.
Mapa:
Muestra la planta arquitectónica del modelo. Por defecto muestra la
planta donde te encuentras y permite cambiar entre niveles para
facilitar la comprensión.
Regresar:
Permite salir del menú.
74
Figura 4
Panel de ayuda
que se muestra al
iniciar la
aplicación
Fuente: Autor.
Conclusiones Parciales
Inquilino posee dos herramientas fundamentales: un plugin para 3ds Max
programado en MaxScript que realiza toda la preparación previa del modelo, y una
herramienta en Unity programada en C# usando además el SDK de Google
Cardboard, que define todo el funcionamiento de la aplicación para Android.
Es necesario instalar en el ordenador Unity 3d, 3ds Max, Android SDK y Java
Development Kit (JDK) para realizar todo el proceso de construcción de la
aplicación
La herramienta de Unity 3d es un proyecto de Unity (Unity Project). La misma está
formada por 18 scripts que definen todo su funcionamiento interno.
La herramienta es independiente del estilo de visualidad final, el cual es definido
por el usuario al aplicar materiales a su proyecto original, en este caso en el
software 3ds Max.
La herramienta para Unity 3d requiere que el desarrollador realice el baking al
objeto de navegación para la primera persona, etiquete los objetos de la escena
y compile la aplicación para Android.
La herramienta para el 3ds Max requiere una participación activa del desarrollador
a la hora de crear y seleccionar los elementos necesarios para el procesamiento
del modelo (materiales, objeto de navegación, planos de corte, etc).
75
Luego de compilar el proyecto se obtiene la aplicación Inquilino VR que requiere
ser instalada y ejecutada en un smartphone con sistema operativo Android en su
versión 4.4 o superior.
El producto final permite al usuario navegar en primera persona y en vista aérea,
cambiar el modo de iluminación (diurna o nocturna), abrir un mapa planimétrico
del proyecto, ocultar o mostrar niveles y hacer zoom en la vista aérea.
La interface gráfica de la aplicación de visualización arquitectónica para Android
es sencilla e intuitiva.
El panel de ayuda ofrece toda la información necesaria para comenzar el recorrido
arquitectónico sin experiencia previa.
El plugin para 3ds Max selecciona el objeto de navegación, los niveles de corte,
los layers de mobiliario, reconoce los cristales del proyecto, ubica el norte, exporta
un fichero en formato FBX con las texturas y dos documentos TXT con información
geométrica necesaria para la herramienta de Unity.
76
Capítulo 3 Uso de la herramienta Inquilino VR en un proyecto arquitectónico real
En el presente estudio se implementa la visualización a través de Inquilino VR del caso
concreto de un proyecto de rehabilitación arquitectónica de un estudiante de la Facultad
de Construcciones de la Universidad Central Marta Abreu de las Villas en su proyecto de
tesis. Con ello se ensaya el alcance real y práctico de esta herramienta y se detectan
particularidades de su implementación para un caso práctico.
El proyecto es la rehabilitación de la escuela primaria Hurtado de Mendoza ubicada en
el Boulevard de la Ciudad de Santa Clara y corresponde al Trabajo de Diploma del
estudiante de arquitectura Javier Valero Blanco presentado el mismo curso académico
en el cual el presente estudio se realiza. El modelo tridimensional para ser visualizado a
través de Inquilino VR es resultado del mencionado trabajo de diploma, modelado
originalmente por Javier Valero, y usado para el presente estudio con su aprobación para
este fin.
3.1 Ventajas de este proyecto para la presentación en realidad virtual
77
El proyecto de la rehabilitación de la escuela primaria Hurtado de Mendoza en concreto
es escogido para probar la herramienta Inquilino VR por varias razones:
Poseer más de un nivel. Permite el uso de la función de ocultar y mostrar niveles
durante la navegación exterior en tercera persona, el uso de la función de mostrar
la planta arquitectónica del nivel actual y el desplazamiento por superficies
inclinadas como escaleras o rampas.
Contar con grandes áreas donde no se interrumpa la vista y se logre un efecto
estereoscópico más evidente. Grandes espacios (como el patio central) brindan
una visión panorámica más limpia y una sensación de entorno mucho mayor que
en lugares pequeños.
Es un proyecto con estilo historicista con influencia neoclásica, lo que brinda
algunos elementos decorativos de interés como son la cornisa, el frontón, las
escocias del falso techo, las columnatas del patio central, las molduras de la
fachada y los altares de la galería principal. Estos rasgos de la arquitectura exigen
mayor potencia de cómputo que en proyectos más simples con menor conteo de
polígonos, y exponen posibles problemas de optimización del modelo.
Presenta una obra en fase de conceptualización. El nuevo monumento a José
Martí dentro de la escuela aún no se ha decidido por lo que a través de esta
aplicación se puede pre-visualizar y tomar una decisión en cuanto a la elección
final si se analiza integrado a al contexto real simulado.
La edificación cuenta con iluminación monumental nocturna. Puede ser probado
el modo día-noche de la aplicación Inquilino VR que permite visualizar el modelo
en estos dos horarios del día, y de esa forma evaluar el esfuerzo computacional
que el cambio de modo implica.
Cuenta con vegetación y gran cantidad de elementos arquitectónicos como
puertas y ventanas que dejan pasar la iluminación natural, así como elementos
antiguos y de nueva construcción, todo lo cual conforma una visualidad
interesante.
78
3.2 Características computacionales del modelo tridimensional original:
El modelo tridimensional del proyecto arquitectónico provisto por Javier Valero Blanco
fue originalmente modelado en SketchUp 2017 e importado posteriormente a 3ds Max
2017 con el objetivo de beneficiarse de las herramientas de iluminación de ese software
para una mejor visualización del mismo y la incorporación de modelos importados de
mobiliario y vegetación (Archimodels). La versión del modelo en 3ds Max tiene un total
de 7 471 381 polígonos solamente en el inmueble; y con todo el mobiliario y la vegetación
final un total 14 645 699 polígonos.
La cantidad de polígonos de ese modelo está por encima de las recomendaciones para
gestionar tiempo real en un teléfono móvil promedio. Para constatar el posible
rendimiento del software frente a un caso así se realizó, a modo de prueba, una primera
exportación del modelo desde 3ds Max para hacer un ensayo piloto en Inquilino VR y se
probó en tiempo real en la aplicación para Android en un SmartPhone con las siguientes
características:
Xiaomi,
Modelo: RedMi Note 4
Versión de Android: 7.0
Display: 5.5”, 1920x1080px, 480dpi
CPU: Octacore Max 2.0GHz
RAM: 3Gb
Almacenamiento: 32Gb Interno
Debido a que el objetivo de este ensayo del modelo era puramente para evaluar el
desempeño gráfico de la aplicación (pues es el único aspecto que se puede ver afectado
por un alto conteo de polígonos y a la vez es el aspecto más importante en el campo de
la realidad virtual), se omitió todo lo relativo a las cuestiones funcionales de navegación
(la exportación del navmesh), y la división del modelo en niveles con el fin de agilizar el
procedimiento. Esto es factible dado que en este caso específico la visualización
obtenida era para consumo interno y debugging por parte del desarrollador.
79
El resultado de esta prueba de visualización fue que el renderizado en tiempo real del
modelo fluctuaba entre los 11 y los 19 fps. La recomendación para visualización de 3D
en tiempo real en una pantalla de ordenador es de 30 fps, y para la realidad virtual puede
llegar a ser 60 fps. Por lo tanto, se determinó que, dadas las condiciones técnicas del
software Inquilino VR tal y como está implementado hasta el momento, no rinde
correctamente en el orden gráfico para un modelo como el provisto por Javier Valero si
no se modifica adecuadamente para la reducción de la carga poligonal.
3.3 Optimización del modelo arquitectónico 3D
Con el fin de hacer factible tecnológicamente el empleo del proyecto de rehabilitación de
la escuela primaria Hurtado de Mendoza para su visualización a través de la aplicación
Inquilino VR en su fase beta, se decidió implementar acciones de optimización del
modelo cuyo fin es reducir el conteo de polígonos de forma significativa para una
renderización más rápida en tiempo real.
La optimización poligonal debe ser efectuada de manera estratégica de forma tal que las
características visuales del modelo se afecten lo menos posible (o incluso, en teoría,
sean beneficiadas en algunos casos). Para cumplir con este objetivo es necesario
conocer bien las características del proyecto arquitectónico para lograr poner la
geometría modificada en función del modelo de manera correcta.
A continuación, se relacionan las características del modelo 3d del proyecto
arquitectónico empleado que son relevantes para las subsiguientes acciones de
optimización. Más adelante se relacionan las acciones de optimización en sí.
3.3.1 Selección de características del proyecto arquitectónico a tener en cuenta
para la modificación del modelo 3D.
La escuela primaria “Hurtado de Mendoza” se enmarca dentro del Centro Histórico donde
predominan los edificios de la 1ra y 2da mitad del siglo XX. Con dirección Esquina de
Independencia y Calle Lorda en el Consejo Popular Centro, dentro del Boulevard de
Santa Clara que constituye uno de los ejes de mayor importancia de la ciudad. Está
80
rodeado de edificaciones con valores arquitectónicos, ambientales y culturales, con
óptimas condiciones de ubicación y centralidad.
La escuela presenta dos colindancias una lateral y paralela con la calle Lorda con el
centro gastronómico Bar “La Cuevita” y otra en su parte posterior con una vivienda
particular.
El edificio es de estilo Neoclásico, cuyo concepto de belleza está basado en la pureza
de las líneas arquitectónicas, en la simetría y en las proporciones sujetas a las leyes de
la medida y las matemáticas. Reacciona contra los efectos decorativos del barroco y el
rococó y presenta un gusto por la sencillez, con predominio de lo arquitectónico sobre lo
decorativo. Emplea elementos básicos de la arquitectura clásica: columnas, órdenes
dórico y jónico, frontones, bóvedas, cúpulas, etc. El equilibrio, la simetría, las
ortogonales, la alternancia de vano y macizo, así como la sobriedad decorativa y la
síntesis de los detalles que adornan la fachada y el patio interior (en este caso el
equilibrio, las pilastras, las estructuras adinteladas, cornisa, pretil compacto, friso liso sin
decoración alguna), son la esencia del estilo empleado originalmente para su
construcción.
La edificación presenta una planta rectangular en forma de C, totalmente axial, con patio
interior rodeado de columnas y galería techada a ambos lados.
El proyecto incluye como añadidura un el segundo nivel construido con bloques de
hormigón y cubierta de hormigón armado, para lo cual se proyecta una escalera también
de hormigón armado.
Las rejas del segundo nivel se proyectan de nuevo tipo, con una alternativa más
racionalistas, con la concepción de buscar mayor entrada de luz y ventilación natural,
eliminándose las celosías que existen y cubriendo los grandes vanos con estas.
Como parte del proyecto se incluyen también falsos techos y escocias prefabricadas de
yeso acordes con la época del inmueble.
Toda la Carpintería es restaurada en el proyecto, quedando en su totalidad de madera
lacada oscura y cristales semitransparentes. Las puertas de los baños y cuartos de
limpieza tendrán en su parte inferior tablillas fijas para que no se conviertan en espacios
herméticos, sino que permita un intercambio de aire.
81
Todas las luminarias disponen de 2 o 4 lámparas fluorescentes de 40 w, 110 v, en
dependencia de la función de cada local.
Se incorpora un pequeño conjunto escultórico que hace las veces de busto de Martí,
donde aparece la figura del Apóstol y al lado del cual está el asta de la bandera de la
escuela.
Se emplea iluminación LED tanto para el exterior como para el interior con el objetivo de
reanimar la fachada del inmueble en horarios nocturnos, y a la vez, con este mismo tipo
de luminarias, realzar los elementos decorativos del patio interior, estrado y busto de
Martí.
Los locales en los cuales el mobiliario es relevante en el proyecto son:
Dirección
Subdirección
Administración
Laboratorio de Computación
Dos servicios sanitarios, uno para niños y otro para niñas.
Un servicio sanitario para profesores
12 aulas iguales con capacidad para 20 alumnos y un profesor
3.3.2 Optimización del modelo 3d teniendo en cuenta características del proyecto
3.3.2.1 Reducción del conteo de polígonos
La acción fundamental de la optimización del modelo 3d está encaminada a lograr un
modelo con un conteo de polígonos reducido en comparación con el modelo original,
debido a que el conteo de polígonos es el factor que mayor impacto tiene en la velocidad
de renderizado 3D en tiempo real con los algoritmos y herramientas usadas en Inquilino
VR (y usualmente en muchos softwares en tiempo real).
Dado que el modelo original es un modelo en 3ds Max, se emplean las herramientas que
permiten reducción de polígonos que ese software tiene.
82
La reducción del conteo de polígonos se puede hacer en 3ds Max de manera automática
o de manera manual. La reducción automática de polígonos permite conseguir modelos
de menor poligonaje mediante el empleo de herramientas cuyo uso es sencillo y rápido
pero cuya topología resultante es impredecible, mientras que la reducción manual de
polígonos exige por una parte mucha interacción por parte del usuario y resulta en
sesiones de trabajo más largas, pero donde se puede obtener un mejor control sobre la
topología. Los dos diferentes métodos se pueden combinar en la misma escena,
usualmente seleccionando cuales objetos en específico son sometidos a cuál de los
métodos.
3.3.2.1.1 Reducción del conteo de polígonos de forma automática
Para los objetos cuyo poligonaje se redujo de manera automática se empleó el
modificador de 3ds Max llamado ProOptimizer, que permite reformular las mallas de los
objetos estableciendo un límite de vértices a usar.
Se usó para los modelos de:
El busto de Martí. Su carácter de conjunto escultórico con forma geométrica
bastante irregular hace adecuado el empleo de la malla altamente triangulada que
produce el modificador ProOptimizer.
La bandera cubana, que cuelga del asta. Su forma irregular también admite bien
esa triangulación.
Las plantas y las flores.
En muchos de los grandes elementos constructivos que reflejan el estilo
neoclásico, al estar este muy basado en la pureza de las líneas y la simplicidad
geométrica de grandes superficies planas, en las cuales el algoritmo de
ProOptimizer genera particularmente buenos resultados. Esto es producto de que
la triangulación irregular no ofrece ninguna inconveniencia visual cuando las
superficies son coplanares, manteniendo la esencia de este estilo arquitectónico
(exceptuando el tratamiento a ornamentos como capiteles y escocias, que tuvo
que ser diferenciado por su complejidad geométrica).
83
3.3.2.1.2 Reducción de polígonos de forma manual
En los casos de los objetos que fueron intervenidos manualmente, se hizo mediante
operaciones de edición de polígonos usando la tecnología de Editable Poly de 3ds Max
que permite en gran medida (en la versión de 3ds Max 2017 o superior) preservar el
mapeo de texturas de modo tal que no hay necesidad posterior de reajustar las texturas
originales al objeto modificado.
Se usó para los modelos de:
Las nuevas rejas del segundo piso, que originalmente tenían una geometría muy
cargada. Se determina usar un método manual para su retopologización porque
se estima que se puede emplear una sección muy simple para los barrotes (de
cuatro lados luego de retopologizados) ya que una economía tan extrema de
poligonaje en ellos se justica por el hecho de ser observados fundamentalmente
desde abajo y de lejos (desde el suelo del primer piso)
En los muebles, puesto que el conteo de muebles totales planificados para el
proyecto es muy alto, de modo que era eficiente el hecho de conseguir una
reducción controlada y extremista de los polígonos de los mismos, cuyo efecto de
economizar geometría aumentaría con la repetición del mueble. En este caso se
trabajó eliminando incluso polígonos que nunca estarían al alcance de la vista del
observador, como los de las superficies inferiores de los muebles, ya que en
Inquilino VR la cámara nunca desciende por debajo del nivel de un observador
promedio (no es posible agacharse, por ejemplo).
En todos los cristales, eliminando la división inicial en grilla innecesaria (muchos
softwares de modelación 3D generan los planos por defecto con una
cuadriculación rectangular adicional) y también la doble clara ya que el objetivo
de los mismos es ser semitransparentes según las ideas del proyecto, efecto que
minimiza la necesidad de simular una refracción “física” y se puede trabajar como
un simple polígono con alfa (transparencia) media.
En las escocias, donde a cada arco de la sección de las mismas se les dio
solamente tres segmentos, lo cual es aceptable al ser vistas desde abajo y ser el
puntal bastante elevado.
En los dinteles, por la misma razón.
84
En las persianas de tablillas fijas, también originalmente muy subdivididas,
forzándolas a tener una sección rectangular cada una sin subdivisión axial.
En la escalera que conduce al segundo nivel, que al estar concebida de hormigón
armado admite una remodelación aproximativa donde queda con aristas cortantes
y cero subdivisiones en las superficies coplanares.
3.3.2.1.3 Anulación de modelos del mobiliario serializados
Al tratarse de una escuela, existe mucho mobiliario repetido, especialmente aquellos que
están orientados a los alumnos. Según las características del proyecto, el modelo de aula
es el mismo para las doce aulas existentes, de modo tal que existe una reiteración del
mobiliario. Ya que todas las aulas están planificadas para ser iguales, se decidió dejar
mobiliario en sólo una de ellas que sirva como modelo, privando del mismo al resto de
las aulas. Esto es debido a que, incluso empleando modelos altamente optimizados, la
cantidad total de sillas y mesas de estudiantes acumula un conteo de polígonos elevados
que no aparecería en proyectos de otro tipo.
3.3.2.1.4 Eliminación de modelos innecesarios
Debido a la ubicación de la escuela primaria “Hurtado de Mendoza” y el entorno
circundante, se determinó que, según el estilo de la edificación y la propuesta formal del
proyecto, la inclusión de los edificios aledaños y/o contiguos es lo suficientemente
prescindible como para permitir su eliminación en aras de la optimización del proyecto.
Los edificios cercanos aportan poco a la apreciación de la obra. Solamente se mantuvo
la geometría de la calle circundante con un alcance tal que el observador en primera
persona pudiera apreciar bien la fachada, particularmente de noche donde la iluminación
juega un papel importante.
3.3.2.2 Resultado de la optimización geométrica
Luego de todas las acciones destinadas a la reducción del conteo de polígonos, el
modelo quedó con 477 682 polígonos.
85
3.3.2.3 Tratamiento de materiales y luces
Debido a que el cómputo de luces y sombras en combinación con efectos de shaders
(materiales) suele ser costoso en el orden computacional, también se decidió optimizar
el modelo en este sentido para contribuir más, junto con la reducción de polígonos, a la
eficiencia del renderizado.
Para anular el cómputo de luces se empleó la técnica Texture Baking, con la cual el
efecto de las luces y las sombras sobre la geometría de “pinta” en una textura adicional,
de modo tal que la iluminación se considera en lo adelante pre-calculada y no existe la
necesidad de procesarla más.
La cantidad de luces nuevas que tiene el proyecto, y lo relevantes que son para el mismo,
exigen un tratamiento diferenciado para las superficies geométricas que sean emisivas,
(por ejemplo, los tubos de luces fluorescentes) al implementar Texture Baking. A las
mismas se les asignan colores explícitos que reflejan de manera exacta la apariencia
que se desea que esa superficie tenga en el renderizado en tiempo real, puesto que
usualmente su valor real en cuanto a intensidad de color excede mucho la intensidad
representable en LDR (Low Dynamic Range) del 3D de tiempo real para teléfonos
móviles.
También el hecho de que, incluso durante el día, la iluminación de los interiores del
proyecto arquitectónico está planificado para ser una combinación entre luces naturales
y artificiales, permitió usar un nivel de exposición único ponderado para el pre-render del
Texture Baking, lo cual facilita mucho el proceso, acelerando el pre-cálculo de todos los
gráficos que quedan plasmados en texturas.
3.4 Uso de la herramienta Inquilino con el modelo de proyecto optimizado
3.4.1 Creación y selección del objeto de navegación
El objeto de navegación es un modelo geométrico de 3ds Max, comprende los dos
niveles navegables de la edificación unidos por la escalera que es el único acceso al
segundo nivel. El objeto resultante en este caso posee 126 polígonos.
86
Este objeto cubre toda el área navegable por la primera persona excluyendo la
proyección en planta de los muros, las columnas de la galería del patio, las rejas fijas y
el mobiliario (todos los elementos que no deben ser traspasables mientras se navega).
Se tiene el cuidado de dejar abierto el área de las puertas para permitir el acceso a los
locales.
La escalera se resuelve como una rampa, con un plano inclinado simple (sin tener en
cuenta los escalones) que sigue la forma general de la escalera. El objeto de navegación
de la primera persona es un solo elemento (una malla única y continua) Esto asegura la
correcta generación del Navigation Mesh (navmesh).
3.4.2 Creación y selección de los planos límites de cada nivel
Los planos de corte se crean y seleccionan en función del falso techo, los diferentes
entrepisos y cubiertas de la solución. En el caso de este proyecto fueron creados dos. El
primero, debajo del falso techo del primer nivel y el segundo debajo de la cubierta del
segundo nivel.
3.4.3 Selección de los layers de mobiliario
En el caso de este proyecto existe un layer de mobiliario que se selecciona en la última
fase del proceso de preparación previa para su identificación dentro del sistema Inquilino.
Sin embargo, dado que la funcionalidad de manejo de layers no está completada en el
producto de Unity 3d (está pendiente su implementación en el futuro), esta acción no
tiene ningún impacto para este caso específico. En el futuro se podrá reusar los datos de
exportación de este modelo para interacción con layers del mobiliario una vez resuelto
este problema.
3.4.4 Procesamiento final del modelo
El procesamiento final del modelo y la exportación de las texturas y del fichero en formato
FBX tardó aproximadamente 2 minutos. La reducción del tiempo que tardó el plugin de
3ds Max en procesar el modelo se redujo notablemente con respecto a la prueba con el
modelo sin optimizar, dado que en un inicio este tardó 37 minutos.
87
El fichero FBX que contiene el modelo ocupa en disco un total de 20.4 MB y las texturas
resultantes son 116 en total y ocupan 131 MB.
3.4.5 Bakeo del NavMesh
El bakeo del Navegation Mesh se realizó correctamente. Todas las áreas quedaron
conectadas, lo que demuestra que el trabajo realizado a la hora de crearlo fue
satisfactorio.
3.4.6 Etiquetado de los elementos de la escena
Se generaron 134 elementos divididos en tres grupos correspondientes a las tres
divisiones por niveles: primer nivel, segundo nivel y cubierta.
Un total de 132 elementos fueron asignados con la etiqueta MODEL y dos elementos
con la etiqueta GLASS correspondiente los cristales del primero y segundo nivel.
3.4.7 Compilación de la aplicación para Android
La aplicación para Android resultante ocupa en disco un total de 129.5 MB y tardó 5
minutos en terminar de compilarse, porque era necesario comprimir las 116 texturas con
el método ETC.
Todas estas operaciones fueron realizadas en un ordenador con las siguientes
características técnicas:
CPU: i7-2400K (a 3.0 GHz)
GPU: NVIDIA GeForce™ GTX 630
RAM: 8GB DDR3
Sistema Operativo: Windows 10 Pro
88
3.5 Resultados de Inquilino VR con el proyecto a presentar
La aplicación instalada en el celular ocupa un total de 146 MB de almacenamiento en la
tarjeta Interna, no requiere base de datos adicional y es totalmente compatible con el
Xiaomi RedMi Note 4, teléfono usado para la ejecución.
Figura 5
Pantalla Principal del smartphone con la
aplicación Inquilino VR
Fuente: Autor.
La calidad de visualización escogida en Unity para dispositivos móviles fue (Good), que
garantiza que no existan pérdidas notables durante la compresión de las texturas y
sacrifica en su lugar cálculo de sombras suaves, característica que no es utilizada en
esta aplicación.
Se utiliza un anti-aliasing de 2x para garantizar terminaciones suaves en los bordes.
89
El rendimiento de la aplicación fue medido en distintas partes del modelo, donde la
cantidad de polígonos mostrados era variable. Estas mediciones indican que el rendereo
en tiempo real fluctuaba entre los 51 y 60 fps.
Figura 6
Navegación en
Primera Persona
por la escuela
Hurtado de
Mendoza.
Fuente: Autor.
Figura 7
Navegación en
Vista Aérea por la
escuela Hurtado
de Mendoza.
Fuente: Autor.
Conclusiones parciales:
Para la presentación y prueba de la herramienta Inquilino VR se empleó un
proyecto arquitectónico real: “Rehabilitación de la escuela primaria Hurtado de
Mendoza” cuyas características se determinaron como convenientes para hacer
la prueba piloto de la herramienta.
90
Se demostró que la herramienta Inquilino VR no puede, en su fase actual, importar
modelos computacionales con una gran densidad de polígonos porque el
rendimiento se afecta drásticamente. Es necesaria una optimización previa.
Para una optimización acertada y eficiente del modelo con vistas a mejorar el
rendimiento es necesario tener en cuenta una selección de características del
proyecto arquitectónico en cuestión con las cuales debe contribuir las acciones de
optimización
La forma fundamental empleada para la optimización del modelo arquitectónico a
emplear fue la reducción del conteo de polígonos.
El empleo de la técnica de texture baking contribuyó también a mejorar la
velocidad de renderización en tiempo real.
Para una visualización correcta de la realidad virtual se sugieren una velocidad de
rendereo de 60 fps. Con el modelo optimizado se lograron de 51 a 60 fps y con el
modelo sin optimizar de 11 a 19 fps.
Para la ubicación de los planos límites de nivel se tuvo en cuenta la posición del
falso techo y de la cubierta para que estas no entorpezcan la visualización del
interior de la edificación.
Se generó un objeto de navegación en primera persona (navmesh) de 126
polígonos que permite restringir el movimiento en primera persona del observador
por los lugares transitables del modelo arquitectónico.
Se generó, para el uso de la realidad virtual, una aplicación para sistema operativo
Android llamada Inquilino VR cuyo espacio en disco es de 146 Mb.
La aplicación fue probada en un solo dispositivo, un Smartphone de gama media-
alta de marca Xiaomi, modelo RedMi Note 4.
91
Conclusiones
De las tecnologías disponibles para la visualización de gráficos 3d en tiempo real
e implementación de Realidad Virtual con estereoscopía, se determinó que las
más adecuadas para las condiciones de los profesionales cubanos y en particular
para la extensión del proyecto Inquilino son el empleo de Unity 3d con SDK de
Google CardBoard para sistema Android, y programación en lenguaje C#.
La aplicación creada se llama Inquilino VR y tiene las siguientes características:
- Extiende las funcionalidades de una herramienta para visualización de
proyectos arquitectónicos previamente construida (Inquilino 1.0 beta)
- Emplea un smartphone montado en un casco de tipo smarthphone display
para la generación y visualización de gráficos.
- Emplea el dispositivo gamepad bluetooth para la interacción del usuario
con el modelo arquitectónico y la navegación dentro del mismo.
- Requiere del empleo de modelos optimizados en relación con los modelos
que normalmente se generan del uso de los softwares de creación de
arquitectura 3D.
- Admite la mayoría de las características visuales del modelo 3D tal y como
se elabore en 3ds Max.
- Permite la exploración del modelo arquitectónico 3D mediante el tránsito
por el mismo en primera persona y también la observación en vista aérea.
- Permite la comparación entre las condiciones de iluminación diurna y
nocturna del modelo arquitectónico 3D.
- Ofrece una ayuda para que el usuario pueda comprender la interacción con
el programa.
- Es capaz de distinguir entre los distintos niveles que componen la
edificación 3D y usar esa información para eliminar pisos en la vista aérea
e inspeccionar el interior del edificio.
92
La herramienta Inquilino VR está compuesta por dos sub-herramientas
fundamentales que hay que usar en combinación para lograr el funcionamiento de
la solución completa: una herramienta programada creada para 3ds Max y otra
creada para Unity 3d, que contienen la implementación de los algoritmos
necesarios.
La herramienta Inquilino VR necesita, para su correcto funcionamiento,
implementar de manera general algoritmos de exportación de modelos 3D, texture
baking, reducción de conteo de polígonos, generación de gráfico estereoscópico,
definición de navmesh, alguno de los cuales no se encuentran automatizados en
el momento presente.
La parte programada de Inquilino VR incluye, como resultado, cuatro scripts en
lenguaje MaxScript para la parte de 3ds Max con aproximadamente 330 líneas de
código, y 18 scripts en lenguaje C# para la parte de Unity 3d con aproximadamente
2150 líneas de código.
Para la presentación y prueba de Inquilino VR se emplea el modelo arquitectónico
de la rehabilitación de la escuela primaria Hurtado de Mendoza ubicada en el
Boulevard de la Ciudad de Santa Clara y correspondiente al Trabajo de Diploma
del estudiante de arquitectura Javier Valero Blanco en 2018. El mencionado
proyecto no fue elaborado originalmente con vistas a ser empleado con Inquilino
VR.
93
Recomendaciones
Insertar el uso de Inquilino VR en la Facultad de Construcciones de la UCLV para
ser usado con más proyectos de la misma dentro de la práctica docente.
Definir posibles características nuevas de interacción que enriquezcan a Inquilino
VR como producto y que sirvan a los intereses de los profesionales y estudiantes
de arquitectura que lo empleen.
Elaborar una forma de navegación en el modelo virtual que permita prescindir del
gamepad bluetooth para la interacción del usuario con el modelo arquitectónico.
Implementar el uso de Inquilino para modelos elaborados en otros softwares de
creación 3D de uso común por arquitectos y estudiantes de arquitectura, como
Revit, Sketchup, ArchiCAD, etc.
Automatizar más rasgos del procedimiento de exportación de modelos
tridimensionales hacia Unity 3d para Inquilino VR, pues todavía es un
procedimiento complejo.
Automatizar progresivamente los procedimientos de optimización del modelo
virtual que recibe la aplicación de Unity 3d con el objetivo de que el profesional
tenga que emplear el menor tiempo posible en tareas de optimización manuales.
94
Bibliografía
1. Fotogrametría. CEFOCCA, UNSJ.
2. . "Java SE Offical Web Site." Retrieved 17 de marzo, 2018, from www.oracle.com/technetwork/java/javase/overview/index.
3. (1995). Realidad Virtual. Glosario de Términos de Realidad Virtual. D. I. d. R. V. T. 1.
4. (2014). "Gamasutra." Retrieved 16 de marzo, 2018, from http://www.gamasutra.com.
5. (2015). "Android SDK Glossary." Retrieved 2 de mayo, 2018, from www.developer.android.com/guide/appendix/glossary.
6. (2015). "Open Source Java." Retrieved 8 de abril, 2018, from www.community.java.net/jdk/opensource.
7. (2015). "Pluralsight." Retrieved 5 de mayo, 2018, from http://pluralsight.com.
8. (2015). "Realidad Virtual y Arquitectura." Retrieved 26 de marzo, 2018, from https://www.tworeality.com.
9. (2016). Qué es la VR: historia y tipos de gafas de realidad virtual. Mediatrends.
10. (2016). "Realidad Virtual en la arquitectura." Retrieved 17 de abril, 2018, from https://www.uniat.com.
11. Agreement, U. E. U. L. (2010). "Unity." Retrieved 27 de abril, 2018, from http://unity3d.com/unity/unity-end-user-license-3.x.
12. Álvares, J. A. (2011). "La espada de Damocles." Retrieved 15 de abril, 2018, from http://rvjaac.blogspot.com/2011/08/la-espada-de-damocles-ivan-sutherland.html.
13. Archdaily (2016). "Iris Prospect: Herramienta convierte modelos 3D en realidad virtual." Retrieved 17 de mayo, 2018, from http://www.costosperu.com/noticias/iris-prospect-modelos-3d-virtual/.
95
14. Armory3d (2018). Retrieved 16 de abril, 2018, from www.armory3d.org.
15. Colado, S. (2016). "Análisis de Samsung Gear VR: bienvenido al mundo real." Retrieved 21 de marzo, 2018, from http://www.androidpit.es.
16. Correa, E. (2017). "Breve historia de la Realidad Virtual." Retrieved 24 de marzo, 2018, from www.linkedin.com.
17. Cruz, M. V. (2017). "Realidad virtual. Una sacudida al mundo de la arquitectura." Retrieved 14 de febrero, 2018, from http://www.3dfonik.com.
18. Developers, A. (2014). "SDK Tools." Retrieved 2018, from www.developer.android.com.
19. Dougherty, C. (2015). Google Intensifies Focus on its Cardboard Virtual Reality. New York Times.
20. Edgar, G. K. (1995) Simulated and Virtual Realities: elements of perception. Vision and display,
21. Fowle, K. (2015). "The Vanguard of Virtual Reality: An Embarrassing Arcade Game." Retrieved 18 de marzo, 2018, from www.theatlantic.com.
22. Friedman, T. (1995). "Making sense of software: computer games and interactive textuality." S. G. Jones. Retrieved 28 de febrero, 2018, from http://www.duke.edu/tlove/simcity.htm.
23. Gartner (2013). "Smartphone Sales Accounted for 55 Percent of Overall Mobile Phone Sales in Third Quarter of 2013." Retrieved 4 de mayo, 2018, from http://www.gartner.com/newsroom/id/2623415.
24. Greenberg, K. (2012, 22 de mayo). "Stereo Realist Guide." Retrieved 28 de marzo, 2018, from http://www.digitalstereoscopy.com.
25. Kahn, J. (2011). "The Visionary." The New Yorker.
26. Kerpelman, T. (2015). "How to Make a VR Game with Unity." Retrieved 21 de marzo, 2018, from www.raywenderlich.com.
27. Kruger, M. (1991). Realidad Artifical II, Addison-Wesley Profesional.
28. Leal Carrazana, G. (2016). Inquilino 1.0 Beta: Elaboración de software para el análisis y presentación
29. interactiva de proyectos arquitectónicos. Facultad de Construcciones, UCLV: 88.
30. Leslie, B. (2007). Native C Aplication for Android. Benno's Blog.
96
31. Lippman, A. "The Aspen Movie Map." Retrieved 16 de marzo, 2018, from www.inter-doc.org/indice/the-aspen-movie-map.
32. López, M. C. (2012). Realidad virtual y Robótica.
33. Madway, G. (2015) Android hits top sport in U.S. smartphone market.
34. Martín, P. A. (2016). "¿Quieres realizar realidad virtual para arquitectura?". Retrieved 14 de abril, 2018, from www.icarasarquitectura.com.
35. Medina, E. (2017). "Armory 3D es un prometedor motor de juegos 3D que se integra en Blender." Retrieved 14 de abril, 2018, from www.muylinux.com.
36. Micó, J. L. (2017). "Realidad virtual en la arquitectura: no se imagine su casa, entre en ella." Retrieved 15 de marzo, 2018, from http://www.lavanguardia.com.
37. Mortonheilig. "Telesphere Mask." Retrieved 7 de abril, 2018, from www.mortonheilig.com/TelesphereMask.pdf.
38. Nagata, K. (2009). "Nintendo secret: It's all in the game." The Japan Times.
39. Navas, M. Á. (2016). "Gafas Realidad Virtual." Retrieved 24 de abril, 2018, from www.profesionalreview.com.
40. Nobel-Jørgensen, M. (2010). "Morten Nobel´s Blog." Retrieved 22 de marzo, 2018, from http://www.mortennobel-blog.com.
41. Ortega, J. L. (2016). "Un repaso a la historia de la Realidad Virtual." Retrieved 25 de marzo, 2018, from http://es.ign.com/realidad-virtual/109691/feature/un-repaso-a-la-historia-de-la-realidad-virtual.
42. Pepicq, B. (2017). "¿Por qué nos mareamos jugando con la Realidad Virtual?". Retrieved 14 de marzo, 2018, from www.androidpit.es.
43. Porter, M. (2010). "Media Design School website." Retrieved 12 de abril, 2018, from http://www.mediadesigns-chool.com.
44. Quinion, M. (2015). "Joystick." World Wide Words.
45. Requirements, U. S. "Unity." 18 de marzo, from http://unity3d.com/unity/system-re-quirements.html.
46. Rheingold, H. (1992). La realidad virtual. New York, Simon & Schuster.
47. Ripton, J. T. (2014). "Google Cardboard: everything you need to know." Techradar. Retrieved 18 de abril, 2018, from www.techradar.com.
97
48. Robertson, A. M., Ross (2017). "Daydream is Google's Android-powered VR platform." The Verge.
49. Roehl, B. (1997). Late Night VRML 2.0 with Java. Ziff Davis Press.
50. Sanz, M. (2015). "Proyectando arquitectura con tecnología de realidad virtual." Retrieved 23 de abril, 2018, from https://www.arquitecturayempresa.es.
51. Schroeder, S. A. (2011). Adopting Game T echnolog y for Architectural. I. P. e-Pubs.
52. Selzer, M. A., Elisabet Modelos de Interacción y Aplicaciones en Realidad Virtual mediante Dispositivos Móviles.
53. Sheffield, B. (2006). "Wii Reactions: Developers Comment." from http://www.gamasutra.com.
54. Westfall, J. (2009). "Backup & Restore Android Apps Using ADB ". Retrieved 3 de abril, 2018, from www.JonWestfall.com.
55. Whyte, J. (2002). Virtual reality and the Built Enviroment. Great Britain.
56. Worrydream. "The Ultimate Display." 11 de marzo, from www.worrydream.com/refs/Sutherland%20-%20The%20Ultimate%20Display.pdf.
