Luego de un largo descanso, toca actualizar. A principios de año dije que uno de los proyectos que valía la pena seguir en el 2012 era Lime, y parece que no me equivoqué. Para los que no sigan los cambios en Github, que supongo que serán todos, aquí les va un breve resumen de lo que se ha alcanzado y lo que falta por hacer.
En el momento de escribir esto, Lime ya es completamente basado en deferred rendering como los motores modernos, excepto en Android. Esto permite un número bastante alto de luces dinámicas en la escena, en teoría cientos, siempre y cuando solo una docena o más sean visibles al mismo tiempo. Todo depende de la potencia de la tarjeta gráfica y como muestra les diré que en mi Geforce 9500 el rendimiento es bastante decente. Esto se debe a varias optimizaciones del shader. Esto no es todo, aunque Android no tiene un deferred renderer, sí ofrece luces dinámicas. Por supuesto, no se puede esperar mucho del hardware gráfico de un móvil o tablet. Me atrevo a afirmar que Lime posee uno de los sistemas de renderizado más avanzados entre los motores gráficos. Esto viene con un costo: Lime solo soporta OpenGL 3 y OpenGL ES 2.
En cuanto al editor, luego de algunos tropiezos, ya casi tenemos una herramienta productiva. El avance ha estado lastrado por carencias de Qt, que no permite un editor con iluminación en tiempo real (es imposible tener renderizado diferido dentro del widget GL) y lamentablemente Lime aún no posee un GUI avanzado que permita sustituir a Qt. Pero muy pronto tendremos algo que permitirá crear protipos de escenas con cierta facilidad y eficiencia.
La mayoría de las funcionalidades que faltan están fuera del renderizador. Aún se necesita un gestor de recursos, las herramientas para artistas son muy primitivas, el sistema de materiales podría ser mejor (la idea es proporcionar una biblioteca de materiales desde la cual podremos heredar materiales nuevos), no hay soporte nativo para animaciones (actualmente se utilizan archivos md5) ni lo habrá a corto plazo y como ya mencioné, el GUI es bastante limitado. No hay trazado de rayos ni colisiones, aunque sí hay un demo de integración de Bullet. El API no es estable aún, de hecho cambia bastante, sin embargo lo encuentro extremadamente fácil de comprender. Otro detalle que vendría bien es soporte para más formatos de imagen, por el momento solo trabaja con DDS comprimidos. El subsistema de sonido hace tiempo que tiene pendiente una revisión y para más inri, el desarrollo es mayormente sobre Linux, por lo que no es trivial compilarlo para Windows.
Por tanto, Lime todavía no es apto para desarrollar juegos, lo cual no impide que sea divertido hacer cosas con él y aunque es un poco temprano para las predicciones de cara al 2013, estoy seguro que de valdrá la pena seguir observándolo. O en mi caso, seguir colaborando en su desarrollo.
En el momento de escribir esto, Lime ya es completamente basado en deferred rendering como los motores modernos, excepto en Android. Esto permite un número bastante alto de luces dinámicas en la escena, en teoría cientos, siempre y cuando solo una docena o más sean visibles al mismo tiempo. Todo depende de la potencia de la tarjeta gráfica y como muestra les diré que en mi Geforce 9500 el rendimiento es bastante decente. Esto se debe a varias optimizaciones del shader. Esto no es todo, aunque Android no tiene un deferred renderer, sí ofrece luces dinámicas. Por supuesto, no se puede esperar mucho del hardware gráfico de un móvil o tablet. Me atrevo a afirmar que Lime posee uno de los sistemas de renderizado más avanzados entre los motores gráficos. Esto viene con un costo: Lime solo soporta OpenGL 3 y OpenGL ES 2.
En cuanto al editor, luego de algunos tropiezos, ya casi tenemos una herramienta productiva. El avance ha estado lastrado por carencias de Qt, que no permite un editor con iluminación en tiempo real (es imposible tener renderizado diferido dentro del widget GL) y lamentablemente Lime aún no posee un GUI avanzado que permita sustituir a Qt. Pero muy pronto tendremos algo que permitirá crear protipos de escenas con cierta facilidad y eficiencia.
La mayoría de las funcionalidades que faltan están fuera del renderizador. Aún se necesita un gestor de recursos, las herramientas para artistas son muy primitivas, el sistema de materiales podría ser mejor (la idea es proporcionar una biblioteca de materiales desde la cual podremos heredar materiales nuevos), no hay soporte nativo para animaciones (actualmente se utilizan archivos md5) ni lo habrá a corto plazo y como ya mencioné, el GUI es bastante limitado. No hay trazado de rayos ni colisiones, aunque sí hay un demo de integración de Bullet. El API no es estable aún, de hecho cambia bastante, sin embargo lo encuentro extremadamente fácil de comprender. Otro detalle que vendría bien es soporte para más formatos de imagen, por el momento solo trabaja con DDS comprimidos. El subsistema de sonido hace tiempo que tiene pendiente una revisión y para más inri, el desarrollo es mayormente sobre Linux, por lo que no es trivial compilarlo para Windows.
Por tanto, Lime todavía no es apto para desarrollar juegos, lo cual no impide que sea divertido hacer cosas con él y aunque es un poco temprano para las predicciones de cara al 2013, estoy seguro que de valdrá la pena seguir observándolo. O en mi caso, seguir colaborando en su desarrollo.
Comentarios
Publicar un comentario