Sarah Alexandra Yánez Rodrigues

¡Hola!

En esta oportunidad les comparto un poco del proceso creativo que dio lugar a estas etiquetas  generativas, diseñadas para las botellas de la marca VinoZeta.

 

En mi planteamiento, quise respetar la petición del cliente y hacer mi propia propuesta siguiendo los mismos
lineamientos: ajustarme en la medida de lo posible al diseño de la etiqueta, pero integrando un imagen generativa,
única para cada cliente, que simule el humo y sus movimientos vaporosos.

Así pues, del caso propuesto mantuve la estructura de la etiqueta, dejando un espacio al lado izquierdo, reservado para
los datos de fabricación del vino, el número de serie de la botella, los datos de la marca e información del grado
alcohólico. La porción del lado derecho de la etiqueta, que ocupa la mayor parte, es la destinada a la imagen generada.
Así pues, la primera parte del proceso fue planificar cómo iba a aplicar los datos de una tabla a mi diseño generativo.
Primero quise implementar la idea de crear una semilla única para cada cliente, siendo esta un número de muchos
caracteres (elemento de tipo long en Java), y a partir de ahí empecé a trabajar mi idea. Lo primero fue crear la tabla con
mis datos de ejemplo, con una columna para cada dato: Nombre del comprador, Apellidos, Añada del vino, Número de
serie de la botella y Número del pedido; trabajando también con un dato extra, el número de botellas de un pedido, que
aunque no aparece de manera explícita en la tabla, podemos obtenerlo a través de la cantidad de filas con un mismo
número de pedido.

En cuanto al aspecto del diseño, si bien tenía claro que quería incorporar el uso de formas como agentes o walkers para
lograr el aspecto vaporoso, también quería adaptar la imagen de la uva como concepto ligado al vino, por lo que pensé
que sería buena idea mapear alguno de los datos de la tabla a la cantidad de uvas presentes en un racimo, que primero
se dibujaría en pantalla y luego sus uvas, en el papel de agentes, se desplazarían dentro del área de la imagen para
generar las virutas de humo. Con esta idea en mente me planteé que, para trabajar con una semilla, debía destinar
partes de su extensión a un fin en concreto: por ejemplo, una primera cantidad de números determinaría la cantidad de
uvas presentes en el racimo, otro grupo de números de la semilla determinaría la cantidad de colores presentes en la
paleta, otro grupo los ángulos de la trayectoria de los agentes, y así sucesivamente.

Con esta base, comencé a trabajar, primero que nada extrayendo los datos de la tabla para construir mi objeto del
cliente, y así poder acceder a los datos de forma más fácil. Fue a medida que iba construyendo el objeto y sus métodos,
pensando cómo aplicar los datos a lo agentes, que decidí descartar la opción de una semilla tan extensa y en cambio
apliqué varios datos de un cliente a diferentes aspectos de los agentes, como explico a continuación:
La suma de los valores unicode del nombre completo (nombre + apellidos) determinarían la paleta de colores, única
para el cliente.

La cantidad de botellas de un pedido indicarían la cantidad de vértices presentes en la forma del agente, con un
mínimo de 3 vértices para pedidos de menos de tres botellas, así como también determinarían la cantidad de
agentes generados. Esto permite que la forma obtenida por el programa también sea personalizada según el
número de botellas del pedido.

El promedio de los dos últimos dos dígitos del número de serie de la/s botella/s del pedido se mapean para obtener
la dimensión del radio de los agentes.

También se barajaron otras ideas como, por ejemplo, utilizar la añada de alguna manera para determinar la velocidad
de los agentes, o la saturación de los colores en caso de utilizar una paleta de colores fija; sin embargo, en etapas más
avanzadas y a medida que se iba experimentando con el comportamiento del diseño, estas ideas se descartaron, ya
fuera porque complicaban el programa sin necesidad, o porque simplemente su uso no tenía cabida dentro del
comportamiento o estética deseados.

Con estas reglas en mente, creé los métodos del objeto Cliente (Customer) que me permitieran almacenar esos datos,
así como el objeto Agente (Agent), que recibiría al objeto anterior para crear los agentes a medida.

Diría que el desafío más grande vino dado por la creación y manipulación de los agentes, donde los recursos del caso de
estudio disponibles en OpenProcessing.org y la sección “Shapes from Agents” del libro Generative Design Revised
fueron esenciales para el desarrollo del comportamiento de los agentes. El lograr los valores correctos para la velocidad,
el movimiento, el tamaño, y saber de dónde se obtenían, fue un desafío, ya que a pesar de que esto se había definido
desde un principio, en muchos casos la teoría no funcionaba en la práctica. Otro de los retos fue asegurarme de que, si
bien es necesaria cierta aleatoriedad para poder generar este tipo de imágenes, era preciso poder distinguir los gráficos
generados para un cliente u otro, ya que este era el objetivo real del proceso, y por eso había cierto peligro en recurrir en
exceso al factor aleatorio, y no a los datos externos de la tabla. Asimismo, después de hacer varias pruebas, me pareció
que el generar varios agentes recargaba en exceso el diseño, así que acabé por descartar la idea y utilicé uno solo.
Así pues, mi planteamiento inicial cambió mucho a lo largo del proceso, pero estoy satisfecha con los resultados
obtenidos, que comparto a continuación.

 

Este proceso ha sido especialmente interesante para poder entender cómo se pueden utilizar datos externos en un
diseño generativo, la complejidad de esta traducción entre datos y gráficos, y cómo el manejo de la información con la
que trabajamos es crucial en la definición del resultado de nuestro diseño. Diría que los desafíos más complicados del
proyecto han sido:

• Adaptar la información al diseño que el cliente ha solicitado, sabiendo cómo mapearla de forma que sea útil en la
  generación de nuestra imágenes, y permitiendo que cada imagen generada sea diferente de la anterior, pero
  identificable a la vez.
• Mantener el orden al momento de asignar valores de datos externos a valores dentro de nuestro algoritmo
  generativo. Esto es así porque, cuando se trabaja con varios datos a la vez y mientras hacemos pruebas, es fácil
  olvidar para qué sirve un dato en específico, o no utilizar datos que pensábamos que serían necesarios durante las
  etapas de planificación, lo que puede resultar en código verboso.

En general, he quedado bastante contenta con el resultado 🙂

¿Y a ti, qué te parece?

¡Hola! 🙂

En esta oportunidad me gustaría compartir mi primer proyecto de diseño generativo, que fue desarrollado para la segunda entrega de la asignatura homónima.

Para este encargo, se pidió analizar un caso de diseño generativo de un cartel para la edición #27 del Mercat de la Volta, un evento que une el arte y la comunidad, y que tiene lugar anualmente en el barrio de Sant Narcís, en Girona. El análisis sirvió como paso previo a la creación de mi propia versión, y como acercamiento a la estructura que sigue un proyecto generativo en fases de desarrollo.

Ya con las manos en la masa, lo primero fue plantear la pregunta ‘¿Qué es lo que identifica a un barrio?”. La respuesta es bastante amplia y varía mucho para cada caso, haciendo que fuera demasiado difícil de responder, así que la siguiente estrategia fue buscar otros trabajos de diseño que integraran la identidad visual de un vecindario, proceso del que surgió esta suerte de moodboard:

 

 

¡Hola! 🙂

En esta entrada les comparto la historia de mi flipbook, titulada «Un Vuelo Accidentado». ¡Espero que la disfruten!

Saludos,

Sarah.