PFM: Traducción de Java a C#

Una vez entendido su funcionamiento (y aprovechando las vacaciones), he empezado con la traducción del código, de Java a C#, empezando por la clase EEPEngine. A partir de esa clase, continué de forma fluida, introduciendo las clases (y métodos) que el propio Unity me iba avisando que necesitaban las demás clases. Así, continué hasta que Unity ya no me informó de ningún error, y ya tenía la siguiente jerarquía de clases:

Sin embargo, algunas clases estaban vacías. Así que continué completando todas las clases, y añadiendo más clases que se necesitaban, hasta la jerarquía de clases que tengo ahora mismo:

La traducción de Java a C# fue bastante sencilla. Los cambio más significativos son los siguientes:

• El código original en Java utilizaba ArrayList. Yo en C# he usado List, porque he leído en los foros de Unity que es más útil y más cómodo, sobre todo porque le especificas el tipo de la lista, mientras que con ArrayList (en C#) no. Además, ArrayList en C# también puede generar otros problemas.
• He utilizado float en vez de double (utilizado en el código original), recomendado por mi tutor porque todo el motor de Unity trabaja con float, y al utilizar Mathf (que necesita floats), al hacer cast se pierde precisión.
• El código original utiliza HashMap. Yo he utilizado un equivalente en C#, Dictionary, al que se le especifica el tipo de Key y de Value, al igual que con HashMap (con Hashtable, sin embargo, no). Recorrer una colección de tipo Dictionary, es sencillo, utilizando: foreach (KeyValuePair p in ...).
• La última diferencia es que en C# no hay que declarar las excepciones que lanza un método; las extrae directamente del cuerpo del método.

Taller de texturado

Para el taller de texturado, tuvimos que ponerle texturas a la cabeza de un personaje con casco (con photoshop). Como quería hacer algo "original", decidí influirme en los marcianos de Mars Attacks:

Y el casco me quedó así (era la primera vez que usaba photoshop, así que aunque no lo parezca, me costó hacer el casco-cerebro):

Es difícil de reconocer con tanto retoque, pero con photoshop le puse la cara de un actor. Si te fijas mucho, y conoces bien al actor en cuestión, tal vez consigas reconocerlo ;)

Taller de iluminación

En la asignatura Modelado Geométrico hemos tenido un taller de iluminación (utilizando Maya) y uno de texturizado (con Photoshop).

Para el taller de iluminación, tuvimos que renderizar unas escenas para mostrar lo que habíamos aprendido.

• La primera escena trataba simplemente de una serie de esferas, y teníamos que crear una luz y jugar un poco con sus atributos:

• Para la segunda escena teníamos que proyectar una imagen en la pared de una sala llena de sillas (como un gobo), y se me ocurrió simular una sala de cine en la que se proyecta una película antigua:

• La tercera escena era a libre elección, utilizando Mentalray. Modelé mi habitación , y le añadí varias esferas distintas (unas de colores, una transparente y otra que emite luz de color verde claro) que se reflejan en la estantería y en la mesa. La lámpara de la mesilla de noche emite luz de color azul. Por la ventana, entra la luz del sol.

• La última escena también era a libre elección, utilizando Maxwell. La escena contiene un cenador, unas esferas que podrían ser asientos de estilo moderno (aunque no parecen muy cómodas; las añadí para ver el reflejo de los demás objetos en ellas, e incluso el reflejo rojo de las esferas en las columnas del cenador), y una mesa con unas tazas y un tablero de ajedrez con piezas de cristal.

PFM: Emotional Elicitation Process (EEP)

Mi primera tarea consistirá en traducir el modelo EEP, comentado en la entrada anterior de este blog, de Java a C#, para poder trabajar con él en el motor de juego (Game Engine) Unity3D. Para ello, primero es necesario comprender bien la arquitectura de EEP (que viene explicada en la tesis de Luis Peña, un profesor muy majo, y mi tutor de proyecto):

El modelo EEP (Emotional Elicitation Process) está dividido en cuatro componentes:

• Diccionarios Conceptuales (Conceptual Dictionaries – CP): proporcionan las definiciones de los elementos generales necesitados por el motor para evaluar los eventos. Por ejemplo, el tipo de Acciones que el evento podría registrar. Estos diccionarios son distintos de los Diccionarios AGCBAR (Automatic Game Controllers Behaviors with Affect Responses) y están solo relacionados con los procesos internos del modelo EEP.

• Perfil del Personaje (Character Profile – CP): define los parámetros numéricos que representan la definición general de la personalidad del personaje y la identificación del estado de ánimo (Mood State µi), en el espacio del ánimo (mood space, M). También proporciona la cuantificación de los elementos registrados por los diccionarios conceptuales. Por ejemplo, el valor que le da un personaje a la acción de Dar-Dinero registrada en los diccionarios.

• Motor de proceso de provocación emocional (Emotional Elicitation Process Engine – EEPE): descompone, analiza y evalúa un evento. También analiza las emociones y sus niveles de intensidad como resultado de la evaluación de un evento Ei.

• Espacio de vector de ánimo (Mood Vector Space – MVS): representa el estado de ánimo del personaje actual, µi. El MVS es un espacio tridimensional derivado del modelo PAD. Aquí, las emociones percibidas por un personaje son convertidas por el EEPE en vectores en este espacio, y traducen el estado de ánimo del personaje de un punto a otro dentro de los límites del MVS. Por ejemplo, un punto en concreto en este espacio puede representar un estado de ánimo de un personaje en particular en un momento en particular.

Por lo tanto, fuera del modelo, podemos implementar las interfaces que sintetizan los eventos generados por el entorno (Motor de Juego [Game Engine] en el caso de la Arquitectura de AGCBAR) para poder producir los ánimos indicados por el Motor Emocional:

• Constructor de Eventos (Event Builder – EB): dados los eventos generados por el entorno, Ei, este componente se adapta a la estructura necesitada por el EEPE. Este componente puede ser definido como un envoltorio de los eventos entrantes. Cada evento entrante puede producir de 0 a N eventos internos de EEP {εj} ∈ ε, (por la relación causal entre los eventos y sus componentes).
• Etiquetador de Ánimo (Mood Tagger – MT): los ánimos son un conjunto discreto de valores finitos que tienen su significado en el contexto del Motor de Juego. Sin embargo, el Modelo EEP opera sobre una representación continua del Estado de Ánimo, el cual está basado en la representación MVS. Es la responsabilidad del MT proyectar el estado de ánimo continuo, µi ∈ M, a uno de los valores discretos, Ti ∈ T. Este espacio de estado es la representación básica de la cual extraemos el estado de ánimo, para luego traducirlo a las etiquetas de estado de ánimo Ti ∈ T a través de la interfaz de ánimo en la arquitectura de AGCBAR.

Esta estructura de eventos es necesaria para el análisis balanceado de las emociones. También proporciona los parámetros cruciales para la clasificación y cuantificación de las emociones producidas por los eventos. Por ejemplo, los eventos están asociados conforme a sus fuentes y objetivos, y sus consecuencias causales son traducidas como eventos emocionales.

Además de esto, una representación continua del estado de ánimo permite al motor EEP operar con transiciones de grano fino (indicadas por los eventos). También permite la proyección del número discreto de etiquetas de ánimo definida por la arquitectura AGCBAR.

PFM: Empezando

La Inteligencia Artificial (IA) me ha parecido siempre una de las áreas más interesantes de la informática. Mi PFC también fue dentro del campo de la IA, aunque nada que ver con videojuegos (ya que trataba de Neurología). En el Máster había ofertado un PFM muy similar al trabajo que realicé como PFC, y algunos me aconsejaban cogerlo, ya que no tendría que aprender de cero todo, y me sería más sencillo... pero alguien me recordó que hay que ir tras los sueños, y mi sueño siempre han sido los videojuegos, y estoy estudiando esto para acercarme cada vez más a ese sueño. Así que he elegido este PFM, y no podía estar más contenta.

La IA en los videojuegos es tan importante como los gráficos. De hecho, yo diría que más, ya que un juego con gráficos no muy buenos pero con una buena IA puede ofrecer mucho entretenimiento, mientras que al revés no; la calidad gráfica, por muy impresionante que sea, no da la diversión. Además, si se busca realismo, éste no depende solo del aspecto visual, sino también del comportamiento realista de los personajes. Sin embargo, los videojuegos tienen cada vez mejores gráficos, mientras que la IA apenas evoluciona.

Por ejemplo, algo que ha hecho que el Dragon Age sea uno de mis videojuegos favoritos es la IA de los personajes que te acompañan. Según qué decisiones tomes en la historia, las acciones que hagas y las conversaciones que tengas con ellos, y según la personalidad de cada personaje, varía el grado de amistad que ellos tienen contigo. Incluso puedes enemistarte con uno y que abandone tu grupo (o puede que nunca se haya unido al él). Así, cada personaje tiene su propia personalidad, y ciertos eventos pueden cambiar sus sentimientos hacia ti, reaccionando de diferentes formas según tus actos. Esto es similar a lo que se pretende en este PFM: mostrar un comportamiento de personajes realista, guiado por emociones como respuesta a eventos.

Este PFM se centra en el comportamiento de los personajes (sus emociones), en sus reacciones frente a determinados eventos, condicionados por su personalidad y su estado de ánimo. Para ello, se utilizará el modelo Emotional Elicitation Process (EEP), que explicaré más tarde en este blog.

Práctica: Mallas de triángulos

La primera práctica que he hecho para el Máster fue implementar tres ejercicios manipulando mallas de triángulos.


El primero era muy simple; tan solo tenía que imprimir por pantalla las áreas mínima y máxima de los triángulos de la malla y el área total, y una lista con los triángulos con factor de forma mayor que 4.

La segunda parte consistía en pintar los vértices frontera de una malla abierta de color rojo:

Aunque para el triángulo se ve mucho más claro, porque tiene una frontera claramente diferenciada, con una malla como la que se muestra a continuación, con muchos más vértices, se ve mejor si la implementación hace realmente lo que se le pide. Los vértices en los que se ve que el color rojo se extiende más hacia arriba, es porque pertenecen a facetas aguja, que son triángulos alargados hacia arriba. Con estos colores, parece que le han cortado la cabeza al pobre hombre.

La última parte era la más compleja. Tuve que construir las matrices de adyacencia, de difusión y del sistema, un vector UV_0, repartiendo los vértices externos a lo largo de los lados de un cuadrado de lado 1, y por último resolver el sistema para obtener LU.

Como salida, obtenemos el triángulo, con la textura (cuadrada) pegada. Pero la mejor forma de ver que funciona correctamente es probarlo con la malla de la cabeza.

 

¡Hola mundo!

¡Hola! Bienvenido a mi blog.

Mi nombre es Laura, y soy informática. Estoy estudiando un Máster en Informática Gráfica, Juegos y Realidad Virtual, y voy a empezar a trabajar en un Proyecto Fin de Máster centrado en la IA (Inteligencia Artificial) aplicada a videojuegos. Este blog me servirá como cuaderno de bitácora, donde iré escribiendo los avances en el proyecto, así como trabajos de otras asignaturas, y más cosas relacionadas con el Máster o con los videojuegos o la informática en general.

Así que, si te interesan los temas de informática gráfica, videojuegos e inteligencia artificial, no olvides pasarte de vez en cuando por este blog. Intentaré escribir algo todas las semanas.

¡Saludos! =)