Desarrollo de una Extensión para Blender para la Generación y Parametrización de Texturas
Abstract
Este proyecto aborda un desafío común en los gráficos por computadora: crear modelos 3D que se asemejen de manera detallada y precisa a entidades físicas. Aunque existen muchas técnicas para mitigar este problema, este proyecto se centra en el Baking, una técnica que se usa ampliamente en la industria, pero cuya preparación y ejecución suelen consumir grandes cantidades de recursos temporales y computacionales. A su vez, este proyecto se centra en la generación y evaluación de coordenadas de textura o "parametrizaciones", técnica que no siempre proporciona soluciones óptimas. El objetivo de este proyecto es desarrollar 3 herramientas que automatizan el proceso de Baking, crear parametrizaciones que tengan en cuenta la geometría del modelo y evaluar la calidad de las parametrizaciones relacionadas con un modelo 3D, respectivamente. Los resultados obtenidos con la herramienta Baking demuestran la fiabilidad de las texturas generadas al tiempo que simplifican significativamente la intervención del usuario. A su vez, la herramienta de parametrización puede distinguir entre diferentes modelos, dando así una base para futuras mejoras en comparación con técnicas ya existentes. Por otra parte, la herramienta de evaluación de la configuración permite un análisis detallado que tiene en cuenta varias estadísticas. Todo el código del proyecto se puede encontrar en https://github.com/InfinitGamer/FIB-TFG-BLENDER.
Full text
id192739 DESARROLLO DE UNA EXTENSIÓN PARA BLENDER PARA LA GENERACIÓN Y PARAMETRIZACIÓN DE TEXTURAS JEREMY COMINO RAIGÓN Director/a IMANOLMUÑOZPANDIELLA(DepartamentodeCienciasdelaComputación) Codirector/a CARLOSANDUJARGRAN(DepartamentodeCienciasdelaComputación) Titulación GradoenIngenieríaInformática(Computación) Memoria del trabajo de fin de grado Facultat d'Informàtica de Barcelona (FIB) Universitat Politècnica de Catalunya (UPC) - BarcelonaTech
Agradecimientos Me gustar´ıa dar mi agradecimiento a Imanol Mu˜noz Pandiella por todo el apoyo, gu´ıa y confianza que me ha proporcionado durante todo el transcurso de este proyecto. Su nivel de conocimiento ha ayudado a encaminar el proyecto en la mejor direcci´on posible. A su vez, me gustar´ıa dar las gracias a Carlos Andujar Gran por proporcionar gu´ıa en la fase inicial del proyecto y tambi´en por proporcionar los recursos m´as t´ecnicos para poder enfrentar de la mejor manera posible la implementaci´on de todo el proyecto. Por ´ultimo, quisiera dar las gracias, en especial, a mi familia por todo el apoyo y cari˜no que me han dado durante todo este tiempo. Tambi´en agradezco profundamente a mis amigos cercanos, quienes han estado a mi lado en cada paso del camino. Sin todos ellos, yo no estar´ıa en la posici´on en la que estoy actualmente.
Resumen Este proyecto aborda un desaf´ıo com´un en los gr´aficos por computadora: crear modelos 3D que se asemejen de manera detallada y precisa a entidades f´ısicas. Aunque existen muchas t´ecnicas para mitigar este problema, este proyecto se centra en el Baking, una t´ecnica que se usa ampliamente en la industria, pero cuya preparaci´on y ejecuci´on pueden consumir grandes cantidades de recursos temporales y computacionales. A su vez, este proyecto se centra en la generaci´on y evaluaci´on de coordenadas de textura o “parametrizaciones”, t´ecnica que no siempre proporciona soluciones ´optimas. El objetivo de este proyecto es desarrollar 3 herramientas que automatizan el proceso de Baking, crear parametrizaciones que tengan en cuenta la geometr´ıa del modelo y evaluar la calidad de las parametrizaciones relacionadas con un modelo 3D, respectivamente. Los resultados obtenidos con la herramienta Baking demuestran la fiabilidad de las texturas generadas al tiempo que simplifican significativamente la intervenci´on del usuario. A su vez, la herramienta de parametrizaci´on puede distinguir entre diferentes modelos, dando as´ı una base para futuras mejoras en comparaci´on con t´ecnicas ya existentes. Por otra parte, la herramienta de evaluaci´on de la configuraci´on permite un an´alisis detallado que tiene en cuenta varias estad´ısticas. Todo el c´odigo del proyecto se puede encontrar en https://github.com /InfinitGamer/FIB-TFG-BLENDER.
Resum Aquest projecte aborda un desafiament com´u en els gr`afics per computadora: crear models 3D que s’assemblin de manera detallada i precisa a entitats f´ısiques. Encara que existeixen moltes t`ecniques per a mitigar aquest problema, aquest projecte se centra en el Baking, una t`ecnica que s’usa `ampliament en la ind´ustria, per`o la preparaci´o i l’execuci´o de la qual pot consumir grans quantitats de recursos temporals i computacionals. Al seu torn, aquest projecte se centra en la generaci´o i avaluaci´o de coordenades de textura o “parametritzacions”, t`ecnica que no sempre proporciona solucions `optimes. L’objectiu d’aquest projecte ´es desenvolupar 3 eines que automatitzin el proc´es de Baking, crear parametritzacions que tinguin en compte la geometria del model i avaluar la qualitat de les parametritzacions relacionades amb un model 3D, respectivament. Els resultats obtinguts amb l’eina Baking demostren la fiabilitat de les textures generades al mateix temps que simplifiquen significativament la intervenci´o de l’usuari. Al seu torn, l’eina de parametritzaci´o pot distingir entre diferents models, donant aix´ı una base per a futures millores en comparaci´o amb t`ecniques ja existents. D’altra banda, l’eina d’avaluaci´o de la configuraci´o permet una an`alisi detallada que t´e en compte diverses estad´ıstiques. Tot el codi del projecte es pot trobar en https://github.com/InfinitGa mer/FIB-TFG-BLENDER.
Abstract This project addresses a common challenge in computer graphics: creating 3D models that closely and accurately resemble physical entities. While many techniques exist to mitigate this problem, this project focuses on Baking, a technique that is widely used in industry, but whose preparation and execution can consume large amounts of time and computational resources. In turn, this project focuses on the generation and evaluation of texture coordinates or “parameterisations‘’, a technique that does not always provide optimal solutions. The aim of this project is to develop 3 tools that automate the process of “Baking‘’, create parameterisations that take into account the geometry of the model and evaluate the quality of the parameterisations related to a 3D model, respectively. The results obtained with the Baking tool demonstrate the reliability of the generated textures while significantly simplifying user intervention. In turn, the parameterisation tool can distinguish between different models, thus providing a basis for future improvements compared to existing techniques. Moreover, the configuration evaluation tool allows for a detailed analysis that takes into account various statistics. All project code can be found at https://github.com/InfinitGamer/FI B-TFG-BLENDER.
´ Indice 1. Introducci´on y alcance 1 1.1. Contexto.................................... 1 1.1.1. Conceptos............................... 2 1.1.1.1. Blender ........................... 2 1.1.1.2. Textura ........................... 2 1.1.1.3. Baking ............................ 2 1.1.1.4. Coordenadas de textura . . . . . . . . . . . . . . . . . . 3 1.1.1.5. Distorsi´on.......................... 4 1.1.2. Problema a resolver . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.3. Stakeholders.............................. 5 1.2. Justificaci´on.................................. 5 1.2.1. EstudiosPrevios ........................... 5 1.2.2. Justificaci´on.............................. 6 1.3. Alcance .................................... 6 1.3.1. Objetivos ............................... 6 1.3.2. Requisitos............................... 8 1.3.2.1. Requisitos no funcionales . . . . . . . . . . . . . . . . . . 8 1.3.2.2. Requisitos funcionales . . . . . . . . . . . . . . . . . . . 8 1.3.3. Riesgos y obst´aculos . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.4. Metodolog´ıayrigor.............................. 9 1.4.1. Metodolog´ıa.............................. 9 1.4.2. Monitorizaci´on ............................ 9 2. Planificaci´on temporal 11 2.1. Descripci´on de las tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2. Recursos.................................... 16 2.2.1. Recursos humanos . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2.2. Recursos materiales . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3. Gesti´ondelriesgo............................... 17 2.3.1. Riesgo ................................. 17 2.3.2. Impacto ................................ 17 2.3.3. Mitigaci´on............................... 18 3. Presupuesto 19 3.1. Presupuesto personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2. Presupuestogen´erico ............................. 21 3.2.1. Costes Software ............................ 21 3.2.2. Costes Hardware ........................... 21 3.2.3. Costes de alojamiento . . . . . . . . . . . . . . . . . . . . . . . . 22 3.2.4. Costes de contingencia . . . . . . . . . . . . . . . . . . . . . . . . 22 3.2.5. Imprevistos .............................. 22 3.2.6. Costetotal .............................. 23 3.3. Controldegesti´on .............................. 23 4. Sostenibilidad 24 4.1. Autoevaluaci´on ................................ 24
4.2. ´ Ambitoecon´omico .............................. 25 4.3. ´ Ambitosocial ................................. 25 4.4. ´ Ambitomedioambiental ........................... 25 5. MVP 27 5.1. Conceptos................................... 27 5.1.1. Propiedades.............................. 27 5.1.2. Mesh.................................. 28 5.2. Funcionalidades................................ 29 5.2.1. Criterios iniciales . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.2.2. Baking ................................. 30 5.2.2.1. Proceso de Baking ..................... 30 5.2.2.2. Algoritmo de Baking .................... 35 5.2.2.3. Configuraci´on manual . . . . . . . . . . . . . . . . . . . 36 5.2.2.4. Configuraci´on Autom´atica . . . . . . . . . . . . . . . . . 39 5.2.2.5. Switch ............................ 41 5.2.2.6. Interfaz gr´afica . . . . . . . . . . . . . . . . . . . . . . . 44 5.2.3. Parametrizaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.2.3.1. Proceso de parametrizaci´on . . . . . . . . . . . . . . . . 47 5.2.3.2. Algoritmo de parametrizaci´on . . . . . . . . . . . . . . . 50 5.2.3.3. Separador de Mallas . . . . . . . . . . . . . . . . . . . . 52 5.2.3.4. Interfaz Gr´afica . . . . . . . . . . . . . . . . . . . . . . . 54 5.2.4. Analizado de parametrizaciones . . . . . . . . . . . . . . . . . . . 56 5.2.4.1. Estad´ısticos . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.2.4.2. Algoritmo de analizado . . . . . . . . . . . . . . . . . . . 58 5.2.4.3. Interfaz Gr´afica . . . . . . . . . . . . . . . . . . . . . . . 59 6. An´alisis y discusi´on de los resultados 60 6.1. Entornodepruebas.............................. 60 6.2. Experimentos ................................. 60 6.2.1. Baking ................................. 61 6.2.1.1. Prueba1........................... 61 6.2.1.2. Prueba2........................... 63 6.2.1.3. Prueba3........................... 64 6.2.1.4. Prueba4........................... 67 6.2.1.5. Prueba5........................... 68 6.2.1.6. Prueba6........................... 69 6.2.1.7. Prueba7........................... 70 6.2.2. Parametrizaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 6.2.2.1. Prueba1........................... 71 6.2.2.2. Prueba2........................... 73 6.2.2.3. Prueba3........................... 75 6.2.2.4. Prueba4........................... 77 6.2.3. Analizado de parametrizaciones . . . . . . . . . . . . . . . . . . . 79 6.2.3.1. Prueba1........................... 79 6.2.3.2. Prueba2........................... 80 6.2.3.3. Prueba3........................... 83 6.2.3.4. Prueba4........................... 84
7. Conclusi´on 86 7.1. Evaluaci´on de objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 7.2. Limitaciones.................................. 88 7.3. Reflexi´on.................................... 88 Bibliograf´ıa y Webgraf´ıa 90
´ Indice de Figuras 1. Aplicaci´on Normal Mapping con datos del proceso de Baking ....... 3 2. Comparativa de im´agenes con efecto Aliasing ............... 4 3. DiagramaGant ................................ 16 4. PropiedadesRNA............................... 28 5. Imagendenodos ............................... 29 6. Comparativa de sistemas de referencia . . . . . . . . . . . . . . . . . . . 31 7. Ejemplo Coordenadas Baric´entricas . . . . . . . . . . . . . . . . . . . . . 32 8. Ejemplo de interpolaci´on bi-lineal . . . . . . . . . . . . . . . . . . . . . . 33 9. Imagen funcionamiento Ray Tracing .................... 33 10. Mapa de oclusi´on ambiental . . . . . . . . . . . . . . . . . . . . . . . . . 34 11. Comparativa nivel de discretizaci´on . . . . . . . . . . . . . . . . . . . . . 40 12. Problemas margen tipo Extend ....................... 40 13. Imagenmen´uobjeto ............................. 43 14. Interfaz apartado Baking ........................... 45 15. Imagen marcas Unwrap ............................ 48 16. Resultado del algoritmo de Unwrap ..................... 49 17. Resultado Lightmap Pack .......................... 50 18. Cubodentrodeesfera ............................ 52 19. Imagenmaniqu´ı................................ 53 20. Interfaz apartado parametrizaci´on . . . . . . . . . . . . . . . . . . . . . . 55 21. Ejemplo analizado de parametrizaci´on visual . . . . . . . . . . . . . . . . 56 22. Interfaz apartado analizado de parametrizaciones . . . . . . . . . . . . . 60 23. ´ Arbol de nodos del modelo Barril ...................... 61 24. Comparativa de texturas del modelo Barril ................. 62 25. Diferencias del modelo Barril ........................ 62 26. Comparativa lum´ınica modelo Iglesia .................... 63 27. Comparativa de similitud modelo Iglesia .................. 64 28. Imagen Caballo de Ajedrez .......................... 65 29. ´ Arbol de nodos del modelo Caballo de ajedrez ............... 65 30. Comparativa de similitud modelo Caballo de ajedrez ............ 66 31. Comparaci´on modelo Caballo de ajedrez .................. 66 32. Comparaci´on modelo Caballo de ajedrez con coordenadas de textura . . . 67 33. Comparativa de similitud modelo Esfera .................. 68 34. Modelo cubo con configuraci´on Low ..................... 69 35. Modelo cubo con configuraci´on Medium ................... 70 36. Modelo cubo con configuraci´on High ..................... 71 37. Modelo esfera ................................. 72 38. Resultado parametrizaci´on esfera . . . . . . . . . . . . . . . . . . . . . . 72 39. Parametrizaci´on esf´erica sobre esfera . . . . . . . . . . . . . . . . . . . . 73 40. Modelo cilindro ................................ 74 41. ´ Areasuperficiecilindro............................ 74 42. Resultado parametrizaci´on cilindro . . . . . . . . . . . . . . . . . . . . . 75 43. Parametrizaci´on cil´ındrica sobre cilindro . . . . . . . . . . . . . . . . . . 75 44. Modelo ´ Arbol ................................. 76 45. Modelo ´arbol separado ............................ 76 46. Resultado parametrizaci´on ´arbol . . . . . . . . . . . . . . . . . . . . . . . 77
Figura 2: Comparativa entre una imagen y un escalado de esta, donde se aprecia el efecto del Aliasing. (Fuente de la imagen: [17]) 1.1.1.5. Distorsi´on La distorsi´on en coordenadas de textura es el fen´omeno ocurrido cuando el tri´angulo obtenido a partir de las coordenadas de textura no corresponde en forma o tama˜no con el tri´angulo conformado por las coordenadas del objeto [18]. Existen dos tipos de distorsi´on: Distorsi´on en ´ Area: El tri´angulo producido por las coordenadas de textura es un escalado del tri´angulo original. Haciendo que la distancia entre cada punto del tri´angulo var´ıe respecto al original Distorsi´on en ´ Angulo: El tri´angulo producido por las coordenadas de textura no tiene los mismos ´angulos que el tri´angulo original. Haciendo que la forma de ambos no se parezca entre si. 1.1.2. Problema a resolver En Blender existen dos problemas relacionados con las texturas. El primer problema es la generaci´on de estas. El Baking es una t´ecnica muy utilizada, pero que necesita una preparaci´on extensa para que funcione. Por otra parte, existe el problema de la generaci´on de coordenadas de textura, donde en ocasiones se generan unas coordenadas con distorsi´on o solapamiento, afectando entonces a la fidelidad del modelo con la realidad. Como podemos ver, estos problemas afectan tanto a la productividad de los usuarios como a la calidad de los modelos 3D creados. Por lo tanto, estos problemas son importantes y no deber´ıan dejarse sin resolver. 4
1.1.3. Stakeholders Este proyecto consta de diferentes grupos, cuya relevancia var´ıa. Principalmente, se pueden dividir en 2 grupos diferentes. El primer grupo consiste en esas personas que est´an directamente involucradas en la realizaci´on del proyecto. Esto incluye al director Imanol Mu˜noz Pandiella y al co-director Carlos Andujar Gran, cuyos roles ser´an los de proporcionar orientaci´on para el buen desarrollo del proyecto. Por otra parte, el alumno Jeremy Comino Raig´on ser´a responsable de la planificaci´on, desarrollo y documentaci´on del proyecto. A su vez, se encargar´a de ejecutar las diferentes validaciones, analizar los resultados extra´ıdos de estos y presentar unas conclusiones. El segundo grupo no est´a directamente relacionado con el propio desarrollo del proyecto, pero s´ı que se beneficiar´a de los resultados obtenidos. Este grupo son los usuarios de Blender, cuyo rol es el poder utilizar la extensi´on para sus propios proyectos y, a su vez, pueden utilizarlo como una base para extender o mejorar las funcionalidades inicialmente desarrolladas. 1.2. Justificaci´on Una vez especificadas las bases para el entendimiento te´orico del proyecto, procedemos a la justificaci´on del proyecto y su relevancia. Se explicar´a el estado actual del campo de estudios y sus avances actuales (Secci´on 1.2.1). Posteriormente, se debatir´a la necesidad del trabajo dando una serie de razones basadas en los estudios previos (Secci´on 1.2.2). 1.2.1. Estudios Previos Por una parte, en la comunidad Blender, se han desarrollado varias extensiones con el objetivo de facilitar y automatizar el proceso del Baking [19][20], optimizando as´ı el flujo de trabajo y ampliando las capacidades del software en el campo de la creaci´on de mapas y texturas. El principal inconveniente que podemos encontrar es el aspecto econ´omico y la capacidad de extensi´on de estos. Son extensiones comerciales que, para poder ser utilizadas, primero tienen que ser adquiridas. Haciendo que para una instituci´on p´ublica de investigaci´on resulte un inconveniente. A su vez, al ser extensiones de terceros y debido a restricciones impuestas en licencias, es posible que el c´odigo no est´e disponible para los usuarios. Esto hace que no sea posible extender sus capacidades a posteriori. Por otra parte, en el campo de la computaci´on gr´afica se han desarrollado diversos algoritmos de mapeo de coordenadas de textura [4][21][22]. En Blender por ejemplo, existe el algoritmo “Smart UV Mapping”, donde intenta hacer un mapeo inteligente bas´andose en ciertos par´ametros que el usuario introduce. Aun as´ı, se han reportado problemas de distorsi´on y superposici´on de coordenadas [23]. Esto hace que los modelos no lleguen a tener una fiel representaci´on de lo que deber´ıan ser. 5
1.2.2. Justificaci´on Como se ha dicho en la Secci´on 1.1, el proyecto se plante´o para ayudar al grupo ViRVIG a generar texturas. Concretamente, este grupo trabaja con objetos con una gran cantidad de pol´ıgonos que, a su vez, pueden tener asociado un material ´unico. Esto hace que el proceso de Baking pueda tardar horas o incluso d´ıas ´unicamente preparando el objeto para hacer este proceso. A su vez, estos pol´ıgonos pueden conformar una geometr´ıa irregular, haciendo que las coordenadas de textura asociadas a este objeto pno sean las m´as id´oneas. Bas´andonos en lo dicho anteriormente, vemos que la creaci´on de una extensi´on propia para Blender que automatiza la creaci´on de texturas y tambi´en crear un algoritmo de generaci´on de coordenadas de textura es la opci´on m´as apropiada por los siguientes motivos: Accesibilidad y Costo: Debido a las restricciones econ´omicas que se pueden tener en instituciones de investigaci´on, gracias a la creaci´on de una extensi´on, eliminar´ıa los costes asociados a la obtenci´on de licencias de terceros para obtener las mismas capacidades que la extensi´on proporciona. Flexibilidad y Extensibilidad: Al ser una propuesta Open-Source, se otorgar´ıa a los usuarios la flexibilidad para poder reutilizar y adaptar la extensi´on a sus necesidades. A la vez que se le podr´ıa extender sus funcionalidades. Optimizaci´on del flujo de trabajo: Como hemos explicado en la Secci´on 1, el Baking es un proceso que se hace a nivel de modelo. Por lo tanto, automatizar este proceso y poder ser extendido a escenas con m´as de un objeto puede ser beneficioso para los usuarios. Todo esto debido a que no emplear´ıan todo su tiempo en hacer este proceso de manera manual. Mejora en la calidad de modelos: Vemos que los algoritmos utilizados para la generaci´on de coordenadas de textura actualmente en Blender pueden presentar problemas. Por lo tanto, implementar un m´etodo alternativo puede ser beneficioso para los modelos 3D. Todo esto debido a que un nuevo algoritmo puede favorecer a una representaci´on m´as fiel de los objetos. 1.3. Alcance A partir de la justificaci´on explicada en la Secci´on 1.2, esta secci´on tiene el objetivo de detallar los objetivos (tanto obligatorios como opcionales) del proyecto. A su vez, se har´a un estudio de posibles obst´aculos o complicaciones que pueden surgir a lo largo de la realizaci´on del proyecto. 1.3.1. Objetivos A continuaci´on se muestran los objetivos obligatorios para obtener un Minimum Viable Product o Producto M´ınimo Viable (MVP): 6
1. Fundamentaci´on te´orica: a) Entendimiento del funcionamiento de la API de Blender. b) Entendimiento s´olido del funcionamiento del proceso de generaci´on de texturas. c) Entendimiento s´olido de las diferentes proyecciones de objetos sobre formas volum´etricas simples. d) Entendimiento de los diferentes m´etodos para establecer si existe una semejanza entre los modelos 3D y formas volum´etricas simples. 2. Implementaci´on del sistema de automatizaci´on: a) Desarrollo eficiente de un mecanismo manual de variaci´on de par´ametros para la generaci´on de texturas de caracter´ısticas fotom´etricas. b) Desarrollo eficiente de un mecanismo autom´atico de par´ametros para la generaci´on de texturas de caracter´ısticas fotom´etricas. c) Desarrollo de un mecanismo de cambio entre materiales previamente existentes de los objetos y hechos con el proceso de automatizaci´on. 3. Implementaci´on del sistema de generaci´on de coordenadas de texturas: a) Implementaci´on de un sistema de generaci´on de coordenadas de textura. b) Implementaci´on de un sistema de evaluaci´on sencillo e intuitivo de la calidad de las coordenadas de textura generadas. 4. Evaluaci´on: a) Verificaci´on de las capacidades de los sistemas implementados. b) Comparaci´on de las coordenadas de textura generadas por el sistema implementado y el sistema implementado por Blender. A continuaci´on, tambi´en se describen una serie de objetivos opcionales a modo de expansi´on del MVP, cuya realizaci´on se har´ıa despu´es de un estudio de viabilidad. 1. Expansi´on del sistema de automatizaci´on: a) Implementaci´on de un sistema de generaci´on de texturas de caracter´ısticas no fotom´etricas. b) Implementaci´on de un sistema de continuaci´on de la tarea en caso de fallo de la aplicaci´on de Blender. 2. Expansi´on del sistema de generaci´on de coordenadas de texturas: a) Implementaci´on de un sistema de optimizaci´on de las coordenadas de texturas generadas. b) Implementaci´on de un sistema de evaluaci´on avanzado de las coordenadas de texturas. 7
1.3.2. Requisitos A ra´ız de los objetivos planteados. Tambi´en se han extra´ıdo una serie de requisitos funcionales y no funcionales para poder asegurar el correcto desarrollo del proyecto. 1.3.2.1. Requisitos no funcionales Uso de buenas pr´acticas de programaci´on. Con la capacidad del c´odigo de ser mantenible. Asegurar una implementaci´on eficiente de los sistemas propuestos. Asegurar una interfaz intuitiva y f´acil de utilizar. El plazo de desarrollo del proyecto no debe de superar los 3.5 meses. 1.3.2.2. Requisitos funcionales El usuario puede interactuar con diferentes aspectos involucrados en el proceso de Baking (tama˜no de la textura resultante, caracter´ıstica a hacer Baking, margen establecido, etc). El usuario puede interactuar con 3 modos predefinidos para hacer Baking. El usuario puede intercambiar entre los materiales originales y los creados por el Baking. El usuario puede generar coordenadas de textura a partir de un modelo 3D previamente creado. El usuario puede generar un estad´ıstico representativo de la calidad de las coordenadas de texturas proporcionadas. 1.3.3. Riesgos y obst´aculos Durante el desarrollo del proyecto, diferentes riesgos y obst´aculos se tienen que tener en cuenta para un correcto desarrollo de este. Inexperiencia del alumno: Al ser el primer proyecto para el alumno, el cual utiliza la API de Blender, el aprendizaje puede retrasar el progreso del proyecto. Altos requisitos computacionales: El proceso de Baking es un proceso con muchos requisitos computacionales el cual puede afectar en la verificaci´on de la funcionalidades y el tiempo de desarrollo del sistema correspondiente. 8
Complejidad en la implementaci´on: El Baking es uno que involucra diferente etapas. Esto puede presentar un riesgo en el dise˜no del proceso automatizado y el tiempo de desarrollo. Complejidad te´orica de la generaci´on de coordenadas de textura: La complejidad de hacer una estimaci´on en la semejanza entre un modelo 3D y una forma volum´etrica. Esto puede retrasar el tiempo de desarrollo de los sistemas. 1.4. Metodolog´ıa y rigor Con el objetivo de asegurar el correcto desarrollo del proyecto. En esta secci´on hablaremos sobre la metodolog´ıa que se utilizar´a y, por lo tanto, la que mejor se adec´ua. A su vez, explicaremos las herramientas que se utilizar´an con el objetivo de monitorizaci´on del proyecto y validaci´on. 1.4.1. Metodolog´ıa Debido a las restricciones de tiempo impuestas por el trabajo y la complejidad del proyecto, se ha optado por la creaci´on de un MVP y, posteriormente, la extensi´on de este. Todo esto mencionado anteriormente se puede dividir en los siguientes puntos: Desarrollo del MVP: Se hace un estudio te´orico de las funcionalidades obligatorias a hacer. Posteriormente se desarrolla el MVP, donde se eval´ua las funcionalidades implementadas a medida que se van implementando. Extensi´on MVP: A continuaci´on del desarrollo del MVP, se har´a un estudio de la viabilidad de los objetivos opcionales. Posteriormente se har´a el desarrollo y validaci´on de los puntos que se han considerado aptos para desarrollarse. Para poder hacer lo mencionado anteriormente, se optar´a por utilizar una metodolog´ıa en cascada para cada una de las 2 funcionalidades principales (proceso de Baking y generaci´on de coordenadas de textura) del MVP. Esto es debido a que se tiene una visi´on clara de lo que debe ser el producto final gracias a la generaci´on de objetivos (Secci´on 1.3.1) y tambi´en a la especificaci´on de una serie de requisitos (Secci´on 1.3.2) [24]. A su vez, se tienen bien definidas las tareas y el plazo que tienen estas (Secci´on 2.1), haciendo que la metodolog´ıa en cascada sea id´onea para este tipo de situaciones. Por ´ultimo, como medida de control del proyecto, se har´an reuniones semanales con los directores del proyecto para explicar el estado de este. A consecuencia de lo mencionado en las reuniones, se har´an modificaciones en la planificaci´on [24]. 1.4.2. Monitorizaci´on Durante el desarrollo del proyecto, se utilizar´a el repositorio GitHub como herramienta de control de versiones. De esta manera se puede ver de una manera sencilla los cambios 9
hechos a lo largo del desarrollo, no solo por el alumno, sino tambi´en por los directores del trabajo. El repositorio se estructurar´a en una rama principal donde se ir´an subiendo todos los cambios relacionados con las tareas. Por otra parte, se har´a una rama secundaria de desarrollo, la cual se subir´an los desarrollos diarios que hay en el proyecto. Por parte de la documentaci´on del proyecto se opta por utilizar el editor de Latex Overleaf [25]. Ya que permite el acceso al documento desde cualquier dispositivo gracias a su almacenamiento en la nube. A su vez, con el objetivo de tener una visibilidad de las diferentes tareas involucradas en el proyecto, se utilizar´a Trello [26] como herramienta de supervisi´on. Esta herramienta permite la creaci´on de tareas que se pueden agrupar en funci´on de las semanas establecidas para el desarrollo del trabajo. Por ´ultimo, para mantener las reuniones con todos los integrantes del proyecto se utilizar´a Google Meet. Todo esto ya que forma parte del entorno proporcionado por la Universidad Polit´ecnica de Catalu˜na. 10
2. Planificaci´on temporal En esta secci´on se hablar´a sobre la planificaci´on temporal del proyecto dividido en tareas. Todo esto, con el objetivo de finalizar y completar los objetivos planteados en la secci´on anterior. Este trabajo empieza el d´ıa 18 de septiembre del 2024 y su finalizaci´on prevista es el 24 de enero del 2025. Por consiguiente, la realizaci´on del trabajo ser´a a lo largo de 128 d´ıas y tendr´a una duraci´on prevista de 550 horas aproximadamente. La dedicaci´on en per´ıodo de lunes a viernes ser´a de 4 horas diarias. Durante este per´ıodo se realizar´an tareas de desarrollo en casa. En per´ıodo de s´abado a domingo se dedicar´an 5 horas diarias a la realizaci´on de tanto tareas de desarrollo como de documentaci´on. De igual manera que las tareas del per´ıodo de lunes a viernes, este tipo de tareas se har´an desde casa. 2.1. Descripci´on de las tareas Una vez explicados, a rasgos generales, el tiempo de desarrollo total del proyecto y el horario de realizaci´on del trabajo (Secci´on 2), procederemos con la explicaci´on de las diferentes tareas a realizar, con el objetivo de completar satisfactoriamente los diferentes objetivos establecidos. GP - Gesti´on del proyecto La gesti´on del proyecto es una de las fases cruciales en todo proyecto para poder llevarlo a cabo de manera satisfactoria. En este concepto se engloban tareas de planificaci´on, definici´on de trabajo y documentaci´on de este. A su vez, tambi´en se incluyen las reuniones semanales con los directores del proyecto a modo de supervisi´on. Se estima que la realizaci´on total del bloque supondr´a una duraci´on de 150 horas. GP.1 - Alcance En todo proyecto es necesario establecer los l´ımites en los que se abarcar´a el proyecto. Es por eso que se ha dedicado un tiempo al inicio del proyecto para definir cu´al es el objetivo del proyecto, cu´al es la soluci´on y qu´e se necesita para poder realizarlo. La duraci´on ha sido de 20 horas. Para poder realizar este estudio, se ha necesitado investigar sobre el estado actual de los diferentes recursos que hay para poder satisfacer de alguna manera la necesidad propuesta. GP.2 - Planificaci´on Con el objetivo de poder satisfacer los objetivos propuestos en la secci´on del alcance. Se realiza una planificaci´on tanto temporal como de recursos necesarios para la realizaci´on 11
de este. Se estima que para la realizaci´on de esta tarea son necesarias 15 horas. GP.3 - Presupuesto Se realiza un presupuesto con el objetivo de cuantificar econ´omicamente el proyecto. En esta tarea se har´a un estudio de los costes, tanto materiales como los costes personales necesarios para la realizaci´on del trabajo. Se estima que la realizaci´on de esta tarea es de 10 horas. GP.4 - Informe de sostenibilidad Se analizar´a a partir de las fases anteriores el impacto ambiental, social y econ´omico que supone la realizaci´on del proyecto. El tiempo necesario para la realizaci´on de esta tarea ser´a de 5 horas. GP.5Validaci´on Se rectificar´a todo lo que se ha comentado en el feedback proporcionado por el tutor de GEP. El tiempo estimado ser´a de 10 horas. GP.6 - Reuniones El objetivo principal de las reuniones ser´a informar a los directores del proyecto del estado actual de este y de las posibles dificultades que el alumno puede tener. A su vez, se han acordado reuniones semanales de 1 hora. En total, ser´an 15 horas. GP.7 - Documentaci´on Un punto crucial en todo proyecto es la documentaci´on de este. El objetivo de esta fase es ir documentando las diferentes partes del desarrollo. Como se ha mencionado anteriormente, esta fase se har´a de manera paralela junto a la fase de desarrollo. El tiempo estimado es de 60 horas. GP.8 - Presentaci´on El ´ultimo paso en la realizaci´on del proyecto es la presentaci´on de este. Por lo tanto, para poder hacer una buena defensa ante el tribunal que evaluar´a el TFG, se preparar´a una presentaci´on, un gui´on y, por ´ultimo, se har´an ensayos para este. El tiempo total ser´a de 15 horas. 12
TP - Trabajo Previo El objetivo de estas tareas es la preparaci´on de las diferentes necesidades de desarrollo y tambi´en el estudio previo requerido para estas. Estas tareas se desarrollar´an justo al principio de cada una de las fases principales de desarrollo. El tiempo estimado ser´a de 20 horas. TP.1 - Estudio previo Debido a que la API de Blender abarca un gran espectro de funcionalidades. Ser´a necesario hacer un estudio para saber c´omo utilizar esta herramienta. A su vez, se tendr´a que aprender c´omo se hace el proceso convencional de generaci´on de texturas y generaci´on de coordenadas de textura en el software previamente mencionado. El tiempo total ser´a de 18 horas. TP.2 - Preparaci´on del entorno Vemos que esta tarea, aunque no llegue a suponer un gran porcentaje de todo el proyecto, tiene una gran importancia para poder desarrollar bien el trabajo . En esta tarea se har´a la instalaci´on de los programas de Blender yVisual Studio Code, as´ı como su configuraci´on para poder obtener un rendimiento ´optimo para el alumno. El tiempo estimado ser´a de 2 horas. BG - Automatizaci´on del proceso de Baking Este conjunto de tareas se centrar´a en desarrollar y validar las diferentes funcionalidades relacionadas con la automatizaci´on de texturas. El tiempo estimado es de 170 horas. BG.1 - Creaci´on del algoritmo de automatizaci´on En esta tarea se har´a el propio desarrollo del algoritmo de automatizaci´on del proceso de Baking. Debido a la dificultad que puede tener este desarrollo, se estima que la duraci´on sea de 80 horas. BG.2 - Selecci´on de la interfaz gr´afica manual En esta tarea se elegir´an los elementos de interacci´on (Widgets) que tendr´a para el sistema manual de generaci´on de texturas. La duraci´on estimada es de 10 horas. 13
ID Tarea Tiempo Roles Coste Coste SS GP Gesti´on del proyecto 150h - 5,112.60 e6,559.47 e GP.1 Alcance 20h C 460.00 e590.18 e GP.2 Planificaci´on 15h C 345.00 e442.63 e GP.3 Presupuesto 10h C 230.00 e295.09 e GP.4 Informe de sostenibilidad 5h C 115.00 e147.54 e GP.5 Validaci´on 10h C 230.00 e295.09 e GP.6 Reuniones 15h C, I, P, T 1,023.60 e1,313.28 e GP.7 Documentaci´on 60h C, I 2,364.00 e3,033.01 e GP.8 Presentaci´on 15h C 345.00 e442.63 e TP Trabajo Previo 20h -352.88 e452.75 e TP.1 Estudio previo 18h I 295.20 e378.74 e TP.2 Preparaci´on del entorno 2h P, T 57.68 e74.00 e BG Automatizaci´on del proceso de Baking 170h - 2,627.20 e3,370.70 e BG.1 Creaci´on del algoritmo de automatizaci´on 80h BG.1.1 Investigaci´on 20h I 328.00 e420.82 e BG.1.2 Desarrollo 60h P 936.00 e1,200.89 e BG.2 Selecci´on de la interfaz gr´afica manual 10h P 156.00 e200.15 e BG.3 Creaci´on del sistema autom´atico de generaci´on 30h BG.3.1 Investigaci´on 5h I 82.00 e105.21 e BG.3.2 Desarrollo 25h P 390.00 e500.37 e BG.4 Selecci´on de la interfaz gr´afica autom´atica 10h P 156.00 e200.15 e BG.5 Creaci´on del sistema switch entre texturas 15h BG.5.1 Investigaci´on 3h I 49.20 e63.12 e BG.5.2 Desarrollo 12h P 187.20 e240.18 e BG.6 Selecci´on de la interfaz gr´afica del switch 5h P 78.00 e100.07 e BG.7 Pruebas de validaci´on 20h T 264.80 e339.74 e CG Generaci´on de coordenadas de textura 210h - 3,012.00 e3,864.40 e CG.1 Sistema de relaci´on de objetos y formas volum´etricas 90h Investigaci´on 30h I 492.00 e631.24 e Desarrollo 60h P 936.00 e1,200.89 e CG.2 Sistema de separaci´on de objetos por cortes 60h Investigaci´on 20h I 328.00 e420.82 e Desarrollo 40h P 624.00 e800.59 e CG.3 Sistema de calidad de coordenadas 40h Investigaci´on 10h I 164.00 e210.41 e Desarrollo 30h P 468.00 e600.44 e CG.4 Pruebas de validaci´on 20h T 264.80 e339.74 e - Total 550h - 11,104.68 e14,247.30 e Tabla 2: Tabla donde se encuentran las diferentes tareas y su respectivas horas y el precio tanto para el trabajador como el dinero teniendo en cuenta las cotizaciones a la seguridad. Roles: C - Coordinador, I - Investigador, P - Programador, T - Tester. 20
3.2. Presupuesto gen´erico Dentro de los costes gen´ericos tendremos en cuenta todos los costes, no solo personales, de todo el proyecto. En este tipo de presupuesto entrar´an, por consiguiente, los costes de software,hardware y tambi´en todos los gastos de alojamiento. 3.2.1. Costes Software Para el desarrollo de nuestro proyecto hemos mencionado 6 programas necesarios para el desarrollo de este. Overleaf [25]: Herramienta que se utilizar´a el plan gratuito. Por lo tanto, no habr´a un coste asociado a este. Visual Studio Code [27]: Este editor de texto es gratuito. Por lo tanto, no hay un coste asociado a este. Blender [10]: Es un software de c´odigo abierto. Por lo tanto, no se le aplicar´a ning´un coste a esta herramienta. ImageMagick: Es un software gratuito. Por lo tanto, no comporta ning´un coste asociado a este. Github: Es una plataforma gratuita. Por lo tanto, no comporta ning´un coste asociado a esta. Google Meet: Es una plataforma gratuita. Por lo tanto, no comporta ning´un coste asociado a esta. Como podemos observar, en este proyecto no tenemos ning´un coste asociado a software debido a que las herramientas de trabajo se proporcionan de manera gratuita. 3.2.2. Costes Hardware Para la realizaci´on de este proyecto, el ´unico material necesario ser´an ordenadores. En este caso, debido a ser un proyecto del ´ambito de gr´aficos en computaci´on, tanto al rol de programador y de tester, se les tendr´a que proporcionar un ordenador con tarjetas gr´aficas de alta capacidad. A continuaci´on se muestra una tabla de amortizaciones con todos los materiales. Para calcular la amortizaci´on. Se ha utilizado la siguiente formula, donde se divide el precio del dispositivo entre el n´umero de horas de su vida ´util (en nuestro caso, en un a˜no hay de media 220 d´ıas laborales, donde se trabaja 8 horas diarias). Amortizacion = P recioDispositivo V idaUtil∗220∗8∗HorasUtilizadas. 21
Hardware Precio Unidades Vida ´util Horas totales de uso Amortizaci´on Port´atil 800 e2 4 a˜nos 331 horas 37,31 e Ordenador 1400 e2 4 a˜nos 326 horas 64,82 e Total - - - - 102,13 e Tabla 3: Tabla de costes relacionado con los costes de hardware. 3.2.3. Costes de alojamiento En la secci´on dedicada a la planificaci´on temporal se especific´o que todas las tareas se har´ıan en casa. Teniendo en cuenta que todas las tareas se har´an en un ordenador o port´atil, todas las tareas pueden tambi´en ser hechas en una oficina o coworking. Debido al tama˜no del equipo conformado en el proyecto, se ha optado por la utilizaci´on de un espacio de coworking para la realizaci´on del proyecto. Este espacio cuesta 216 eal mes, incluyendo en este los gastos de agua, electricidad, wi-fi y comida. El tiempo de realizaci´on del proyecto se tiene previsto en 5 meses, por lo tanto el coste asociado al alojamiento es de 1,080 e. 3.2.4. Costes de contingencia Con el objetivo de poder hacer frente a todos los costes planteados, incluso con obst´aculos e imprevistos. Se ha optado por hacer un presupuesto de contingencia, basado en un 20 % del total del presupuesto actual. A continuaci´on, se muestra una tabla con el coste de contingencia asociado a cada coste mencionado anteriormente. Tipo Coste Contingencia Personal 14,247.30 e2,849.46 e Software 0 e0e Hardware 102,13 e20.43 e Alojamiento 1,080 e216 e Total 15,429.43 e3,085.89 e Tabla 4: Tabla donde se muestran los costes y su correspondiente coste de contingencia. 3.2.5. Imprevistos A continuaci´on, se har´a un presupuesto para los imprevistos que pueden surgir durante la realizaci´on del proyecto. Aumento del tiempo de desarrollo: Con el objetivo de poder satisfacer los objetivos propuestos, si se viera una necesidad de aumentar el tiempo de desarrollo, se a˜nadir´ıa un tiempo adicional al desarrollo. Concretamente, ser´ıa 30 horas de 22
desarrollo y 15 horas al proceso de testing, que recaer´ıan directamente en el programador y tester. Por lo tanto, el coste total ser´ıa de 855.25e. Al ser un trabajo relacionado con investigaci´on de nuevas t´ecnicas, el riesgo de que ocurra es elevado. Concretamente se ha estimado en un 25 %. Fallo del hardware: Vemos que en este caso, lo necesario ser´a comprar hardware nuevo. Por lo tanto, el coste ser´a el estipulado en la tabla 3. Aun as´ı, se estima que la probabilidad de sufrir este imprevisto es del 5 %. A continuaci´on se muestra una tabla que muestra el coste resumido en los puntos anteriores: Imprevisto Coste Riesgo Coste total Aumento tiempo desarrollo 855.25 e25 % 213.81 e Port´atil 1 800 e5 % 40e Port´atil 2 800 e5 % 40 e Ordenador 1 1,400 e5 % 70 e Ordenador 2 1,400 e5 % 70 e Total 5,255.25 e433,81 e Tabla 5: Tabla de costes asociados a cada imprevisto mencionado. 3.2.6. Coste total Una vez calculados todos los costes relacionados con el desarrollo del proyecto, se hace el c´alculo total del desarrollo del proyecto. Para calcular el coste total se sumar´an todos los costes mencionados anteriormente. A continuaci´on se muestra una tabla a modo de resumen. Tipo de coste Coste Personal 14,247.30 e Software 0e Hardware 102,13 e Alojamiento 1,080 e Contingencia 3,085.89 e Imprevistos 433.81 e Total 18,849.13 e Tabla 6: Tabla de costes generales del proyecto 3.3. Control de gesti´on Para poder hacer un control de todas las posibles desviaciones que se pueden producir a lo largo de todo el desarrollo del proyecto. Se han propuesto una serie de descriptores num´ericos para un mejor control de estas desviaciones. 23
Este control se har´a durante las reuniones semanales. De esta manera se podr´a tener un control activo durante toda la realizaci´on del proyecto. A continuaci´on mostramos la lista de descriptores num´ericos que nos ayudar´an en el control: Desviaci´on total de horas:HorasReales −HorasEstimadas HorasEstimadas ∗100 Desviaci´on de los diferentes costes:CosteReal −CosteEstimado Desviaci´on coste de tarea: (HorasReales−HorasEstimadas)∗PrecioHoraTarea Rendimiento del coste:CosteEstimado CosteReal Rendimiento del tiempo empleado en tareas:TiempoEstimado TiempoEmpleado 4. Sostenibilidad A continuaci´on, se har´a una serie de an´alisis relacionados con la sostenibilidad y el desarrollo del proyecto. Concretamente, se har´a una autoevaluaci´on sobre la competencia de sostenibilidad. Posteriormente, se har´an 3 an´alisis (econ´omico, social y medioambiental) de las posibles repercusiones que puede generar el desarrollo del proyecto. 4.1. Autoevaluaci´on No solo a lo largo del Grado en Ingenier´ıa Inform´atica, sino tambi´en durante etapas anteriores como la educaci´on secundaria o el bachillerato, se nos ha estado explicando de varias maneras el concepto de sostenibilidad y cu´al es su importancia en nuestro d´ıa a d´ıa. Por lo tanto, como ingenieros que queremos llegar a ser, es de entender que este tema debe de ser tratado con suma rigurosidad en todo proyecto que realizamos durante el transcurso de nuestra vida. A´un as´ı, este tema es de dif´ıcil tratamiento. Todo esto debido a que a´un no somos conscientes de todas las implicaciones que podemos llegar a tener cuando realizamos un proyecto. Desde un punto de vista personal, siempre he relacionado el concepto de sostenibilidad con un concepto medioambiental y no es del todo incorrecto. En todo desarrollo de proyecto no solo existe un solo proceso implicado. Podr´ıamos decir que, para poder establecer una base la cual nosotros poder trabajar, se han tenido que dar varios procesos que puede que no sean vistos a primera vista. A´un as´ı, el concepto de sostenibilidad necesita ser complementado con otros dos conceptos que son de suma importancia para la humanidad. El siguiente concepto ser´ıa el econ´omico. Este tambi´en es un concepto que est´a bastante extendido en todo el ´ambito laboral, ya que no carece de importancia. El dinero actualmente es nuestro mecanismo de regulaci´on de recursos. En consecuencia, hacer un estudio extenso de este nos ayuda a no desaprovechar recursos y ayudar a todo el planeta. 24
Por ´ultimo, tenemos el ´ambito social. En opini´on propia, este concepto ha sido el m´as desapercibido para m´ı. Pero gracias a los recientes acontecimientos ocurridos alrededor del mundo, veo cada vez m´as su importancia para el bienestar de la humanidad. Bas´andome en lo dicho anteriormente, pienso que este estudio se deber´ıa de hacer en todo trabajo, independientemente de su naturaleza. Todo esto debido para poder saber todas las implicaciones que un proyecto puede tener. 4.2. ´ Ambito econ´omico Desde el punto de vista econ´omico podemos ver que el coste asociado a la realizaci´on del proyecto es adecuado teniendo en cuenta las implicaciones de uso del proyecto. Estas implicaciones van relacionadas con la reducci´on del tiempo de trabajo del usuario para generar texturas y tambi´en coordenadas de texturas. Por ejemplo, el uso inicial de esta extensi´on era el de generar texturas para modelos hist´oricos. Estos modelos presentan la dificultad de ser muy complejos geom´etricamente, hasta el punto de poder tener un material asociado para cada cara de este. Esto puede entonces suponer horas o incluso d´ıas solo en generar texturas. Por lo tanto, ayudar a automatizar este proceso ayuda a reducir el tiempo de dedicaci´on, lo que se traduce en un descenso del coste asociado a la realizaci´on de esa tarea. A su vez, al ser una extensi´on gratuita, esta podr´a ser utilizada en otros trabajos. Esto har´a que tambi´en puedan hacer uso de estas funcionalidades y poder optimizar su desarrollo. Ayudando a reducir costes. 4.3. ´ Ambito social En el ´ambito social y como se ha mencionado en el ´ambito econ´omico. El uso inicial de esta extensi´on es la generaci´on de texturas y coordenadas de texturas de modelos hist´oricos. Ayudar a optimizar este proceso ayudar´a a generar modelos que se vean de manera fiel al modelo y de forma r´apida. Esto har´a que las personas puedan aprovechar estos modelos de forma m´as temprana compar´andolo con hacer el proceso manual. Esto tambi´en desemboca en poder hacer otros proyectos de culturizaci´on de la poblaci´on de manera m´as anticipada, al tener todo lo necesario con mucha m´as antelaci´on de lo que se har´ıa hasta ahora. A su vez, optimizar y reducir estos procesos har´a que se puedan beneficiar de otros de mayor inter´es para la sociedad. Esto es debido a que la extensi´on no solo puede ser utilizada en este ´ambito mencionado en el p´arrafo anterior, sino tambi´en en otros como arte, animaci´on, videojuegos, etc. 4.4. ´ Ambito medioambiental La realizaci´on de este proyecto no supone un gran impacto medioambiental. ´ Unicamente la construcci´on y funcionamiento de los dispositivos electr´onicos suponen un impacto 25
negativo a este. Para poder mitigar este impacto, ser´ıa optar por soluciones m´as baratas que no llegaran a consumir tantos recursos. A´un as´ı, debido a los requisitos de este proyecto para poder ejecutar Blender, esta idea solo se podr´ıa utilizar para los ordenadores dedicados a la documentaci´on e investigaci´on del proyecto. Otra manera de mitigar es optar por ordenadores de segunda mano. Este enfoque tambi´en es preferente para los ordenadores dedicados a la documentaci´on e investigaci´on. No obstante, tambi´en puede ser aplicado a ordenadores de desarrollo y testeo. Esta alternativa ayudar´ıa al reciclaje y a una mejor gesti´on de los recursos que hay en el planeta. 26
5. MVP Con el objetivo de poder entender el desarrollo del MVP, se necesita explicar una serie de conceptos relacionados con la estructura de Blender y c´omo este gestiona todas las entidades. A continuaci´on, en la Secci´on 5.1 se explicar´an los elementos a tener en cuenta para la realizaci´on de cada una de las funcionalidades propuestas. Una vez explicados los conceptos, en la Secci´on 5.2 se har´a la explicaci´on de las funcionalidades propuestas y las implementaciones utilizadas. Por ´ultimo, en la Secci´on 6 se mostrar´an las pruebas realizadas a las diferentes funcionalidades. 5.1. Conceptos 5.1.1. Propiedades En Blender existe el concepto de “propiedades”. Estas son las encargadas de guardar la informaci´on del proyecto en la aplicaci´on y, a su vez, hacen de puente entre el usuario y la API. Para entender mejor este concepto, tenemos que explicar los 2 tipos de propiedades que existen en Blender: Propiedades DNA: Estas se encargan de almacenar todos los datos que tienen que ser persistidos en memoria. Esto no quita que tambi´en puedan ser utilizados durante la ejecuci´on del proyecto. Un ejemplo de este tipo de propiedades son los tipos Material oMesh [32]. Propiedades RNA: Este tipo de propiedades se caracteriza por darnos una forma sencilla de interactuar con las propiedades DNA. Este tipo de propiedades est´an preestablecidas, como se muestra en la Figura 4, pero tambi´en se nos ofrece crear combinaciones de estas [33]. 27
Figura 4: Imagen gr´afica donde muestra las diferentes propiedades RNA [34]. (Fuente de la imagen: [33]) Como podemos ver, tenemos dos tipos de propiedades en Blender con el objetivo de gestionar un archivo y todo el proyecto que contiene. A su vez, gracias a la utilizaci´on de Python como lenguaje de scripting, se puede hacer uso de las diferentes estructuras que ofrece el lenguaje. El ´unico inconveniente es que estas son estructuras temporales que solo estar´an presentes durante la ejecuci´on del proyecto. Es decir, no se guardar´a en el archivo de Blender el contenido de estas estructuras. A diferencia de las estructuras creadas a partir de propiedades RNA, que s´ı se preservan. 5.1.2. Mesh La propiedad mesh o malla es esa propiedad caracter´ıstica de todos los modelos 3D de Blender. La propiedad tiene acceso a diferentes aspectos relacionados con la malla [35]. Los utilizados en la realizaci´on de este trabajo son los siguientes: Poligons: Esta propiedad nos da todos los pol´ıgonos involucrados en la malla del objeto. Cada pol´ıgono, por su parte contiene informaci´on de sus v´ertices, material asociado y coordenadas asociadas [36]. Materials: Los materiales son los encargados de almacenar y mostrar caracter´ısticas relacionadas con el color de los materiales [37]. En Blender, los materiales pueden tener asociado un mapa de nodos que representa las diferentes cualidades del material. En la Figura 5 se muestra una imagen correspondiente a un mapa de nodos. 28
Figura 5: Imagen correspondiente al mapa de nodos de un material. (Fuente de la imagen: [38]) UV layers: Los mapas UV son las traducciones que se hacen a cada coordenada del modelo a una coordenada de textura [39]. Un modelo puede tener en su interior m´as de un mapa de UV y que a su vez, puede utilizar m´as de uno. Esto es mediante la selecci´on de los mapas UV durante la creaci´on de un material. Como podemos ver, la propiedad Mesh ser´a con la que trabajaremos para poder hacer tanto la funcionalidad de Baking como la generaci´on de coordenadas de textura. 5.2. Funcionalidades Una vez explicados los conceptos relativos a Blender y el proyecto. Procederemos a la explicaci´on de las diferentes funcionalidades propuestas para el MVP. A su vez, para poder explicar estas funcionalidades, se establecer´a primero unos criterios iniciales para la creaci´on de estos modelos. 5.2.1. Criterios iniciales Para la creaci´on de las diferentes funcionalidades del MVP. A continuaci´on se establecen unos requisitos iniciales que todo modelo debe tener para poder ser utilizado en las funcionalidades. Para la funcionalidad del Baking se tendr´an en cuenta estos criterios: Todo modelo tiene asociado 1 mapa de texturas o UV map. Posterior al desarrollo del MVP, se har´a un estudio para poder hacer Baking de modelos con m´as de 1 mapa de texturas sin la intervenci´on del usuario. Para las funcionalidades relacionadas con el tema de la parametrizaci´on, se tendr´an en cuenta estos criterios: 29
Como podemos observar, este proceso funciona a nivel de objeto, es decir, esto se hace por cada objeto al que se le quiere aplicar el Baking. A su vez, teniendo en cuenta lo dicho en la Secci´on 5.1.2 acerca de la capacidad de cada pol´ıgono de una mesh de tener un material asociado. En el peor de los casos, se puede llegar a tener tantos materiales como pol´ıgonos tenga la mesh a hacer Baking. Bas´andonos en lo mencionado anteriormente, se quiere extender para poder utilizarse con varios modelos y con la m´ınima intervenci´on por parte del usuario. A su vez, como consideraci´on extra, se utilizar´a la automatizaci´on del proceso de Baking sobre propiedades ´opticas. Esto es debido a que para hacer Baking sobre propiedades vectoriales, como las normales del modelo, es necesario utilizar el modelo original y un “modelo recipiente” donde se proyectar´an las normales del modelo original [53]. A continuaci´on, con todo lo mencionado, se ha dise˜nado este algoritmo: Algorithm 2 Algoritmo de Baking automatizado Par´ametros: modelos seleccionados: Lista de modelos a procesar. anchura: Anchura de la imagen a generar. altura: Altura de la imagen a generar. propiedades: Propiedades de baking a aplicar. ruta: Ruta donde se guardar´a la imagen. for modelo ∈modelos seleccionados do imagen ←Imagen(anchura,altura) for poligono ∈modelo.poligonos do material ←poligono.material if material no tiene una copia ya creada then material baked ←Copia(material) nodo textura ←Nodo textura(imagen) Seleccionar nodo textura A˜nadir nodo textura amaterial baked material baked.nodos.activo ←nodo textura poligono.material ←material baked else poligono.material ←Copia de material ya creada end if end for Seleccionar modelo Bake(Modelo, propiedades) Guardar imagen en ruta for poligono ∈modelo.poligonos do Restaurar material original end for end for 5.2.2.3. Configuraci´on manual 36
Una vez establecido el algoritmo te´orico por el cual se fundamenta la funcionalidad de la automatizaci´on del proceso de Baking, se explicar´a a continuaci´on qu´e par´ametros puede manipular el usuario para poder hacer uso de esta funcionalidad. Primeramente, podemos hacer una diferenciaci´on entre los par´ametros dependiendo de qu´e elemento est´e configurando. Podemos entonces diferenciar en 3 grandes bloques: par´ametros de motor gr´afico, par´ametros de resultado y par´ametros de Baking. Los par´ametros de motor gr´afico son aquellos a los que su configuraci´on afecta tanto a su elecci´on como a las capacidades de ´este. Actualmente, Blender ofrece estos par´ametros relacionados con el motor gr´afico: Tipo: En Blender actualmente existen 2 motores gr´aficos, EEVEE yCycles. Por el momento, el ´unico motor que soporta la funcionalidad de Baking es Cycles. Esto hace que, aunque pueda ser un par´ametro configurable, en nuestro caso, sea necesario fijarlo a un determinado valor. Es decir, es necesario fijarlo a Cycles para poder hacer uso de la funcionalidad. Dispositivo: El dispositivo es el tipo de unidad de procesado que el motor gr´afico utilizar´a para poder hacer el proceso de Baking. En este caso, este proceso se puede hacer con la utilizaci´on de la CPU o GPU. Vemos que ambas opciones son importantes para el usuario a tener en cuenta. Todo esto debido a las posibles capacidades que puede tener el ordenador que utiliza esta funcionalidad y tambi´en las necesidades de recursos que puede tener el usuario. Por estas razones, este par´ametro forma parte de la configuraci´on manual que se ofrece. Por otra parte, tenemos que los par´ametros de resultado son aquellos que se relacionan con la especificaci´on de la imagen resultado que se crea. Para la funcionalidad nos hemos centrado en los principales aspectos de una imagen. A continuaci´on se muestran los par´ametros estudiados: Dimensiones: Vemos que las dimensiones de imagen est´an relacionadas con un aspecto que el usuario es muy posible que quiera modificar. Este aspecto es el nivel de detalle del resultado. Es por esto que tanto la altura como la anchura de la imagen resultado forman parte de los par´ametros seleccionados. Localizaci´on de guardado: El resultado del proceso de Baking es com´unmente utilizado en diferentes proyectos que puede no tener que ser relacionados con Blender. Ejemplos de estos, son videojuegos, pel´ıculas, realidad virtual, entre otros. Por lo tanto, existe una necesidad de poder exportar el resultado al disco duro. A causa de esto, para poder solventar esta necesidad, el usuario puede introducir la localizaci´on de guardado de la imagen. Formato: Para este par´ametro, debido a la necesidad de poder ser exportado y utilizado en una gran variedad de entornos, se estudi´o la implementaci´on de elegir entre formato JPEG yPNG. A´un as´ı, vimos un problema con uno de los formatos y la necesidad de poder dar resultados fieles al proceso. Ambos formatos utilizan un m´etodo de compresi´on basado en 2 principios diferentes [54]. A continuaci´on se hace una explicaci´on de los dos principios: 37
•Compresi´on Lossless: Principio utilizado en PNG, se basa en comprimir la informaci´on de tal manera que se pueda volver a recomponer toda la informaci´on original en todo momento. Es decir, no hay p´erdida de informaci´on durante la compresi´on [55]. •Compresi´on Lossy: Principio utilizado en JPEG, se basa en comprimir la imagen superando el l´ımite dado por la entrop´ıa de un canal de informaci´on [55]: H(X) = −X i p(xi) log2p(xi) Para esto, se recurre a la p´erdida de parte de la informaci´on durante el proceso de compresi´on. Esto hace que el resultado de recuperado no sea igual a la informaci´on original. Debido a que nuestro objetivo es dar resultados fieles al resultado generado por el proceso de Baking y tambi´en los posibles usos de la funcionalidad en creaci´on de texturas de alto nivel de detalle de modelos de patrimonio hist´orico. Se ha optado por la utilizaci´on del formato PNG como formato predeterminado para la funcionalidad creada. Por ´ultimo, tenemos los par´ametros de Baking. Estos est´an relacionados con la configuraci´on del Bake, ofrecido por Blender. A continuaci´on se muestran los par´ametros estudiados: Lista de objetos: Este es el par´ametro cr´ıtico y de mayor importancia para la funcionalidad. Ya que la funcionalidad se centra en poder hacer Baking a un conjunto de modelos 3D que el usuario introduce previamente. Tipo de Bake:Blender ofrece un conjunto de caracter´ısticas para poder hacer Bake. Como se dijo en la Secci´on 5.2.2.2, se quiere hacer el proceso sobre propiedades relacionadas con el color. Por lo tanto, a continuaci´on se muestran las propiedades escogidas para el dise˜no: Concepto Descripci´on Combined Combinaci´on de diversas propiedades. Ambient Occlusion Exposici´on a la luz ambiente. Emit Emisi´on del material. Normalmente, esta en materiales capaces de emitir luz. Environment Exposici´on al entorno. Normalmente utilizado para simular materiales que reflejan la luz, como cristales o espejos. Roughness Rugosidad del material. Afecta a como el color del material se puede llegar a ver. Diffuse Componente difusa del color. Glossy Componente que simula el brillo de la superficie. Tabla 7: Tabla donde se muestran los tipos de Bake y una breve descripci´on de estos. Contribuciones: Por cada tipo de Bake pueden existir una serie de contribuciones que afectan al resultado final. Estas tienen como objetivo a˜nadir m´as detalles 38
relacionados con el tipo de Bake. A continuaci´on se muestra con las contribuciones asociadas a cada tipo de Bake: Concepto Contribuci´on Combined Luz directa, luz indirecta, color base, componente difusa, componente glossy, componente transmission y componente emit. Diffuse yGlossy Luz directa, luz indirecta y color base. Tabla 8: Tabla donde se muestran las contribuciones que se pueden agregar a cada tipo de Bake. Tipo de margen: Durante la realizaci´on del proceso se le a˜nade un margen extra al resultado, con el objetivo de que al acceder justo en los l´ımites del pol´ıgono no exista ning´un error. Estos errores pueden pasar debido a la limitaci´on que presenta la codificaci´on en coma flotante de ciertos n´umeros, haciendo que en ciertos casos se pierda precisi´on y por lo tanto se llegue a acceder a una coordenada diferente a la especificada (normalmente se accede a una coordenada cercana a esta). Por lo tanto, se utiliza este margen para que, si llegan a acceder a coordenadas incorrectas, obtengan el valor correspondiente. Actualmente existen 2 tipos de margenes: Concepto Explicaci´on Adjacent Faces El margen de un pol´ıgono est´a conformado por p´ıxeles que pertenecen a pol´ıgonos que son adyacentes entere si. Extend El margen est´a conformado por una extensi´on del pol´ıgono hacia fuera de este. Tabla 9: Tabla de tipos de margenes existentes en Blender. Por cada uno se hace una explicaci´on sobre que consiste el m´etodo. 5.2.2.4. Configuraci´on Autom´atica El objetivo de esta funcionalidad es proporcionar al usuario menos experimentado con los diferentes par´ametros del Baking una manera accesible e intuitiva de hacer uso de la funcionalidad explicada en el apartado anterior. Por lo tanto, nuestro foco estar´a puesto en dar diferentes niveles de detalle a cambio de un mayor consumo de recursos del algoritmo. Si analizamos los diferentes par´ametros que contribuyen al nivel de detalle de las texturas generadas, podemos encontrar principalmente 2 par´ametros: Tama˜no de la textura: Esto es debido a que estamos intentando discretizar un espacio de dos dimensiones en una matriz en un ordenador. Como podemos ver en la Figura , vemos c´omo la discretizaci´on de una imagen en dos tama˜nos diferentes afecta al nivel de detallismo de esta. 39
Figura 11: Comparativa donde se puede ver los efectos del nivel de discretizaci´on en el nivel de detalle que presentar´ıa la representaci´on de un circulo de color azul. (Fuente de la imagen: [56]) A´un as´ı, el tama˜no de textura est´a directamente relacionado con el tiempo de ejecuci´on del algoritmo. Es decir, a m´as resoluci´on tiene la textura, el algoritmo tiende a tardar m´as tiempo en ejecutarse. Margen: Como se mencion´o en la Secci´on 1.1.1.4, la coma flotante tiene problemas de precisi´on en la representaci´on de n´umeros. En este caso, las coordenadas de textura de aristas pueden sufrir problemas al acceder a textura. Por esta raz´on, una manera para mitigar este problema es mediante la implementaci´on de un margen alrededor del resultado del Baking. Aun as´ı, el tiempo de ejecuci´on del algoritmo no solo se ve afectado por el tama˜no del margen, sino tambi´en por el m´etodo. El menos costoso de los m´etodos explicados en la Secci´on 5.2.2.3 es el m´etodo Extend ya que se extienden los bordes del pol´ıgono. Pero este m´etodo puede tener fallos en el nivel de detallismo cuando las coordenadas de textura entre pol´ıgonos est´an muy juntas. Ya que los bordes podr´ıan solaparse. Esto mencionado anteriormente se puede observar en la Figura 12: Figura 12: Imagen donde se puede ver el solapamiento en la textura debido al uso del m´etodo Extend para los margenes. (Fuente de la imagen: [57]) Por esto, la t´ecnica que ofrece mejores resultados es Adjacent Faces, pero supone un mayor coste algor´ıtmico. 40
A partir de este an´alisis hemos optado por 3 configuraciones. Estas son: Configuraci´on Descripci´on Low Tama˜no de textura de 512*512 pixeles y con un margen de 16 pixeles del tipo Extend. Medium Tama˜no de textura de 1024*1024 pixeles y con un margen de 16 pixeles del tipo Adjacent Faces. High Tama˜no de textura de 2048*2048 pixeles y con un margen de 32 pixeles del tipo Adjacent Faces. Tabla 10: Tabla donde se muestra las diferentes configuraciones autom´aticas disponibles y una breve descripci´on de ellas. (Elaboraci´on propia) 5.2.2.5. Switch Con el objetivo de ayudar a los usuarios a poder observar los resultados del proceso de Baking de manera sencilla, se implementa este mecanismo de switch. Podemos separar el mecanismo de switch en 3 grandes aspectos que son esenciales para entender su funcionamiento. El primero de todos es la preparaci´on de las estructuras necesarias para poder hacer uso del mecanismo de switch. Para que el mecanismo necesita una estructura que preserve, en todo momento, por cada objeto que se ha sometido al proceso de Bake, el material original y el material que contiene la textura generada por el proceso de Baking. Por lo tanto, se opta por hacer una estructura basada en las propiedades RNA (ver Secci´on 5.1.1). Concretamente, la estructura mencionada contiene los siguientes atributos por cada objeto a guardar: Name (String): Nombre del objeto que se ha hecho Bake. Bake Type (String): Nombre de la propiedad que se ha hecho Bake. Is Valid (Boolean): Indica si la representaci´on del objeto en esta estructura contiene o no alg´un error. Polygons (Colecci´on de struct): Contiene la informaci´on que tiene cada pol´ıgono del objeto, esencial para poder cambiar entre material original y material Baked. Concretamente, tiene los siguientes atributos. •Index (Int): Identificador del pol´ıgono en el objeto. •Original material index (Int): Identificador del material original. •Bake material index (Int): Identificador del material generado por el proceso de Baking. 41
A su vez, para poder utilizar esta estructura, se ha de integrar con el algoritmo de Baking para que esta estructura contenga la informaci´on de los objetos que han sido sometidos al proceso de Baking. Por eso se a˜naden estos 2 procedimientos al algoritmo general: A˜nadido de la informaci´on: Durante la ejecuci´on se a˜naden todos los atributos previamente mencionados. A su vez, si se detecta alg´un error en el proceso de Baking de este objeto, se procede a eliminar esta informaci´on de la estructura. Generaci´on de materiales Baked: Posterior a la ejecuci´on de hacer el Bake del objeto. Se generan todos los materiales Baked. Concretamente, se genera un material Baked por cada material original. Esto se hace para poder asegurar que podamos hacer una conversi´on entre material original y material original. Es decir, necesitamos que la transformaci´on se pueda invertir. Por lo tanto, esta transformaci´on debe de ser biyectiva. Posterior a la preparaci´on del switch viene la ejecuci´on del algoritmo, para esto se muestra el Algoritmo 3 por el cual se basa nuestro mecanismo de switch. Algorithm 3 Algoritmo te´orico para aplicar el switch Par´ametros: info: Lista de informaci´on de modelos procedente de la estructura switch: Booleano para determinar si queremos pasar a material original o Baked for modelo ∈info do if info es valido then modelo original ←modelo con identificador material.name for poligono ∈modelo.polygons do poligono ←poligono correspondiente a poligono.index if switch then Asignar a poligono el material baked else Asignar a poligono el material original end if end for end if end for Por ´ultimo, para poder utilizar este mecanismo incluso con modificaciones de los modelos a posteriori, se necesita explicar el proceso de mantenimiento. Para esto, se hace uso de una funcionalidad llamada Handlers. Un handler es una funci´on que se ejecuta ante la aparici´on de ciertos eventos. En Blender concretamente existe un handler para poder gestionar modificaciones de los objetos. Este handler por lo tanto, reconstruir´a la estructura para esos modelos que est´en en ella y hayan sido modificados. 42
A su vez, este handler no considera como modificaci´on la eliminaci´on del objeto. Es por esto que, en un principio, se contempl´o la posibilidad de sobrescribir el operador de delete que ya viene implementado en Blender. Desafortunadamente, esta idea se descart´o debido a que Blender prohibi´o la sobreescritura de operadores b´asicos. Por lo tanto, se opt´o por hacer un operador adicional que nos ayudase a gestionar el caso de eliminaci´on de objetos. A su vez, se cambiaron los atajos de teclado y se a˜nadi´o una opci´on extra en el men´u de objetos para poder hacer uso de esta funcionalidad, todo esto con el objeto de que el usuario note la m´ınima diferencia entre utilizar el operador original y el implementado. A continuaci´on, en la Figura 13 se muestra una imagen del resultado: Figura 13: Imagen del men´u objeto donde se observa la opci´on a˜nadida ”Delete Everywhere”. (Elaboraci´on propia) Por ´ultimo, como se ha dicho anteriormente, este handler se activa cuando se modifica un objeto. Concretamente en cambios de geometr´ıa y de apariencia. Por lo tanto, este handler se puede ejecutar durante la ejecuci´on del propio algoritmo de Baking y tambi´en 43
del algoritmo de switch. En consecuencia, con el objetivo de evitar esto, el handler solo se ejecutar´a si ninguno de estos 2 procesos est´a activo. Para poder satisfacer el objetivo mencionado anteriormente, hemos creado una estructura de datos RNA de comunicaci´on donde el handler podr´a acceder al estado de estos procesos. A su vez, los diferentes procesos tambi´en podr´an registrar su estado de ejecuci´on. Esta estructura de datos contiene los siguientes atributos: Baking active (Boolean): se encarga de informar si el proceso de Baking est´a siendo ejecutado. Para esto, antes de la ejecuci´on de este, se asignar´a a True este atributo. Posteriormente, se asignar´a False al acabar el proceso. Switch active (Boolean): se encarga de informar si el algoritmo de switch est´a siendo ejecutado. Para esto, antes de la ejecuci´on de este, se asignar´a a True este atributo. Posteriormente, se asignar´a False al acabar el proceso. 5.2.2.6. Interfaz gr´afica Con el objetivo de poder dar al usuario una experiencia m´as cercana a la utilizaci´on de la herramienta de Baking existente en Blender, se ha hecho una interfaz gr´afica siguiendo mayoritariamente el estilo que tiene la interfaz gr´afica asociada a esta herramienta. La API de Blender utiliza el concepto de paneles para poder generar la interfaz gr´afica. A su vez, estos paneles pueden ser subpaneles de otro panel y as´ı conforman una jerarqu´ıa entre ellos, justo como se puede ver en la Figura 14: 44
Figura 14: Imagen donde se muestra la interfaz de basada en paneles y subpaneles de todas las funcionalidades relacionadas con el Baking. (Elaboraci´on propia) A continuaci´on se muestran una serie de tablas, correspondientes a las diferentes funcionalidades relacionadas con el proceso de Baking, con los diferentes tipos de paneles creados. Configuraci´on Manual Para la funcionalidad de Baking con configuraci´on manual, se ha optado por esta distribuci´on de paneles: 45
Figura 18: Imagen donde se muestra un cubo dentro de una esfera. (Fuente de la imagen: [63]) Un caso com´un es un cubo como en la Figura 18. Si se intenta ajustar la forma volum´etrica id´onea para un cubo y solo teniendo en cuenta sus v´ertices, entonces una esfera puede ajustarse. Esto es debido a que los 8 v´ertices pueden formar parte de la superficie de la esfera. Como se muestra en la Figura 18. Para poder mitigar este caso, se puede ver que se ha apostado por la implementaci´on de un super-sampling de las caras. En otras palabras, se hace un muestreo extra donde se escogen al azar puntos de cada cara del modelo. El n´umero de puntos es un par´ametro que el usuario puede escoger mediante la manipulaci´on de una variable “densidad”, cuya unidad es puntos/unidad2. Es decir, el usuario puede manipular cu´antos puntos por ´area tiene el modelo. Por ´ultimo, este algoritmo, debido a que genera un nuevo mapa de coordenadas de textura en un modelo 3D. Este puede activar el handler hecho para la funcionalidad del switch. Por lo tanto, para que no se ejecute a la vez que estamos haciendo la proyecci´on, se ha incluido en la estructura de comunicaci´on el siguiente atributo: Ransac active (Boolean): Se encarga de informar si el algoritmo de parametrizaci´on est´a siendo ejecutado. Para esto, antes de la ejecuci´on de este, se asignar´a a True este atributo. Posteriormente, se asignar´a False al acabar el proceso. 5.2.3.3. Separador de Mallas Para poder ayudar a mejorar la calidad de las parametrizaciones obtenidas con la funcionalidad mencionada anteriormente, se propone un separador de mallas. El objetivo de esta funcionalidad es separar mallas para posteriormente poder aplicar el algoritmo de parametrizaci´on a cada una de las separaciones. Como se ha mencionado anteriormente, esta funcionalidad se crea con el prop´osito de mejorar la calidad de las parametrizaciones. Esto es debido a la idea en la que est´a basada la funcionalidad: una malla compleja puede ser descrita como una uni´on de diferentes 52
submallas m´as simples. Por lo tanto, la parametrizaci´on se puede describir como la parametrizaci´on de submallas m´as simples. Un ejemplo de esto se puede ver en la Figura 19. Figura 19: Imagen de un modelo maniqu´ı donde se puede apreciar la formaci´on de una estructura humanoide a partir de estructuras m´as simples. (Fuente de la imagen: [64]) Debido a la complejidad asociada con la elecci´on de los lugares donde realizar la separaci´on, se propone un proceso semiautom´atico en el que el usuario solo tiene que seleccionar los v´ertices de la malla por donde se har´a el corte. En un principio, para hacer esta funcionalidad se quer´ıa hacer uso de la funci´on de Blender bpy.ops.mesh.shortest_path_select, que seleccionando 2 v´ertices calcula el camino con m´ınima distancia. Pero debido a la utilizaci´on del entorno bmesh utilizado en el modo edici´on de Blender, no es posible una integraci´on entre el entorno y la funci´on. Esto es debido a que para utilizar bmesh en un modelo, este tiene que ser cargado en este entorno. Entonces el paso del modelo entre los diferentes entornos (bmesh yBlender) hace que la informaci´on no persista en ambos entornos. Por lo tanto, se ha optado por hacer una implementaci´on del algoritmo de Dijkstra [65] para calcular el camino m´ınimo entre 2 v´ertices. Con todo lo mencionado anteriormente, se ha creado el Algoritmo 5. 53
Algorithm 5 Algoritmo te´orico de separador de mallas Par´ametros: mesh: Malla 3D con poligonos. v seleccionados: v´ertices del modelo seleccionado ordenado cronol´ogicamente por la selecci´on. aristas ← ∅ for vertice, siguiente vertice ∈v seleccionados do p aristas ←Dijkstra(mesh, vertice, siguiente vertice) aristas ←aristas ∪p aristas end for if |v seleccionados|>= 3 then vert ini ←v seleccionados.first vert fin ←v seleccionados.last p aristas ←Dijkstra(mesh, vert ini, vert fin) aristas ←aristas ∪p aristas end if for arista ∈aristas do arista.marca ←T rue end for poligono ←mesh.poligonos.first cc ←Pol´ıgonos conectados a poligono y teniendo como l´ımite las marcas puestas Separamos cc de mesh Como podemos observar, el algoritmo tiene como input un ciclo formado por los v´ertices seleccionados. Este ciclo tiene como objetivo separar 2 regiones del modelo. Por ´ultimo, este algoritmo, al estar modificando la geometr´ıa del modelo 3D, puede llegar a activar el handler que se implement´o para el sistema del switch. Por lo tanto, para que no se ejecute a la vez que estamos haciendo el proceso de separado, se ha incluido en la estructura de comunicaci´on el siguiente atributo: Mesh Separator active (Boolean): Se encarga de informar si el algoritmo de separado de mallas est´a siendo ejecutado. Para esto, antes de la ejecuci´on de este, se asignar´a a True este atributo. Posteriormente, se asignar´a False al acabar el proceso. 5.2.3.4. Interfaz Gr´afica Para poder hacer uso de las funcionalidades descritas anteriormente, se ha hecho una interfaz gr´afica. Esta interfaz gr´afica tiene el objetivo de ser simple y de seguir el flujo que tiene Blender para este tipo de funcionalidades. Por lo tanto, se ha decidido separar las funcionalidades de la interfaz en 2 partes: Selecci´on del modelo: Esta parte de la funcionalidad se hace mediante el visor gr´afico existente en la aplicaci´on. De esta manera hacemos que el usuario acostumbrado a Blender tenga una asimilaci´on sencilla de la funcionalidad. 54
Selecci´on de par´ametros y ejecuci´on: Esta parte se hace mediante la creaci´on de una interfaz visual donde el usuario pueda interactuar con los elementos necesarios. Todo esto se puede ver en la Figura 20 Figura 20: Imagen donde se muestra la interfaz gr´afica con la selecci´on de par´ametros y ejecuci´on de las funcionalidades relacionadas con la secci´on de parametrizaci´on. (Elaboraci´on propia) Algoritmo de parametrizaci´on Para la interfaz gr´afica asociada al algoritmo de parametrizaci´on se ha optado por este esquema de paneles: Nombre Padre Descripci´on ParametrizationPanel -Panel principal de la funcionalidad. Este tiene incorporado el bot´on por el cual se ejecutar´a la funcionalidad de parametrizaci´on IterationsPanel ParametrizationPanel Panel encargado de establecer el n´umero de iteraciones que hace RANSAC para identificar la forma id´onea. Para establecer el n´umero de iteraciones se hace uso de un campo num´erico. DensityPanel ParametrizationPanel Panel encargado establecer el par´ametro de densidad el cual ser´a utilizado para el super-sampling. Para poder llevar a cabo esto se har´a uso de un campo num´erico. VerbosePanel ParametrizationPanel Panel encargado de indicar al algoritmo si quiere mostrar informaci´on acerca de la ejecuci´on del algoritmo o no. Para llevar a cabo esto se hace uso de una checkbox. Tabla 14: Tabla donde se muestra los diferentes paneles para la secci´on de la parametrizaci´on. 55
Separador de mallas Para la funcionalidad del separador de mallas se ha optado por este esquema de paneles: Nombre Padre Descripci´on MeshSeparatorPanel - Panel principal de la funcionalidad. Este panel contiene el bot´on que se encarga de ejecutar el algoritmo de separador de mallas. Tabla 15: Tabla donde se muestra los diferentes paneles para la secci´on del separador de mallas. 5.2.4. Analizado de parametrizaciones Con el objetivo de poder explicar la calidad de las parametrizaciones de una malla, se ha propuesto hacer una funcionalidad de analizado. Actualmente existen diferentes t´ecnicas que se utilizan para poder analizar las parametrizaciones existentes. A continuaci´on se muestra una serie de m´etodos de amplio uso. Informaci´on visual: En este tipo de m´etodo se utiliza la parametrizaci´on existente y, mediante diferentes indicativos visuales (predominantemente mediante el uso del color), se indica la calidad de una textura. Es id´oneo para mostrar de manera precisa informaci´on que afecta a una regi´on en concreto de la parametrizaci´on, como se puede ver en la Figura 21. Figura 21: Ejemplo donde se muestra la deformaci´on de la parametrizaci´on de manera visual. (Fuente de la imagen: [66]) Estad´ısticos: En este tipo de m´etodo se intenta cuantificar de manera num´erica la calidad de las parametrizaciones. Esta t´ecnica sirve para poder clasificar de manera general toda la parametrizaci´on. Esta t´ecnica es ampliamente utilizada en 56
otros campos aparte de los gr´aficos por computador, como por ejemplo, inteligencia artificial, procesamiento de im´agenes, simulaci´on, entre otros. Estos estad´ısticos utilizan principalmente los valores propios de una matriz relacionada con la transformaci´on de coordenadas de modelo a coordenadas de textura. Concretamente, estos valores representan la longitud de los ejes de cada pol´ıgono. De esta manera podemos ver si ha deformado alguno de sus 2 ejes principales [18]. Gr´aficos: Este m´etodo combina la sencillez de los estad´ısticos con la precisi´on de la informaci´on visual. El objetivo de este m´etodo es generar un diagrama, como por ejemplo un diagrama de barras, que ayude a entender de manera m´as precisa la calidad y los posibles errores que tiene una parametrizaci´on. Como podemos observar, existen diferentes m´etodos para describir la calidad. Cada uno de ellos, comporta un nivel de dificultad asociado a su implementaci´on. A su vez, vemos que cada uno ofrece un nivel de detallismo en su explicaci´on diferente entre s´ı. Aunque utilizar el m´etodo de Informaci´on Visual es el que ofrece un nivel m´as preciso para evaluar las parametrizaciones. Este tiene un coste de implementaci´on muy elevado, debido a su complejidad en la implementaci´on. Por esta raz´on, se ha decidido implementar el an´alisis de parametrizaciones teniendo en cuenta los m´etodos estad´ısticos y gr´aficos. De esta manera, se ofrece una forma de poder analizar las texturas de manera precisa, mientras que la complejidad de su implementaci´on permite ser creada en los tiempos establecidos. 5.2.4.1. Estad´ısticos A continuaci´on se explicar´an los diferentes estad´ısticos implementados (tanto estad´ısticos num´ericos como gr´aficos). Area Distorted: Este estad´ıstico num´erico sigue la siguiente formula: Area Distorted =Pn i=0 area poligonoi·is distortedi Pn i=0 area poligonoi is distortedinos indica si el pol´ıgono iest´a distorsionado (valiendo 1) o no (valiendo 0). Es decir, esta f´ormula nos dice el tanto por uno de ´area del modelo que presenta alg´un tipo de distorsi´on. Average Area Distorted: Este estad´ıstico num´erico sigue la siguiente formula Area Distorted =Pn i=0 area poligonoi·(valor propio maxi valor propio mini −1)) Pn i=0 area poligonoi Como podemos observar, la divisi´on de los valores propios nos indica el ratio de distorsi´on entre ejes. A su vez, se le resta 1 porque el ratio ideal es cuando la longitud de ambos ejes es la misma y, si no hay distorsi´on, queremos que esa ´area no se cuente. En conclusi´on, este estad´ıstico nos indica la distorsi´on promedio que hay en el modelo. Entendemos distorsi´on como el ratio entre las longitudes de los ejes. 57
Ratio Distorted: Este estad´ıstico visual tiene la idea de crear un histograma donde se muestra, por cada ratio de distorsi´on existente en el modelo, el n´umero de pol´ıgonos asociados a este. De esta manera, podemos ver los efectos de la distorsi´on en todo el modelo. Es decir, podemos ver si afecta a una gran cantidad de pol´ıgonos o no y en qu´e medida afecta a estos. A su vez, debido a que el histograma puede ser separado en diferentes intervalos, se ha optado por utilizar la regla de “Freedman-Diaconis”[67] para calcular el n´umero de intervalos ideal. De esta manera hacemos que el usuario llegue a entender mejor el histograma. 5.2.4.2. Algoritmo de analizado El objetivo del algoritmo es que sea intuitivo de utilizar y que, a su vez, se pueda extender de manera sencilla. Por lo tanto, se ha decidido separar la l´ogica de extracci´on de valores propios y la l´ogica de an´alisis de estos. Por parte de la l´ogica de extracci´on de valores propios. Estos son los pasos principales para poder extraer los valores propios: 1. Alineaci´on ortogonal: En este paso, se toma cada pol´ıgono y se hace que su vector normal pase a ser el vector (0,0,1). De esta manera omitimos las rotaciones cuando creamos la matriz de transformaci´on entre coordenadas del modelo y coordenadas de textura. 2. Centrado: En este paso, se centra cada pol´ıgono en el (0,0,0). A su vez, este paso es aplicado a las coordenadas de textura del pol´ıgono. De esta manera, la matriz de transformaci´on no se ver´a afectada por las traslaciones que se le pueden haber aplicado. 3. Generaci´on de la matriz de transformaci´on: En este paso, se genera la matriz de transformaci´on asociada a la transformaci´on de un pol´ıgono a sus coordenadas de textura. Esta matriz es cuadrada debido a que para calcularla se utilizan las componentes xeyde los v´ertices de los pol´ıgonos (debido a que al aplicar la alineaci´on ortogonal a este, la componente zpasa a ser la misma en todos los v´ertices del pol´ıgono). Para calcular esta matriz es necesario 2 puntos por cada pol´ıgono y se tiene que resolver la siguiente ecuaci´on matricial: u1u2 v1v2=M·x1x2 y1y2 4. B´usqueda de valores propios: Teniendo la matriz de transformaci´on M. Se procede a la b´usqueda de los valores propios de la matriz R=MTM. Por parte de la l´ogica de analizado, para permitir la expansi´on de la funcionalidad y que otros desarrolladores puedan crear diferentes estad´ısticos. Se opta por crear una interfaz llamada IndicatorInterface. Esta interfaz incorpora un m´etodo evaluate donde, mediante la introducci´on de una lista de valores propios y una lista de pol´ıgonos, devolver´a 58
o un n´umero decimal (en caso de los estad´ısticos num´ericos) o una imagen (en caso de los estad´ısticos gr´aficos). De esta manera, conseguimos que el desarrollador pueda olvidarse completamente de la l´ogica de extracci´on y solo tenga que preocuparse por la l´ogica de an´alisis. En base a todo lo mencionado, a continuaci´on se muestra el algoritmo te´orico planteado: Algorithm 6 Algoritmo te´orico de analizado de parametrizaciones Par´ametros: mesh: Malla 3D con pol´ıgonos. metodo: nombre del m´etodo de analizado que se utilizar´a para analizar la malla valores propios ← ∅ estadisticos ←Estadisticos implementados en formato {nombre : estadistico} for poligono ∈mesh.poligonos do vertices ←poligono.vertices UV s ←poligono.coordenadas textura vertices alineados ←AlineacionOrtogonal(vertices) vertices alineados ←Centrar(vertices alineados) UV s ←Centrar(UV s) T matrix ←CrearMatrixT ransformacion(vertices alineados, UV s) valores ←CalcularV aloresP ropios(T matrix) valores propios ←valores propios ∪valores end for estadistico ←estadisticos.get(metodo) return estadistico.evaluate(valores propios, mesh.poligonos) 5.2.4.3. Interfaz Gr´afica Para la interfaz gr´afica de la funcionalidad, hemos optado por la sencillez como principal aspecto. A continuaci´on mostramos el esquema de paneles por el cual se fundamenta la interfaz. Nombre Padre Descripci´on AnalyzePanel - Panel principal de la funcionalidad. Este panel contiene le bot´on que se encarga de ejecutar uno de los indicadores IndicatorPanel AnalyzePanel Panel encargado de la selecci´on. Para hacer esta selecci´on se utiliza un selecci´on desplegable con todo los estad´ısticos disponibles. A su vez, para los estad´ısticos gr´aficos se ofrece un campo para seleccionar la ruta de guardado del gr´afico. Tabla 16: Tabla donde se muestra los diferentes paneles para la secci´on del analizado de parametrizaciones. En la Figura 22 se muestra la interfaz creada. 59
Figura 22: Interfaz de la secci´on de analizado de parametrizaciones. (Elaboraci´on propia) Para mostrar los resultados se ha decidido mostrar un mensaje de pop-up para los estad´ısticos num´ericos. Para los estad´ısticos gr´aficos, debido a la gesti´on que tiene Blender sobre la salida de la consola de Python integrada en ´el, no es posible mostrar las im´agenes por pantalla. Debido a esto, se ha optado por el guardado del resultado en disco. 6. An´alisis y discusi´on de los resultados Una vez explicadas las funcionalidades del MVP. A continuaci´on se har´a el proceso de testeo de estas. Para ello, se har´a una serie de test, cada uno con el objetivo de poder ver la efectividad de las funcionalidades. 6.1. Entorno de pruebas Para la realizaci´on de las pruebas, se har´a en un entorno con las siguientes caracter´ısticas m´as importantes en el entorno: CPU: Intel core I7-9750H. GPU: GeForce RTX 2060, GDDR6 6GB mobile edition. Memoria RAM : Memoria DDR4 8GB*2 2666 MHz. Todos estos componentes forman parte de un port´atil GL75 9SEK [68]. Por lo tanto, en todo momento, el dispositivo estar´a conectado a la corriente el´ectrica con el ´unico objetivo de poder utilizar todas las capacidades de los componentes mencionados. 6.2. Experimentos Para la realizaci´on de los experimentos, se explicar´a el objetivo de la prueba, configuraci´on utilizada, la ejecuci´on de esta, el resultado que se espera y el resultado obtenido. 60
6.2.1. Baking A continuaci´on se presentan las diferentes pruebas realizadas a la funcionalidad de Baking. Principalmente, se centrar´an en la configuraci´on manual y autom´atica del Baking. 6.2.1.1. Prueba 1 El objetivo de esta prueba es ver que se pueden llegar a obtener resultados relacionados con el color fieles a lo que el objeto aparenta. El modelo utilizado es un modelo 3D correspondiente a un barril de madera conformado por 220 tri´angulos [69]. A su vez, este tiene asociada una imagen como textura donde est´a la apariencia de este. Se proceder´a a crear una textura de 1024*1024 p´ıxeles, con un margen de 16 p´ıxeles del tipo Adjacent faces. La propiedad escogida es Diffuse y la contribuci´on es Color. Se ha elegido esta configuraci´on, ya que el proceso de Bake deber´a generar una textura pr´acticamente id´entica a la textura que ya viene por defecto en el modelo. Todo esto es debido a que el material del objeto utiliza como color ´unicamente el color proveniente de la textura original. En la Figura 23 se el ´arbol de nodos correspondiente. Figura 23: ´ Arbol de nodos asociado al material del modelo Barril, se puede observar que el color proviene ´unicamente del nodo textura. (Elaboraci´on propia) A continuaci´on, en la Figura 24 se muestra tanto la textura original como la generada con la funcionalidad creada. 61
En la Figura 33 mostramos una comparaci´on entre la imagen de entorno y la imagen producida: (a) Imagen de entorno (b) Imagen producida Figura 33: Comparativa de similitud entre el entorno original utilizado y la proyecci´on sobre el modelo Esfera obtenida tras el proceso de Baking. (Elaboraci´on propia) Vemos que la imagen ha hecho una rotaci´on sobre su eje Y, lo cual nos da un indicativo de que se ha hecho la proyecci´on del entorno correctamente. A su vez, vemos que no hay diferencias notables entre los 2 m´etodos. Por tanto, vemos que la ejecuci´on con Environment como tipo de Baking produce resultados aceptables. 6.2.1.5. Prueba 5 El objetivo de esta prueba es comprobar la efectividad de la opci´on Low en la configuraci´on autom´atica del Baking. Para esto, utilizaremos como referencia el objeto Cubo ya 68
existente en Blender. A su vez, para el modelo se ha optado por tener un color en cada una de las caras para poder ver de manera m´as f´acil los resultados. Como configuraci´on del plug-in se ha optado por utilizar la opci´on Diffuse y con las contribuciones Color,Direct eIndirect. Por ´ultimo, se utiliza la configuraci´on Low. Si utilizamos la opci´on Low, deber´ıamos ver una textura de 512*512 p´ıxeles donde cada una de las caras del cubo situada al borde de la parametrizaci´on tiene un borde extendido de unos 16 p´ıxeles. En la Figura 34 se muestra el resultado obtenido: Figura 34: Modelo cubo con configuraci´on Low. (Elaboraci´on propia) Como podemos ver en la Figura 34, se ha hecho un margen de 16 p´ıxeles ´unicamente en esas caras que forman parte del borde de la parametrizaci´on. A su vez, la imagen tiene unas dimensiones de 512*512 p´ıxeles. Por lo tanto, podemos ver que la configuraci´on Low funciona acorde a lo establecido. 6.2.1.6. Prueba 6 El objetivo de esta prueba es comprobar la efectividad de la opci´on Medium en la configuraci´on autom´atica del Baking. Para esto, utilizaremos como referencia el objeto Cubo ya existente en Blender. A su vez, para el modelo se ha optado por tener un color en cada una de las caras para poder ver de manera m´as f´acil los resultados. Como configuraci´on del plug-in se ha optado por utilizar la opci´on Diffuse y ´unicamente la contribuci´on Color. Por ´ultimo, se utiliza la configuraci´on Medium. Si utilizamos la opci´on Medium, deber´ıamos ver una textura de 1024*1024 p´ıxeles con un borde del tipo adjacent faces de 16 p´ıxeles. Por lo tanto, cada cara que est´e en el borde de la parametrizaci´on tendr´a un borde de otro color correspondiente a la cara adyacente a ´esta. 69
A continuaci´on se muestra el resultado obtenido: Figura 35: Modelo cubo con configuraci´on Medium. (Elaboraci´on propia) Podemos en la Figura 35 ver c´omo las caras del l´ımite de la parametrizaci´on tienen el borde correspondiente al borde de la cara adyacente a este. A su vez, vemos c´omo las esquinas de estos bordes obtienen una cara no f´ısicamente adyacente. Ejemplo de esto es la esquina de color amarillo posicionada en la cara blanca. Esto es debido a que Blender hace uso de adjacent faces no con la topograf´ıa del modelo, sino con la de las coordenadas de textura. Haciendo que caras no adyacentes en el modelo s´ı lo sean en el espacio de textura. Por lo tanto, a partir del resultado obtenido. Podemos verificar la efectividad de la configuraci´on Medium. 6.2.1.7. Prueba 7 El objetivo de esta prueba es comprobar la efectividad de la opci´on High en la configuraci´on autom´atica del Baking. Para esto, utilizaremos como referencia el objeto Cubo ya existente en Blender. A su vez, para el modelo se ha optado por tener un color en cada una de las caras para poder ver de manera m´as f´acil los resultados. Como configuraci´on del plug-in se ha optado por utilizar la opci´on Diffuse y ´unicamente la contribuci´on Color. Por ´ultimo, se utiliza la configuraci´on High. Si utilizamos la opci´on high, deber´ıamos ver una textura de 2048*2048 p´ıxeles con un borde del tipo adjacent faces de 32 p´ıxeles. Por lo tanto, cada cara que est´e en el borde de la parametrizaci´on tendr´a un borde de otro color correspondiente a la cara adyacente a ´esta. A continuaci´on se muestra el resultado obtenido: 70
Figura 36: Modelo cubo con configuraci´on High. (Elaboraci´on propia) Podemos ver en la Figura 36 que hay un borde de 32 p´ıxeles correspondiente a las caras adyacentes en espacio textura. Por lo tanto, vemos que la configuraci´on high funciona acorde a lo establecido. 6.2.2. Parametrizaci´on A continuaci´on se presentan las pruebas realizadas con la secci´on de Parametrizaci´on. Esta secci´on se centrar´a en probar el algoritmo de parametrizaci´on. 6.2.2.1. Prueba 1 Para esta prueba se probar´a el algoritmo de parametrizaci´on y la detecci´on de formas esf´ericas. Para esto se utilizar´a un modelo de una esfera proporcionada por Blender. En la Figura 37 se puede observar este modelo. 71
Figura 37: Imagen del modelo esfera proporcionado por Blender. (Elaboraci´on propia) Como configuraci´on inicial de la prueba. Se ha decidido elegir 250 iteraciones y una densidad de 0.5 puntos/unidad2. Como resultado de la prueba, debido a que el modelo inicial es una esfera. El resultado esperado deber´ıa ser obtener una proyecci´on esf´erica. A continuaci´on, en la Figura 38 se muestra el resultado obtenido: Figura 38: Resultado obtenido al parametrizar el modelo esfera con las condiciones mencionadas anteriormente.(Elaboraci´on propia) Podemos ver que el algoritmo de parametrizaci´on ha escogido hacer una proyecci´on esf´erica, lo cual es positivo. A su vez, viendo la parametrizaci´on dada, podemos ver lo siguiente: 72
Figura 39: Parametrizaci´on resultante al aplicar la proyecci´on esf´erica al modelo esfera. (Elaboraci´on propia) Podemos ver que la proyecci´on ha decidido crear 2 “singularidades” correspondientes a los polos de la esfera. Esto es debido a la forma en que decide Blender parametrizar la malla, bas´andose en la posici´on del visor. Como se explic´o en la Secci´on 5.2.3.2, Blender utiliza la posici´on del visor para crear la parametrizaci´on. Por lo tanto, debido a todo lo mencionado anteriormente, vemos que el algoritmo de parametrizaci´on puede detectar formas esf´ericas sencillas. 6.2.2.2. Prueba 2 El objetivo de esta prueba es probar la efectividad del algoritmo para detectar formas cil´ındricas. Para esta prueba utilizaremos el modelo cilindro que ya viene preestablecido por Blender. A continuaci´on, en la Figura 40 se puede ver el modelo escogido: 73
Figura 40: Imagen del modelo cilindro proporcionado por Blender. (Elaboraci´on propia) Como configuraci´on inicial de la prueba. Se ha decidido elegir 200 iteraciones y una densidad de 3.0 puntos/unidad2. La raz´on es que los pol´ıgonos que conforman la superficie del cilindro son rect´angulos cuya ´area es inferior a 1 u2. Figura 41: Imagen donde se muestra el ´area de uno de los rect´angulos que conforman la superficie lateral del modelo cilindro. (Elaboraci´on propia) Esto hace que el super-sampling no llegue a coger ning´un punto. Al aumentar la densidad a 3.0 puntos/unidad2conseguimos que el super-sampling llegue a escoger puntos extras para utilizarlos en el algoritmo de parametrizaci´on. El resultado esperado es conseguir una proyecci´on cil´ındrica debido a que el modelo es un cilindro. 74
A continuaci´on, en la Figura 42 se muestra el resultado obtenido: Figura 42: Resultado obtenido al parametrizar el modelo cilindro con las condiciones mencionadas anteriormente.(Elaboraci´on propia) Podemos ver que el algoritmo ha decidido crear una proyecci´on cil´ındrica. Justo lo que se hab´ıa predicho anteriormente. Figura 43: Parametrizaci´on resultante al aplicar la proyecci´on cil´ındrica al modelo cilindro. (Elaboraci´on propia) Si miramos con detalle la Figura 43, vemos 2 zonas de “singularidad” correspondientes a la parte superior e inferior del cilindro. Se sit´uan en el borde superior e inferior debido a la posici´on del visor que hemos elegido durante la proyecci´on. Aun as´ı, vemos que la superficie restante del modelo no tiene ning´un solapamiento. Por lo tanto, debido a todo lo mencionado anteriormente, podemos decir que el algoritmo detecta de manera correcta formas volum´etricas cil´ındricas, pero el principal problema radica en la forma en que se hace la proyecci´on. 6.2.2.3. Prueba 3 El objetivo de esta prueba es probar el algoritmo de parametrizaci´on sobre modelos m´as complejos, pero que a´un conservan una relaci´on con un cilindro o esfera. Para esto haremos uso del modelo ´arbol [73]. A continuaci´on, en la Figura 44 se muestra una imagen de este modelo: 75
Figura 44: Imagen donde se muestra el aspecto del modelo ´arbol. (Elaboraci´on propia) Vemos que este modelo se puede representar como un cilindro (haciendo referencia al tronco del ´arbol) unido con una esfera (haciendo referencia a la copa de este). Por esta raz´on, con el objetivo de poder ayudar a la correcta identificaci´on de estas formas. Se separan estas dos partes mediante el uso de la funcionalidad Separador de mallas. En la Figura 45, se muestra una imagen donde se puede ver la separaci´on: Figura 45: Imagen donde se ve el modelo ´arbol, separado en 2 partes. (Elaboraci´on propia) A continuaci´on, como condiciones iniciales utilizaremos 500 iteraciones y una densidad de 2.0 puntos/unidad2. El resultado esperado es obtener una parametrizaci´on esf´erica en la copa del ´arbol y una 76
parametrizaci´on cil´ındrica en el tronco de este. A continuaci´on, en la Figura 46 se muestran los resultados: (a) Parametrizaci´on copa del ´arbol. (b) Parametrizaci´on tronco del ´arbol. Figura 46: Resultados obtenidos al parametrizar el modelo ´arbol con las condiciones mencionadas anteriormente.(Elaboraci´on propia) Podemos ver que el algoritmo ha seleccionado las parametrizaciones adecuadas para cada una de las submallas que se hab´ıan creado. (a) Proyecci´on esf´erica sobre copa del ´arbol. (b) Parametrizaci´on cil´ındrica sobre tronco del ´arbol. Figura 47: Parametrizaci´on obtenida tras aplicar las proyecciones mencionadas sobre las submallas del modelo ´arbol. (Elaboraci´on propia) A su vez, observamos que ´unicamente hay un cierto solapamiento en la proyecci´on cil´ındrica. Todo esto es debido a la existencia de ramas que comparten las mismas coordenadas que la superficie del ´arbol cuando se proyecta todo sobre un cilindro. Por consecuencia, debido a todo lo mencionado anteriormente, vemos que el algoritmo detecta formas volum´etricas en objetos que tienen una topograf´ıa m´as compleja que las pruebas anteriores. 6.2.2.4. Prueba 4 Para esta prueba se quiere comprobar la calidad de la parametrizaci´on generada frente a las que ya ofrece Blender. Para esto se utilizar´a el modelo icosfera. 77
(a) Modelo esfera (b) Parametrizaci´on correspondiente al modelo esfera. Figura 55: Imagen del modelo esfera junto a su parametrizaci´on. (Elaboraci´on propia) En cuanto a la configuraci´on inicial, se utilizar´a el estad´ıstico Area Distorted, mencionado anteriormente. El resultado esperado es obtener una puntuaci´on de 1,0 en el estad´ıstico. Todo esto debido a que todo el modelo presenta distorsi´on. A continuaci´on se muestra el resultado obtenido: Figura 56: Resultado obtenido al utilizar el estad´ıstico Area Distorted sobre el modelo esfera. (Elaboraci´on propia) Como podemos observar, el 100 % del ´area del modelo presenta distorsi´on. Esto cuadra con lo que se hab´ıa propuesto anteriormente. En consecuencia, gracias a todo lo mencionado anteriormente, podemos verificar que el algoritmo es capaz de detectar distorsiones utilizando el estad´ıstico Area Distorted. 6.2.3.4. Prueba 4 El objetivo de esta prueba es ver el correcto funcionamiento del estad´ıstico Average Distorsion. Para llevar a cabo esta prueba se utilizar´a el modelo esfera. Todo esto debido 84
a que Blender proporciona una parametrizaci´on con distorsi´on y, a su vez, un m´etodo para crear parametrizaciones donde se intenta minimizar la distorsi´on. Por lo tanto, de esta manera obtenemos 2 parametrizaciones con dos grados diferentes de distorsi´on y f´acilmente apreciables. A continuaci´on, en la Figura 57 se muestran las 2 parametrizaciones utilizadas: (a) Parametrizaci´on n´umero 1 correspondiente al modelo esfera. (b) Parametrizaci´on n´umero 2 correspondiente al modelo esfera. Figura 57: Parametrizaciones escogidas para el modelo esfera. (Elaboraci´on propia) Como configuraci´on inicial se ha utilizado el estad´ıstico num´erico Average Distorsion, como se ha explicado anteriormente. El resultado esperado es obtener una distorsi´on media superior con la primera parametrizaci´on compar´andola con la segunda. Todo esto debido a que presenta una distorsi´on mayor. (a) Resultado parametrizaci´on n´umero 1. (b) Resultado parametrizaci´on n´umero 2. Figura 58: Resultados obtenidos al aplicar en las parametrizaciones escogidas el estad´ıstico Average Distorsion. (Elaboraci´on propia) Podemos observar en la Figura 58 que el estad´ıstico ha dotado de un mayor valor a la primera parametrizaci´on, justo como se hab´ıa planteado anteriormente. En consecuencia, gracias a todo lo mencionado anteriormente, podemos verificar que el estad´ıstico num´erico Average Distorsion funciona de forma correcta. 85
7. Conclusi´on En esta secci´on final se har´a una evaluaci´on de los diferentes objetivos (Secci´on 7.1) propuestos en la secci´on de GEP 1.3.1. Posteriormente, en la Secci´on 7.2, se har´a una evaluaci´on de las funcionalidades propuestas, explicando sus limitaciones y mejoras que se podr´ıan hacer. Por ´ultimo, en la Secci´on 7.3 se har´a una reflexi´on personal del trabajo. Todo esto explicando lo aprendido en este y el significado de acabarlo. 7.1. Evaluaci´on de objetivos Objetivos obligatorios En general, se han cumplido con satisfacci´on todos los objetivos obligatorios propuestos. A continuaci´on, se explica de manera m´as detallada cada uno de los objetivos y c´omo se han cumplido: Fundamentaci´on te´orica Durante el proyecto se ha llegado a entender el funcionamiento de la API de Blender y de esta manera se ha llegado a aprovechar de manera eficiente todas sus capacidades. A su vez, se ha llegado a entender no solo c´omo funciona el proceso de Baking a un nivel m´as intr´ınseco, sino tambi´en a nivel pr´actico. De esta forma, se ha podido entender c´omo automatizar el proceso. Por parte de la parametrizaci´on, se ha llegado a entender qu´e proyecciones hay disponibles en Blender y c´omo se puede elegir la mejor bas´andose en un proceso iterativo donde se escoge la mejor opci´on en cada iteraci´on. De esta manera tambi´en ha llegado a entender de mejor manera c´omo una cierta forma la podemos categorizar seg´un el concepto de “semejanza”. Implementaci´on del sistema de automatizaci´on El sistema de automatizaci´on para la generaci´on de textura se ha dise˜nado teniendo como objetivo dotar al usuario de si quiere adentrarse en todos los diferentes par´ametros que envuelven al proceso de Baking o si quiere ser r´apido y apostar por configuraciones ya preestablecidas. Todo esto tambi´en haciendo que el algoritmo no consuma muchos recursos de la aplicaci´on. Por lo tanto, se ha podido crear de manera eficiente tanto el mecanismo manual como autom´atico para la generaci´on de texturas. Por ´ultimo, se implement´o el sistema de switch, permitiendo al usuario intercambiar entre materiales originales y texturas generadas de manera simple. Esto hace que se haya podido crear el mecanismo de cambio entre materiales previamente existentes de los objetos y hechos con el proceso de automatizaci´on. A su vez, para expandir la vida ´util de esta funcionalidad, se ha hecho un mecanismo de actualizaci´on de la informaci´on interna que se utiliza para hacer los intercambios. 86
Implementaci´on del sistema de generaci´on de coordenadas de texturas El sistema de parametrizaci´on de modelos 3D se ha dise˜nado mediante el uso del algoritmo de RANSAC y proyecciones sobre objetos volum´etricos simples. Todo esto, a su vez, ofrece una manera de ser expandido por los usuarios. En consecuencia, se ha podido implementar un sistema de generaci´on de coordenadas de textura. Adem´as, se hizo un sistema de separaci´on de mallas que ayuda a mejorar las parametrizaciones que da el algoritmo mencionado anteriormente. A su vez, se ha podido crear un sistema de evaluaci´on de parametrizaciones bas´andose en estad´ısticos. Todo esto mediante la utilizaci´on de una interfaz gr´afica intuitiva y simple. Por lo tanto, se ha podido implementar un sistema de evaluaci´on sencillo e intuitivo de la calidad de las coordenadas de textura generadas. Evaluaci´on Durante la fase de testeo de las funcionalidades se han hecho pruebas, que est´an documentadas en esta memoria, donde se muestra el buen funcionamiento de las funcionalidades propuestas. Por lo tanto, se han verificado las capacidades de los sistemas implementados. A su vez, como parte de la evaluaci´on de la generaci´on de parametrizaciones, se hizo una prueba donde se compara con otras parametrizaciones proporcionadas por Blender. Por lo tanto, se ha cumplido el ´ultimo punto propuesto de esta secci´on. Objetivos opcionales Debido a la falta de tiempo, no se han podido implementar los sistemas opcionales propuestos en un inicio. Por lo tanto, no se han podido satisfacer los objetivos opcionales. Requisitos no funcionales Por parte de los requisitos no funcionales se han podido cumplir los siguientes objetivos: Asegurar una implementaci´on eficiente de los sistemas propuestos. Asegurar una interfaz intuitiva y f´acil de utilizar. El plazo de desarrollo del proyecto no debe de superar los 3.5 meses. Aun as´ı, hay un punto que no se puede considerar como completamente cumplido debido a la falta de experiencia en estructuraci´on de software y tambi´en teniendo en cuenta la arquitectura de Blender. Este punto es: uso de buenas pr´acticas de programaci´on, con la capacidad del c´odigo de ser mantenible. 87
7.2. Limitaciones Aunque se hayan creado de manera satisfactoria todas las funcionalidades propuestas en el MVP. Estas no carecen de limitaciones y mejoras. A continuaci´on se muestra una lista de mejoras que se podr´ıan hacer para mejorar las funcionalidades. Mayor tipo de proyecciones: Actualmente, el algoritmo de parametrizaci´on contempla 2 tipos de proyecciones (esf´erica y cil´ındrica). Esto hace que objetos no semejantes a estos no tengan una parametrizaci´on id´onea. Se podr´ıan a˜nadir m´as tipos de proyecciones como toroide,planar, entre otros, con el objetivo de dar m´as cobertura al algoritmo. Esto, a su vez, necesitar´ıa mecanismos de proyecci´on, ya que Blender no ofrece las proyecciones mencionadas. Posicionamiento del visor en la proyecci´on: Cuando hacemos una proyecci´on de un objeto para obtener nuevas coordenadas de textura. El visor se sit´ua mirando al frente del objeto. Esto no siempre es id´oneo porque no todas las caras del objeto est´an mirando en la direcci´on del visor. Por esta raz´on, se podr´ıa hacer un sistema donde se calcula la posici´on id´onea del visor y as´ı reducir la distorsi´on. Una idea para calcular esta posici´on es mediante hacer la media aritm´etica de todas las normales del modelo. Esto te indica en qu´e direcci´on est´a mirando de forma gen´erica el modelo. M´as par´ametros de control en el Baking: Aunque se hizo un estudio de los par´ametros relevantes del Baking. Tambi´en se pueden buscar aquellos que involucran al renderizado. Es decir, par´ametros m´as relacionados no tanto con el proceso, sino con el motor el cual se utiliza. Solapamientos en la evaluaci´on de parametrizaciones: Aunque la distorsi´on es un factor a tener en cuenta en cuanto a la calidad de una parametrizaci´on. Este no es el ´unico aspecto a tener en cuenta. Los solapamientos entre caras de un modelo cuando se parametriza es un suceso que suele pasar y se ha de tener en cuenta cuando se analiza la calidad de estas. Por lo tanto, se podr´ıa extender el algoritmo de analizado mediante la introducci´on de este par´ametro en el analizado. A su vez, tambi´en se pueden a˜nadir otros aspectos a evaluar. Ampliaci´on del Baking a caracter´ısticas no fotom´etricas: Como ya se plante´o en los objetivos opcionales, el sistema de automatizaci´on del proceso de Baking tambi´en podr´ıa extenderse para contemplar otro tipo de caracter´ısticas, como las normales del modelo. 7.3. Reflexi´on En mi opini´on personal, este es mi primer proyecto en solitario y de esta envergadura que he tenido que llevar a cabo. Durante la realizaci´on de este proyecto he sentido todo tipo de sensaciones: felicidad, frustraci´on, incluso ira. Pero al final, todo el esfuerzo obtiene su recompensa. A nivel de aprendizaje, me quedo con todos los conocimientos de Blender y de geometr´ıa que he tenido que aprender para llegar a finalizar todas las funcionalidades propuestas. 88
Conocimientos que podr´e aplicar en sectores de Inform´atica gr´afica. A su vez, los tendr´e como curiosidad de la rama de Matem´aticas que m´as me interesa, la geometr´ıa. A su vez, como lecci´on que me llevo a mi carrera profesional, dir´ıa que siempre es m´as importante la planificaci´on del proyecto que incluso el propio proyecto en s´ı. De esta manera se tiene claro el rumbo que se quiere tener y se sabe qu´e hacer en todo momento cuando los imprevistos empiezan a surgir. Adem´as, si tuviera que decir un consejo para mi yo del futuro a partir de este proyecto, ser´ıa el de recordar lo bueno aparte de lo mejorable. Todo proyecto no es perfecto y hay que saber vivir con la idea de que lo que uno hace siempre es mejorable y tambi´en se podr´ıa hacer mucho m´as. A´un as´ı, esto no nos impide valorar lo que ya se ha hecho y estar orgullosos de esto. Por ´ultimo, me gustar´ıa agradecer a mis directores por toda la ayuda y gu´ıa dada durante este per´ıodo; de no ser por ellos, este proyecto no hubiera sido posible hacerlo en el tiempo estimado. A su vez, quiero agradecer a todas esas personas que han estado junto a mi lado durante todo el tiempo que he hecho la carrera de Ingenier´ıa Inform´atica en esta universidad, en especial a toda mi familia por apoyarme en los momentos m´as duros. De no ser por ellos, no podr´ıa haber estudiado esta carrera. 89
Bibliograf´ıa y Webgraf´ıa [1] Vectary — The importance of texture baking.url:https://www.vectary.com/3d -modeling-blog/texture-baking/ (visitado 20-09-2024). [2] Maxon - ZBrush - PolyPaint. en. url:https://www.maxon.net/en/zbrush/feat ures/polypaint (visitado 20-09-2024). [3] Tomas Akenine-M¨oller et al. Real-time rendering. eng. Fourth edition, first issued in hardback. A Balkema book. Boca Raton London New York: CRC Press, 2019. isbn: 978-1-138-62700-0. [4] Alla Sheffer et al. “ABF++: fast and robust angle based flattening”. en. En: ACM Transactions on Graphics 24.2 (abr. de 2005), p´ags. 311-330. issn: 0730-0301, 15577368. doi:10.1145/1061347.1061354.url:https://dl.acm.org/doi/10.1145 /1061347.1061354 (visitado 22-09-2024). [5] How to bake textures in Blender - Artisticrender.com.url:https://artisticren der.com/how-to-bake-textures-in-blender/ (visitado 14-10-2024). [6] [SOLVED] UVs from imported mesh slightly distorted causing texture misalignment - General / Feedback & Requests - Epic Developer Community Forums.url:http s://forums.unrealengine.com/t/solved-uvs-from-imported-mesh-slightly -distorted-causing-texture-misalignment/151770/8 (visitado 14-10-2024). [7] Why does a texture used on opengl objects looks poor in quality and stretched? Forum post. Sep. de 2012. url:https://stackoverflow.com/q/12472752 (visitado 14-10-2024). [8] ViRVIG.url:https://www.virvig.eu/ (visitado 23-09-2024). [9] Projects.url:https://www.virvig.eu/projects.php (visitado 23-09-2024). [10] Blender Foundation. About. en. url:https://www.blender.org/about/ (visitado 20-09-2024). [11] James D. Foley, ed. Computer graphics: principles and practice. 2nd ed. in C. Addison-Wesley systems programming series. Reading, Mass: Addison-Wesley, 1995. isbn: 978-0-201-84840-3. [12] DirectX 6.0 Goes BallisticWith Multiple New FeaturesAnd Much Faster Code–MSJ, January 1999. Oct. de 2016. url:https://web.archive.org/web/20161031110 040/http://www.microsoft.com/msj/0199/direct3d/direct3d.aspx (visitado 20-09-2024). [13] What is Baking ? — Substance 3D bakers. en-US. url:https://helpx.adobe.co m/content/help/en/substance-3d-bake/getting-started/what-is-baking.h tml (visitado 21-09-2024). [14] Baking.url:https://learn.foundry.com/modo/content/help/pages/shading _lighting/image_baking_workflow.html (visitado 21-09-2024). [15] Paolo Cignoni. La bildo estas kopiita de wikipedia:en. La originala priskribo estas: url:https://commons.wikimedia.org/wiki/File:Normal_map_example.png (visitado 11-12-2024). 90
[16] Texture Coordinates.url:https://docs.safe.com/fme/html/FME-Form-Doc umentation/FME-ReadersWriters/!FME_Geometry/Texture_Coordinates.htm (visitado 21-09-2024). [17] Aliasing and Moire patterns.url:https://matthews.sites.wfu.edu/misc/Dig Photog/alias/ (visitado 21-09-2024). [18] Carlos Andujar Gran. Distortion - YouTube.url:https://www.youtube.com/wa tch?v=rNFgPW8t-4U (visitado 25-09-2024). [19] Simplebake - Simple Pbr And Other Baking In Blender. en. url:https://blende rmarket.com/products/simplebake---simple-pbr-and-other-baking-in-bl ender-2 (visitado 22-09-2024). [20] Oven Bake — Blender Baking Addon. en. url:https://blendermarket.com/pr oducts/ovenbake?search_id=32781689 (visitado 22-09-2024). [21] Yusuf Sahillio˘glu y Ladislav Kavan. “Detail-Preserving Mesh Unfolding for Nonrigid Shape Retrieval”. En: ACM Trans. Graph. 35.3 (mayo de 2016), 27:1-27:11. issn: 0730-0301. doi:10.1145/2893477.url:https://doi.org/10.1145/2893477 (visitado 20-09-2024). [22] Roi Poranne et al. “Autocuts: simultaneous distortion and cut optimization for UV mapping”. En: ACM Trans. Graph. 36.6 (nov. de 2017), 215:1-215:11. issn: 07300301. doi:10.1145/3130800.3130845.url:https://dl.acm.org/doi/10.1145 /3130800.3130845 (visitado 22-09-2024). [23] Smart UV Mapping Problems. - Support / Materials and Textures - Blender Artists Community.url:https://blenderartists.org/t/smart-uv-mapping-proble ms/616997 (visitado 22-09-2024). [24] Metodolog´ıa en cascada: Ventajas e inconvenientes. es. Ago. de 2023. url:htt ps : / / safetyculture . com / es / temas / metodologia - en - cascada/ (visitado 10-10-2024). [25] Overleaf, Editor de LaTeX online. es. url:https://www.overleaf.com (visitado 30-09-2024). [26] Gestiona los proyectos de tu equipo desde cualquier lugar — Trello.url:https: //trello.com/es (visitado 24-09-2024). [27] Visual Studio Code - Code Editing. Redefined. en. url:https://code.visualstu dio.com/ (visitado 30-09-2024). [28] Sueldo: Project Manager en Espa˜na 2024 — Glassdoor.url:https://www.gla ssdoor.es/Sueldos/projectmanagersueldoSRCH_KO0, 15.htm (visitado 03-10-2024). [29] Sueldo: Investigador en Espa˜na 2024. es. url:https://www.glassdoor.es/Suel dos/investigador-sueldo-SRCH_KO0,12.htm (visitado 03-10-2024). [30] Sueldo: Programador en Espa˜na 2024 — Glassdoor.url:https://www.glassdoo r.es/Sueldos/programador-sueldo-SRCH_KO0,11.htm (visitado 03-10-2024). [31] Sueldo: Qa Tester en Espa˜na 2024. es. url:https://www.glassdoor.es/Sueldo s/qa-tester-sueldo-SRCH_KO0,9.htm (visitado 08-10-2024). [32] DNA - Blender Developer Documentation.url:https://developer.blender.or g/docs/features/core/dna/ (visitado 01-11-2024). 91
[33] RNA - Blender Developer Documentation.url:https://developer.blender.or g/docs/features/core/rna/ (visitado 01-11-2024). [34] blender/source/blender/makesrna/RNA types.h at master ·wisaac407/blender ·GitHub. url:https://github.com/wisaac407/blender/blob/master/source/blender /makesrna/RNA_types.h (visitado 01-11-2024). [35] Mesh(ID) - Blender Python API.url:https://docs.blender.org/api/main/b py.types.Mesh.html#mesh-id (visitado 01-11-2024). [36] MeshPolygon(bpy struct) - Blender Python API.url:https://docs.blender.o rg/api/main/bpy.types.MeshPolygon.html#bpy.types.MeshPolygon (visitado 01-11-2024). [37] Material(ID) - Blender Python API.url:https://docs.blender.org/api/main /bpy.types.Material.html#material-id (visitado 01-11-2024). [38] Bump Node - Blender 4.2 Manual.url:https://docs.blender.org/manual/en /latest/render/shader_nodes/vector/bump.html (visitado 01-11-2024). [39] MeshUVLoopLayer(bpy struct) - Blender Python API.url:https://docs.blend er.org/api/main/bpy.types.MeshUVLoopLayer.html#bpy.types.MeshUVLoop Layer (visitado 01-11-2024). [40] Cartesian coordinate system - Wikipedia.url:https://en.wikipedia.org/wiki /Cartesian_coordinate_system (visitado 05-01-2025). [41] 8. NumPy: estructuras matriciales — Python para Ingenieros.url:https://jor gedelossantos.github.io/apuntes-python/NumPy.html (visitado 08-11-2024). [42] Coordenadas baric´entricas (n-simplex). es. Page Version ID: 162952912. Oct. de 2024. url:https://es.wikipedia.org/w/index.php?title=Coordenadas_bari c%C3%A9ntricas_(n-simplex)&oldid=162952912 (visitado 11-11-2024). [43] Espacio af´ın. es. Page Version ID: 157939256. Feb. de 2024. url:https://es.w ikipedia.org/w/index.php?title=Espacio_af%C3%ADn&oldid=157939256 (visitado 10-11-2024). [44] Interpolaci´on bilineal. es. Page Version ID: 157470829. Ene. de 2024. url:https: //es.wikipedia.org/w/index.php?title=Interpolaci%C3%B3n_bilineal&old id=157470829 (visitado 10-11-2024). [45] Path Tracing vs. Ray Tracing, Explained — TechSpot.url:https://www.techsp ot.com/article/2485-path-tracing-vs-ray-tracing/ (visitado 10-11-2024). [46] Ambient occlusion. en. Page Version ID: 1228936235. Jun. de 2024. url:https://e n.wikipedia.org/w/index.php?title=Ambient_occlusion&oldid=1228936235 (visitado 03-11-2024). [47] What is an Environment Map? — Visual FX Tools.url:https://www.visualfx .tools/glossary/e/environment-map (visitado 03-11-2024). [48] UnrealMatter. How to BAKE AMBIENT OCCLUSION MAPS in Blender. Nov. de 2022. url:https://www.youtube.com/watch?v=ChxGAcKO92Y (visitado 11-11-2024). [49] Sampling - Blender 4.2 Manual.url:https://docs.blender.org/manual/en/l atest/render/cycles/render_settings/sampling.html#adaptive-sampling (visitado 10-11-2024). 92
[50] Intel®Open Image Denoise.url:https://www.openimagedenoise.org/ (visitado 11-11-2024). [51] NVIDIA OptiX™Ray Tracing Engine. en-US. url:https://developer.nvidia .com/rtx/ray-tracing/optix (visitado 11-11-2024). [52] Markom3D. How to Bake textures in Blender under 3 minutes Beginner Tutorial. Dic. de 2023. url:https://www.youtube.com/watch?v=SDqpnfTRtIU (visitado 02-11-2024). [53] Como hacer Bake de Normales en Blender - YouTube.url:https://www.you tube.com/watch?si=- IjykNLMJkGLsU4P&v=tfobFDQr5cA&feature=youtu.be (visitado 13-01-2025). [54] JPEG vs. PNG: Which one should you use? — Adobe. en-US. url:https://www.a dobe.com/creativecloud/file-types/image/comparison/jpeg-vs-png.html (visitado 03-11-2024). [55] Khalid Sayood. Introduction to data compression. eng. Fifth edition. Cambridge: Morgan Kaufmann Publishers, 2018. isbn: 978-0-12-809474-7. [56] Publicado por Juan Gomar — 28 agosto 2019 — Trucos — 0. Resoluci´on 720p vs FHD 1080p vs 1440p vs 4k, todo lo que necesitas saber. es. Section: Trucos. Ago. de 2019. url:https://www.tuexperto.com/2019/08/28/resolucion720pv sfhd1080pvs1440pvs4ktodoloquenecesitassaber/ (visitado 25-11-2024). [57] Denoise Bake results after extending borders. en. url:https://blender.communi ty/c/rightclickselect/PY7z/ (visitado 25-11-2024). [58] UV Operators - Blender 4.3 Manual.url:https://docs.blender.org/manual/e n/latest/modeling/meshes/editing/uv.html (visitado 12-12-2024). [59] Seams - Blender 4.3 Manual.url:https://docs.blender.org/manual/en/late st/modeling/meshes/uv/unwrapping/seams.html (visitado 01-12-2024). [60] Erik Selin. The definitive tutorial to UV mapping in Blender. en-US. Jun. de 2019. url:https://artisticrender.com/the-definitive-tutorial-to-uv-mappin g-in-blender/ (visitado 01-12-2024). [61] R. Schnabel, R. Wahl y R. Klein. “Efficient RANSAC for Point-Cloud Shape Detection”. En: Computer Graphics Forum (2007). Publisher: The Eurographics Association and Blackwell Publishing Ltd. issn: 1467-8659. doi:10.1111/j.1467-8 659.2007.01016.x. [62] RANSAC. es. Page Version ID: 163523481. Nov. de 2024. url:https://es.wikip edia.org/w/index.php?title=RANSAC&oldid=163523481 (visitado 01-12-2024). [63] Herman Jaramillo. Answer to ”Using Tikz, is it possible to draw a cube within a sphere?”. Dic. de 2015. url:https:// tex.stackexchange. com/a / 281287 (visitado 17-12-2024). [64] Mu˜neco articulado / action figure - STLFinder.url:https://www.stlfinder .com/model/mu%C3%B1ecoarticuladoactionfigure5TQij0Ul/767028/ (visitado 12-12-2024). [65] Dijkstra’s algorithm. en. Page Version ID: 1262671356. Dic. de 2024. url:https: //en.wikipedia.org/w/index.php?title=Dijkstra%27s_algorithm&oldid=12 62671356 (visitado 12-12-2024). 93