A mi me han gustado especialmente, sin ningún orden específico:

Multi-threading made easier through Open-Source Threading Building Blocks

Task stealing: cuando un core real se queda sin tareas “roba” a otro una tarea para maximizar el throughput

Después de hacer una extensa introducción sobre paralelismo, paralelismo sobre datos, paralelismo funcional, etc… muy orientado a videojuegos (bien!) nos presenta Threading Building Blocks(TBB), una librería brutal, open-source y multiplataforma, de la mano de intel.

La parte novedosa de usar TBB es que está orientado a tareas (task patterns), no a programar threads (hilos) como tal. Programar tareas hace que, teóricamente, el diseño escale automáticamente según el número de cores que tenga nuestro procesador. TBB es para C++, y está hecho para C++, por lo que usa plantillas para definir concurrent-containers (hash, queue, vector, ..), algoritmos paralelos (sort, for, while, reduce, …), tiene también un patrón “pipeline” para poder encadenar tareas, scalable-memory-allocators (para evitar sincronizaciones entre tareas al reservar memoria), etc.

Otra razón para usar tareas es que es fácil debuggear, ya que por diseño, puedes limitar todo a un single thread y depurar, una vez todo funciona puedes lanzarlo en multithread con casi todas las garantías de que va a funcionar.

En general TBB está muy bien montado. No se si se nota las ganas que tengo de usarlo

To hardcode or not – considerations about an ultimate demotool

Motor de render picoEngine, integrado dentro de Maya como plugin. Escena de la última demo de plastic: Linger in Shadows

¿ hardcodear demos ó demotools ? Evolución de plastic desde sus primeras demos hardcodeadas a los plugins y editores que ahora usan para diseñar demos. Por lo visto tienen su motor de render (picoEngine) integrado como un plugin del editor que usen (Maya en este caso), y un editor de escenas para ajustar timelines, velocidad, etc.

Definitivamente para plastic el enfoque está muy cerca del artista, aunque reconocen que cierta funcionalidad es más cómoda de implementar en código que diseñarla con un editor.

Tonite let’s all make demo in Bingen

La demo cuenta una historia, tiene un flujo y los efectos de transición, no son tales, si no que se integran en ese flujo conectando una escena con la siguiente, suavemente.

Vemos la otra cara de la moneda, para ASD lo principal es el código como herramienta y defienden que muchos de los efectos y transiciones no se podrían hacer con comodidad en un demoeditor. Por otro lado, como con plastic, no todo es blanco o negro.

Empieza con las razones por las que no hacemos demos ( me ha gustado eso de : “19% estamos intimidados por Farbrausch” ) y cómo las hacen en ASD. Básicamente: librería sencillita en C++, soporte básico para manejo de shaders y texturas, sin engine para animaciones, sistemas de partículas adecuados, scripting para los eventos y funciones de cámara imaginativas.

Desmitifican el “hacer una hardcoded demo es más difícil” y explican paso a paso como organizan sus demos. Detallan cómo organizan las escenas, efectos y las transiciones (aunque las transiciones de ASD son para dar de comer aparte).

Del motor de partículas destacan que es una pérdida de tiempo el típico bucle de actualización de partícula por frame, ya que en el 95% de los casos, las partículas se comportan de forma determinista por lo que se puede calcular su path previamente.

También es interesante cómo ajustan los detalles de las escenas, utilizando rands, y semillas asociadas a eventos de teclado y ratón para encontrar algún estado que quede bien en la demo (mola!!!).

Las cámaras tienen solo un par de movimientos, elípticos y lineales, interpolados con s-curves, simple y controlable.

El resto es filosofía de diseño, muy, muy interesante.

When there’s smoke there’s fire

¡¡ Ruido, y más ruido !!

Una presentación de nvidia muy asequible para el público en general sobre generación procedural y cálculo en la GPU. Explica con muchísimo detalle perlin noise para modelado de partículas, al margen del uso que hagan la explicación por si sola ya merece la pena.

Después continúa con la evolución del perlin noise hacia el Simplex noise y cómo usarlo, acabando con notas sobre el sampleado del ruido para conseguir los mejores resultados.

La segunda parte de la charla trata sobre cómo renderizar humo. Empieza por la composición del humo en la escena (esta es la parte fácil y similar con la primera parte de la charla). Después comenta cómo calcular la simulación de fluidos en la GPU y añade cómo detectar las colisiones con geometría de la escena (pasándola a un volumen).

Update Iconoclast by ASD increíble!!! En el canal #demoscene (irc-hispano.org) estamos flipando.

Ah! y fotos de la Euskal13 aquí: slack y rolemusic

Felicidades a Slack y Lemoniac por ese gran premio.

Otros Links:
Paradise by RGBA Ganadora en intros de 64k en la Euskal Encounter 12.

Al tercer día ya se puede afirmar que se han agotado todas las PowerBalls, y al final cuando nos habíamos decidio ir a comprarlas ya no quedaban! Pese a todo David y yo hemos dejado el record de la fila en 11440 revoluciones y 11370 respectivamente

ZzzzZZZzzzZZZzzzzzzZz Buenas noches zzzzzZZZZZzzZZZZzzZZzz

Levantados a la temprana hora de las 9:30, con un buen lavado de cara, estamos listos para empezar a trabajar (definitivamente montar un weblog es un sumidero increible de tiempo invertido, y poco productivo).

Hoy toca programar!