El tema de hacer un juego online suele estar bastante minusvalorado por la gente y los productores nóveles. Blizzard ha revelado datos de su infraestructura .

Son 30 departamentos. Tienen 37 diseñadores de videojuego, que se encargan de niveles, magias, eventos, diseño de los mapas, etc.  Sólo del diseño de sus propiedades, porque para modelado/dibujo/etc tienen a 51 artistas. PAra programación (engine*red/ui/tools) son 32 personas.

Pero lo gordo es el mantenimiento. 340 personas hacen falta para la gestión de facturas. 275 para la traducción, 240 para el control de calidad y testeo, y nada menos que 2000 masters para llevar la comunidad. Para los 13.500 servidores, necesitan 68 personas. Sumando equipo de recursos humanos, márqueting, finanzas, etc, hace un total de 4600 personas, y 20.000 equipos, que gastan 1.3 petabytes de almacenamiento.

Desde intel, nos hacen referencia a esta oferta de empleo , para el que le pueda interesar.

Es en Guadalajara, méjico, y está relacionado con la parte de gráficos de la compañia.

En campos como el ray tracing o la simulación física, la intersección de rayo/triángulo es una rutina clave, donde se invierte mucha parte del tiempo de cálculo.

El primer método propuesto se basa en mirar las coordenadas baricéntricas de la intersección del rayo con el plano del triángulo, para comprobar posteriormente si están dentro del triángulo. Este método se describe en raytracing news de noviembre del 88, o en el libro Graphics Gems de Andrew Glassner, de 1990. Es fácil de entender y de derivar en papel con conocimientos básicos de matemáticas. Hay que tener cuidado con temas como puntos en el origen, triángulos de área 0, etc, ya que el código requiere de divisiones. Por ejemplo, recordad que los números en coma flotante en un ordenador incluyen el -0.0, comprobaciónes del tipo x > 0 se evalúan incorrectamente con el 0 negativo.

El segundo método, y el más usado en muchos campos, es el que denomina MT97, por los autores del paper Fast Minimum Storage Ray Triangle Intersection, publicado en 1997. Se basa en desplazar y rotar el rayo a un espacio de coordenadas donde u,v son las coordenadas baricéntricas. Lo más importante de este algoritmo es que no requiere de precálculos, ahorrando así mucha memoria y el proceso de previo de generar datos por cara. La función sólo necesita los 3 vértices del triángulo para devolver un resultado correcto. Es la opción más adecuada para soluciones "on the fly" de generación de triángulos.

El tercer método, es el propuesto en Interactive Rendering with Coherent Ray Tracing, por Ingo Ward en sus trabajos de ray tracing en tiempo real. El método se basa en que la baricéntricas de la intersección son las mismas aunque veamos el triángulo proyectado en un plano. El cálculo es un poco mayor que el MT97 si lo hacemos por fuerza bruta. Pero lo interesante es que podemos precalcular muchos datos necesarios en una tabla antes de realizar las intersecciones. Usando este tabla, se logra un aumento considerable de velocidad, a costa de más accesos a memoria. La estructura de aceleración ocupa unos 48 bytes por cara, que son unos aceptables 48Mb en una malla típica de 1M de triángulos. Pero lo que hace realmente potente este método es la facilidad con la que se adapta a SSE. Permitiendo así testear 4 rayos contra 1 mismo triángulo en pocos ciclos.

El cuarto método, propuesto en Ray-Triangle Intersection Algorithm for Modern CPU Architectures, usa coordenadas plücker, que es un sistema de coordenadas muy apropiado para resolver problemas de intersecciones. El problema es que, a parte de ser 6D, son costosas de calcular. Pero permiten elimitar divisiones costosas. Y funciona muy bien cuando comprobamos 4 rayos, o incluso paquetes de 4x4 rayos contra un triángulo. Ademas, si los triángulos comparten bordes, se pueden aprovechar cálculos entre cada testeo de intersección.

Más información en el wiki de codepixel .

El tema del raytracing en tiempo real y la representación de vóxeles está tomando cada vez más importancia en el mundo de los gráficos. En el último SIGGRAPH de Nueva Orleans se han presentado muchas cosas interesantes sobre este tema.

Por ejemplo, el pasado SIGGRAPH 2008, id software presentó imágenes de lo que será su motor, basado en vóxeles , que aumenta el detalle de los escenarios. Rapidamente, otras empresas están trabajando en esta tecnología, y crytek ha presentado recientemente cosas sobre esto (aqui y aqui ).

Por ejemplo, este investigador, Cyril Crassin , se dedica especialmente a estudiar el tema de los vóxeles de gran tamaño. Este es el enlace a su última charla, que repasa el tema aplicado a los nuevos motores de juegos , donde nos explica un pipeline basado en GPU para representar la información, y una estructura de octrees, empaquetando los nodos hoja en bricks o ladrillos, que almacenan datos globales para todo el paquete, como la opacidad. También nos habla de temas a destacar para el realtime, como la instanciación, el filtrado de los bordes, sombras suaves, y efectos como depth of field.

 Otra tecnología que parece al menos curiosa, es el motor de raytracing de NVIDIA, Optix Ray tracing , basado en shaders para evaluar los rayos. Recordad que NVIDIA es dueña de Mental Ray, y por ahí puede introducir este tipo de tecnologías en el mercado. Lo más interesante es el pipeline que proponen para extender todo esto en la tarjeta. Esta presentación del SIGGRAPH 2009 nos habla más de los shaders que podemos definir en el recorrido de rayos. Las posibilidades todavía están por descubrir, falta investigación en este campo. NVIDIA presenta el ejemplo de implementar photon mapping en espacio de pantalla usando Optix, para simular iluminación global a un framerate interactivo.

El pipeline cambia con la llegada de CUDA, OpenCL o Larrabee, y la posibilidad de instanciar muchos hilos simultaneos, pero con poco acceso a memoria. Sobre todo esto se habla en esta larga presentacion de NVIDIA sobre pipelines alternativos de render.

Estos días estoy probando a optimizar la intersección de un rayo con un triángulo, y en especial el tema de la estructura de aceleración que almacena los triángulos. Mi iea es sacar provecho del SSE y lanzar 4 rayos al mismo tiempo.

Estoy en concreto probando los kd trees, sobre todo porque estoy leyendo unas tesis muy detalladas sobre el tema. En el wiki tenéis más información y una lista completa de enlaces. En general se considera que es la estructura más rápida para lanzar rayos, pero es muy costosa de generar rápidamente. Por eso hay motores de raytracing que prefieren usar BVH. El coste de creación es muy importante en las partes dinámicas de la escena, y hay papers que hablan de cómo reaprovechar un BVH para crear el del siguiente fotograma.

Lo que estoy haciendo ahora es crear un árbol optimizado. Para ello uso el Surface Area Heuristics, que no es más que dar una función de coste a los futuros nodos hijos, teniendo en cuenta el número de objetos candidatos y el volumen que ocupan. También se tiene en cuenta el coste de no hacer ninguna división (por ejemplo, si el area que ocupan todos los triángulos es muy reducido). El algoritmo busca la opción con el menor coste.

Además, se elimina el espacio vacío, creando nodos de 0 elementos. Asi el algoritmo de intersección no perderá el tiempo intentando colisionar contra triángulos, en amplias zonas de la geometría.

La tesis que más me ha gustado por ahora es esta , de Carsten Benthin.

Los siguientes pasos son el intentar optimizar el árbol teniendo en cuenta la cámara. Ya que si sabemos a priori dónde vamos a lanzar los rayos, podremos optimizar la colocación del rayo.

El problema principal que tengo es el excesivo consumo de memoria. Cada paso necesito ir creando unas listas de bboxes que son bastante costosas en cuanto a memoria, y me limitan bastante en cuanto a la cantidad de triángulos que puedo manejar. He leído de gente que usa listas enlazadas en vez de arrays, para reutilizar la lista de candidatos...

Como véis, para desarrollar uso el interface de blender. Así puedo editar y ver rápidamente los nodos. Trabajar así es verdaderamente cómodo, y me permite ir probando diferentes casos sin tener que recompilar.

Entre las innumerables charlas de este año en SIGGTRAPH, shash nos ha destacado en la lista de correo de codepixel esta sesión sobre la programación de shaders modernos. Algunos pdf´s interesantes:

Beyond Programmable Shading Retrospective; charla de un miembro deATi con una visión general de los pipelines de render, su evolución ylos retos que tienen para el futuro, sobre todo en paralelismo.

Parallel Graphics in Frostbite - Current & Future : charla de DICE (mirror' s edge, battle field) sobre le motor de render que usan. Esta charla es muy completa y contiene muchísimas ideas sobre cómo paralelizar el motor. Al parecer, la técnica de dividir la pantalla en tiles, a la hora de iluminar, se está convirtiendo en un standard, sobre todo en PS3. El motor trabaja usando jobs que forman un joblist ordenado. En la propia presentación se exponen algunos ejemplos de trabajos que se paralelizan. Es interesante también ver el gráfico de las dependencias para ver la complejidad que todo esto está tomando.

id tech 5 Challenges : sobre el nuevo y espectacular motor de render de id softwar. A parte de las capturas (creo recordar que era una especie de sistema de voxeles), nos habla de cómo maneja las texturas y de detalles interesantes del sistema multitarea, evitando bloqueos y dependencias.

GPU Primitives---Case Study: Hair Rendering : sobre el renderizado de pelo, y la importancia de ordenar las curvas para calcular las sombras y la opacidad total.

Innovating in a Software Graphics Pipeline : habla sobre técnicas que podremos utilizar para no enviar tanta información a la tarjeta, como dividir la textura, aplicar listas de texturas, lita de render targets, usar pequeños tiles para aprovechar mejor la caché, etc.

A Real-Time Micropolygon Rendering Pipeline Is Not Far Away : sobre aplicar el tipo de render de renderman (arquitectura REYES) a las tarjetas actuales. Un completo repaso de su arquitectura y pipeline.

En el SIGGRAPH 2009 se están presentando muchas novedades y tecnologías. Entre ellas, el khronos group acaba de anunciar OpenGL 3.2 , 

Jon Valdés nos ha escrito un resumen en la lista de correo donde apunta las diferencias de esta versión. Os transcribo aquí los puntos importantes:

•  Geometry shaders: Igual que la extensión que ya había, pero ya es parte del core.

• Layered Rendering:  Cualquier textura 2D (FBOs, etc) puede tener varias capas. El geometry shader puede especificar a qué capa envía cada primitiva (gl_Layer). Esto permite renderizar algo en todas las caras de un cubemap en un único pase, por ejemplo.
  

• Flat shading de variables de GLSL: Si especificas que el varying es flat, la variable no se interpola entre los vértices de la primitiva. Por defecto se toma el valor del último vértice de la primitiva, pero también se puede pedir que use el primero.
  

• Disable Depth clipping: Permite eliminar el near y el far plane, teniendo depth buffers no limitados al rango [0,1]
  

• Texturas multisample: Toda textura 2D puede tener varios samples en cada texel, incluyendo los FBOs. Han metido también instrucciones de GLSL para leer samples concretos de una textura. Esto permite generar un FBO multisampleado, y luego hacerle un pase al FBO leyendo todos sus samples --> Deferred shading+ MSAA !! (Tengo la impresión de que esto lo han implementado usando los layers de antes, siendo cada layer un grupo de samples...)
  

• Seamless cubemaps: El filtrado de texturas en los bordes de las imágenes de un cubemap ahora lee las imágenes adyacentes para hacer el filtrado linear.
  

• Sync objects: permiten esperar (hacer un wait) a que OpenGL termine una determinada operación, o comprobar si la ha terminado ya (es como glFinish, pero más fino). Tiene timeouts e informa de si ha habido errores en la ejecución. Todavía no está implementado, pero está pensado para poder hacer waits a comandos concretos (para OpenGL 3.3, supongo).

ArtFutura y LABoral convocan sus conocidos y prestigiosos premios de animación y desarrollo de videojuegos, con premios de 6.000€ repectivamente.

Los plazos son el 10 de Septiembre para la animación, y 20 de Septiembre para el videojuego.

Los premios ya tienen tradición en el panorama indy español, como una plataforma excelente para dar a conocer proyectos y equipos de trabajo.

Los ganadores recibirán su premio en Art Futura 2009, que se celebrará entre el 29 de Octubre al 1 de Noviembre en Barcelona, con proyecciones simultáneas en otras ciudades de España y Argentina.

En la web de intel, y sus publicaciones gráficas , podemos leer varios papers sobre raytracing, y en especial sobre raytracing orientado a tiempo real.

Fast Ray Tracing for Modern General Purpose CPU : datos generales sobre cómo acelerar el raytracing, y temas a tener en cuenta. Nos habla, por ejemplo, de los costes de recorrer un kd-tree, de forma bastante ilustrativa.

Multi-Level Ray Tracing Algorithm : sobre cómo recorrer un árbol usando grupos de rayos.El paper muestra muchas características que se pueden tener en cuenta si los rayos son similares y coherentes. Por ejemplo, si lanzamos varios rayos con los mismos signos en su dirección, hay muchos descartes que podemos aprovechar. Lo mismo sucede con el propio recorrido del árbol, que podemos recordar de alguna forma para no volver a comenzar desde el nodo raiz. 

Fast, parallel, and asynchronous construction of BVHs for ray tracing animated scenes : trata el tema del multithreading para generar el BVH. El paper propone reconstruir la estructura cada pocos fotogramas, y usar una arquitectura asíncrona para ir recreando la estructura en paralelo, aprovechando ciertas características de la reación de esta estructura.

Efficient SIMD single-ray traversal using multi-branching BVHs : algoritmo muy paralelizable para recorrer la geometría. El paper estudia un BVH con 16 hijos y se testean grupos de 16 triágulos en las hojas. La creación se basa en un BVH binario, pero cambiando las condiciones para colapsar nodos teniendo en cuenta que intersecar 1 triángulo ahora es lo mismo que 16. Por lo que cambia la heurística para tomar decisiones a la hora de crear la estructura.

En la web Dimension 2.5 han publicado un completo resumen de las conferencias de este año en Mundos Digitales 2009.

En el resumen podeis leer sobre las chalas de ilion, la de efectos de javier romero y la de personajes de juan solís. Tambien hay charlas interesantes en general, como la de ziah fogel (aunque fue muy corta), o la de Diego Gutierrez, del GIGA de Zaragoza, que ha sido  muy comentada entre los asistentes. Y como siempre,a conferencia de Jordi Barés, The mill, donde nos cuenta los secretos para el rodaje de anuncios para nike.Una suerte que estos profesionales de esta altura nos cuenten cómo funciona le mundo del cine por dentro.

Estos días se está celebrando el SIGGRAPH 2009 en Nueva ORleans,  y en la web podemos leer qué es lo que ha sido seleccionado para cursos y papers técnicos.

Para hacerse una idea rápida de lo nuevo en cuanto a investigación, podemos ver este vídeo resumen con las tecnologías que más destacan este año.

PatchMatch: A Randomized Correspondence Algorithm for Structural Image Editing : Un video increible que nos permite mover zonas de la imagen y readaptarlas a otras partes de la imagen.

Modeling Human Color Perception under Extended Luminance Levels : De este paper ya habíamos hablado en la web anterioremente. Se trata de ajustar los niveles de iluminación de la imagen en función de cómo el cebro humano percibe el color.

 Energy-Preserving Integrators for Fluid Animation : Un sistema de integración de fluidos que permite colisiones de forma estable.

 Coordinates for Instant Image Cloning : Permite copiar elementos de una imagen a otra imagen distinta. El algoritmo se encarga de adaptar los bordes y el sistema de color para que la integración sea la adecuada.

 Video SnapCut: Robust Video Object Cutout Using Localized Classifiers : Busca las partes del vídeo que están en movimiento (eso sí, con una cámara bastante fija), y nos permite separarlas para una posterior edición.

 PatchMatch: A Randomized Correspondence Algorithm for Structural Image Editing :un paper que permite modificar zonas de la imagen usando patches, buscando zonas similares para recrear la imagen preservando propiedades de textura. Es increible el resultado que consigue.

Variational Harmonic Maps for Space Deformation : un a técnica que permite modificar las mallas preservando muchas propiedades. Crea una especie de "carcasa" sobre el objeto que define la forma y sirve para controlar la deformación.

 Seguramente quedan muchos más, los iremos desgranando poco a poco en los próximos días.

En la web de GameLab 2009 podeis ver las conferencias que se realizaron este año. Hay algunas muy interesantes que merecen la pena, para los que no pudieron asisistir. Estos días estuve viendo las que me han parecido más interesantes:

Bienvenida Oficial : políticos hablando sobre la industria, con la presencia de la Ministra de Cultura.

Inversión y capital riesgo : Varias empresas de capital riesgo y el fundador de Virtual Toys hablando sobre las dificultades de conseguir financiación.

Desarrollo de negocios en comunidades online :  Varios participanes con experiencia nos comentan cómo han conseguid montar una comunidad online que funcione y tenga beneficios. Algo realmente complicado.

Propiedad Intelecutal e Industrial :  Varios expertos nos comentan qué hay que tener en cuanta cuando desarrollamos propiedad intelectual propia e intentamos venderla fuera de nuestras fronteras.

Creer en los invisible : charla de Daniel Sánchez Crespo, de novorama, que nos muestra el juego invisimals, de realidad aumentada. Una pasada. Además, al principio noshalba de su relación con sony.

Planet 51 , donde Ignacio Pérez Dolset nos muestra los trailers de la película y el videojuego. Especialmente interesante porque destaca como factor clave el motor de render cyclops (autobombo!).

Esta charla de sony sobre su motor Phyre Engine nos explica cómo aprovechar el coprocesador de la PlayStation para ayudar a realizar cálculos con la GPU.

La SPU es más lenta que la GPU para pintar geometría, pero aun así, puede utilizarse para precalcular datos. En general, se utiliza la técnica de marcar regiones del fotograma para descartar postprocesos posteriores. Podemos denominar esto "clasificación por tiles". En las capturas de la presentación se puede ver muy claramente.

Por ejemplo, en el Depth of Field, la SPU se utiliza para preprocesar ciertos rangos, y marcar zonas en el frame. Con esto podemos evitar realizar costosos cálculos posteriores en la GPU, descartando rápidamente partes del fotograma que no requieren calcular el radio de desenfoque porque la SPU nos lo ha marcado como máximo.

Otro uso de la SPU es el Deferred Shading, donde la SPU realiza las pasadas iniciales (normales, profundidad, etc) y la GPU se dedica a combinar el resultado final. Realizando la clasificación por "tiles" podemos acelerar el proceso, marcando previamente zonas que no están afectadas por determinadas luces.

También es posible realizar una forma de anti alias "adaptativo", marcando tiles de la pantalla donde es necesario realizar más sampleado.

Otro uso es el rendeizado de luces volumétricas. Como es un pase final, se puede realizar en la SPU.

La presentación nos habla de los problemas de acceso a memoria aleatorio de la SPU, que parecen bastante importantes, y destacan especialmente cuando intentamos acceder a puntos aleatorios de un shadowmap. Es un problema que hay que solucionar con adecuados algoritmos de cacheado, o almacenando/generando todo el shadow map a la memoria de la SPU.

Creo que es interesante leer sobre estas técnicas aunque no desarrollemos para la PS3, porque podremos hacer algo similar con el futuro Larrabee y sus capacidades multitarea.

El motor de raytracing en tiempo real, Arauna, acaba de sacar una nueva demo, un pinball que está bastante chulo . Es verdad que usando una tarjeta gráfica, todo esto se renderiza bastante bien, pero es un ejercicio interesante que nos sirve para ver hasta dónde puede llegar esta tecnología por software.

Arauna usa BVH (jerarquía de volúmenes) para acelerar las intersecciones. El motivo es que funciona muy bien cuando hacemos test con un grupo de rayos. Arauna usa SIMD, comprobando varios rayos al mismo tiempo, y para acelerar el shading. Para acelerar el pintado de píxeles, se usa un antialias adaptativo para lanzar mñas rayos donde es necesario (normalmente los bordes de los objetos). En este enlace hay más información sobre los detalles técnicos .

Despues de varios días fuera, ya vuelvo a estar al 100% para actualizar la web. Estos días han pasado muchas cosas, pero en especial, ha sido el Gamelab 2009 , que según me han contado, fue todo un éxito tanto de conferenciantes como de los asistentes. Una excelente noticia. Esta semana se celebra también en Galicia el festival Mundos Digitales , el más importante a nivel animación que se celebra hoy en día, con la presencia de empresas importantes. También destacar que ha salido el segundo trailer de la película Planet 51 , con nuevas escenas, y calentando motores para su estreno el 20 de noviembre.