O que aprender para se tornar um programador de gráficos
(blog.demofox.org)- As competências exigidas para vagas em gráficos em tempo real pedem ao mesmo tempo APIs gráficas explícitas do lado da CPU e iluminação e shading do lado da GPU, e é difícil se aprofundar muito nas duas áreas simultaneamente
- No lado da CPU, lida-se com APIs modernas como DirectX12, Vulkan e Metal, além de carregamento de assets e trabalho de suporte de engine; no lado da GPU, entram sombras, ambient occlusion, pós-processamento e características de desempenho da GPU
- O foco do aprendizado em GPU é escrever um path tracer e entender PBR; Ray Tracing in One Weekend, LearnOpenGL PBR, a documentação do Filament e PBRT podem ser bons pontos de partida
- O portfólio ideal mostra conhecimento com um renderizador em tempo real baseado em C++, um path tracer que gere imagens fotorrealistas e código para comparar e validar os resultados dos dois tipos de renderização
- A matemática necessária gira em torno de álgebra linear, trigonometria básica e um pouco de cálculo; no lado da CPU para desenvolvimento de jogos, a linguagem é C++, e a linguagem de shader mais comum é HLSL
Gráficos em tempo real lidam com CPU e GPU ao mesmo tempo
- Renderização moderna, na prática, é quase uma junção de dois tipos de trabalho
- Aprendizado do lado da CPU: programação de engine para APIs explícitas modernas como DirectX12, Vulkan e Metal, além de carregamento de assets e outras tarefas de suporte
- Aprendizado do lado da GPU: matemática moderna de iluminação e shading, sombras, ambient occlusion, efeitos de pós-processamento e a diferença entre o que é rápido e o que é lento na GPU
- Aprender as duas áreas ao mesmo tempo é muito difícil
- Para focar no lado da GPU, é possível usar ferramentas com menor carga no lado da CPU, como OpenGL, WebGL, DirectX11 e engines mais antigas
- Para focar no lado da CPU, dá para começar exibindo um triângulo na tela e depois um mesh, sem se preocupar tanto se o resultado está bonito
Path tracing e PBR
- O aprendizado do lado da GPU inclui escrever um path tracer
- Path tracing é a técnica usada em renderização para filmes e é o alvo que as técnicas modernas de renderização em tempo real tentam aproximar
- Um bom material inicial é o livro online gratuito Ray Tracing in One Weekend, que é acessível e mostra o processo de criar renderizações fotorrealistas
- Physically Based Rendering (PBR) trata da iluminação, especialmente da forma como o specular é aplicado
- PBR é uma abordagem baseada em princípios que produz bons resultados quando suas regras são seguidas
- Antes do PBR, usava-se muita fórmula arbitrária, ajuste manual e hacks para iluminação, então um asset que parecia bom em uma condição de luz podia parecer escuro demais ou brilhante demais em outra
- Como resultado, era preciso criar versões diferentes do mesmo asset para diferentes condições de iluminação, o que exigia muito tempo e esforço
- PBR faz com que os assets pareçam mais consistentes em várias condições de iluminação e reduz o tempo e o esforço gastos na criação de versões específicas
- Ainda assim, tempo, custo e esforço de produção de assets continuam sendo um grande gargalo no desenvolvimento de jogos
Materiais de estudo recomendados
- Para começar em PBR, a seção PBR Theory do LearnOpenGL e suas subseções são indicadas
- Para se aprofundar mais, a documentação do Filament pode ser o próximo passo
- Quanto mais fundo se vai em PBR, mais cálculo e estatística aparecem
- Depois disso, há o livro online gratuito Physically Based Rendering: From Theory To Implementation
- Machine learning talvez não entregue, hoje, tudo o que o hype promete, mas ainda vale a pena aprender técnicas de fitting e otimização como parte da caixa de ferramentas da ciência da computação
- Como material relacionado, pode-se consultar o vídeo Machine Learning For Game Developers
Código que vale mostrar no portfólio
- Para provar conhecimento a recrutadores, o ideal é ter código-fonte compartilhável em um lugar como GitHub e apontá-lo no currículo
- Exemplo de portfólio:
- Um renderizador com cara de engine que carregue assets como modelos e texturas e os renderize em tempo real na tela
- Incluindo alguns efeitos como iluminação e sombras, depth of field, area lights, tone mapping e ray traced shadows
- Se possível, com iluminação baseada em PBR, câmera controlável pelo usuário, APIs como DX12 e Vulkan, e uso de C++
- Um path tracer que gere imagens fotorrealistas
- Se possível, em C++, mas pode ser também um programa que apenas exporte PNG sem janela
- Não precisa ser em tempo real
- Melhor ainda se o path tracer for um modo separado dentro do renderizador tipo engine
- Isso permite comparar o resultado path traced com a renderização PBR em tempo real para validar a precisão
- Se você conseguir apontar onde as duas renderizações não coincidem, explicar por que diferem e pensar em formas de aproximá-las sem perder tempo real, isso será ainda mais valorizado
- Um renderizador com cara de engine que carregue assets como modelos e texturas e os renderize em tempo real na tela
Matemática, algoritmos e escolha de linguagem
- Ao fazer os itens acima na prática, você encontra naturalmente a matemática necessária
- O essencial é álgebra linear com multiplicação de matrizes, cross product, dot product, trigonometria básica e um pouco de cálculo
- Em gráficos e desenvolvimento de jogos, o mínimo de matemática exigido é relativamente pequeno, mas a faixa de matemática que pode ser aplicada é praticamente ilimitada
- Com algoritmos é parecido
- É preciso conhecer tipos abstratos de dados e algoritmos básicos como linked list, hash table, ordenação e busca
- Os algoritmos mais rápidos muitas vezes são simples, e arrays são muito mais rápidos que linked lists
- Conceitos mais avançados de algoritmos ajudam quando realmente é preciso algo novo e sob medida
- A linguagem que se deve aprender para desenvolvimento de jogos é C++
- Algumas pessoas usam Rust e ela tem alguma presença, mas não é a linguagem padrão que as pessoas esperam
- WebGPU traz muitos recursos que o WebGL não tinha e está se tornando uma plataforma mais séria, permitindo fazer o trabalho do lado da CPU em JavaScript
- Ainda assim, não se vêem muitas vagas com WebGPU nem muito conteúdo de WebGPU na web
- A linguagem de shader mais comum é HLSL
- Alguns usam GLSL
- Em jogos multiplataforma, muitas vezes os shaders são convertidos para outras linguagens de shader
Escopo de uso de LLM e ML
- Atualmente, a tecnologia de ML parece estar abaixo do necessário para grande parte dos usos em que está sendo vendida
- Claude ajuda ao conversar sobre matemática, artigos e algoritmos pouco familiares
- Nessas situações, é fácil verificar se está inventando coisas e também é fácil validar a plausibilidade com outras fontes
- Para programação, não é tão útil
- Mesmo que produza código que funcione como você quer, ainda será preciso gastar tempo para entender esse código
- Nesse caso, a avaliação é que costuma valer mais a pena escrever por conta própria
- Pode ser útil para usos pequenos
- Por exemplo, perguntar “há algum bug neste arquivo?”; se a resposta for yes, dá para investigar, e mesmo que seja no, o custo de perguntar é quase zero
- A crença é que um dia a humanidade criará uma inteligência em nível humano e irá além disso, mas não dá para saber se isso acontecerá dentro da própria vida
- A era atual dos LLMs se parece mais com um ensaio geral para quando a “coisa de verdade” chegar
1 comentários
Opiniões no Hacker News
Primeiro é preciso diferenciar se você quer criar jogos ou fazer programação de engines 3D
Se quiser criar jogos, é melhor usar uma engine existente como Unreal Engine, Unity, Godot ou Bevy, e você vai aprender problemas de gráficos em um nível mais alto, em vez de como empurrar pixels diretamente. O que é realmente difícil é tornar o jogo divertido
Se quiser criar uma engine 3D, precisa saber que já existem engines de jogos ruins demais por aí. Só no lado de Rust, os principais projetos são 3 renderizadores fracassados, 1 renderizador inacabado e o renderizador dentro do Bevy, e há muito mais projetos dizendo “vou criar uma engine de jogos”. Leva cerca de 2 anos só para chegar ao nível de “primeiro renderizador”, e chegar a cenas grandes, detalhadas e dinâmicas é algo muito maior
Se o objetivo é emprego, a indústria de jogos não tem bons salários nem bons horários, quando o projeto acaba o emprego também acaba, e, como em Hollywood, há candidatos de sobra tentando entrar. Além disso, por causa do colapso do Metaverse, agora há excesso até de gente experiente
Mobile é um trabalho de compressão em que tela, poder de processamento, GPU e bateria são todos limitados, e por isso a maioria dos jogos indie hoje é 2D. É o que ainda é viável, e com frequência são feitos também em HTML/JavaScript
Mas criar um renderizador básico e um game loop não é tão difícil, e provavelmente nem será a maior parte do código do jogo. Para um jogo simples, um
drawObject()dentro de um loopforjá pode bastar, e preocupações como streaming de recursos, otimização de bindings e paralelismo podem ficar para depois, quando forem necessáriasFico curioso sobre que ponto de partida e quais critérios de sucesso estão por trás desse parâmetro de “2 anos até o primeiro renderizador”. Cerca de um ano atrás, em um mês de tempo livre — menos de uma semana em tempo integral — fiz um renderizador diferido com iluminação dinâmica, shadow mapping e alguns pós-processamentos
Também não há motivo para menosprezar 2D. Boa parte do trabalho sério acontece em interfaces 2D, e WebGL e o antigo canvas 2D hoje também são bastante poderosos. Entre os jogos indie de sucesso, muitos são 2D
É verdade que a indústria de jogos não é das melhores, mas hoje quase tudo usa GPU. Escrever e depurar tarefas de machine learning, visualização de dados, HUD e interfaces de usuário comuns também muitas vezes exigem entendimento de gráficos
Além de jogos, há muito mais áreas que usam gráficos, como visualização e simulação, e bons programadores gráficos são extremamente raros, então é uma carreira surpreendentemente decente. Isso contrasta bastante com o fato de que parece mais difícil para desenvolvedores de jogos ou artistas conseguirem bons empregos. Ainda assim, tanto a demanda quanto a oferta são pequenas, então pode não ser fácil trocar de emprego
Olhando só para estabilidade profissional, eu desencorajaria fazer de desenvolvimento de jogos uma carreira, mas programação gráfica é diferente
Entre os jogos que joguei nos últimos anos, Core Keeper (Unity), WORMHOLE (Unity, especialmente o lag no modo infinito) e Crab Champions (UE4, em que é preciso usar upscaling que deixa a imagem feia para manter 60 fps em 1920x1200) tiveram problemas graves de desempenho
Por outro lado, Terraria, Necesse e Barony usam engines próprias, rodam muito bem e parecem melhores quanto mais o tempo passa
Para ser justo, Tiny Rogues (Unity), pelo que me lembro, rodava bem na maior parte do tempo, mas como o desenvolvedor está trabalhando para sair da Unity no futuro, parece que ele mesmo também encontrou problemas
Eu entendo a diferença entre criar um jogo e criar uma engine, e a importância de realmente terminar e lançar, mas é difícil deixar um bom legado se você entrega lixo. Acho melhor garantir um certo nível de qualidade, mesmo que seja por um caminho mais longo. Jogos às vezes são jogados por décadas após o lançamento, e, se houver bugs ou lag, as pessoas continuarão passando por isso
“Vou primeiro criar minha própria engine para este jogo, para facilitar os próximos jogos” é uma armadilha surpreendentemente forte. Isso porque você aprende coisas realmente importantes e obtém pequenas vitórias todos os dias. Você faz mais um unroll para a cena parecer suave, adiciona mais uma camada lógica ao formato de configuração para facilitar a criação de cenas, lê mais um paper da SIGGRAPH
Sempre há algo importante a melhorar, mas essas coisas não se juntam para formar um jogo finalizado. Olhando para trás, usar uma engine própria é a maneira perfeita de adiar a parte difícil, mas necessária, do jogo com que um técnico sonhava: “torná-lo divertido”. Você aprende a habilidade de programar videogames impressionantes, mas não aprende a fazer jogos
Há também uma armadilha secundária. Você aprende cem maneiras de criar efeitos visuais bonitos que rodam suavemente em tempo real, mas não aprende a usá-los como arte
Isso é muito parecido com a armadilha do “Enterprise Java”. Só que é mais sutil porque lida com termos concretos. Como não há uma Factory Factory Interface no Scene Graph, você acha que escapou dessa bala, mas acaba deixando passar que, para colocar um bitmap na tela e fazê-lo reagir a teclas, aquilo em si é desnecessário
Isso vale especialmente em 2D. Por exemplo, estou criando um jogo com uma engine de jogo feita por mim, com foco em desempenho, compressão e uma arquitetura sem servidor nem banco de dados
Essa engine tem uma estrutura e suposições muito específicas sobre a arquitetura do jogo para alcançar desempenho e compressão extremos dentro das restrições que defini. Pretendo publicar em breve um post relacionado no Hacker News, se possível na semana que vem
No passado, também tentei várias vezes criar jogos de navegador com Unity, Godot e React, mas aprender as APIs era penoso, e as engines não satisfaziam minhas restrições extremas. Claro que isso também pode ter sido culpa minha por não saber lidar bem com essas engines, mas, olhando para trás, acho que o que consegui internamente teria sido impossível sem uma engine customizada feita do zero
Aprendi muita coisa criando minha própria engine e meu próprio jogo, e especialmente hoje, graças aos LLMs, acho que para desenvolvedores experientes criar uma engine de jogo sob medida por conta própria de repente entrou no campo do realista para a maioria dos desenvolvedores
Hoje, eu não recomendaria a ninguém entrar em programação gráfica
Comecei em 2001, quando foi anunciada a primeira GeForce 1 da Nvidia, a chamada “Gigatexel shader card”, e desde então a velocidade de avanço e inovação nessa área tem sido de dar vertigem. Comparada a 25 anos atrás, a tecnologia de hoje é realmente incrível
Mas há um grande “porém” nessa maravilha. A área está evoluindo a uma velocidade assustadora. A Nvidia já lançou até efeitos baseados em IA que afetam cenas e assets, algo que na época eu nem imaginava que pudesse ser possível em tempo real
Já nem sei se é possível se tornar um “bom especialista” nessa área. Em outras palavras, a pergunta é: “onde está o John Carmack de hoje?”. Ele ficou famoso por extrair até a última gota do hardware e usar ideias que estavam escondidas na comunidade, mas hoje não parece haver fosso competitivo para alguém assim. A área é ampla demais e muda rápido demais para haver oportunidade de se tornar o próximo Carmack
Há também outro ponto de vista. Se até agora você só fez apps web e Kubernetes, talvez seja justamente bom experimentar programação gráfica. O loop de feedback é eletrizante, e você passa a sentir o quão absurdamente rápido um computador comum pode ser. Mesmo que no fim você acabe fazendo otimizações que não importam, isso tem valor porque você nunca aprendeu, em baixo nível, o quanto as coisas podem ser rápidas
Também há muito material, e a matemática não é excessivamente difícil. Modelagem 3D pode acabar sendo uma saída criativa que você nem sabia que tinha. Mesmo que não se aplique em nada ao seu trabalho principal, você passa a apreciar de uma forma nova a arte que é a programação de computadores, e talvez decida nunca mais tocar em Kubernetes e gastar 5 anos do seu tempo livre escrevendo seu próprio motor de jogo
Há muitos malucos assim, e a comunidade de desenvolvedores amadores que não foi desgastada pelo desenvolvimento profissional de jogos é maior do que parece. O Discord de Graphics Programming também é um espaço acolhedor que vale conferir. É só tentar
Para alguém que na verdade não se importa com o que vai fazer e só quer uma transição de carreira, o conselho de evitar talvez esteja certo. Mas viver desse jeito não é uma boa abordagem. É melhor seguir aquilo que você considera interessante e valioso, aprender coisas novas constantemente e desafiar a si mesmo. Aí fica relativamente claro se vale ou não aprender computação gráfica, e para a pessoa certa o saldo é positivo. Mesmo que não vire profissão, as habilidades se transferem bem para muitas outras áreas
Não há problema em não ser tão famoso quanto uma das pessoas mais conhecidas de uma área; dá para fazer só porque é divertido. A matemática e a arte de gráficos e programação de jogos são belas por si só
Meu motivo para não entrar em programação gráfica é outro. Motores 3D com vértices e texturas ainda existirão daqui a alguns anos? Ou tudo será renderizado diretamente por modelos de mundo de IA? Quanto código haverá nos jogos, ou eles existirão como uma sequência de prompts escritos de forma inteligente?
Se você precisa de um tutorial rápido de álgebra linear, pode ver este material imprimível de 4 páginas que escrevi: https://minireference.com/static/tutorials/linear_algebra_in...
Também há aqui um notebook com exemplos de código em SymPy: https://github.com/minireference/noBSLAnotebooks
Graças às visualizações, coisas que não tinham feito sentido na aula de Linear 101 ficaram muito claras
Fico um pouco surpreso que não haja menção a princípios básicos de design ou à compreensão das características da percepção humana
Meu irmão foi artista de produção em jogos de computador famosos dos anos 90 e 2000, e vivia reclamando de programadores e gerentes sem sensibilidade visual e sem curiosidade para entender o lado dos artistas
Gráficos não são minha especialidade, mas, como músico, sound designer e produtor, os coders de DSP de áudio mais eficazes e influentes que conheço entendem os fundamentos da música, a física e a acústica do som, e as armadilhas entre o processamento digital discreto e a forma como percebemos e interpretamos estímulos
Ajuda quando um programador gráfico tem uma mentalidade artística, mas normalmente ele trabalha em um nível bastante baixo, então isso não é essencial para ter sucesso
A IA mudou um pouco o cálculo, ou pelo menos tem potencial para mudar, mas acho que boa parte da onda “aprenda a programar” de meados dos anos 2000 vinha também desse motivo. Era um movimento para tratar o desenvolvimento de software como “uma funcionalidade, não um produto” para especialistas de áreas existentes, fazendo com que as pessoas que mais conheciam o domínio criassem software diretamente, em vez de traduzirem requisitos para a equipe de desenvolvimento
Sinceramente, programação gráfica costuma ser mais um papel de serviço, tornando possível o que essas pessoas querem fazer ou ajudando-as a criar o que imaginaram
Inigo Quilez é citado como exemplo de alguém que é ao mesmo tempo programador gráfico e artista, e ele é realmente uma pessoa poderosa, quase um unicórnio
Pessoalmente, gosto mais de tocar música e de programação de áudio, e isso acaba sendo uma boa base para aprender DSP. Por exemplo, se você empurra o ruído de renderização para as altas frequências, às vezes um filtro passa-baixa é mais eficaz para remover o ruído.
Se tiver curiosidade e tempo, vale a pena aprender. É muito divertido, você aprende bastante e isso também faz de você um engenheiro melhor em várias outras áreas da ciência da computação. Você passa a entender hardware, programação de sistemas, o modelo de máquina do programador etc.
Mas, se o dinheiro for seu objetivo final, é melhor não aprender. Hoje em dia, a recompensa é efêmera, temporária e não garantida.
Eu sempre tive interesse em programação gráfica e, alguns anos atrás, comecei a aprender Vulkan por conta própria. Não sei quanto tempo gastei no total, mas acho que foram uns 6 meses de tempo livre à noite, talvez um pouco menos. Acabei criando algo próximo de um framework de renderização.
Só que é o tipo de coisa em que, quanto mais você avança, mais percebe o quanto não sabe. No momento em que você começa a achar que a estrutura está boa, descobre que aquela não é a arquitetura correta.
No fim, o que você faz é basicamente matemática aplicada de iluminação, e o resto é encanamento. Você pensa “por que o spotlight está atravessando o cubo?”, aí vê que precisa calcular sombras, e acaba passando semanas investigando como colocar isso no pipeline de renderização. Ainda assim, se você gosta desse tipo de coisa, é bem “divertido”.
Por exemplo, mesmo para criar sombras, você precisa escrever umas 10 vezes mais código do que a técnica em si exigiria essencialmente.
Para aprender programação gráfica, acho muito mais prazeroso escrever um renderizador por software. Há menos código, e o código que você escreve toca no núcleo do problema, em vez de ser boilerplate. A desvantagem é perder a aceleração por hardware, então fica mais lento.
Se você só quer criar jogos, use uma engine de jogos como Unity, Godot ou Unreal.
Se você quer trabalhar com gráficos no nível de engines, simulações ou renderizadores, precisa aprender uma linguagem de baixo nível e uma API gráfica. Como linguagem, recomendo C++; C ou Rust também podem ser usados, mas C é um pouco difícil, e a própria API gráfica já é difícil, então você provavelmente não vai querer brigar também com a linguagem. Rust também pode ser uma boa opção, mas pessoalmente acho o tempo de compilação muito lento e a sintaxe feia.
Como API, recomendo OpenGL. É multiplataforma, antiga — o que é ao mesmo tempo vantagem e desvantagem — e é a mais fácil entre elas.
learnopengl.com é, de longe, o melhor tutorial de OpenGL, então recomendo seguir por ele.
Depois de usar OpenGL por um tempo, você pode expandir para Vulkan ou para bibliotecas gráficas que implementam várias APIs; ou, se estiver satisfeito, pode continuar usando OpenGL.
Definitivamente não é fácil, mas acho que é uma das áreas mais fascinantes da ciência da computação.
É meio estranho eu mesmo dizer isso, mas a comunidade também é ótima. A web é uma boa forma de compartilhar o que você cria enquanto aprende, coletar feedback e ganhar visibilidade. Dentro da comunidade, também há muitos casos de pessoas que passaram a trabalhar profissionalmente com gráficos 3D.
Às vezes dou uma olhada no repositório e fico constrangido com o quanto o código daquela época era bagunçado, mas acho que, sem aquele projeto, eu não estaria onde estou hoje.
Você começa com tags simples, adiciona animações e, se faltar algo, acrescenta componentes da comunidade. Se ainda não for suficiente, pode modificar com ThreeJS e chegar até shaders. O A-Frame é excelente.
Além disso, também dá para fazer AR e VR.
Em vez de “virar programador gráfico”, que tal simplesmente fazer programação gráfica? Comece tentando coisas simples, vá pegando o jeito e, quando você perceber que no fim é uma questão de enviar logística para a GPU, dá para construir todo tipo de conceito complexo em cima disso.
É como subir uma pequena montanha e, de repente, tudo se encaixar e você pensar “uau…”. Você começa a enxergar as possibilidades e as coisas para experimentar.
Frases como “sou escalador”, “sou gamer”, “sou artista”, “sou mãe”, “sou pai”, “sou rato de academia”, “sou programador gráfico” não significam necessariamente uma profissão, mas sugerem algo mais profundo do que um envolvimento leve e passageiro.
Hoje aprendi o formato de imagem PPM, que é muito acessível para esse tipo de uso. Escrever um bitmap não é exatamente ciência de foguetes, mas PPM é ainda mais fácil.