Hace poco llegué a otra página web: https://raytracing.github.io/ donde presenta tres libros⁴. Después de ojearlos los tres (son muy cortitos) comencé por el primero: Ray Tracing in One Weekend.

En el título promete hacer un raytracer en un fin de semana... muy poco tiempo me parece. No digo que no haya alguien capaz de hacerlo, pero no creo que esté a mi alcance. Llevo un par de ratos leyendo y picando código, pero estoy convencido que lo del fin de semana será si picas código sin parar para dormir, ni comer, ni cagar.

El caso es que ya tengo algo picado, no mucho. Pero ha sido prometedor: primera explicación, primer código metido y primera imagen conseguida. Vale que aún no he trazado un sólo rayo pero me anima el haber seguido las explicaciones y haber conseguido el resultado esperado. Teniendo en cuenta además, que el código que el libro propone es C++ y yo lo estoy haciendo en erlang. ¿Por qué? Porque al verlo me he imaginado lo que puede ser un proceso imagen lanzando procesos rayos que se distribuyen por varias máquinas en distintos nodos de una red y conseguir hacer un raytracer distribuido sin las complicaciones de otros lenguajes.

En contra me tropiezo con el problema de convertir el código POO de C++ a código funcional de erlang.

Vale, es poca cosa pero funcionó a la primera, a pesar de que a las explicaciones que da el «libro» le he hecho algunos cambios. Concretamente he separado la generación del gráfico, escribiéndolo directamente a un fichero, del contador que muestra el avance del render. En el libro, utiliza el flujo normal de salida para escribir el fichero y el flujo de error para indicar el avance⁵. Además, le he añadido un lanzador de nombre rerl, que viene a ser raytracerl más corto... y que lo he acortado también porque me imaginaba a Joaquín Reyes presentándolo al grito de raytraceeeerrllll imitando a cualquier informático famoso⁶ con acento manchego y no me resultaba serio.

El primer problema que me encontré es que al hacerlo en erlang había que lanzar la máquina virtual, cargar el módulo y llamar a la función que dibuja la imagen. La solución: hacer un lanzador que lo haga por nosotros en forma de escript:

#!/usr/bin/env escript
%% -*- erlang -*-
%%! -smp enable -sname lanzador
main([Nombre_Fichero]) ->
    imagen:dibujar(Nombre_Fichero);
main([]) ->
    imagen:dibujar().

Como se ve, el módulo que lleva el cotarro se llama imagen y tiene una función que se llama dibujar. Si se le pasa un nombre de fichero, llama a imagen pasándole ese nombre donde debe escribir el resultado. En otras ocasiones, cuando hago un escript, suelo intentar controlar algún posible error, como que falte algún parámetro. Sin embargo, en este caso, como es una herramienta de lanzamiento para pruebas y cualquier fallo es importante, prefiero no manejar error y que me informe de los detalles fallo que ha ocurrido.

Por otro lado, el código que genera la imagen que he mostrado más arriba es el siguiente:

-module(imagen).

-define(ANCHO,256).
-define(ALTO,256).
-define(FICHERO,"imagen.ppm").

-export([
          dibujar/0
        , dibujar/1]).

dibujar() ->
    dibujar(?FICHERO).

dibujar(Fichero) ->
    Cabecera = io_lib:format("P3~n~p ~p~n255~n", [?ANCHO,?ALTO]),
    {ok,F} = file:open(Fichero, [write]),
    B = 63,
    Imagen =
        lists:map(
          fun(G) ->
                  io:format("Faltan ~p filas  \e[36D", [G]),
                  lists:map(
                    fun(R) ->
                            io_lib:format("~p ~p ~p~n", [R,G,B])
                    end,
                    lists:seq(0,255))
          end,
          lists:seq(255,0,-1)),
    file:write(F, Cabecera ++ Imagen),
    file:close(F),
    io:format("\nFin.\n").

Muy sencillo de entender: el módulo imagen está compuesto por dos funciones con el mismo nombre, dibujar, que puede llevar el parámetro del nombre de fichero o no. En caso de no llevar, utiliza la constante ?FICHERO para llamar a la función con parámetro.

Por el nombre del fichero por defecto se puede ver que utilizamos el formato de imagen ppm, que es un formato de imagen definido mediante texto ASCII y si no tienes muy claro cómo funciona, lo voy a explicar más despacio. Veamos la cabecera:

P3
256 256
255

La cabecera que genera el programa se divide en las siguiente líneas⁷:

• Número mágico: en la familia de ficheros gráficos denominados como portable pixel format PPM, los dos caracteres P3 indican que es un fichero ASCII que contiene valores RGB.
• Ancho y alto: en pixeles de la imagen. En este caso la imagen tendrá \(256 \times 256\) es decir un cuadrado de 0 a 255 píxeles de lado.
• Valor máximo del color: en este caso el valor de cada componente puede llegar hasta 255, el mínimo siempre es 0.

A partir de ahí, en el ejemplo, cada punto será dibujado por una combinación RGB tal que los componentes R y G se toman de dos contadores obtenidos mediante lists:seq y el valor B se mantiene constante en 63. Luego crea una cadena por cada punto, uno por línea, con la instrucción io_lib:format("~p ~p ~p~n", [R,G,B]).

Al final, cuando tiene la cabecera y la imagen preparadas, las escribe en un fichero y después lo cierra guardando el contenido.

Lo siguiente que hace el librillo es crearse algunas clases básicas: en realidad una clase vec3 para almacenar y operar valores representados por 3 valores individuales. Lo utiliza tanto para guardar valores de vectores, propiamente dichos, como para guardar colores. En erlang podría utilizar tuplas con el formato {A,B,C} y luego operar la tupla según el concepto que almacene. Sin embargo, creo que me irá mejor no mezclar las churras y las merinas.

No lo he mirado, pero seguramente en el futuro, el autor, separará esos conceptos derivando clases, por lo que voy desobedecer un poco la línea argumental inicial del tutorial y voy crear los dos conceptos separados. Podría, por ejemplo, crear tuplas del estilo {color,{r,g,b}} o {vec3,{x,y,z}}, pero ésto es la definición de un registro o record. Como además supongo que esas definiciones las necesitaré en todos los módulos que se irán creando, las pongo en un fichero aparte que llamo registros.hrl y que presenta el siguiente contenido:

-record(vec3,  {x,y,z}).
-record(color, {r,g,b}).

Primera aproximación a un tutorial que promete explicar, por lo menos a priori, cada paso de forma clara y directa. No puedo afirmar si el código que escribe el autor es correcto y compila en todos los casos, porque estoy utilizando otro lenguaje para realizar los ejercicios que propone y tengo que escribir mi propio código. Recordad: en mi máquina funciona.

El utilizar erlang y no C++ puede representar un problema importante más adelante cuando se meta de lleno en el uso de clases y otras características de la programación orientada a objetos que tendré que adaptar a la programación funcional. Como ejercicio parece un interesante juego intelectual. Al principio me preocupará más entender cómo funciona todo el sistema y no tanto la eficiencia, sin embargo, intentaré también ir preparando el código para optimizarlo.

El formato de salida del fichero se mantiene durante los tres libros, por lo que he podido ver. No es un formato muy eficiente, ocupa bastante en disco, pero es sencillo de escribir y de leer.

De momento es muy pronto para saber qué módulos se convertirán en el futuro en procesos de erlang para ser procesados de forma concurrente. A bote pronto, creo que serán los píxeles de imagen y los rayos que se envían para calcular su color. Pero aún no hemos llegado a trazar ningún rayo... que, espero, lo haré en una próxima entrega de estos apuntes.

Por último, ya disculparéis si utilizo el blog como mi libreta de notas. Alguien puede aburrirse con esto, pero quizá a otros les sirva de inspiración o incluso para resolver alguna duda.