Desde la semana pasada estoy trabajando en la integración básica de un sistema de scripting y la verdad es que ha sido muy interesante. Siempre en casos anteriores preferí usar DLLs para favorecer la performance pero ahora que a nivel de CPU podemos hacer mas cosas y teniendo en cuenta que por ejemplo el Albedo Engine no va a usar stencil shadows, hay CPU-time para agregar un sistema de scripting y hacerle mas fácil la vida a la persona que alguna vez llegue a usar el engine. Cuando estuve pensando en usar un sistema de scripting lo primero que me vino a la mente fue usar Lua. Después de todo, es uno de los sistemas de scripting más antiguos, y tiene una solidez que es consecuencia de la cantidad de usuarios que tiene. Pero después hacer varios tests me di cuenta que no es lo que quería. Primero que nada la sintaxis de LUA no me gusta, no concuerda con la sintaxis del engine (que esta escrito en C++). Trabajar con LUA en C++ es bastante molesto incluso si usas herramientas como toLua o usando otras librerías como Luabind (que tampoco es bueno porque no quiero quince capas intermedias para recién poder llegar a LUA). Por otra parte mas allá que no estaba buscando el máximo de performance (si lo hiciera seguiría haciendo DLLs), definitivamente no es que lo sacara de mi mente. Teniendo en cuenta eso empecé a buscar alternativas hasta que encontré AngelScript.
Primero que nada registrar clases es muy fácil, nada de tener que modificar las clases para que se ajuste al sistema de scripting. La sintaxis es muy parecida a C++ lo que me permite pasar código que tenia en el engine directamente al sistema de scripting de manera muy fácil. Es el sistema de scripting más rápido que probé, muy estable, no tiene ningún memory leak (por lo menos que haya visto). También es muy fácil de extender, por ejemplo AngelScript en si no soporta strings por defecto entonces lo que hice fue integrar de manera muy fácil los strings de STL. Realmente estoy muy conforme con el sistema de scripting aunque es verdad que solo tiene una semana, pero realmente no veo nada que pueda ser un inconveniente en el futuro.
Con la llegada de placas que soportan formatos HDR (High Dynamic Range), y con el lanzamientos de monitores HDR como el BrightSide DR37-P es importante analizar porque manejar todo en HDR es importante, incluso cuando se hace la salida final a un dispositivo o formato LDR (Low Dynamic Range). Pero antes que nada veamos lo más básico, que quiere decir Low o High Dynamic Range.
Dynamic Range es un termino usado en diferentes campos de investigación para describir el radio entre el valor mas pequeño y mas grande posible en un indicador de cantidad variable. Si el dynamic range es Low (Bajo) entonces quiere decir que el radio entre el valor mas bajo y el mas alto es pequeño, y si es High (Alto) entonces el radio entre el valor mas bajo y el mas alto es grande.
En el campo de la computación grafica, sobretodo en la sección de simulaciones en tiempo real, siempre predomino el Low Dynamic Range ya que los valores en general eran guardados en variables de 8-bits con valores entre 0.0 y 1.0. Por ejemplo un lightmap en un píxel tiene el valor [1.0 1.0 0.5] entonces esta iluminado totalmente, y a eso se lo modulaba con el valor de una textura difusa con el valor por ejemplo [0.5 1.0 1.0] entonces se puede determinar que el valor final es [0.5 1.0 0.5].
Aunque eso se ve relativamente bien, ¿que pasa cuando tenemos que definir en el lightmap que la iluminación es dos veces mas fuerte que en el caso anterior? Ahí nos damos cuenta porque los valores LDR entre 0.0 y 1.0 limitan muchísimo por ejemplo en este caso la iluminación de una escena. En cambio si uno tiene un lightmap HDR entonces es posible guardar el valor [2.0 2.0 1.0] entonces al momento de modular el valor con el de la textura difusa el valor termina siendo [1.0 2.0 2.0]. Pero incluso cuando el beneficio de usar HDR no es tan evidente como en la iluminación, es importante ver que incluso cuando la salida final es a un medio LDR, todos los cálculos intermedios tendrían que estar en HDR. Porque en realidad, todo lo que se estuvo haciendo en el pasado con LDR era aproximar lo que realmente uno como programador grafico quería hacer. Pero cuando la tecnología llega para realizar algo de la manera correcta sin hacer aproximaciones, tenemos que dentro de lo posible utilizar al máximo esa tecnología porque hacer las cosas correctamente nos ayuda a mejorar en general nuestro producto.
Para tener en cuenta el impacto de tener formatos HDR internos podemos ver que ahora es posible hacer procesos de propósitos generales en el GPU sin necesidad de usar el CPU. Aunque la parte mas importante reside en el uso de mas que nada fragment programs, sin tener formatos HDR las posibilidades para implementar algoritmos básicos eran muy bajos por lo limitado en la parte matemática. En cambio con HDR es posible guardar valores de 16-bits o 32-bits por componente dando muchísima mas libertad para realizar algoritmos complejos donde los pasos intermedios y los resultados están todos en HDR. Para mas información sobre el tema pueden ir al sitio GPGPU.
Si tienen cualquier duda sobre el tema por favor dejen un comentario en este post y apenas lo vea lo respondo.