📱 Tutorial
500 líneas de C++ bastan para entender cómo funciona realmente OpenGL (y te sorprenderá lo simple que es)
¿Alguna vez te has preguntado qué pasa realmente cuando le dices a OpenGL que dibuje un triángulo? La mayoría de los programadores usan APIs gráficas como cajas negras durante años sin entender qué ocurre detrás.
Un desarrollador acaba de publicar en HN un tutorial que se ha vuelto viral con 244 puntos: un renderer 3D completo en 500 líneas de C++ puro, sin OpenGL, sin Vulkan, sin DirectX. Zero dependencias externas.
Y lo mejor: después de leerlo, OpenGL deja de ser magia. Te cuento lo que aprendí y por qué deberías hacer el mismo ejercicio aunque nunca toques gráficos en tu vida.
¿Por qué 500 líneas? El mito de la complejidad
Cuando abres cualquier libro de gráficos por computadora, te bombardean con matrices de 4x4, quaternions, pipelines de renderizado, transformaciones homogéneas… Suena a que necesitas un doctorado para dibujar un puto cuadrado.
La realidad es que los fundamentos caben en 500 líneas. El autor del tutorial (tinyrenderer en haqr.eu) demuestra que con solo tres conceptos puedes renderizar cualquier modelo 3D con texturas, sombras y luces:
- Rasterización de triángulos: cómo convertir un triángulo en píxeles
- Coordenadas baricéntricas: cómo interpolar colores, texturas y profundidad
- Z-buffer: cómo saber qué polígono está delante de cuál
Eso es todo. Todo lo demás —shaders, transformaciones, culling— son variaciones de estas tres ideas.
De Bresenham a sombras en una tarde
El tutorial empieza con lo más básico: el algoritmo de Bresenham para dibujar líneas. Sí, ese mismo que aprendiste en la universidad y juraste que nunca usarías.
Luego avanza a rasterización de triángulos —el corazón de cualquier GPU— donde cada triángulo se descompone en píxeles individuales. Aquí es donde ves por primera vez cómo tu CPU (no tu GPU) puede hacer este trabajo si entiendes el algoritmo correcto.
Después llega el z-buffer, esa estructura invisible que evita que los objetos de atrás se dibujen encima de los de adelante. Lo implementas en 20 líneas. Te cambia la percepción de cómo funciona el hardware.
Y al final del día, tienes specular lighting, shadow mapping (sí, sombras dinámicas), ambient occlusion y hasta toon shading. Todo en ~500 líneas, sin una sola llamada a glDrawArrays.
Por qué esto importa (aunque no seas gamedev)
Hay una razón por la que este tutorial explotó en HN: los mejores programadores entienden sus abstracciones. No porque necesiten implementarlas, sino porque cuando algo falla, saben exactamente dónde mirar.
¿Tu framebuffer se corrompe? Sabes que el problema está en la memoria del z-buffer. ¿Los triángulos se dibujan en orden incorrecto? Es culling, no magia. Conocer la implementación te da superpoderes de debugging.
Y ojo: esto aplica a cualquier abstracción. Bases de datos, redes, compiladores, sistemas operativos. Los devs que se toman el tiempo de mirar debajo del capó siempre terminan escribiendo mejor código.
¿Deberías hacer el tutorial?
Si sabes C++ básico (punteros, clases, archivos), puedes completar este tutorial en un fin de semana. El autor estima 10-20 horas para estudiantes que empiezan desde cero.
No necesitas matemáticas avanzadas. Las transformaciones 3D son álgebra lineal de prepa: multiplicar matrices de 4x4. Si sabes sumar y multiplicar, puedes renderizar un modelo de Suzanne (el mono de Blender) con texturas y sombras.
El código está en GitHub, el autor provee una clase para manejar imágenes TGA (el formato más simple que existe), y cada paso está explicado con el código lado a lado con el resultado visual. No hay teoría sin práctica.
El camino de aprendizaje inverso
Lo interesante de este enfoque es que invierte la forma tradicional de aprender gráficos. En vez de empezar con OpenGL y preguntarte "¿cómo funciona glDrawArrays?", empiezas con píxeles y construyes hacia arriba.
Es como aprender a programar escribiendo assembly antes de tocar Python. Doloroso al principio, pero tu comprensión del sistema es órdenes de magnitud más profunda.
La mayoría de los devs de juegos modernos nunca han escrito un rasterizador. Y se nota cuando optimizan: tiran llamadas de draw a lo loco sin entender el costo real de cada operación. Con 500 líneas de C++, entiendes por qué un shadow map cuesta frames de rendimiento.
La verdad incómoda
Aquí va mi opinión polémica: Deberías saber hacer esto aunque trabajes en web. El 90% de los desarrolladores web no tiene idea de cómo funciona la aceleración por hardware de CSS 3D transforms, canvas, WebGL o WebGPU. Usan librerías como Three.js sin entender qué pasa cuando llaman a render().
No digo que escribas tu propio engine 3D para producción. Digo que entender los fundamentos te hace un mejor desarrollador en cualquier stack. Cuando sepas que un triángulo se rasteriza píxel por píxel, entenderás por qué 60 FPS en WebGL es un logro, no un derecho.
❤️ Comparte esto con ese colega que usa Three.js sin tener idea de cómo funciona un framebuffer. Le va a cambiar la perspectiva.
¿Tú has escrito algún renderer desde cero? ¿O crees que es pérdida de tiempo cuando existen librerías que hacen todo? Te leo en los comentarios.