Ayer me he puesto en serio con el motor de juegos Melt, para intentar tener algo funcionando lo antes posible, aunque me temo que todavía le falta bastante. Voy a empezar, como no, con el módulo de gráficos, pero intentando que no sea éste el que tiene mayor protagonismo.

Teniendo la experiencia de SDE a mis espaldas sé que hay un par de cosas que no quiero repetir. Una de ellas es que la parte gráfica acababa absorbiendo a las demás. Eso voy a intentar que no pase sacando el arbol de nodos fuera del módulo gráfico. Además, así conseguiré que no haya que andar actualizando cada módulo, pues las transformaciones (posición y rotación) irán en ese árbol y, por ejemplo, el motor físico las modificará y el gráfico leerá de ahí directamente. Sin andar pasando datos de uno a otro.

Otra cosa que pienso hacer es crear objetos “modelo” en cada uno de los módulos y tener varias instancias en el árbol. Un ejemplo práctico, quiero una sala llena de antorchas emitiendo partículas de fuego. Hasta ahora, con el SDE, tendría que tener cientos de sistemas de partículas cada uno con su gestión interna de partículas (cálculo de posiciones, vida de las partículas, etc). Sin embargo, ahora podría tener el mismo sistema de partículas en 100 posiciones, por lo que todo el cálculo se haría una vez y simplemente tendría que renderizar 100 veces cambiando la matriz de transformación del objeto.

Al tener fuera del módulo gráfico el árbol de la escena, la estructura principal de dicho módulo es la cola de render, dónde se organizan los nodos para dibujarlos en pantalla. Evidentemente, con lo que os he contado antes, algo falla, porque necesito tener una clase más para poder ordenar las instancias de cada objeto gráfico. Eso ya está contemplado y será transparente para el usuario, que no tiene que saber ni que existen dichas clases.

Supuestamente, esto permitiría hacer varias pasadas por el árbol de la escena para filtrar los nodos visibles para una cámara y añadirlos a la cola de render.Todavía no tengo muy claro dónde irá ese proceso, pero supongo que hay cosas que no puedo planear del todo hasta haberlas hecho y entendido correctamente.

De momento, lo poco que he trabajado con LWJGL he de decir que es exactamente lo que esperaba y está muy bien diseñado. Te quita lo más rutinario y te deja programar el resto. Por ejemplo, la gestión de una ventana (creación y destrucción) que siempre termina siendo un cut&paste de un tutorial o algo así, aquí ya está hecho. Sin embargo, el resto de cosas más importantes hay que programarlas en OpenGL a pelo. Pero me gustó el detalle de que simplifiquen ciertas cosas.

Estoy diseñando con el fixed-pipeline en mente (sin shaders, vamos) porque no tengo ni idea sobre como generalizar el uso de shaders y tampoco me hace gracia obligar al usuario a tener X ficheros de shaders porque el motor los pide. Supongo que con el cursillo de shaders que empieza este sábado tendré algo más de idea. Pero de momento los shaders se van a quedar como parte de los materiales.