Para los que quieran practicar un poquito de programación gráfica interactiva, os recomiendo mirar el pygame , una extensión de python que nos permite hacer prototipos rápidos de las ideas que tengamos en la cabeza.

PyGame nos ofrece código para gestionar una ventana, a través de la SDL. Nos permite también la gestión de eventos, tema complicado, y que se vuelve sencillo a través de python. También incluye funciones para cargar texturas y mostrar imágenes en pantalla, y hasta soporte para sonido.

Además, tenemos la ventaja de que python es un lenguaje que cuenta con muchísimas librerías adicionales, por ejemplo, para acceder a bases de datos, descargar información de internet, letura de ficheros XML, etc.

El coste, obiamente, es el  del rendimiento. PyGame es bastante lento cuando hablamos de pintar con OpenGL.

Dimensión 2.5 nos ofrece otra larga y didáctica entrevista , a la que nos tiene acostumbrados. En este caso es uno de los fundadores del famoso estudio Keytoon, que nos asombró a todos con su corto/demostración del motor de render Maxwell.

Fue uno de los participantes el el corto "Alma " de Rodrigo Blaas, Una apuesta muy importante de los mejores profesionales que podemos encontrar por aquí.

La entrevista nos habla de su nuevo proyecto, una academia de 3D dirigida a sacar buenos resultados, independientemente de la herramienta. Sigue el modelo que realmente creo que funciona, donde se intenta que el alumno salga de la escuela con una demo potente. que al menos en el mundo de la infografía, y sobre todo en los artistas, es lo único que te va a abrir alguna puerta laboral. El planteamiento me parece correcto, y será una opcion más de formación de calidad.

Llevo unos meses un poco liado, enfrascado en varios proyectos que me han quitado un poco de tiempo para codepixel... pero el mundo de los gráficos continúa avanzando, y siempre hay novedades y tecnologías que comentar.

Hoy quería destacar este nuevo motor gráfico : OctaneRender . Es uno de los nuevos motores que están surgiendo como setas, que usan CUDA para renderizar imágenes fotorealístas en tiempo real, de forma interactiva. Este motor me ha llamado la atención porque parece que está creado desde cero, pensado en CUDA, y en la web tiene unas capturas impresionantes, como esta , que ha sido renderizada en tan sólo 4 minutos.

Estamos viendo unos avanzes increibles en la tecnología de GPGPU, y la consolidación de OpenCL va a traer nuevas herramientas muy interesantes en este campo. Aquí hay un buen campo de investigación, y en el futuro se ampliarán las tesis doctorales y papers sobre cómo aprovechar mejor OpenCL/CUDA en estos campos. Estaremos atentos.

Por mi parte, creo que hay muchas limitaciones en un motor "fisicamente correcto", sobre el campo de la producción real en cine, como puede ser el tema de la dificultad en separar los diferentes pases de información. Pero hay que reconocer que conseguir uns resultados fotorealistas nunca fue tan sencillo y rápido. Y quizas para campos como la integración con video real, pueda tener un hueco precisamente por esto. Por supuesto, en arquitectura o publicidad, estas tecnologías tendrán gran aceptación.

Hoy me he encontrado con que la Royal Society de Inglaterra, para celebrar su 350 aniversario, ha puesto a disposición de los internautas varias publicaciones históricas de gran relevancia. Una, para mí, fundamental, es una carta de Isaac Newton, comentando sus experimentos con los prismas de cristal , dónde descubre que la luz está formada por un espectro de color, y marcando así el inicio del estudio moderno de la energía. Leyéndo la carta, el lector se contagia de esa ilusión y asombro que le producen sus nuevos descubrimientos. Al final de la carta, pide al resto de los miembros de la Royal Society, que por favor, prueben estos experimentos, y se le comunique cualquier avanze. Isaac Newton no montó un gran negocio, ni fue extremadamente rico, pero es una de las piezas clave que ponen a Inglaterra en el mapa de la historia.

En ese mismo tiempo, en la península reinaba la Inquisición Española, que velaba por los derechos de los fervientes católicos. Entre las medidas para proteger la pureza ideológica, destacaba el “Index Librorum Prohibitorum”, una lista de libros y autores censurados. Esa garantía, consiguió que España estuviese excluida del resto de la comunidad científica durante siglos, condenando a la población a vivir ausentes de Copérnico, Kepler, Descartes, o Kant. Ideas que para el Santo Oficio eran peligrosas, pero que en el resto de Europa sirvieron para poner a la razón y el conocimiento como fuente de progreso. La sociedad española actual está pagando todavía tanto años de retraso científico.

Ayer se ha presentado en el parlamento, por la puerta de atrás, una iniciativa para regular Internet. Con la excusa de los derechos de autor, quieren dar a la administración (sin jueces de por medio), capacidad para censurar páginas. Hoy porque supuestamente tienen enlaces, pero mañana, porque molestan, no interesan o simplemente, no pagan comisiones. Detrás están los de siempre: “Los Otros”, las grandes empresas que quieren tener derecho a decidir qué podemos leer tú y yo. Es realmente paradógico, que quién se dice “socialista”, o quién mantiene un “Ministerio de Igualdad”, sea el que vaya a tener el dudoso honor de incluir la censura en Internet. La red, ese terrorífico invento donde un blogger puede enfrentarse a una multinacional... y ganar. Donde todo el mundo es igual. No estamos aquí hablando de si un partido o otro (Alejo Vidal Cuadras fue el líder de la infame votación en el Parlamento Europeo). Aquí estamos los ciudadanos contra el poder corporativo. Está claro que el objetivo es el de poder filtrar el contenido, poder decir qué se puede o qué no se puede publicar.

Internet es conocimiento, es cultura, es sabiduría, es avance, es progreso. Es la wikipedia, es linux, es facebook... es la posibilidad que tiene la gente corriente de colaborar, de aportar entre todos. En cuanto permitamos a un Santo Oficio, que decida qué es lo que se puede o no se puede leer, condenaremos, otra vez a este país, a siglos de retraso cultural.

Me parece pornográfico, que la ley de Economía Sostenible, se preocupe de cortar páginas de Internet, y no se preocupe de que los proveedores del servicio sean las empresas que más reclamaciones atesoran en cualquier oficina (defensor del pueblo, OCU, telecomunicaciones...). Que tengamos un acceso a internet de segunda, con unos precios desorbitados, y totalmente indefensos ante los abusos de los operadores. !Lo que necesitamos es competencia en ese sector! No grandes empresas que hinchan pecho por los beneficios que obtienen haciendo lobby con los partidos.

Hace unas semanas, los ministros de Industria y de Cultura, se pasaron por los estudios de Ilion, para ver de primera mano cómo se hizo Planet 51. Tengo que decir, que si no fuese por la Royal Society, por la Wikipedia, por los tutoriales desinteresados de internet, y sobre todo, por páginas de descargas que me permitieron probar todo tipo de aplicaciones, desde que era joven, desde luego sin ellas no hubiese aprendido nada de iluminación global, ni de programación. Y lo mismo digo de todos, absolutamente todos, los miembros del equipo que hicieron Planet 51.

Por esto, Codepixel se suma al manifiesto “En Defensa de los Derechos Fundamentales de Internet ”, y espero que entre todos podamos parar la censura.

Repasando enlaces, he encontrado este resumen de una charla de Capcom , explicando los detalles del motor de Lost planet, y una explicación de sus herramientas. El artículo original está en japonés, pero existe una completa traducción en beyond3d . Es un poco antiguo, del 2006, pero la arquitectura es la que más se utiliza hoy en día en los grandes motores, y el artículo está ilustrado con buenos diagramas explicativos.

El motor está pensado para multitarea, dividiendo los distintos procesos en módulos (grandes bloques como el sistema de render, físicas, etc), loops (pequeños sistemas que no encajan en el resto de módulos) y tareas (pequeñas divisiones de código que se ejecutan en multitarea en cada frame). El motor tiene 2 colas, una para tareas que tienen que ejecutarse de forma ordenada, y otra para tareas que pueden ejecutarse en cualquier orden.

Sobre el render, el motor se ejecuta en un hilo independiente, lanzando comandos de pintado, que se ordenan previamente, según material, profundidad, etc. Cada hilo tiene comandos de render que después se "consolidan" en el thread que se dedica a pintar, sumando las colas de todos los hilos del sistema.

En el enlace de beyond3D , podéis ver el resto de la presentación.

Hoy por fin se va a estrenar el proyecto en el que llevo metido todos estos últimos años. Planet 51 sale al público en USA, y la semana siguiente en el resto del mundo. ¿Qué voy a decir de la película? pues que a mi me gusta, y creo que tiene cosas muy potentes, como la iluminación y la animación... y gracias a todo esto, la pelicula transmite, que es lo importante. Llevamos años con todo esto, montando el estudio, montando la forma de trabajar, desarrollando herramientas, cambiando todo para que la calidad sea la mejor posible... Hay mucha gente muy buena que ha trabajado en este proyecto, y el resultado se nota. Ya lo veréis.

Este tutorial os muestra cómo cargar imágenes PNG de forma sencilla. El formato PNG aparece como substituto del GIF, que estuvo muchio tiempo protegido por una patente, por lo que se optó por hacer un formato abierto para las imágenes que se envían en internet.

La comrpesión de PNG utiliza el algoritmo "deflate", el mismo que utiliza el gzip, que no es siempre el más eficiente, pero al menos no tiene problemas de patentes. Es un sistema de compresion que no tiene pérdidas, por lo que se puede abrir un png, grabarlo, abrirlo, grabarlo, etc muchas veces y los valores de los píxeles se mantienen intactos. Al contrario que el jpeg, que va degradando calidad en cada compresión.

Una característica realmente interesante para un programador es la variedad de formatos de pixel que png almacena. Guarda valores en 8 y 16 bits. Los 16 bits son importantes si vamos a hacer muchas operaciones de composición, ya que el redondeo progresivo nos genera bandas de colores uniformes, al ir despreciando decimales. No he probado si el formato 16 bits es compatible con los formatos 16 bits de las GPU´s. Pero si nos vamos al ahorro. PNG soporta formatos "packed", donde por ejemplo, podemos especificar imágenes de 1 bit por pixel. De tal forma que 1 byte, representa el valor de 8 píxeles (muy útil para máscaras).

La librería incluye formas automáticas de conversión. Permite leer las imágenes en 8 bits, aunque estén en 16 bits, o descartar los valores alpha. Todo esto se hace en la lectura, lo cual nos ahorra código, memoria, y tiempo de ejecución.

Un tema que a mí me interesa especialmente es la gestión de color. La cabecera PNG permite especificar valores del espacio de color (incluso embeber un perfil de color completo, pero es muy complicado de leer). Tiene un campo gamma que os permite transformar los valores de los píxeles a lineal. De esta forma, podréis saber si la textura es una imágen con el gamma aplicado (que es lo normal), y hacer la inversa para tener los valores en lineal. De esta forma, podréis operar con ellos sin tener problemas con las transparencias. Pero si teneis una imagen que no tiene gamma (por ejemplo, una textura que uséis de parámetro para un shader), podeis leer la cabecera del png, y no realizar esta conversión. Al elevar un valor a su gamma, y realizar despues el inverso, perdemos mucha precisión (especialmente si trabajamos en 8bits), y este paso nos lo podemos ahorrar si tenemos la imagen en lineal. 

Otro aspecto importante del formato PNG es la posibilidad de meter texto. Pocos programas lo soportan, pero podéis usar la librería para "marcar" texturas, dependiendo del uso que le váis a dar, de esta forma, vuestro motor puede operar de forma distinta en función de lo esté escrito en la cabecera. Por ejemplo, podéis enviar la textura al canal especular, o indicar que no queréis que genere mipmaps en la carga. Las posibilidades son enormes.

Una excelente noticia para los desarrolladores independientes. Epic ha anunciado que su motor gráfico unreal, y todo el juego de herramientas adicionales estan disponibles para usar sin problemas de licencia. En este enlace tenéis más datos.

El acuerdo mantiene un coste cero para desarrollos sin ánimo de lucro. Pueden ser publicados en internet, distribuidos, etc.

Los videojuegos que se pretendan vender, tienen un coste de $99 por desarrollador. Si los ingresos son menores que 5000€, no tienes que pagar nada a Epic. Si tus ingresos superan los $5.000, la comisión será del 25%. Los ingresos pueden ser tanto de venta directa, como de cursos, subscripciones, configuraciones, etc. En el mundo de las consolas, hay que pagar también una parte de las ventas a la plataforma (PlayStation, Nintendo, etc).

Si usas el motor para la empresa, pero no vendes a terceros, el coste es de $2.500 por desarrollador.

En el pack de aplicaciones , está incluido:

Unreal Engine 3 : El motor completo, pero sin código fuente. La lista de capacidades gráficas es enorme.

El potente editor del Unreal , que incluye:

Content Browser : Completo gestor de información y modelos 3D, que permite separar la información por tags.

UnrealScript : Lenguaje de programación nativo del motor, similar a C++.

Kismet : Editor visual de scripts para juegos, para los diseñadores del gameplay (una potente herramienta para separa a los programadores de los diseñadores).

Martinee : Completo editor de cinemática y animaciones, que permite editar la animación en tiempo real y poder ver el resultado final en directo.

Cascade : editor modular de efectos/particulas, etc.

Fisicas : usando la tecnologia NVIDIA Physx, incluye un editor adicional para definir las colisiones, límites, etc.

Lightmass : un simulador de iluminación global para el render.

Todo esto permite generar videojuegos y aplicaciones que corren en un simple ejecutable, haciendo su distribución simple y sencilla.

Esta es una oportunidad excelente para los estudios independientes, que no pueden acceder normalmente a la mejor tecnología. el juego de herramientas es muy potente, y para sacarle partido completamente, hace falta un completo equipo de artistas y diseñadores. Creo que este movimiento es una fuerte apuesta por el mercado emergente de empresas que piensan distribuir de forma online sus videojuegos... quién sabe.

Hoy hacemos público el "Planet Codepixel ", un agregador de blogs para la comunidad de programadores del mundo de los gráficos. Actualmente hay 14 blogs registrados, y muchos de ellos se actualizan con bastante frecuencia.

Si estáis interesados en incluir vuestro blog, podéis enviar un correo a This e-mail address is being protected from spam bots, you need JavaScript enabled to view it con el nombre y la dirección. Buscamos blogs pensados para gente técnica: programación a bajo nivel, tarjetas gráficas, comentarios de nuevas tecnologías, etc. y también es un excelente medio para presentar los proyectos en los que estéis trabajando. Vuestro trabajo puede servir de inspiración a otra gente, y crear escuela :)

ATI anuncia los primeros drivers de OpenCL que realmente soportan la GPU completamente. El programa todavía es beta, pero digamos que ya son funcionales, suficiente para comenzar las pruebas y explorar realmente los límites de la tarjeta.

 Las plataformas soportadas son windows (incluido windows 7) y linux.

Aquí teneis el vídeo de presentación del CryEngine 3 , realmente espectacular. El nuevo motor incluye de todo: iluminación global por tarjeta, físicas, animaciones, inteligencia artificial, etc. Y el kit de herramientas parece bastante completo, con editores de los mapas y sobre todo de la gran cantidad de efectos que podemos incluir, como partículas, humos, etc.

El motor ya está disponible para que los desarrolladores comiencen a usarlo. Eso sí, el precio creo que ronda los €3M...

La semana pasada, se celebró un evento de nvidia , donde las empresas emergentes podían mostrar sus avances a ver si conseguían inversión o simplemente adquisiciones por parte de grandes emrpesas. También los desarrolladores más experimentados podían mostrar aplicaciones desarrolladas con la GPU, y los grupos de investigación podían mostrar sus avances en estos campos . Acaban de publicar los vídeos de las conferencias en la página web .

 Jen Hsun, CEO de la compañía, nos habla de las posibilidades que hay en invertir en tecnología, y los retos que tiene llevar una startup hacia el éxito, ya que la conferencia tiene un alto perfil inversor para pequeñas compañías. Nos recuerda que hay que creer en la compañía, y si consigues el dinero, y crees en la idea, podrás crecer y prosperar. En España es prácticamente imposible encontrar dinero , así que nos quedaremos con las charlas técnicas.

La conferencia más interesante es la que comienza Richard Kerris, CTO de Lucas films, nos habla de cómo usaron las GPU's en cine. Es un tema de bastante actualidad, porque con el tiempo, parece que tanto los videojuegos se están acercando al cine, como el cine comienza a usar tecnología realtime. En este vídeo se muestra cómo el estudio usa GPUs para las simulaciones de partículas, y nos habla de su granja de GPUs para cálculos intensivos. Es la típica charla de ILM dónde nos muestran las capas de renderizado, pero lo interesante es que nos muestran cómo ha mejorado el pipeline de producción . También nos muestran su aplicación zViz, que es un editor 3D construido para diseñar la película, y exportar todos los efectos a render.

NVIDIA ha anunciado su nueva arquitectura de hardware, llamada Fermi

Características

El chip está formado por 16 celdas de stream (Streaming Multiprocessor) con 32 cores por celda, con un total de 512 cores, diseñado para ejecutar una enorme cantidad de tareas en paralelo. En total son 3.000M de transistores.

Los programas de la GPU se denominan kernels. Un kernel se ejecuta en un grid de bloques de threads. Cada thread dentro del bloque de threads ejecuta una instancia del kernel, y tiene asignado su propio id de thread, que utiliza para acceder a un conjunto de datos. Un bloque de threads es un conjunto de threads que se colaboran entre sí, usando sistema de control como barreras, y memoria compartida, para realizar el trabajo del kernel. Un grid es un conjunto de bloques de threads, que lee datos de la memoria principal y devuelve los resultados. De este modo, los threads disponen de memoria local, los thread blocks disponen de memoria compartida, y los grid usan la memoria global. La ejecución en paralelo se gestiona en el controlador GigaThread, que puede gestionar hasta 1.536 threads simultaneamente.

Streaming Multiprocessor

Cada bloque de threads se divide en "warps" de 32 threads, que es la unidad mínima de gestión. Cada SM tiene 2 unidades para gestionar warps, con lo que se pueden enviar 2 warps a cada SM en cada ciclo. El gestor de warps envia las instrucciones a los cores para ejecutar así 32 instrucciones en paralelo.

Los 32 cores del SM no tienen registros, a diferencia de los procesadores normales, ni unidades de traducción de direcciones, etc. Deja todo esto al SM. Los cores son unidades muy simples que pueden cambiar de thread de forma extremadamente rápida.

Cada core del SM tiene una unidad simple de coma flotante que permite pipeline, otra para los enteros, una parte de lógica, un dispacher y una cola de resultados. Todos ellos comparten una zona de memoria especial, a modo de registros locales, de 4kb, que reside en el SM.

Cada SM dispone de 16 unidades de load/store, con lo que se pueden calcular direcciones de memoria para 16 threads de forma concurrente. Los cores usan estas unidades para acceder a los datos exernos al SM.

Para acelerar los cálculos de coma flotante, en cada SM se incluyen 4 procesadores especiales para operaciones complejas, como seno, coseno, etc, denominado Special Function Units (SFUs). Al sacarlos de los cores, el diseño de estos es todavía más sencillo.

Memoria y Caché

Para acceder a la RAM de la tarjeta, se dispone de seis particiones de 64bits, en un interfaz de 384bits, dando una capacidad máxima de 6Gb de memoria DDR5 en la tarjeta.

Se incluyen comprobaciones de fallos de escritura (Error checking and correction) que en general hacen el sistema más estable.

Para acceder a la memoria global del sistema, se usa un path a memoria de tipo "enlace PCI-Express bidirecional", consiguiendo los 12Gb/sec, frente a los 3GB/sec que lograba el anterior path unidireccional.

El chip tiene 1Mb de caché, repartida en grupos de 64Kb, y 768Kb de caché unificada de nivel 2. Esto es un gran avance, ya que anteriormente, las GPUs no disponian de caché para sus cálculos. La arquitectura de caché L1 permite dividir los 64k de cada procesador stream en 2 zonas, una es caché normal, y otra es un local scrachpad (48k cache, 16k local, o viceversa). La idea es que la memoria scrachpad es una memoria que está al mismo nivel que la caché en cuanto a velocidad, pero es controlable por la aplicación (tiene instrucciones propias para escribir en ella), y está pensada como una zona de memoria temporal para cálculos que no se copian a la ram global. Con esto evitamos problemas de contención (muchas celdas escribiendo en el bus de datos). Esta capacidad de poder configurar la forma en que funciona la memoria local, tendrá que ser explorado en el futuro, sobre todo por el compilador.

Programación

Se ha mejorado el set de instucciones, de tal forma que se podrán desarrollar compiladores genéricos, para C++, OpenCL, DirectCompute, etc. Según la información de NVIDIA, el chip ha sido especialmente optimizado para OpenCL y DirectCompute (quizás reconociendo que este será el futuro de las API's). En concreto, permite a los compiladores optimizar el layout de memoria de los arrays, algo que hace que estas APIs ganen en rendimiento.

Las instrucciones ahora son predicadas, eliminando la necesidad de diferentes ramas de ejecución para secuencias de código.

El chip dispone de 64bits para el tamaño virtual de memoria, gracias a un nuevo juego de instrucciones. Los punteros de memoria ahora son unificados. Esto es, ya no existen distintos tipos de memoria enlos kernels, con espacios de memoria distintos. Los 64bits ahora permiten mapear todos los tipos de memoria de la GPU (en programas compilados para la GPU).

Las operaciones atómicas, usadas para el control de bloqueos entre threads, se han optimizado, y ahora son entre un 5X y un 20X más rápidas.

Los cambios de contexto en la ejecución son más rápidos, unos 25ms entre programas Además, se puede ejecutar un kernel, mientras otro está comunicándose con el bus principal de datos. La ventaja es que se puede cambiar varias veces de kernel en cada frame, evitando así los problemáticos übershaders.

Hay posibilidades de depuración como en los procesadores normales: breakpoints, single step, traps, etc. Con ello se facilita enormemente la programación de estas arquitecturas. Este es un cambio crucial, ya que se espera poder depurar CUDA directamente en el depurador del visual studio para GPUs.

Problemas

Todavía dispone de una reducida memoria para cada celda, limitando mucho los programas que se pueden ejecutar.

No es posible mapear la memoria de la GPU directamente, con lo que se pierde mucho tiempo enviado los datos a la GPU desde el programa principal. Además, la ley de Amdahl nos dice que si una parte de un proceso paralelo es lento, todo el programa se limitará a este proceso.

Enlaces

• GT300 en la wikipedia.

• web oficial de fermi.

• The Top 10 Innovations in the New NVIDIA Fermi Architecture, and the Top 3 Next Challenges

 más info en el wiki de codepixel .