Hoy hemos tenido la segunda tanda de clases del curso de motores. Hemos visto gestión de mallas, shaders y materiales, repaso de shaders, teoría de algoritmos de oclusión y partición del espacio y por último, gestión sencilla de la escena.

En general el curso es interesante dentro de que ningún cursillo podrá enseñar nunca nada. Al menos en este se puede echar un ojo a lo que hacen los profesionales de la industria, algo que no se puede aprender ni aún buceando en el código de los mejores motores open-source.

Además, estoy aprovechando los ratos menos interesantes para ir programando un poco mi motor porque, como bien dijo Knudow, en ese entorno “trabajador” dan ganas de ponerse a programar.

Lamentablemente apenas nos van a enseñar formas de gestionar la escena. La clase que nos han dado es poco más que una lista que va renderizando los objetos sin más. Entiendo que hay que suavizar un poco las cosas para los que no tengan ni puta idea, pero me hubiera gustado profundizar un poco más.

También nos han revelado las posibles prácticas que podemos entregar. La primera me obliga a instalar el Visual Studio, así que queda descartada. La segunda es escribir un pequeño trabajo sobre el tema, algo que podría hacer en una tarde sin problemas. La tercera es libre, siempre dentro del tema del curso, así que podría presentar mi PFC o mi anterior motor si ese no vale aunque seguramente opte por la segunda opción.

Tras dos días agotadores, voy a hacer un pequeño post resumen de lo que he aprendido en el cursillo hasta el momento.

Para empezar me reafirmo en la apreciación que tengo de Jesús de Santos: es un tío normal. Sabe de lo que habla y tiene experiencia, pero no va de gran promesa del software español que, en mi opinión, ese tipo de gente ya hay de sobra.

Aunque el cursillo sea estrictamente de aprender a diseñar motores, realmente Jesús nos explica como ha hecho su motor, lo cual no está mal porque tiene un tufillo a motor comercial que uno no encuentra en sus equivalentes OpenSource. Además es un motor moderno, no como los sempiternos Ogre e Irrlicht que se encuentran estancados en un diseño hecho en la era de la fixed-pipeline.

El viernes se hizo incapié en el sistema de reflexión, fundamental a la hora de hacer el binding en Python y a la hora de inferir para utilizar los smart pointers comodamente y sin casts por todos los lados. También se explicó un sistema de serialización sencillito, aunque efectivo.

Por último vimos el motor funcionando (aunque sin renderizar nada). La idea es que el motor envía mensajes de depuración a una aplicación “consola” que los recibe, de forma que se pueden controlar ciertos aspectos del motor de manera remota. Esta aplicación consola es independiente del motor, así que se mantiene en ejecución escuchando en un puerto concreto.

Evidentemente, la consola permite enviar mensajes para que el motor haga cosas, aunque de momento no permite más que lanzar aplicaciones y pedir ciertos datos. Aún así, resulta muy útil, sobre todo teniendo en cuenta que al utilizar un lenguaje de alto nivel interpretado como Python, todo lo que sean ayudas a la depuración son bienvenidas.

El segundo día se centró en la abstracción del renderizador gráfico y su implementación en DirectX9. El concepto principal fue el cómo prácticamente todos los datos se almacenan en buffers, para hacer modificaciones de forma secuencial y aprovechar cada llamada a función al máximo.

Por ejemplo, los cambios de renderstate o asignaciones de parámetros a los shaders se pueden poner en una lista de comandos, de forma que hacemos una especie de Display Lists de OpenGL pero en este otro contexto. Dichos buffers de comandos se ejecutan del tirón así que podemos acumular ahí todos los parámetros que necesitemos modificar (por ejemplo, renderstates) y ejecutar el buffer para aplicarlos. Parece una cosa muy sencillita, y lo es, pero tras ver un par de ejemplos de uso me pareció una muy buena idea.

Quizás, puestos a quejarme de algo, lo que hemos visto ahora es más propio de un middleware que de algo que se pueda llamar motor. Pero todavía queda mucho cursillo, y la verdad es que he aprendido mucho estos dos días, sobre cómo organizar a bajo nivel un motor ya que a alto nivel (grafos de escena, etc.) es relativamente sencillo y es algo que veremos en los próximos días.

Además, me gusta que se vaya al grano con código REAL de su motor y no ejemplos teóricos. Ahí se ve claramente todo. Aunque quizá sea un cursillo que requiere ciertos conocimientos previos que quizá no todos los asistentes tengan. Pero ya se avisaba en la descripción del cursillo. Yo de momento, estoy contento con lo poco que llevamos visto y seguro que mejora en los siguientes días.

Ahora bien, ¿qué nos van a mandar como práctica final del cursillo? El viernes que viene terminará el suspense (espero).

Mañana por la tarde comienza el cursillo de motores de videojuegos que organiza el Gamelab. Se dedicarán algunas horas a “repasar” cosas vistas en cursillos anteriores, pero el grueso del temario tiene a Jesús de Santos García explicando como hacer motores.

Para los que no lo conozcan o no lo recuerden (creo que hice una breve mención en el curso de verano del Gamelab), Jesús parece una persona sencilla, a pesar de haber trabajado como jefe de tecnología en Pyro, y doy fe que es bien joven. Además, cuando se le preguntaba, iba siempre al grano y se veía que sabía de lo que hablaba. Normalmente los ponentes suelen “mojarse poco” al responder, y lo dejan todo en respuestas genéricas.

Y además le gusta el software libre, que es algo que en el mundo empresarial se ve bastante poco (al menos en lo que yo he visto del mundo empresarial ). Todavía estoy a tiempo de aprovechar lo que nos cuente para mi motor, así que espero aprender mucho del tema.

Ya os contaré…

Ayer terminó el cursillo de shaders por fin. No es que haya sido un mal curso, pero lo de madrugar los sábados era un poco varas y al final los momentos interesantes eran cada vez más escasos. Es normal, puesto que no se exigían demasiados requisitos para asistir al curso, por lo que aunque se han intentado dar cosas avanzadas, muchas de las explicaciones eran de conocimiento general.

Además se ha hecho demasiado énfasis en la parte de DirectX, y puede que se haya dado demasiado en comparación a lo que se ha dado de shaders. Por ejemplo, se ha dado el stencil búfer, algo que es totalmente ajeno a los shaders.

Aún así, se me ha hecho más ameno que otros cursos de extensión, quizá porque el tema me interesaba. Además las instalaciones han estado muy bien y creo que aunque es un curso que puede impresionar bastante a los que no tengan ni idea del tema, se puede aprobar perfectamente copiando y pegando de los ejemplos que nos dan.

Lo bueno es que nos hicieron publicidad acerca de otro curso del gamelab que se va a realizar en primavera y tiene muy buena pinta. Va de diseño de motores gráficos y lo da un el ex-jefe de tecnología de Pyro (que ya dio una charla en el curso de verano). El tío parecía muy simpático y muy sencillo, lo que siempre anima a la hora de hincarle el diente a estos temas tan complejos de por sí. A ver si hay suerte y lo hacen en Oviedo… aunque no creo.

Bueno, pues para terminar y cerrar esta serie de posts, aquí dejo la última captura de mi práctica, que será con casi toda seguridad lo que entregue:

Hoy hemos dado cubemaps y parallax mapping. El parallax mapping no se dónde calzarlo (tampoco tengo normal mapping, porque no me parece que pegue bien en la escena, y no es plan de colar ahí todos los efectos). De momento he usado los cube maps para hacer el reflejo del agua. Lo he hecho de una manera distinta a como lo explicó Gusi en clase, pero es que no me gusta copiar y pegar el código de los ejemplos, que aquí estamos para aprender.

También he añadido un minimapa en la esquina superior-derecha, para poder saber exactamente la situación de la escena. Aún así, todavía me faltan algunas cosillas para respetar los mínimos para entregar la práctica. Por ejemplo, no aplico ecuaciones de iluminación a nada de la escena. Me gustaría volver a añadir brillo especular al mar, pero no sé si eso contará. Quizás añada algunos terrenos más, que no cuesta nada y con solo 3, la escena parece vacía.