OpenGL ES 3.0: por qué se sigue enseñando en 2026

Por qué OpenGL ES 3.0 sigue siendo la base de un curso de gráficos en 2026

OpenGL ES 3.0 se publicó en agosto de 2012. Catorce años después, sigue siendo la API sobre la que se construye el módulo de introducción a la computación gráfica que Elias Farhan imparte en SAE Institute Geneva. Su argumento no es nostalgia: es portabilidad.

La decisión importa más allá del aula. Cualquier equipo que tenga que elegir una API de render enfrenta el mismo cálculo: cuánto cuesta migrar y qué se gana con el cambio. Farhan lo plantea sin rodeos: si hay que traducir todo el curso a una API nueva y actualizar cada concepto añadido, la transición tiene que valer realmente la pena frente a lo que ya funciona.

¿Qué hace a OpenGL ES 3.0 tan portable?

El autor eligió esta versión porque, en su opinión, es la más multiplataforma de OpenGL. El mismo programa en C++ (con algunos #ifdef) y los mismos shaders corren en:

• Windows: OpenGL ES 3.0 es compatible con OpenGL 4.3, así que asume directamente 4.3 para no pelear con los drivers.
• Linux: le permite compilar el mismo código con otro compilador.
• Android: la app arranca desde Java y llama a la librería nativa que contiene el código.
• Nintendo Switch: con dos devkits en la escuela, funciona quitando glew o glad y usando el wrapper de OpenGL embebido.
• WebGL2: su razón favorita. OpenGL ES 3.0 es compatible con WebGL2 vía emscripten, lo que permite a los estudiantes portar sus demos a su propio sitio web.
• iOS y macOS: ya no lo soportan, aunque ningún estudiante del programa trabaja en Mac.

Ese último punto es el que sostiene la tesis. La documentación del proyecto CNA, un framework en C++ que reimplementa XNA, confirma el patrón: usa WEBGL2 como renderer por defecto bajo Emscripten y OPENGLES3 por defecto en Linux, Android y los BSD. Es decir, OpenGL ES 3.0 no es solo una elección docente: sigue siendo el denominador común cuando el objetivo es llegar a la mayor cantidad de plataformas con un solo código.

Lo que OpenGL ES 3.0 no puede hacer

El costo de esa portabilidad es real. La API quedó anclada a un conjunto de features que hoy se consideran básicas en render moderno:

• SSBO (shader storage buffer objects): llegaron con OpenGL ES 3.1. Sin ellos, el instancing obliga a pasar por los vertex inputs.
• Compute shaders: también desde ES 3.1. Sin ellos, el post-procesado se hace con un pipeline gráfico y un plano en NDC.
• SPIR-V: disponible desde OpenGL 4.6, ni siquiera en OpenGL ES 3.2.
• Renderizado bindless: la extensión ARB_bindless_texture permite referenciar texturas por un handle de 64 bits, sin cambios de estado costosos.
• Indirect drawing: glDrawArraysIndirect y el multi-draw indirect son core desde OpenGL 4.0 y ES 3.1. Son la base del renderizado dirigido por GPU.
• Debug con KHR_debug: core desde OpenGL 4.3, permite que el driver envíe errores y warnings por callback.

Fuera de OpenGL, el hueco es mayor. El raytracing por hardware llegó con DXR en 2018, y aunque la mayoría de los juegos sigue en un modelo híbrido, títulos como Indiana Jones and the Great Circle, lanzado a fines de 2024, ya lo exigen. Y el renderizado multihilo para generar comandos de GPU, que juegos como Halo Infinite necesitan, no es posible en OpenGL: el estado de render vive en el driver y en un solo hilo.

¿Vale la pena migrar a Vulkan o WebGPU?

Farhan lo tiene claro: no por ahora. Su plan es escribir otro artículo explicando por qué no cambia a Vulkan, con foco en sincronización, PSO y overhead del driver.

Tampoco le convencen los frameworks como atajo. Le gusta la SDL GPU API —la está usando para portar su editor de gráficos y le permite apuntar a Vulkan, DirectX y Metal a la vez—, pero la considera demasiado pesada para un curso introductorio. De bgfx y raylib ha oído cosas buenas. Y WebGPU, además de sumar un lenguaje de shaders nuevo, le resultó más un dolor de cabeza que una alegría por su parecido con Vulkan 1.0.

El argumento pedagógico es el que cierra la discusión: cuando un estudiante comete un error en OpenGL, suele ser claro por qué. Con un framework, también hay que considerar el código de la librería. Y el objetivo del módulo es enseñar una API de gráficos y construir abstracciones encima.

Del lado de la industria, la señal va en sentido contrario. Adam Sawicki, en su análisis sobre el estado de las APIs de gráficos, no recomienda OpenGL como opción porque casi no se usa. Farhan lo cita y aun así mantiene su postura: catorce años es mucho tiempo en computación gráfica, pero el objetivo del curso no es formar especialistas en la API de moda, sino que los estudiantes entiendan cómo funciona el pipeline.

Qué significa esto para tu startup

La discusión parece de aula, pero aplica directo a decisiones de producto y de contratación.

Primero: separa la API de moda del modelo mental. Si contratas perfiles de gráficos, un candidato que entiende el modelo de estado, la sincronización y el pipeline de OpenGL aprende Vulkan o WebGPU en semanas. Uno que solo memorizó la API nueva, no. En la entrevista, pregunta por el por qué de una decisión de render, no por la sintaxis.

Segundo: si tu producto necesita render en el navegador, WebGL2 sigue siendo el piso. Ahí es donde OpenGL ES 3.0 se vuelve estratégico: permite escribir el core en C++ y compilarlo a la web con emscripten, sin mantener dos bases de código. Antes de adoptar WebGPU, revisa cuántos de tus usuarios tienen un navegador que lo soporte de forma estable.

Tercero: calcula la migración como un proyecto, no como un upgrade. El costo real no es reescribir el renderer, es reescribir todo lo que lo rodea: shaders, herramientas, documentación y el conocimiento del equipo. Si la API actual cubre tus necesidades y tu cuello de botella está en otra parte, migrar puede ser la decisión más cara que tomes este año.

La lección de fondo es la misma para un curso y para una startup: la tecnología más nueva rara vez es la respuesta correcta por defecto. La pregunta útil es qué te permite llegar más lejos con el equipo y el presupuesto que tienes hoy.

Fuentes

• Why I teach OpenGL ES 3.0 (fuente original)
• FAQ - CNA Documentation