En la web de XSI podéis leer un artículo muy interesante sobre la forma de trabajar con el gamma del monitor . El monitor no tiene una respuesta "lineal" al color. Esto es, un pixel no seilumina al 50% si mandamos el 50% de gris. La respuesta se parece más a una función exponencial, cuyo exponente solemos llamar "gamma". Realmente la respuesta es más compleja, y los drivers suelen usar una tabla "lookup" para ajustar los valores, sobre todo en los extremos (como los más oscuros). Por eso debemos de corregir las imágenes para que se vean correctamente en los monitores. El jpeg y el png suelen traer perfiles de color donde se especifican correcciones para un monitor estandard sRGB. Pero hay veces que usamos la textura no para un color, si no como parámetro para una función. En ese caso, es importante que no apliquemos ninguna correción a la imagen, ya que alteraremos el resultado. Si trabajamos en HDR, tendremos que tener cuidado de no alterar la imagen hasta el proceso final de "tone mapping", cuando convertimos la imagen en un fotograma final, para no alterar los colores que más salen de rango, y distorsionar así efectos como el motion blur y demás.

Una de las cosas que más apetece renderizar es un coche. Tiene una forma chula, la pintura da mucho juego de shaders, y siempre queda guay con un buen mapa de entorno. Lo dificil es hacer un shader de pintura que quede bien, ya que hay un juego de capas, barnizes, partículas metalizadas que lo hacen complejo. En este estudio han medido cuidadosamente las propiedades BRDF de la pintura, han sacado unas imágenes de ejemplo, y nos dejan la información disponible.

Los que nos negamos a instalar vista, tenemos una vía abierta al desarrollo con las extensiones de opengl, y el modelo de shaders 4.0. Aqui tenemos un ejemplo sencillo , pero que demuestra la potencia de las extensiones de manejo de geometría.

Basicamente se renderiza un array de vertices, se modifican con un shader de geometría, y se pintan en pantalla. En la web podeis descargar el código fuente para tener una base donde trabajar.

Quereis chips paralelos? Pues aquí tenéis más! Este tarjetón de AMD tiene nada menos que 10 procesadores SIMD, con 80 procesadores stream (800 procesadores en total). Soporta nada menos que 24 samples de antialias (de forma adaptativa en los bordes de los polígonos, diseñados especialmente para DX10.1, y está fabricada con 55nm, un tamaño reducido para poder overclockear a gusto. Todo lo que tiene texturas va a ir muy bien con estas taretas. Además, la memoria es GDDR5, que es el doble de rápida que la DDR3. Precio? $300 ! Y a un rendimeinto muy  bueno.

Ha salido una nueva versión de este motor de render con código abierto , un fork del original PBRT . La nueva versión es, a grandes rasgos, más modular. Puede aprovechar muchas partes de blender, como las texturas procedurales, y puedes ambiar muchos sistemas de sampleado. Incluye una versión biased, cosa que es fundamental para entornos de producción.

Lo bueno es que podemos ver el código fuente y aprender cómo funciona un motor de este tipo, pero, a diferencia de motores como el ogre, un motor unbiased requiere de profundos conocimientos matemáticos, sobre todo de estadítica, para poder leer el código y entender bien cómo funciona (a parte de leerse los papers de iluminación global y montecarlo).

La empresa VRcontext, donde trabaja Íñigo Quilez, ha presentado unos vídeos sobre raytracing en tiempo real , con ambient occlusion real (no el truco de espacio de pantalla) usando modelos increiblemente grandes, originales de ficheros cad. Son 2 modelos, uno con 100 millones de polígonos, y otro con 200 millones. No tiene partes móviles, pero aun así, en una máquina de 16 cores, va a unos 20 fps con 2x2 samples de antialias.

Entre los días 20 al 22 de noviembre se va a celebrar en Valencia el primer concreso de desarrolladores de videojuegos , que cuenta con el apoyo del DOID, y la universidad de valencia, con conferencias de sitita gente involucrada en el mundillo, como el estudio independiente "devilish games", virtual toys,grin, etc. Una oportunidad más de conocer este mundillo.

A veces los esudios tienen problemas para conseguir artistas, y si la ética flojea, pues pueden caer en la tentación de pillar ideas de otros juegos, incluso partes de películas como storyboards. A veces se les va un poco la mano, como el rey leon y una peli japonesa llamada kimba. Hay plagios, hay plagios de la leche, y despues está Limbo of the Lost, que es el mayor "copy&paste" de la historia de los videojuegos , hasta el momento.

Se han pillado las escenas de, atención (segun la wikipedia ):

    * The Elder Scrolls III: Morrowind
    * Black & White 2
    * Unreal Tournament 2004
    * Unreal Tournament 2003
    * Diablo II
    * Thief: The Dark Project
    * Thief: Deadly Shadows
    * a CryENGINE2 Tech Demo
    * Silent Hill 4: The Room
    * Return to Castle Wolfenstein
    * Sea Dogs
    * Painkiller
    * Vampire: The Masquerade - Bloodlines
    * The Lord of the Rings: The Battle for Middle-earth
    * Hexen
    * World of Warcraft

 a parte de escenas de piratas del caribe, Beetlejuice, y demás.

Las capturas son la leche... es que no se han cortado un huevo, hasta las descripciones de los objetos, los tipos de letra... vamos, que no han escatimado en pillar datos. No se la que les va a caer, pero no creo que saquen más juegos en el futuro... no se si sería más barato contratar a alguien para modelar.

El service pack 1 del framework 3.5 de .net tendrá un buen soporte para shaders directx. Esto es una gran ventaja para los programadores de c# o los que utilicen el frawork para guis. El soporte está disponible en el nuevo sistem gráfico Windows Presentation Foundation.

Aqui tenemos unos shaders manipuladores de brillo de un bitmap, y en esta web podemos ver unos shaders sencillos 2D para manipular imágenes 2D con correctiones de color, deformaciones, y algun efectillo chulo.

Uno de los mejores libros sobre inversión se titula "El inversor inteligente" de benjamin graham, y nos explica cómo tomar decisiones a la hora de invertir nuestro capital. Sobre la bolsa, nos explica que simplemente comprando un fondo barato referenciado a un gran índice en época de crisis, al cabo de 10 años tendremos una rentabilidad brutal. Un fondo del índice compra todas las acciones que entran en el índice, y sigue exactamente su evolución (si el ibex sube un 2%, el fondo sube un 2%)

Está muy demostrado que eso es cierto. Si se siguen las recomendaciones de las firmas más importantes de inversión, se gana sobre un 20% menos que simplemente comprando un fondo referenciado al índice. De echo, las estadísticas son demoledoras. Segun datos reales de las agencias de bolsa, el 90% de los clientes que invierten en bolsa lo pierden todo el primer año, y sólo un 2% consigue beneficio, y eso aunque la bolsa suba. Lo más impactante es que esos clientes realizan 0,2 operaciones al mes. Cómo es posible? Hay muchos estudios de cómo funciona nuestro cerebro, intentando buscar patrones en la realidad, esperando encontrar un "sistema para hacernos ricos". Por ejemplo, está estudiado que si ponemos a gente a leer secuencias de números totalmente aleatorios, la gente tiende a buscar patrones para predecir el siguiente. Es nuestro cerebro que funciona así.

Y, como bien dice graham, comprar un fondo y esperar es rentable... pero no mola. No pueder ir a una barbacoa a fardar de tu fondo referenciado. Lo que realmente mola es predecir cual será la próxima microsoft, o que empresa se va a disparar la semana que viene. Lo realmente complicado es estar 10 años sin actuar. Eso requiere d euna enorme disciplina y de fuerza emocional para simplemente no hacer nada cuando los beneficios suben. Nosotros queremos beneficios, y los queremos ya, ahora mismo, no dentro de 10 años.

A veces, desarrollar un projecto es lo mismo. Intentamos hacer algo simple, y nuestra cabeza comeinza a pensar y a pensar cómo podemos mejorarlo. Como somos informaticos, rapidamente pensamos en mega arquitecturas superextensinbles que nos permitan hacer cosas fabulosas y maravillosas. Pero lo normal es que nunca sumemos las horas totales que nos va a llevar todo ese desarrollo, por no contar lo que nos va a llevar depurarlo y poder mantenerlo. Yo creo que simplemente no podemos evitarlo, por eso somos informaticos, pero no quiere decir que sea lo mejor.

Y que pasa muchísimas veces? Nuestro cerebro ha pensado un "sistema para hacer projectos" en el que podemos hacer cualquier tipo de cosa que nos propongamos, con un poco de tiempo, pero lo realmente dificil es mantenerse ese tiempo necesario  hasta acabarlo. Es muy complicado mantenerse 2 años realizando la misma tarea sin aburrirse y dejarlo todo. En realidad, es complicado que la cosa pase de más de unos pocos días.

Por eso mi consejo de hoy es ponerse metas pequeñas, o al menos, pensar en horas cada vez que "añadamos una nueva característica" a nuestro sistema, y plantearnos seriamente si en realidad queremos estar tanto tiempo empantanados en la misma tarea. Recordad que es muy dificil estar 10 años sin hacer nada, aunque sea lo mejor.

En bittech están con una serie de artículos con ideas a tener en cuenta para comenzar un estudio independiente de videojuegos. Esta parte toca la relación con los publishers. Nos explican qué cosas suelen pedirnos, qué cosas suelen tener en cuenta.. ventajas y consecuencias de ser independiente, etc.

El crear un estudio con el dinero de otros es una de las cosas más complicadas que puedo imaginarme. El esperar que otra persona te preste para hace algo intangible es muy complicado. Personalmente, creo que la vía internet debería de ser la primera opción para ir comenzando, hasta tener cosas que vayan saliendo. Lo malo es cómo agunatar al principio, mientras no hay nada. Porque cuando ya comienzan a salir cosas visibles, suelen aparecer ideas de negocio (la gente es muy dada a ganar dinero con el trabajo de los demás) .

Y también creo que faltan más ejemplos de éxito, ejemplos donde un estudio consiga un producto bueno que impulse a los demás a apostar por esa vía. Ayudaría bastante para que los empresario, banqueros y demás mundo financiero tomase más atención a una industria que mueve millones (eso sí, muy mal repartidos)

Esta es la web de recursos del master en programación gráfica de la universidad de georgia . Hay muchisimainformación muy buena para aprender a programar 3D yen multiproceso. Hay muchos ejercicios para desarrollar, y sobre todo, presentaciones de cada asignatura. Por ejemplo, hay varias de introducción a Direct3D, o presentaciones sobre el Cell de la ps3. Hay mucho material, bastante básico, pero lo chulo es que está todo concentrado en una sola página. Muy recomendable.

La gente joven se pregunta qué cosas son necesarias para trabajar en la industria como desarrollador. Los jóvenes, en su mayoría, vienen con muchas ideas preestablecidas sobre la forma de programar, y como es el mundo ideal de la empresa. Y mayoritariamente estas ideas son un poco raras y distintas de la realidad.

Por ejemplo, por culpa de los departamentos de recursos humanos (que muchas veces no conocen el perfil que tienen que buscar), la mayoria de las ofertas  de empleo están llenas de siglas de multitud de tecnologías. Esto es un auténtico problema para las empresas, ya que descartan a gente realmente buena de forma un poco estúpida, pero muchos jóvenes, al ver semejante requerimientos, se ponen a hacer cursos de certificación para ampliar la lista de "tags" que pueden poner en su CV. Simplmente porque los de RRHH no quieren hacer su trabajo como debe de ser. Eso sí, para aplicar una búsqueda en una base de datos de candidatos, no hace falta contratar a gente de RRHH, cosa que empiezan a darse cuenta las empresas.

Otra cosa es el sistema educativo, sobre todo el de primaria, que nos enseña a "chapar", a aprenderse de memoria párrafos enteros de libros, y que obliga a pasarse las horas de clase haciendo algo tán estúpido como ir subrayando lo que el profesor va leyendo. Todos recordamos esos libros donde se subrayaba un 80% del texto, y donde los ás imaginativos subrayaban a 3 o cuatro colores (en especial ese rosa chillón que no hay dios que pueda leer). Eso está en las antípodas de lo que significa prepararse en la vida. Pero es muy cómodo para el profesor, que sólo tiene que hacer un "diff" del examen y el texto original, y puntuar el número de "conflictos".

Despues están webs como codepixel. Hay también hay parte de culpa. Aqui hablamos continuamente de papers, de algoritmos, de complicadas tecnologías arcanas de ingeniería. Eso hace que la gente piense que el mundo profesional es precisamente esto,el tener en la cabeza muchísimos papers técnicos y que cada vez que hacemos un programa, independientemente de la complejidad que requiere, sea más o menos una mezcla entre obra de arte, enviar una sonda a marte, y modificar la gestión de memoria del kernel de linux. Por eso, antes de programar cualquier chorrada, nos pasamos un buen rato mirando internet, buscando la solución a tan complejo problema.

Pero... qué es lo que hay que saber realmente en el mundo de la empresa? Pues algo muy dificil. Hay que saber pensar. Así de simple, y así de complicado. Hay que saber cómo depurar un programa sin tener que llenarlo de breakpoints y esperar a que el depurador nos diga la solución, hay que pensar que condiciiones variables tiene un problema antes de desarrollarlo, hay que saber preguntarse a uno mismo para qué hace falta ese programa, esa característica. Hay que sentarse, acotar los problemas en partes pequeñas, y dar soluciones razonadas. Eso es lo que realmente hace un buen profesional.

Muchas veces, cuando trabajamos, lo que más se hace es lanzar una hipótesis, y despues intentamos demostrarla. Muchísimas veces fallamos, pero al menos, tenemos un plan donde ir buscando, y normalmente, acabamos antes que si perdiesemos horas con el depurador buscando fallos. A parte, de disfrutar de ese placer en comprobar que la teoría era correcta.

Cuando una empresa pide una larga lista de tecnologías, lo que está diciendo es que "no tenemos ni puta idea de cómo ni dónde buscar a gente",  asi que es una empresa que seguramente no piensa demasiado, probablemente tenga unos buenos comerciales que metan dinero en el negocio, y a vivir. Es una empresa donde al final, uno que piense, no acabará contento.

Cuando un alumno se pasa el día chapando, sin el más mínimo criterio, está oxidando algo muy valioso, su capacidad de razonar y ver más allá de lo que está escrito en el papel. Realmente se oculta la incapacidad del profesor en hacer que la gente piense, cosa que a mí me parece muy dificil. La prueba está en que google sustituye a todo ese modelo educativo (para que chapar la wikipedia, si ya la tienes online)

Cuando nos pasamos el día leyendo en codepixel sobre los algoritmos, perdemos nuestra capacidad de descubrir, por nosotros mismos, soluciones a los problemas gráficos. Cuando nos pasamos el día buscando en google ejemplos de código, perdemos nuestra capacidad de crear rutinas nuevas, y de desarrollar nuevas tecnologías.

Por eso os invito a intentar, antes de abrir el navegador, a pensar un poco sobre lo que vais a buscar. Aunque sea sólo a declarar una hipótesis de cómo sería la solución ideal.

Al calcular la iluminacion global, cuando mandamos un rayo a un plano, tenemos que .conocer cuanta energia viene del entorno. Miramos las luces directas, y una de las luces directas mas complicadas es el mapa de entorno, cuando es una textura. Porque? Porque no sabemos, en principio, nada de esa imagen. Puede ser que la luz venga uniformemente, puede que la luz venga de una zona muy brillante (como una foto al sol), o puede que venga de varias ventanas (como una catedral). Asi que si mandamos muestra buscando energia, puede que perdamos muhcas en las zonas oscuras. Hay varias formas de poner las muestras en las texturas de forma correcta. Lo normal es hacer un preprocesado para conseguir algun tipo de informacion que permita analizar la textiura. Este paper (algo antiguo) nos habla de aprovechas los wavelets para colocar muestras. Todo el tema de wavelets es parte de la teoria de la señal, del espacio de frecuencia, etc. Y lo mas importante, es que parece muy rapido a la hora de colocar las muestras, y sobre todo, que al colocarlas en las partes mas brillantes de la textura, la imagen final sale mucho mas limpia.

El motor ogre3d es uno de los más completos y populares de los motores 3D opensource. Tiene a muchos desarrolladores trabajando para mejorarlo y usando las distintas herramientas que exsiten actualmente.

Los chicos de intel, siempre tan dispuestos a ayudarnos para que usemos multicores, han escrito un completo pdf sobre multithreading y el ogre3D. Lo chulo es que destripan de forma sencilla cómo está desarrollado el ogre3D, y las distintas capas que lo componen. Así, tenemos un completo diagrama de las distintas etapas de render (que son bastantes).

 El pdf comenta varias cosas que a veces hablamos en esta web. Hace una discusión de cómo modificar los datos de la escena usando multithreading. Podremos usar una cola de comandos. Esto es, un thread postea en una cola "mover objeto" y los comando se van ejecutando de forma secuencial cuando sea preciso. El problema es que a veces hay que mandar comandos con datos muy grandes, que tendríamos que copiar (modificar los vértices, por ejemplo)

 Otra forma es duplicar datos, tener una especie de "double buffer" para lo que se modifica constantemente. El tema es que puede que pintemos más rápido de lo que modificamos las copias. Hace unos días hablamos aquí de unas estructuras de datos en java que hacian algo parecido, pero mas al estilo transacciones, que podría mejorar esto severamente.

Otra forma de meter threads es que el mismo sistema de render sea multithreading. Este es el más complejo, sobre todo porque hay que tener en cuenta un montón de dependencias entre los distintos sistemas, y puede que tengamos que esperar por ciertas partes para completarse. Aqui tambien podríamos usar una cola para renderizar sin bloqueos. 

Y ya a más bajo nivel, podrñiamos hacer multithreading la parte más de bajo nivel (opengl o directx). 

 Los resultados son un poco decepcionantes, ya que las mejoras son, en el mejor de los casos, de un 30%. Eso sí, las demos de ogre son muy gpu, así que no aprovechan los multicores a tope.

De todos modos, mi conclusión es que lo mejor es un thread para el ogre, y dejar a la cpu a realizar el resto de tareas. Esi sí, tendremos que esperar a que el multithreading de gpu sea una realidad (DX10 tene algo ya), para aprovechar mejor ciertas partes de render.