informe de práctica en

UNIVERSIDAD TÉCNICA FEDERICO SANTA MARÍA

DEPARTAMENTO DE ELECTRÓNICA

Informe de Práctica

en

Nexar S.p.A.

Presentado por: Jose Borquez Gaete

Fecha: 02/04/2021

01¥


1

INFORME DE PRÁCTICA

1. Información General

1.1 Alumno

Nombre completo: Jose Ignacio Borquez Gaete Domicilio: Conquista 635, Valparaiso E-mail [email protected] Teléfono: 977095690 Rol USM: 201521025-K Carrera: Ingeniería Civil Electrónica Curso: 6to año Tipo de Práctica: Profesional Fecha de inicio: 18/01/2021 Fecha de término: 19/03/2021 Duración (nro. de semanas): 9

1.2 Empresa

Nombre: Nexar S.p.A. Dirección: Bustos 2410, Santiago Teléfono: +562 3207 2143 Fax: RUT: 76.459.028-7 Dirección Web: www.nexar.cl

1.3 Supervisor

Nombre: Cristian Hernandez Cargo: Director Comercial Oficio o profesión: Desarrollador de Software Teléfono: +56 9 8450 9105 E-mail: [email protected]

→


2

2. Resumen Ejecutivo

El objetivo principal de la práctica consistió en realizar una serie de mejoras a un proyecto ya implementado, así como su limpieza general y optimización, abierto también a sugerencias por parte del practicante. La práctica se realizó en su totalidad mediante teletrabajo, con reuniones varias reuniones semanales por videollamada para mostrar los avances, y la continua asistencia del supervisor. Además de esto, el practicante visito de manera presencial las oficinas de Nexar S.p.A. en Santiago en 3 ocasiones. La primera, para iniciar la practicar, obtener la capacitación inicial, y recibir los equipos necesarios, la segunda, a mitad de la práctica para realizar una muestra presencial de los avances, y la tercera, al finalizar la práctica, para dar una prueba presencial de todas las mejoras desarrolladas, y devolver los equipos. El proyecto “PROBADOR VIRTUAL”, desarrollado en UNITY3D, presenta una alternativa para la prueba de prendas de vestir, creando un entorno de realidad aumentada, donde el usuario, situado frente a una cámara Kinect, puede verse a sí mismo en la pantalla, usando prendas de vestir virtuales, correctamente situadas sobre el usuario de manera 3D. Esta ropa virtual se ajustaría a las dimensiones y medidas del usuario de manera correcta, y no sería una imagen de la prenda sobre la imagen del usuario. La idea del proyecto es que el usuario pueda moverse con naturalidad en la escena, así como girar o cambiar de pose, y que la prenda virtual se ajuste a los movimientos. Durante la primera etapa de la práctica, el practicante se dedica a realizar en proyectos independientes, una serie de mejoras al proyecto, con algunas de ellas ya implementadas, pero que requieren ser mejoradas. La principal mejora a implementar corresponde a la Mascara Inversa y Mascara Directa, soluciones que buscan lograr ocultar los excedentes de ropa del usuario cuando se sitúa la ropa virtual sobre la imagen. El practicante además realizó mejoras al algoritmo de Blend de profundidad, cambios al algoritmo de Push para la detección de interacción con manos, cambio al efecto Blur, propuso un mecanismo totalmente nuevo para manejo manual de los parámetros de color y luminosidad del sensor, y desarrollo inicial de un mecanismo para controlar la aplicación de manera remota utilizando un dispositivo móvil Android. La segunda etapa de la practica consiste en incorporar todas las mejoras anteriores al proyecto ya implementado, así como la optimización y limpieza del código. Durante esta etapa, también se analiza la posibilidad de mejorar la arquitectura, tal de poder incluir una cantidad arbitraria de prendas a futuro. Esta idea fue descartada luego de una reunión con el desarrollador original del proyecto, quien confirmo que para realizar lo anterior, era necesario un cambio completo a la arquitectura del proyecto. Durante el desarrollo de la práctica, el practicante cumplió con los objetivos asignados, entregando todos los proyectos independientes de la primera etapa en proyectos compilados, y presentando de manera presencial el proyecto final con todas las mejoras incorporadas.

←-

I

-

I• 1


3

Actividad del Lugar de Trabajo

Nexar S.p.A. es una empresa comprometida con sus clientes y sus necesidades, con tal de potenciar la sustentabilidad de su negocio, ofreciendo soluciones y recursos tecnológicos innovadores de última generación, y de esta manera presentarse como un partner confiable que agrega valor y competitividad a la actividad empresarial. La confianza de sus clientes junto a la alta calidad de su aporte avala sus servicios, lo que a su vez permite a la empresa ser lucrativa y competitiva en el mercado existente. Actualmente, Nexar S.p.A. se encuentra trabajando en el desarrollo de nuevas tecnologías de realidad aumentada, específicamente en lo que es la generación de avatares virtuales que imiten la complexión y color de piel de los usuarios, a partir de fotos o video a tiempo real, lo que permite a futuro trabajar de una manera más simple la interacción entre componentes virtuales, y su presentación en imagen o video a tiempo real.

3. Organigrama de la Empresa

4. Preparación para la práctica

Uno de los tópicos más importantes durante el desarrollo de la práctica, y que fue indicado como requisito de entrada en la oferta de práctica, fue el conocimiento de Programación Orientada a Objectos. El proyecto en su totalidad esta desarrollado en la plataforma Unity, la cual se programa en lenguaje C#, por lo que el conocimiento de este lenguaje fue fundamental para el correcto desarrollo de la práctica.

Figura 1. Organigrama de la Empresa

• I


4

Otro de los tópicos que fue de gran utilidad, fue haber cursado el ramo Análisis de Imágenes, durante el intercambio en Lund, Suecia, ramo que fue convalidad por Procesamiento Digital de Imágenes. Ya que el proyecto se basa en la obtención de imágenes a tiempo real, tener la terminología y conceptos asociados al procesamiento de imágenes fue de gran utilidad.

5. Sugerencia de Proyecto Innovador

Dentro del contexto de pandemia actual, el mayor problema para el desarrollo de la practica fue el teletrabajo. En conversaciones con el supervisor, el practicante le comenta que uno de los mayores desafíos, fue el tener que realizar las tareas sin mayor interacción con los demás trabajadores de la empresa, interacción normal en contexto de una oficina de trabajo en situaciones normales. Si bien existe un canal de comunicación de la empresa via Discord, la gran mayoría de las interacciones ocurrían en reuniones privadas, por lo que el practicante no tuvo contacto alguno con los demás trabajadores. Esto provoco que el avance y la búsqueda de información fuera más lento por parte del practicante. El practicante propone, considerando la situación actual, reuniones semanales abiertas con los demás trabajadores de la empresa. Esto tiene dos motivos principales. El primero, permite a cada trabajador conocer el trabajo de los demás trabajadores de la empresa, lo que aumenta la interacción, y posibilidad de generar opinión respecto al trabajo hecho. Segundo, funciona como presión para cada trabajador, tanto para mejorar el trabajo realizado de manera semanal, así como para generar la necesidad de entender y poder expresar, de manera más clara, el trabajo que se está realizando.

ANEXOS

Se adjuntan los 2 informes técnicos presentados a la Empresa, los cuales describen el funcionamiento de las mejoras realizadas al proyecto “PROBADOR VIRTUAL”, y su uso en el proyecto.

✓

' l

- l

Mejoras al Proyecto “Probador Virtual” Jose Borquez

Marzo - 2021

INTRODUCCIÓN Este documento describe las mejoras incorporadas al proyecto “Probador Virtual V2.0”, realizadas por el practicante Jose Borquez en el periodo Enero-Marzo 2021.

Todas las mejoras han sido compiladas y probadas, y han sido enviadas en proyectos independientes con su respectivo código fuente al supervisor.

MASCARAS 3D Y FONDO FALSO Uno de los desafíos del proyecto “Probador Virtual”, es poder ajustar la imagen de las prendas de ropa sobre el usuario, sin dejar excedentes fuera del espacio que la prenda esta cubriendo. Esto significa, que el proyecto debe ser capaz de ocultar, de manera eficiente, toda parte del usuario, que se encuentre fuera de la prenda que el usuario se esta probando.

La propuesta de solución consiste en usar Mascaras 3D, situadas en puntos específicos sobre el usuario. Específicamente, se utilizara las funcionalidades de la cámara Kinect Azure, que permite obtener tanto la profundidad de la imagen, como la posición y orientación de distintos “joints” del usuario en la escena, tales como la ubicación de las manos, brazos, piernas, cabeza, etc. Usando esta información, se busca ubicar mascaras 3D sobre la imagen en tiempo real, tal de cubrir (o mostrar) las partes deseadas. Ante esto se proponen dos mecanismos, denominados “Mascara Directa” y “Mascara Inversa”, los cuales ambos dependen de un fondo guardado previamente, denominado “Fondo Falso”.

FONDO FALSO Corresponde a una imagen obtenida por el sensor, donde no existe ningún usuario presente. Busca representar el fondo limpio de la escena, a usarse con las máscaras.

Es manejado por el objeto FakeBackground, el cual contiene dos clases encargadas de generar el fondo falso

fakeBackground: Se encarga de obtener la imagen del sensor cuando no existe usuario presente. Para esto, esta clase implementa un buffer circular, el cual va actualizando el dato mas antiguo imágenes nuevas donde no se encuentre usuario en escena. Por defecto, esta clase guarda la textura cada 8 frames del sensor. Ya que el sensor opera a 30FPS, esto corresponde a una nueva textura cada 266 ms.

Esta clase tiene 2 parámetros públicos, a modificar desde el editor de Unity. textureNumber define el tamaño del buffer circular. Por defecto tiene un valor de 32 texturas, lo que equivale a 8.5 segundos de imágenes. keepSavingTextures define si la clase volverá a tomar texturas aun si el usuario ya ha entrado y salido de escena. Con este parámetro en true, cuando el usuario salga de escena, la clase seguirá actualizando el buffer circular, obteniendo nuevas texturas.

r

2

userTexture: Se encarga de cambiar el fondo según corresponda. Si no hay usuario en escena, el fondo muestra la imagen a tiempo real obtenida por el sensor. Si aparece el usuario, el fondo muestra el fondo falso obtenido por fakeBackground. Esta clase además, tiene una referencia al maniquí virtual, por lo que cuando el usuario sale de escena, el maniquí virtual se desactiva, y solo se ve el fondo a tiempo real.

MASCARA DIRECTA Consiste en ubicar la imagen de la silueta del usuario, sobre el fondo falso. Este mecanismo permite ocultar toda imagen “fuera” del usuario.

Se genera a partir del Shader “ShaderGraphs/MaskShader”, el cual toma una textura base, y la aplica sobre un objeto 3D, usando la técnica de screenSpaceTextures. Esto significa que la textura se aplica a la totalidad de la pantalla, pero solo es visible en los lugares donde el objeto al que se ha aplicado el shader, es visible.

MASCARA INVERSA Consiste en ubicar el fondo falso, dentro de la silueta del usuario, y la imagen en tiempo real en el exterior. A este mecanismo se le agrega una tercera capa, la cual tiene la imagen a tiempo real, y la forma de un maniquí con las medidas del usuario, previa una etapa de calibración. Este mecanismo tiene la ventaja de que puede cubrir los excedentes que puedan ocurrir por ropa muy holgada, pero tiene la desventaja de depender de la calibración de un maniquí virtual.

Se genera a partir de la clase BackgroundRemovalManager, en el objeto UserRemoval. Esta clase, implementada en las demos de Kinect, se encarga de detectar donde se encuentra el usuario, aplicando Alpha igual a 0 en todo el exterior. Para generar la máscara inversa, se utiliza el bool invertAlphaMask, que produce el efecto contrario, es decir, Alpha igual a 0 donde se encuentre el usuario, y 1 a todo el exterior. Al estar este objeto ubicado entre las máscaras y el fondo falso, se genera la máscara inversa.

Esta clase ha sido modificada para poder modificar sin limites las iteraciones de la dilatación. La dilatación permite aumentar el área donde se ha detectado el usuario, eliminando mayor parte de la imagen. Ya que el sensor de profundidad es de menor resolución que el sensor de color, dejar este valor en 0 puede producir que se vea el borde de la silueta del usuario, lo cual no es deseable. Aumentando el valor de la dilatación, es posible corregir esto. además, es posible modificar el color que tendrá la dilatación, o dejarla transparente si así se desea, cambiando el valor de Alpha a 0. Para esto hay que modificar bodyContourColor.

ESCENAS MASCARA CON OBJETOS 3D: Las mascaras se generan con objetos 3D sobre los joints deseados. En la escena, los joints de ambas manos y la cabeza están seleccionados por defecto. Se pueden agregar más joints de interés modificando el script OverlayScript, en el objecto MaskOverlay.

3

Ilustración 1 Mascara por objetos 3D

MASCARA 3D POR MANIQUI VIRTUAL: La mascara se genera en su totalidad en la superficie del maniquí virtual (Situado bajo el objeto ManiquiEjemplo->FemaleBs). Con esto, es posible ver casi en su totalidad la silueta del usuario, salvo en los puntos en que el usuario ocupe mas espacio que el maniquí en la imagen (Por ejemplo, brazos, torso, pelo, etc). Esta escena depende de la calibración del maniquí, por lo que un usuario de gran tamaño no seria mostrado de manera correcta en la escena.

Ilustración 2 Mascara 3D por Maniqui Virtual

MASCARAS CON JOINTS AJUSTADOS AL MANIQUI: En esta escena, se busca una alternativa a la calibración del maniquí, ajustando la posición de las máscaras al maniquí, y no el maniquí a la posición de las máscaras. Las máscaras se generan como una copia de la imagen que entregue la cámara, y ubicadas sobre los joints respectivos. Por defecto, los joints de las manos y la cabeza son detectados. Esto puede ser modificado en la clase MaskScript.

Cada mascara dispone de distintos parámetros públicos para la calibración de sí misma.

posOffset: Offset de posición donde se ubicará la máscara sobre el maniquí. Ciertos joints están ubicados en lugares diferentes a donde uno lo esperaría. Por ejemplo, el joint de la cabeza esta

4

ubicado en la base de esta, y no en el centro, por lo que, sin este offset, la cabeza del usuario se vería más abajo

jointOffset_default y jointOffset_clockwise: Offset de posición de la máscara. Este offset define desde donde se tomará el centro de la máscara, y no donde se ubicará. Este offset es diferente para el modo horizontal y vertical.

targetJoint: Joint objetivo, donde se anclará la máscara. Esos joints corresponden al rigging del avatar.

Para los joints de las manos se ha considerado también una forma de auto escalamiento, el cual permite cambiar el tamaño de la mascara acorde a si la mano esta abierta o cerrada. Para esto, se utilizan también los siguientes parámetros públicos

childJoint: Indica el joint que debe tomar como referencia para medir la distancia y aplicar la auto escala.

handScaleBias: Escalar que multiplica el factor de auto escala.

minMaskSize y maxMaskSize: Valores máximos y mínimos que puede tomar la auto escala en cada eje.

Ilustración 3 Mascara con Joints ajustados al maniquí. Se observa que las mascaras se ajustan a la posición del maniquí, y no a la posición del usuario.

AJUSTE DE LAS MASCARAS CON RECORTES DE LOS JOINTS DEL USUARIO: Las mascaras se generan como un recorte de la imagen que entregue la cámara, por lo que cada mascara es solo una imagen (de menor tamaño que la imagen original) del joint de interés. Por defecto, los joints de las manos y la cabeza son detectados. Al igual que la escena anterior, las mascaras se ajustan a la posición del maniquí.

En esta escena, las mascaras son manejadas por la clase MaskScript_5_1. Además de los parámetros públicos de la clase MaskScript, esta clase contiene los siguientes parámetros nuevos

maskWidth y maskHeight: Tamaño base en pixeles del recorte de la imagen. No corresponde al tamaño de la máscara.

refBias: Escalar que multiplica el tamaño en pixeles del recorte de la imagen.

5

Ilustración 4 Ajuste de las Máscaras con Recortes de los Joints del Usuario. Se observa que las mascaras se ajustan a la posición del maniquí, y no a la posición del usuario.

CONTROLES Botones 1 a 4 : Cambia entre las 4 escenas.

"I" : Alterna entre la Mascara Inversa y Mascara Directa

"M" : Activa y desactiva la visualización del maniquí

"D" : Activa y desactiva la visualización del vestido

"S" : Activa y desactiva la visualización de los Joints

"O" : Cambia la orientación de la cámara.

"NumPad 0": Activa el menú del modo manual de la cámara

MODO MANUAL DE LA CAMARA Es importante hacer calzar la configuración de color y luminosidad de la imagen utilizada como “Fondo Falso”, con la configuración de color y luminosidad de la imagen a tiempo real. El sensor, por defecto, opera en modo automático, modificando esta configuración de manera dinámica según la escena, sin embargo, la librería de Microsoft ofrece métodos para modificar estos valores de manera manual. Por lo tanto, se genera una clase encargada de manejar estos parámetros, así como volver al modo automático, si así se prefiere.

Esta clase se encuentra anidada dentro de la clase ya implementada “Kinect 4 Azure Interface”, encargada de interactuar con el sensor. Dentro del editor de Unity, es posible modificar los valores del modo manual, en el objeto KinectController->Kinect4Azure->Kinect4AzureInterface.

6

Asimismo, se ha agregado un menú en pantalla, que muestra en que modo se está trabajando, así como los valores actuales de cada parámetro, y sus valores mínimos, máximos, y valor por defecto, en caso de existir.

Ilustración 6 Menu del Modo Manual

Es importante notar que existen métodos para obtener los valores específicos de estos parámetros en tiempo de ejecución. Sin embargo, los valores retornados por estos métodos corresponden a los valores que han sido asignados al modo manual, y no los valores que el sensor modifica de manera dinámica en el modo automático.

PARAMETROS 1) TimeExposureAbsolute : Controla el tiempo de exposición del sensor en microsegundos. Internamente, se tiene una lista de valores aceptados por el sensor, por lo que cualquier otro valor se aproximara al valor aceptado más cercano.

2) Brightness : Controla el brillo. El rango es 0 a 255. El valor por defecto es 128.

3) Contrast : Controla el contraste. El rango es 0 a 10. El valor por defecto es 5.

4) Saturation : Controla la saturación. El rango es 0 a 63. El valor por defecto es 32.

5) Sharpness : Controla la nitidez. El rango es 0 a 4. El valor por defecto es 2.

6) Gain : Controla la ganancia. El rango es 0 a 255. El valor por defecto es 128.

Ilustración 5 Controles del modo Manual

7

7) White Balance : Controla el balance de blancos. Se mide en Kelvin. Internamente, el sensor solo acepta valores múltiplos de 10, por lo que cualquier otro valor se aproximara al múltiplo de 10 más cercano. El rango es 2500K a 10000K.

8) Backlight Compensation : Controla la compensación de contraluz. Un valor de 1 activa la compensación, mientras que un valor de 0 la desactiva. Por defecto esta en 0.

CONTROLES DEL MENU Todos los parámetros pueden ser modificados en tiempo de ejecución, siempre y cuando el menú se encuentre activo, y el modo manual activado.

Para abrir el menú, hay que presionar el botón “0” en el teclado numérico.

Una vez abierto el menú, se puede alternar entre el modo automático y manual presionando el botón “9” en el teclado numérico.

Para modificar algún parámetro, hay que presionar en el teclado numérico el número del parámetro correspondiente (Por ejemplo, presionar “3” modifica el Contraste). Esto aumenta el valor de dicho parámetro según el “step” definido en el Editor. Para disminuir el valor de algún parámetro, se debe presionar “Left Ctrl”, junto con el numero respectivo.

EFECTO BLEND Y EFECTO BLUR

EFECTO BLEND Para poder generar un efecto realista, es importante que la prenda seleccionada no obstruya la visión de las partes del cuerpo que, en la vida real, estarían frente a ella. El caso mas común, es cuando el usuario quiere poner los brazos sobre el cuerpo. Para poder hacer esto, se hace uso del efecto “Blend”, el cual se encarga de mostrar parte de la imagen a tiempo real, si la información de profundidad indica que esta esta mas cerca que la prenda de ropa seleccionada.

El proyecto base incluye un algoritmo de Blend, pero este solo consideraba una sección fija de la imagen, así como un nivel de profundidad fijo con el cual compararse. Esto generaba problemas con ciertas posiciones del usuario, así como cuando el usuario se ubicaba a distintas distancias del sensor.

La mejora incorporada corresponde a una modificación de la clase “SceneBlendRenderer”, algoritmo de Blend implementado en las demos de Kinect, que utiliza como base la textura Alpha entregada por backgroundRemovalManager. A esta clase se le ha agregado una textura como entrada, la cual contiene la ubicación de los brazos del usuario en pantalla. Esta textura permite que el nuevo algoritmo de Blend se ejecute únicamente en los pixeles donde se detecte que están los brazos. Esta textura es generada por una segunda cámara (BlendCamera), la cual detecta únicamente las máscaras de los brazos. Además, una segunda textura, generada por una tercera cámara (DressCamera), incluye el detalle de la profundidad del vestido en la imagen, por lo que el efecto Blend se realiza de manera dinámica en cada pixel según la profundidad real de la escena en Unity, y no sobre un valor fijo para toda la imagen.

Ya que la escena implementada no incluye una calibración del maniquí a las medidas del usuario, es posible que exista “sangrado” (Bleeding), entre las mascaras de los brazos y partes del cuerpo del usuario. Esto se debe a que, ya que el maniquí no esta calibrado, es de menor tamaño que el

8

usuario, por lo no es posible realizar la comparación de profundidad en los puntos donde el vestido no esté presente. Esto es difícil corregir si no existe una categorización de las distintas partes del cuerpo del usuario. Para corregir esto, temporalmente se ha agregado una capsula en el torso del usuario (“Vestido Invisible”), la cual busca representar el maniquí calibrado. A esta capsula se le puede ajustar el tamaño para ajustarse al tamaño del torso del usuario y evitar el sangrado.

PARAMETROS useAlpha: Fija el efecto Blend solo a los brazos del usuario.

invertMask: Invierte el canal Alpha entregado por el backgroundRemovalManager.

alphaCutout: Texture generada por la cámara BlendCamera, utilizada para detectar los pixeles donde se encuentren los brazos.

dressDepth: Textura generada por la cámara DressCamera, utilizada para obtener la profundidad del vestido en la escena.

dressOffset: Agrega un offset a la profundidad del vestido, permitiendo que el Blend afecte a mayor o menor parte del usuario.

Ilustración 8 A la izquierda, sangrado del efecto blend. A la derecha, dressOffset bien ajustado para evitar el sangrado.

Ilustración 7 Controles del efecto Blend

9

EFECTO BLUR En ciertas partes del proyecto PROBADOR VIRTUAL, es deseable poder difuminar la imagen a tiempo real, para llevar la atención a la interfaz de usuario en pantalla, la cual no cubre la totalidad de la pantalla. El proyecto incluía un método de efecto Blur, pero era altamente ineficiente.

El practicante propuso un nuevo efecto Blur, generado por un CustomPass de pantalla completa, aplicado a todas las capas antes de la interfaz. Este CustomPass, al ser renderizado a nivel de la tarjeta gráfica, es mucho mas eficiente, y logra un resultado muy convincente y simple de usar.

Este efecto se encuentra implementado en el objecto BlurPass

Ilustración 9 Controles del efecto Blur

PARAMETROS radius: Determina la intensidad del efecto de Blur.

useMask: Permite aplicar el efecto a Blur solo a ciertas capas.

maskLayer: Selecciona las capas a ser afectadas por el efecto Blur.

invertMask: Invierte la selección de capas.

Ilustración 10 Efecto Blur con distintos valores de radius. De izquierda a derecha, 4, 10 y 20.

10

CONTROLES "I" : Alterna entre la Mascara Inversa y Mascara Directa

"M" : Activa y desactiva la visualización del maniquí

"D" : Activa y desactiva la visualización del vestido

"S" : Activa y desactiva la visualización de los Joints

"B": Activa o desactiva el efecto "Blur"

"O": Cambia la orientación de la camara

Flechas Izquierda y Derecha : Ajusta el tamaño del "Vestido Invisible"

Flechas Arriba y Abajo : Ajusta el parámetro dressOffset.

NumPad 0: Activa el menú para el modo manual de la cámara

ALGORITMO DE PUSH Las demos de Kinect, incluyen una clase encargada de detectar gestos e interacciones del usuario frente al sensor. Una de estas interacciones es el “Push”, acción realizada al extender la mano hacia el frente. Esta clase fue modificada para el proyecto, implementando un algoritmo que considera el promedio de los datos guardados, donde el valor de interés es la razón entre la distancia entre la muñeca y el hombro en el eje z, y el largo total del brazo. Esta clase funciona de manera simultanea para ambas manos, por lo que rápidas interacciones con ambas manos, o intercalar la interacción con estas puede llevar a errores en las mediciones.

El practicante desarrolla un segundo algoritmo de Push, el cual es independiente para ambas manos, y no considera un promedio de los datos guardados, si no un umbral mínimo de la variable de interés tal de considerar que ha ocurrido un Push. Para evitar errores en la lectura (Como por ejemplo, valores muy cercanos al umbral seleccionado), se toma una ventana de datos desde el momento en que se supera el valor umbral. Si dentro de esta ventana de datos, muchos valores no han pasado el umbral, se considera como un falso positivo, y no se ejecuta el Push. De la misma manera, si dentro de esta ventana, la mayoría de los valores se mantiene sobre el umbral, el Push se ejecuta de manera normal.

Se implementa también un “reset”, el cual lleva el valor de la variable a 0 luego de 1 segundo, evitando que el Push se mantenga de manera indefinida si se deja de detectar que hay interacción con alguna mano.

PARAMETROS INTERNOS De manera interna, el algoritmo esta constantemente tomando los datos necesarios para la evaluación del Push. Estos son

deltaY: Representa el largo total del brazo, calculado como la suma entre la distancia del hombro al codo, y la distancia del codo a la muñeca. Este valor debería mantenerse constante.

deltaZ: Representa la distancia en el eje z entre la muñeca y el hombro del brazo respectivo

datoActual: Representa la razón entre deltaZ y deltaY.

11

pushedProgress: Representa el valor a ser retornado a InteractionManager. Depende del valor de datoActual. Si no se detecta un Push, retorna un valor entre 0 y Threshold. Si detecta un Push, retorna 1, y si ocurre un reset, retorna 0 hasta que se inicie nuevamente el algoritmo

GUARDADO DE DATOS El algoritmo guarda los datos de interés, para su posterior análisis en caso de ser necesario. Ya que el algoritmo ha sido modificado para considerar ambos brazos de manera independiente, se generan dos archivos “.csv” con la información. Las columnas de ambos archivos corresponden a Tiempo Actual, datoActual, pushedProgress, deltaY, deltaZ, respectivamente.

PARAMETROS PUBLICOS Parámetros a modificar desde el editor de Unity, en el objeto InteractionManager

PUSH_MAX_PERCENT : Valor mínimo para InteractionManager considere que se ha realizado un Push

Threshold : Valor umbral de la razón entre la distancia de la muñeca al hombro del usuario en el eje z, y el largo total del brazo. Este valor determina si se esta o no en Push. Durante las pruebas, se llego al valor de 0.75 como un valor aceptable.

MaxCount : Cantidad de muestras que el algoritmo utilizara para determinar si hubo o no error en la medición. No puede ser menor a 1. Valores muy altos llevaran a un retraso entre que se realiza el push y la lectura de este. Valores muy bajos son mas propensos a errores de lectura.

MaxErrors: Cantidad máxima de errores dentro de la totalidad de muestras leídas tal que se considere que si se ha realizado un Push. Este valor no puede ser mayor que MaxCount. Valores muy altos requieren mayor precisión al realizar el push. Valores muy bajos son mas propensos a que ocurra un error de lectura.

Path: Dirección y nombre que se usara para el guardado de datos. El algoritmo genera 2 archivos, uno para cada brazo, de nombres “$PATH$L.csv” y “$PATH$R.csv”. Dejar este valor en blanco desactiva el guardado de datos.

LeftHandText y RightHandText: Corresponden a objetos de tipo texto que muestran el estado actual de pushedProgress.

Ilustración 11 Controles del nuevo algoritmo de Push

12

COMUNICACIÓN WIFI CON CONEXIÓN POR CODIGO QR Dentro de las ideas de mejora del proyecto, se considera distintas interacciones desde un dispositivo móvil. Estas incluyen poder cambiar prendas y colores, así como poder guardar y reproducir videos con las prendas puestas sobre el usuario. El primer paso para esta mejora es lograr la comunicación entre la aplicación (funcionando como servidor), y una aplicación cliente desde un dispositivo movil.

Usando el Asset “EasyWifiController”, se generan dos proyectos en Unity, uno orientado a funcionar como Servidor desde un computador, y otro orientado a funcionar como Cliente desde un dispositivo móvil Android. Es importante notar que esto solo funciona dentro de la misma red Wifi.

La conexión entre ambos se realiza mediante la lectura de un codigo QR, el cual contiene los puertos Servidor y Cliente a los cuales el Cliente debe conectarse. Para la generación del codigo QR, se utilizo la librería ZXing.NET para Unity, mientras que para la lectura y obtención de la imagen por camara, el asset QRCode.

La librería ZXing.NET para Unity se puede descargar desde el siguiente repositorio. Esta librería esta basada en la librería original ZXing, la cual ha sido implementada en distintas plataformas, y puede ser encontrada en el siguiente repositorio.

CONFIGURACION DEL SERVIDOR Desde el Servidor, debe existir un objecto con la clase EasyWifiManager, configurado como servidor. Para la lectura de los controles, se tiene que agregar un script por control. El asset incluye una serie de controles para usar, tales como botones,sliders y joysticks. Para este proyecto se uso únicamente los controles de tipo “CustomButtonServerController”.

Ilustración 12 Controles del servidor WIFI

serverSocketPort y clientSocketPort: Puertos donde se creara la conexión. Estos deben coincidir con los puertos usados por el cliente.

Ilustración 13 Control del Tipo Boton

13

control: Nombre del control. Este debe coincidir con el nombre del control utilizado desde la aplicación cliente.

notifyMethod: Nombre del método a llamar una vez recibida la interacción del botón. Este método debe existir en algún script asociado al mismo objeto donde se encuentra el botón.

callType: Permite cambiar entre un botón momentaneo y uno botón tipo switch.

CONFIGURACION DEL CLIENTE Desde el cliente, debe existir un objecto con la clase EasyWifiManager, configurado como cliente. Para la configuracion de los controles, se modificó el botón implementado por el asset, para que este no se conecte automáticamente, si no que se conecte solo cuando el codigo QR sea leído correctamente. Estos botones son asignados usando la clase CustomButtonController

controlName: Nombre del control. Este ha de ser igual al nombre del control a ser leído por el servidor.

Al objecto que contiene el CustomButtonController, se le debe agregar un EventTrigger. De esta manera puede ser configurado para ser leído como botón momentaneo (PointerUp y PointerDown), o como botón tipo switch (PointerClick).

CONTROLES La aplicación cliente implementa controles específicos para controlar la aplicación servidor de manera sencilla.

Ilustración 14 Interfaz de la aplicacion Servidor

14

Ilustración 15 Interfaz de la aplicacion Cliente

Show Maniqui: Activa o desactiva la visualización del maniquí.

Show Dress: Activa o desactiva la visualización del vestido.

Next Dress y Prev Dress: Cambia el vestido en el maniquí.

Scan QR: Inicia la visualización de la cámara del dispositivo para realizar la lectura del código QR.

Connect y Disconnect: Envia mensaje de conexión y desconexión al servidor. En caso de no haber escaneado un codigo QR, genera un mensaje de error. En caso de realizarse un timeout con el servidor, genera un mensaje de error.

Proyecto “Probador Virtual” Jose Borquez

Marzo - 2021

INTRODUCCIÓN Este documento describe el funcionamiento del proyecto “Probador Virtual V2.0”, luego de los cambios realizados al incorporar las mejoras descritas en el documento “Mejoras al Probador Virtual”. Además, describe las optimizaciones realizadas, y propone una mejora para alto volumen de ropa.

El proyecto se encuentra funcionando, entregado junto a su código fuente al supervisor.

IMPLEMENTACIÓN DE LAS MEJORAS Todas las mejoras descritas en el documento “Mejoras Probador Virtual” han sido implementadas en el proyecto base, sin mayores modificaciones en su funcionamiento.

MASCARA La máscara seleccionada corresponde a la utilizada en la segunda escena del proyecto Mascaras, correspondiente a Mascara 3D por Maniqui Virtual, a la cual se le ha agregado una segunda capa sobre el maniquí, que busca representar parte del área que rodea la silueta del usuario, además de un segundo material al vestido, llamado Vestido Interno, el cual intenta representar el efecto de transparencia presente en algunos de los vestidos, mediante el uso del mismo Shader (ShaderGraph/MaskShader) ocupado en la máscara directa. Las mascaras agregadas son independientes por cada vestido, y, ya que los vestidos presentan distintos diseños, buscan seguir el comportamiento de estos en ciertos lugares, como, por ejemplo, los tirantes, o el borde del cuello. Esta segunda capa no será visible en pantalla, y solo intenta representar una mayor parte del área del usuario.

Ilustración 1 Maniqui virtual y maniqui virtual con la segunda capa de mascaras

2

Ya que la segunda capa es independiente para cada vestido, los archivos “.fbx”, que contienen la información del modelo 3D del maniquí, han sido ordenados siguiendo una jerarquía única, lo que facilita la automatización de la máscaras.

Ilustración 2 Jerarquia utilizada en los archivos .fbx

Dentro del archivo .fbx, debe existir la información del rigging (mixamorig), el mesh del maniquí si así se desea, y, dentro de un objeto padre llamado DRESSES, todos los mesh asociados a cada vestido. Cada vestido, además, debe incluir un objeto padre llamado MASKS, el cual contiene todas las mascaras a utilizar con ese vestido en particular. Además, todas las máscaras asociadas a los brazos, deben estar dentro de un objecto padre llamado ARMS, para ser detectados por el efecto Blend.

MODO MANUAL DE LA CÁMARA El modo manual, así como el menú asociado, han sido agregados directamente en el proyecto base, siendo necesario únicamente modificar la clase Kinect4AzureInterface, que es la que ahora incluye los métodos asociados para modificar el modo manual. Además, el menú sigue la orientación de la aplicación, rotando y cambiando la posición de anclaje según corresponda. El menú se encuentra en Canvas->ManualModeDebug.

EFECTO BLEND El efecto Blend original ha sido reemplazado por el propuesto por el practicante. Este se puede encontrar en el objeto Escena->BlendRenderer. Se ha agregado el script BlendManager, encargado de rotar el efecto Blend, siguiendo la orientación del sensor según corresponda.

EFECTO BLUR El efecto Blur original ha sido reemplazado por el propuesto por el practicante. Este se puede encontrar en el objeto Canvas->PanelPrincipal->6.Galeria->Blur. Este ha sido modificado para poder ser activado o desactivado a gusto en el archivo de configuración. Cuando el efecto Blur se

3

encuentra desactivado, en su lugar, para imitar el efecto, se muestra una imagen semi-transparente. Este comportamiento lo controla la clase blurScript, ubicada en el mismo objeto.

ALGORITMO DE PUSH El algoritmo de Push ha sido reemplazado por el propuesto por el practicante. Este es llamado internamente por la clase InteractionManager, ubicada en Escena->InteractionManager.

SPLASHSCREEN Se ha implementado el SplashScreen modificado por el practicante. Este se muestra cada vez que se inicia la escena, y sigue la orientación de la pantalla según corresponda. Es importante recordar, que, por defecto, Unity muestra el logo de Unity en el SplashScreen, a menos que se use una versión licenciada del software.

SELECCIÓN DE MEJORAS MEDIANTE ARCHIVO “VARIABLES.INI” Se han agregado entradas al archivo de configuración “variables.ini”, por lo que ciertas mejoras pueden ser activadas y desactivadas a gusto. Estas son

useMasks: Activa y desactiva el uso de todas las máscaras. En false, desactiva las máscaras de los vestidos y la máscara inversa, así como el uso de estas para el efecto Blend, y el fondo falso.

useInvMask: Activa y desactiva únicamente la máscara inversa

Ademas, se han mantenido las entradas que controlan el efecto Blur y efecto Blend

blendEffectActive: Activa y desactiva el uso del efecto Blend en su totalidad.

blurEffectActive: Activa y desactiva el uso del nuevo efecto Blur. En false, usa una imagen fija blanca semi-transparente.

COMUNICACIÓN WIFI CON CONEXIÓN POR CODIGO QR Para implementar la comunicación wifi con conexión por código QR, el proyecto completo fue copiado en un nuevo proyecto, con todas las mejoras incluidas, para poder trabajar sobre este de manera paralela. Se busca poder controlar la prenda seleccionada, y el color de esta, todo esto, de manera sincronizada con los controles y la galería ya incorporados en la aplicación servidor.

Asimismo, se ha modificado la interfaz de la aplicación cliente, siendo ahora posible especificar que prenda y que color se desea usar. Para la selección del vestido, se puede hacer click en el icono del vestido deseado, o hacer click en los botones Next Dress y Prev Dress.

Los controles son gestionados por la clase wifiControls, en el objecto Wifi->DressControls. Los controles usados corresponden a dos clases CustomInt (Uno para seleccionar el vestido, y otro para el color), y una clase CustomButton, para mostrar u ocultar el maniquí.

4

Ilustración 3 Interfaz de la Aplicación Cliente

Esta modificación es compatible con los controles ya implementados en el proyecto. La clase wifiControls se encarga de manejar y sincronizar la galería con los controles recibidos por Wifi, así como de activar y desactivar los vestidos y colores seleccionados. además, se encarga de no cambiar el vestido seleccionado, si la aplicación se encuentra en la Galería.

LIMPIEZA GENERAL Y OPTIMIZACIÓN DEL PROYECTO Ya que el proyecto aun se encuentra en una etapa de desarrollo, presenta una serie de puntos a optimizar y mejorar. La gran mayoría de estos, se presento en la forma de referencias públicas a múltiples scripts dentro del mismo objeto, así como referencias públicas a objetos, padres de otros objetos referenciados. Estas referencias fueron corregidas en su mayoría, referenciando únicamente al objeto padre que contiene los scripts u otros objetos.

Se encontraron también, asignaciones que no eran usadas, métodos que no eran llamados, y asignaciones que, si eran usadas, pero que no tenían impacto alguno en el desarrollo del proyecto. Esto fue corregido borrando el código respectivo, previa testeo de que efectivamente no afectaba el funcionamiento del proyecto.

La ultima parte de la optimización del proyecto, consiste en agrupar referencias similares, dentro de listas públicas. En su inicio, el proyecto referenciaba estos objetos de manera individual, lo que era ineficiente y poco productivo. El ejemplo recurrente en este caso fue las referencias a los 4 vestidos, los cuales tenían que ser asignados manera manual, siendo que estos vestidos, siempre están disponibles dentro del mismo objeto. Este caso y otras referencias fueron cambiadas por listas, las cuales, dentro de los scripts respectivos, son referenciados en el método Awake() o Start() según corresponda, y trabajados de manera automatizada en ciclos for.

PROPUESTA DE ARQUITECTURA PARA ALTO VOLUMEN DE ROPA Dentro de los objetivos esperados del practicante, estaba la modificación para poder incorporar un alto volumen de ropa de manera dinámica, utilizando varios archivos .fbx, esto es, poder a futuro, asignar mas de 4 vestidos, pudiéndose agregar prendas individuales sin la necesidad de generar un unico modelo .fbx con todas las prendas ya asignadas.

5

Esta modificación fue descartada, luego de tener una reunión con el desarrollador inicial del proyecto, quien confirmó que esta modificación requiere de una reestructuración completa de la arquitectura del proyecto, partiendo por la interfaz gráfica, y a como se asignan las medidas del usuario al modelo.

El mayor problema actualmente, que impide poder realizar esta mejora, es que la arquitectura del proyecto ha sido desarrollada para siempre trabajar con un solo modelo, el cual tiene siempre 4 vestidos. Para poder modificar esto, se propone

1. Generar modelos .fbx individuales para cada vestido. La existencia de un modelo único, con todas las prendas ya asignadas en el mismo modelo, es ineficiente, y poco escalable. Estos modelos deberían incluir solamente el mesh de la prenda, mas el rigging necesario. Mas aun, estos modelos deberían cargase de manera dinámica, para evitar uso innecesario de recursos.

2. Modificar los scripts encargados de asignar los BlendShapes al modelo del maniquí virtual. Actualmente, estos scripts asignan los BlendShapes a un modelo único (El cual contiene todas las prendas). Estos scripts deberían tener una lista dinámica de modelos, escalable, tal de poder cargar y asignar los BlendShapes solo a los modelos de las prendas que se estén usando.

3. Asignar los BlendShapes solo a los modelos activos. Actualmente, los BlendShapes se asignan inmediatamente luego de la calibración del usuario, lo cual no es escalable si se considera una cantidad arbitraria de modelos. La asignación de los BlendShapes debería hacerse únicamente a los modelos de las prendas activa, y asignarse a los demás modelos únicamente cuando estos sean cargados.

4. Se debe reestructurar la interfaz gráfica, en específico, la galería. La galería de vestidos es el único lugar donde se puede seleccionar la prenda, por lo que esta debería ser la base para poder implementar una mayor cantidad de prendas. La generación del “carrusel” debería ser dinámica, tomando todos los modelos cargados en el proyecto (no activos). Actualmente, este carrusel tiene solo la imagen de los 4 vestidos, y solo el intentar agregar una nueva prenda es poco modular.

MANAGER DE MODELOS FBX Si bien la arquitectura del proyecto, no permite el uso de múltiples modelos, si se realizo una reestructuración, con tal de poder actualizar el modelo actual de manera fácil y automatizada, sin la necesidad de asignar las referencias necesarias de manera manual.

Esta clase se encarga de seleccionar entre distintos modelos al momento de cargar la escena, así como de entregar todas las referencias necesarias a cualquier objeto dentro del modelo. De esta forma, cualquier referencia necesaria del modelo, puede ser obtenida directamente utilizando los metodos implementados en esta clase, sin tener que referenciar al objeto solicitado directamente.

Ademas, se encarga de ubicar las luces dentro del modelo respectivo, esto con el objetivo de que las luces se muevan de manera dinamica, dentro de la referencia del modelo.

6

Ilustración 4 Controles del Manager de Modelos FBX

fbxIndex: Indica el index del modelo a utilizar. Este index corresponde al numero del modelo dentro del objecto FBX IMPORTA MANAGER, siendo 0 el primer modelo.

Ilustración 5 Estructura del Manager de Modelos FBX

Para el correcto funcionamiento de las físicas de las prendas, el manager de modelo FBX debe estar dentro del objeto ObiSolver.

informe de práctica en

Documents