Cómo convertirse en programador gráfico

• La forma de iniciarse en gráficos varía según los conocimientos previos, la forma de aprender y el hardware, más que por una única respuesta correcta, y el equipo de AMD Game Engineering considera que para principiantes puede hacer falta un punto de partida más amigable
• La programación gráfica consiste en escribir tanto código C++ del lado de la CPU como código de shaders del lado de la GPU, y conectarlos mediante APIs gráficas como DirectX, Vulkan u OpenGL
• A partir de 2023, las opciones principales se dividen entre APIs legacy como OpenGL, DirectX 11 y WebGL, y APIs explícitas modernas como Vulkan, DirectX 12, Metal y WebGPU
• Las APIs legacy son más fáciles de aprender, pero la complejidad del driver y del runtime ha crecido; las APIs modernas exigen más código y mayor comprensión de la GPU, pero ofrecen más control
• Al principio se puede comenzar en entornos simples como OpenGL, WebGL, motores de juego o Shadertoy, y si ya se entiende bien C++ y el pipeline de la GPU, también es posible entrar directo a Vulkan o DirectX 12

---

Estructura básica de la programación gráfica

• La respuesta corta sobre el lenguaje que más usan los programadores gráficos es C++
• En la práctica, el trabajo consiste en escribir tanto código host que corre en la CPU como código de shaders que corre en la GPU
  • El código host en la CPU normalmente se escribe en C++
  • El código para la GPU se escribe en lenguajes de shading de alto nivel como HLSL o GLSL
• La API gráfica es el punto de conexión que permite que el código de CPU solicite trabajo a la GPU usando shaders y los datos y metadatos necesarios

Con qué API gráfica empezar

• A partir de 2023, las APIs comúnmente usadas en juegos de PC y aplicaciones 3D se dividen en dos grandes grupos
  • APIs legacy: OpenGL, DirectX 11, WebGL
  • APIs explícitas modernas: Vulkan, DirectX 12, Metal, WebGPU
• OpenGL, DirectX 11 y WebGL se basan en un enfoque histórico para programar la GPU y, desde la perspectiva del programador, son más simples y fáciles de aprender
• Esa simplicidad tiene un costo
  • Con el tiempo, la implementación interna del driver y del runtime se volvió más compleja
  • Esto deriva en cuellos de botella del lado host y en una carga de drivers complejos que los fabricantes de GPU deben mantener
• Mantle de AMD apareció en PC entre 2013 y 2016, y mediante la colaboración entre GPUs de AMD y EA DICE ofreció un acceso de más bajo nivel a la GPU y una abstracción más delgada
• Metal apareció en 2014 en las plataformas de Apple, y DirectX 12 y Vulkan llegaron en 2016 para abordar la programación de GPU de una manera más explícita y de más bajo nivel

Tradeoff de aprendizaje entre APIs fáciles y APIs explícitas

• Vulkan y DirectX 12 exigen que el programador especifique con mayor claridad qué trabajo quiere que haga la GPU, por lo que la carga inicial es mayor
• A cambio, se obtiene más control y también mayores oportunidades para mejorar el rendimiento y la eficiencia del trabajo en la GPU
• La diferencia entre APIs se nota incluso al ver el ejemplo de dibujar el primer triángulo
  • En OpenGL o DirectX 11 se puede dibujar el primer triángulo con unas 10 líneas aproximadamente
  • En Vulkan y DirectX 12 hace falta mucho más código
• OpenGL y DirectX 11 ocultan muchos detalles y permiten llegar rápido a trabajo gráfico productivo, pero eso puede hacer que el funcionamiento de la GPU parezca una caja mágica
• Vulkan y DirectX 12 exigen desde el inicio conocimiento de más bajo nivel y comprensión de la GPU, pero a cambio cada línea de código deja más claro qué va a ocurrir en la GPU

Opciones de ruta de entrada

• Incluso dentro del equipo de AMD Game Engineering conviven tanto la opinión de que empezar con DX12 o Vulkan puede ser demasiado áspero para adolescentes o principiantes, como la idea de que sí es posible si se cumplen ciertas condiciones
• OpenGL ha perdido actualidad y relevancia, pero sigue considerándose suficiente para aprender las bases
• WebGL puede ser un buen punto de partida para entender el pipeline gráfico
  • En la web se pueden manejar gráficos en tiempo real con JavaScript sin necesidad de C++
  • Con WebAssembly también es posible correr gráficos en C++ dentro del navegador
• WebGPU ofrece conceptos más cercanos a las APIs gráficas modernas, pero puede requerir menos detalles de bajo nivel
  • Al empezar a escribir código complejo todavía se pueden encontrar varios problemas
  • Aun así, es prometedora como API para prototipado, aprendizaje y educación
• También es posible comenzar primero con un motor de juego
  • Unreal Engine tiene un peso importante en los juegos de PC
  • Unity también es una alternativa común
  • También existen motores open source más pequeños y simples como Godot
• Hay escuelas que imparten la primera clase de rendering con Unity, pero existe el riesgo de que los estudiantes no entiendan por qué necesitan aprender conocimientos de bajo nivel
• Para empezar con una API explícita conviene conocer bien el panorama general del pipeline gráfico moderno y de cómo el hardware de GPU lo implementa, o tener la disposición de aprender esa comprensión al mismo tiempo

Recursos de aprendizaje recomendados y siguientes pasos

• LearnOpenGL: sitio para principiantes muy bueno para aprender programación gráfica con una API real en C++
• Scratchapixel: permite enfocarse en cómo funcionan conceptos como el ray tracing sin mucho código
• Udemy: puede servir para buscar cursos dirigidos a principiantes
• Rastertek: tutoriales de OpenGL y DirectX 11
• Ray Tracing in One Weekend: adecuado para un enfoque de aprender construyendo si ya puedes programar un poco
• A trip through the graphics pipeline: aunque es un texto de 2011 y anterior a las APIs explícitas, sus conceptos de hardware y software desde la perspectiva de la GPU siguen siendo aplicables
• learn wgpu: sitio para aprender WebGPU con un estilo parecido a LearnOpenGL, aunque todavía está en desarrollo
• Your first WebGPU app: puede servir como material de introducción a WebGPU
• Shadertoy: permite escribir shaders sin manejar directamente una API gráfica, así que puede ser un punto de partida más simple
• Vulkan Tutorial: también se menciona en el contexto de que al aprender Vulkan o DirectX 12 es importante no tener miedo de copiar y pegar
• Si todavía no decides un lenguaje o ecosistema de API, puedes probar varios enfoques y seguir usando el que mejor se adapte a ti

[GN⁺]

Opiniones en Hacker News

• Para principiantes, conviene dar un paso atrás y preguntarse primero “qué quiero crear”, en lugar de empezar por “qué herramientas voy a usar”.
  Incluso al aprender al inicio, no hay que perder de vista el resultado final. Hoy hay demasiadas herramientas en gráficos por computadora que abstraen las muchas etapas necesarias para dibujar píxeles en pantalla, así que uno puede terminar sufriendo desde el principio con código de bajo nivel y recién después darse cuenta de que, en el área a la que quería llegar, se usan Unity, TouchDesigner, threejs o After Effects, y casi nada de C++.
  Por supuesto, aprender cómo funcionan las cosas desde la base tiene muchísimo valor, pero creo que hacerlo primero es un enfoque lento. El aprendizaje se acelera cuando entras a la industria y entiendes los conceptos del funcionamiento interno mediante herramientas de abstracción como motores de juegos o programación visual.
  Lo digo como alguien que pasó años aprendiendo C++ y OpenGL con dificultad, y que durante mucho tiempo luchó contra el costo hundido que me impedía aceptar enfoques no-code. Al final, si este camino no te ayuda a crear lo que quieres crear, es mejor no perder tiempo en él.

  • Conviene escuchar este consejo. Al inicio de mi carrera decidí que iba a convertirme en experto en OpenGL, y creo que en cierta medida lo logré.
    No escribí un libro de texto como Mark Kilgard, pero trabajé en profundidad en varias capas de la API: desde el nivel de drivers hasta pruebas de conformidad, optimización de rendimiento, código de juegos y aplicaciones, y las principales plataformas de escritorio y móviles.
    ¿Y a dónde me llevó eso? La verdad, no muy lejos. Ahora casi nadie se preocupa por OpenGL, y cuando dos de los principales fabricantes de sistemas operativos terminaron abandonándolo, quedó prácticamente como una tecnología muerta. Basta buscar OpenGL en “HN Who's Hiring” para verlo.
    Podría haber reaprendido otras APIs gráficas como Direct3D, Vulkan o Metal, pero hoy el código gráfico de bajo nivel lo abstraen los motores, así que no hay muchos lugares que necesiten a ese tipo de persona. Incluso las empresas que necesitan personal para drivers gráficos de bajo nivel son, como mucho, 5 o 6 en todo el mundo, lo que lo convierte en un nicho que limita la carrera.
    Cuanto más te concentras en una parte pequeña de la máquina, más necesitas convertirte en un experto mundial para hacer de eso toda tu carrera. Si tu plan no es ser el próximo John Carmack, recomiendo ir más a lo amplio que a lo profundo.
  • Es una trampa clásica en la que siempre caen los desarrolladores nuevos. Ni siquiera es algo exclusivo de la programación gráfica.
    YouTube está lleno de videos de programación para principiantes que te hacen aprender una lista interminable de stacks tecnológicos en lugar de enfocarse en crear algo interesante. El resultado es que, para llenar el currículum, terminas construyendo un aparato de Rube Goldberg complejo y casi ritualista incluso para renderizar unas pocas líneas de texto en una página web.
    En la universidad hice algo de programación gráfica durante un semestre, y era lo suficientemente compleja como para que una respuesta razonable a “qué quiero crear” fuera algo como “renderizar un triángulo verde sobre un fondo negro”. De ahí pasar a un cuadrado, un cubo, una esfera, una esfera animada y una pelota que rebota es una progresión natural y te mantiene enfocado en el objetivo. Así que también hay que evitar el error de responder a la pregunta anterior con “un shooter en primera persona con iluminación por ray tracing y dispersión subsuperficial”.
    La primera versión del código de la pelota que rebota va a ser realmente horrible. Y está bien. Con el tiempo aprenderás a optimizarlo y mejorarlo. Además, pocas cosas son tan emocionantes como descubrir por tu cuenta los patrones de diseño. Lees un libro sobre un tema nuevo y piensas: “¡Eh, esto ya lo estoy haciendo!”.
  • Como alguien que intenta entrar en esta área, me cuesta estar del todo de acuerdo. Muchas ofertas de programación gráfica, quizá todas, exigen de antemano conocimientos de C++.
    Claro, también se puede entrar por otro rol, como programador de gameplay, y moverse poco a poco hacia gráficos; incluso puede que sea más fácil. Pero al final, un puesto de programador gráfico requiere C++.
    Lo dicho antes parece más aplicable a alguien que quiere volverse productivo rápidamente en trabajos relacionados con gráficos, no a la programación gráfica en sí.
  • Es un buen consejo. Es una trampa común también en preguntas como “qué lenguaje debería aprender / cuál es el mejor lenguaje”, porque saltan directamente por encima de “qué quiero crear”.
    Las herramientas cambian con el tiempo y, por experiencia, los ingenieros excelentes suelen saber manejar varias herramientas con distintos niveles de dominio, en lugar de profundizar en una sola.
  • Creo que, al igual que con los algoritmos de ordenamiento, todavía vale la pena enseñar esta programación de bajo nivel en la universidad.
    Aunque no termines haciendo eso en un trabajo real, obtienes mucho conocimiento teórico y entrenamiento en algoritmos complejos.
    Los gráficos también dan mucha experiencia en matemática aplicada. Hay muchísimas áreas que buscan desesperadamente gente capaz de hacer matemática. En mi trabajo anterior, en software para máquinas CNC, también necesitábamos a alguien que pudiera programar la matemática necesaria para controlar un taladro y darle cierta forma a un bloque de metal, y fue muy difícil encontrarlo. En cambio, los ingenieros de DevOps en la nube, aunque caros, eran relativamente fáciles de conseguir.

• Creo que un programador gráfico debería tener una comprensión general y equilibrada de cómo funcionan los gráficos. Más allá de la programación simple y el conocimiento de APIs, un buen programador gráfico debería conocer matrices de rotación, vista y proyección, matemática vectorial general, programación de shaders, primitivas procedurales como Voronoi, SDF y Perlin, composición de imágenes, renderizado forward y deferred, distintas técnicas de muestreo, y técnicas de sombras e iluminación.
  También necesita entender cómo funciona el pipeline de arte y cómo extraer datos de aplicaciones 3D, usar con comodidad profilers y depuradores, tener la capacidad de leer papers de SIGGRAPH, conocer técnicas de partición espacial y jerarquías de volúmenes, implementar un ray tracer simple, comprender primitivas como sprites, triángulos y polígonos de n lados, y tener experiencia con partículas y simulación.

  • Me gustaría saber si podrías ampliar un poco lo de “cómo funciona el pipeline de arte y cómo extraer datos de aplicaciones 3D”.
    Conozco el flujo muy básico de creación de un modelo —modelado → skin/rigging → animación → texturizado— y, a grandes rasgos, cómo se escribe eso en un archivo. Pero esta parte es especialmente difícil de aprender con experiencia práctica real si no trabajas junto a artistas.
  • Me pregunto cómo se puede conseguir empleo como desarrollador gráfico si uno sabe la mayor parte de esta lista.
    Hago programación gráfica como hobby y he aprendido muchas de las cosas mencionadas aquí, pero como no tengo experiencia laboral, casi no consigo oportunidades de entrevista.
  • ¿Dónde se pueden aprender estas cosas?

• Recomiendo el curso Graphics From Scratch de Pikuma. Lo primero que haces es escribir una función set_pixel usando SDL, y de ahí en adelante implementas todo directamente en código
  Escribes tú mismo todas las operaciones con matrices, todas las transformaciones de vértices e incluso toda la rasterización de triángulos, calculando qué color debería tener cada píxel
  https://pikuma.com/courses/learn-3d-computer-graphics-progra...

  • Mi sitio web/libro/curso también cubre el mismo enfoque, y es gratis
    https://www.gabrielgambetta.com/computer-graphics-from-scrat...
  • Otro voto para esta recomendación. Tomé este curso hace unos meses sabiendo casi nada de programación gráfica, y aunque solo tenía algunos años de experiencia como ingeniero de software generalista, terminé entendiendo bastante bien el proceso por el que una forma 3D se dibuja en pantalla
    Después pude aprender WebGPU en unos pocos días; creo que habría sido imposible sin la comprensión que obtuve del curso
    Si necesitas motivación, hice una demo compilando a Wasm el renderer que se construye al final del curso: https://rmshin.github.io/3d-renderer-wasm
  • Es un punto interesante. He estado pensando cómo diseñaría yo un curso introductorio de gráficos
    ¿Debería empezar con código SDL estilo putpixel, como en los 90, o con Shadertoy? Por supuesto, la matemática básica de matrices siempre es importante. Pero ¿cómo habría que enseñar la rasterización de triángulos? ¿Se puede pasar a coordenadas homogéneas y quadtree sin recorrer scanlines?
    ¿De verdad hay que enseñar sombreado Phong, o se puede ir directo a BRDF? Algunas partes podrían terminar siendo más enseñar “trucos viejos” que habilidades útiles
    Hoy en día, la estadística y el muestreo son mucho más importantes. Creo que los gráficos se vuelven más matemáticos cada año. Así que hay que aprender matemáticas y enseñar matemáticas
  • Hay varios buenos recursos para implementar renderizado 3D desde cero
    De ellos, recomiendo muchísimo este repositorio de GitHub: https://github.com/ssloy/tinyrenderer/wiki/Lesson-0:-getting...
    Si aprendes de forma visual, este canal también es un tesoro: https://www.youtube.com/watch?v=ih20l3pJoeU
  • “¡Sin GPU, sin OpenGL, sin DirectX!” es exactamente lo contrario de lo que esperaría alguien que quiere aprender programación gráfica

• En Shadertoy se puede aprender gráficos mediante escritura de shaders. Muchos programadores gráficos empiezan ahí
  Haciendo un poco de autopromoción, hice más de 10 tutoriales sobre escribir shaders en VS Code, SDF, ray marching, funciones de ruido, movimiento browniano fractal, etc.
  https://github.com/suboptimaleng/shader-tutorials
  Por supuesto, estoy parado sobre los hombros de gigantes como Inigo Quilez, The Art of Code, SimonDev y Acerola

• Hay muchísimos caminos para convertirse en programador gráfico sin empezar con DX/VK/OGL. Tampoco es obligatorio usar C++. Basta ver los increíbles gráficos 3D que hace 3Blue1Brown con Python
  Si quieres usar un motor de juegos, aprende DirectX o Vulkan; si quieres crear aplicaciones de navegador, aprende WebGL
  Pero esas API son pesadas y por sí solas no te enseñan mucho sobre gráficos. Si quieres aprender los conceptos de gráficos, conviene construir tanto un rasterizador como un trazador de rayos por tu cuenta, en el lenguaje que prefieras
  También hay muchas bibliotecas gráficas y entornos de programación mucho más divertidos que pelearse con Vulkan o DirectX. Processing es excelente, y también vale la pena mirar PlotDevice.io basado en Python, o sus predecesores NodeBox y DrawBot. ShaderToy es otro lugar donde puedes aprender mucho sobre escribir shaders y renderizar, y además es fácil empezar. En JavaScript también hay muchas opciones y bibliotecas. Estas alternativas son mucho más accesibles y motivadoras para principiantes, y aun así dan la potencia y flexibilidad para que una persona curiosa profundice tanto como quiera

• Ya que este artículo llegó a la portada, comparto un recurso que se usa realmente en la industria de la programación gráfica. Como referencia, soy uno de los autores: https://raytracing.github.io/
  También aparece en la sección “Useful Websites” del artículo anterior
  Los gráficos ya son un campo tan amplio que ya no existe un único método de aprendizaje que sirva para todos. Si quieres aprender gráficos, recomiendo buscar un mentor

  • Es un buen recurso. En particular, estoy muy de acuerdo con la idea de enseñar primero las matemáticas mediante trazado de rayos, antes que las API

• Soy desarrollador de juegos, pero no programador gráfico profesional. En el trabajo uso API gráficas modernas y shaders GLSL, pero recientemente, cuando un chico de 13 años quiso pasar de Scratch o Python a aprender C++, decidí que lo mejor era sacar una vieja DLL de OpenGL 1.2 que seguía en mi computadora desde 1999 y hacer que empezara con código de modo inmediato usando glut y glbegin/glvertex/glend
  Es mucho más divertido que soportar toda la configuración que exigen las API modernas. Al chico le interesa más la geometría computacional, como los diagramas de Voronoi, así que la API gráfica es solo un medio para un fin, y por ahora no importan los shaders vistosos ni la iluminación. El rendimiento de C++ y el viejo OpenGL es aproximadamente mil veces más rápido que Scratch, así que creo que encontramos un buen punto para su etapa actual de aprendizaje
  Incluso con la API simplificada de OpenGL 1.2, intentar entender C++ y OpenGL al mismo tiempo es una carga de aprendizaje bastante ambiciosa, así que la simplicidad ayuda a que sea mentalmente manejable. Por ahora va bien: hizo una demo decente de marching squares y lo ayudé a agregar un menú de IMgui para poder ajustar parámetros en tiempo de ejecución. Fue bastante divertido

• No sé exactamente qué está preguntando este sitio web. ¿Quiere hacer rigging? ¿Texturizado? ¿Modelado? ¿Escribir drivers? ¿Crear GUI? ¿Animaciones para sitios web? ¿Herramientas gráficas? ¿Shaders? ¿Un motor de fotos 2D? ¿Juegos 2D? ¿Juegos 3D? ¿Scripts procedurales? ¿Optimización de código gráfico?
  Bajo “gráficos por computadora” hay cientos de áreas. Pero este sitio web se enfoca en un rincón muy pequeño de ellas: programación de SDKs gráficos

  • Un programador gráfico es una categoría de programador bastante bien definida. Muchas de las cosas mencionadas antes, como rigging, texturizado y modelado, no son programación gráfica
    De un programador gráfico se espera que pueda trabajar en general con juegos, 3D, 2D, herramientas, shaders y optimización
  • Puede ser confuso, pero normalmente “programador gráfico” se refiere a alguien que trabaja en un motor de renderizado gráfico, ya sea en tiempo real u offline

• Yo también estoy en ese camino. Hace 2 años hice mi primer motor 3D siguiendo varios tutoriales y videos de YouTube
  Es muy simple, pero me gustan las cosas simples. Ahora estoy haciendo un juego de construcción de ciudades con este motor. Es realmente divertido aprender a manipular elementos usando matrices y productos cruzados
  https://www.youtube.com/watch?v=cvyrfPUpyp0