Portuguese version. intro to chapter 4.
rnbastos
5 years ago
parent
aa0ebbef95
commit
f6c1020174
@ -0,0 +1,47 @@
|
||||
# Introduction
|
||||
|
||||
<canvas id="custom" class="canvas" data-fragment-url="cmyk-halftone.frag" data-textures="vangogh.jpg" width="700px" height="320px"></canvas>
|
||||
|
||||
As imagens acima foram feitas de maneiras diferentes. A primeira foi feita pela mão do Van Gogh, aplicando-se camada a camada de tinta. Levou horas. A segunda foi produzida em segundos pela combinação de quatro matrizes de pixel: uma para ciano, uma para magenta, um para amarelo e outro pra preto. A diferença chave é que a segunda imagem é produzida de forma não-serial (ou seja, não foi passo a passo, mas todos ao mesmo tempo).
|
||||
|
||||
Este livro é sobre a técnica computacional revolucionária, *fragment shaders*, que está levando imagens geradas digitalmente a um nível mais alto. Você pode pensar nisso como sendo o equivalente à impressa de Gutenberg para gráficos.
|
||||
|
||||
|
||||
|
||||
Fragment shaders te dão controle total sobre os pixels rendereizados na tela, em velocidade super. É por isso que eles são usados para todas as finalidades, desde filtros de vídeo em celulares até videogames 3D incríveis.
|
||||
|
||||
|
||||
|
||||
Nos capítulos seguintes, você vai descobrir o quão incrivelmente rápida e poderosa é essa técnica, e como aplicá-la para seu trabalho pessoal e profissional.
|
||||
|
||||
## Para quem é este livro?
|
||||
|
||||
Este livro é escrito para programadores criativos, desenvolvedores de jogos e engenheiros que têm experiência em codificação, um conhecimento básico de álgebra linear e trigonometria, e quem quiser levar seu trabalho a um novo nível excitante de qualidade gráfica (se você quer aprender como programar, eu recomendo fortemente que comece com o [Processing](https://processing.org/) e volte mais tarde quando estiver comfortável com isso.).
|
||||
|
||||
Este livro vai te ensinar como usar e integrar shaders em seus projetos, melhorando a qualidade gráfica e performance. Devido ao fato de shaders GLSL (OpenGL Shading Language) compilarem e rodarem em grande variedade de plataformas, você vai poder aplicar o que aprendeu aqui para qualquer ambiente que usar OpenGL, OpenGL ES ou WebGL. Em outras palavras, você vai poder aplicar e usar seu conhecimento com sketches do [Processing](https://processing.org/), aplicações [openFrameworks](http://openframeworks.cc/) , instalações interativas [Cinder](http://libcinder.org/) , websites [Three.js](http://threejs.org/) ou jogos iOS/Android.
|
||||
|
||||
## O que este livro cobre?
|
||||
|
||||
Este livro vai focar no uso de shaders de pixel em GLSL. Primeiro vamos definir o que são os shaders; então vamos aprender como fazer formas proceduralmente, padrões, texturas e animações com eles. Você vai aprender as fundações da linguagem de shaders e como aplicar em cenários mais úteis, como: processamento de imagens (operações com imagens, convoluções de matrizes, blurs, filtros de cores, tabelas de lookup, e outros efeitos) e simulações (jogo da vida de Conway, reação e difusão de Gray-Scott, ondas em água, efeitos de cores de água, células de Voroni, etc). Em direção ao fim do livro, vamos ver um conjunto de técnicas avançadas baseadas em Ray Marching.
|
||||
|
||||
*Existem exemplos interativos para você brincar em cada capítulo.* Quando você muda o código, vai ver as mudanças imediatamente. os conceitos podem ser abstratos e confusos, então os exemplos interativos são essenciais para ajudá-lo a aprender o material. Quanto mais rápido você colocar os conceitos em movimento, mais fácil será o processo de aprendizagem.
|
||||
|
||||
O que esse livro não cobre:
|
||||
|
||||
* Este *não é* um livro de openGL ou webGL. OpenGL/webGL é um assunto maior que GLSL ou fragment shaders. Para aprender mais sobre openGL/webGL eu recomendo dar uma olhada em: [OpenGL Introduction](https://open.gl/introduction), [the 8th edition of the OpenGL Programming Guide](http://www.amazon.com/OpenGL-Programming-Guide-Official-Learning/dp/0321773039/ref=sr_1_1?s=books&ie=UTF8&qid=1424007417&sr=1-1&keywords=open+gl+programming+guide) (também conhecido como o livro vermelho) ou [WebGL: Up and Running](http://www.amazon.com/WebGL-Up-Running-Tony-Parisi/dp/144932357X/ref=sr_1_4?s=books&ie=UTF8&qid=1425147254&sr=1-4&keywords=webgl)
|
||||
|
||||
* Este *não é* um livro de matemática. Embora venhamos a cobrir um bom número de algoritmos e técnicas que se baseiam no entendimento de álgebra e trigonometria, não vamos explicá-los em detalhes. Para questões relacionadas com matemática eu recomendo que você tenha um desses livros por perto: [3rd Edition of Mathematics for 3D Game Programming and computer Graphics](http://www.amazon.com/Mathematics-Programming-Computer-Graphics-Third/dp/1435458869/ref=sr_1_1?ie=UTF8&qid=1424007839&sr=8-1&keywords=mathematics+for+games) ou [2nd Edition of Essential Mathematics for Games and Interactive Applications](http://www.amazon.com/Essential-Mathematics-Games-Interactive-Applications/dp/0123742978/ref=sr_1_1?ie=UTF8&qid=1424007889&sr=8-1&keywords=essentials+mathematics+for+developers).
|
||||
|
||||
## O que você precisa para começar?
|
||||
|
||||
Não muito! Se você tem um browser modernos que possa rodar WebGL (como Chrome, Firefox ou Safari) e uma conexão à internet, clique no botão para o próximo capítulo no fim desta página para começar.
|
||||
|
||||
Alternativamente, baseado no que você tem, ou no que você precisa deste livro você pode:
|
||||
|
||||
- [Fazer uma versão offline deste livro](https://thebookofshaders.com/appendix/00/)
|
||||
|
||||
- [Rodar os exemplos em um Raspberry Pi sem um browser](https://thebookofshaders.com/appendix/01/)
|
||||
|
||||
- [Fazer um PDF do livro para imprimir](https://thebookofshaders.com/appendix/02/)
|
||||
|
||||
- Checar o [repositório GitHub](https://github.com/patriciogonzalezvivo/thebookofshaders) deste livro para ajudar a resolver questões e compartilhar código.
|
||||
@ -0,0 +1 @@
|
||||
# Introdução
|
||||
@ -0,0 +1,50 @@
|
||||
# Começando
|
||||
## O que é um shader?
|
||||
|
||||
No capítlo anterior, nós descrevemos shaders como o equivalente da imprensa de Gutenberg para os gráficos. Por quê? E mais importante: o que é um shader?
|
||||
|
||||
|
||||
|
||||
Se você já tem experiência em desenhar com computadores, já sabe que nesse processo você desenha um círculo, depois um retângulo, uma linha, alguns triângulos, até compor a imagem que você quer. Esse processo é muito similar a escrever uma carta ou livro à mão - é um conjunto de instruções em que se faz uma tarefa depois da outra.
|
||||
|
||||
Shaders também são um conjunto de instruções, mas as instruções são executadas todas de uma vez só para cada pixel na tela. Isso quer dizer que o código que você escreve tem que se comportar de modo diferente dependendo da posição do pixel na tela. Como um tipo na imprensa, seu programa vai funcionar como uma função que recebe uma posição e retorna uma cor, e quando é compilado, vai rodar extraordinariamente rápido.
|
||||
|
||||
|
||||
|
||||
## Por que os shaders são rápidos?
|
||||
|
||||
Para responder isso, eu lhe apresento as maravilhas do *processamento paralelo*.
|
||||
|
||||
Imagine a CPU do seu computador como uma grande esteira ou tubo industrial, e cada tarefa como algo que passa por ela - como uma linha de produção. Algumas tarefas são maiores que outras, o que significa que requerem mais tempo e energia para se lidar com elas. Dizemos assim que elas requerem mais poder de processamento. Por causa da arquitetura dos computadores, os trabalhos são forçados a serem executados em série; cada tarefa tem que ser terminada uma de cada vez. Computadores modernos geralmente têm grupos de quatro processadores que trabalham como essas linhas de produção, completando tarefas uma após a outra para manter as coisas rodando suavemente. Cada esteira é conhecida como *thread*.
|
||||
|
||||
|
||||
|
||||
Videogames e outras aplicações gráficas requerem muito mais poder de processamento que outros programas. Por causa de seu conteúdo gráfico, eles têm que fazer um número gigantesco de operações pixel-a-pixel. Cada pixel na tela precisa ser calculado, e em jogos 3D as geometrias e perspectivas precisam ser calculadas também.
|
||||
|
||||
Vamos voltar à nossa metáfora de tubos e tarefas. Cada pixel na tela representa uma pequena tarefa simples. Individualmente, cada tarefa de pixel não é uma grande questão para a CPU, mas (e esse é o problema) as pequenas tarefas têm que ser feitas em cada pixel na tela. Isso significa, em uma tela antiga em 800x600, que 480.000 pixels têm que ser processados por frame, o que significa 14.400.000 cálculos por segundo! Sim! Isso é um problema grande o suficiente para sobrecarregar um microprocessador. Em uma tela moderna retina 2880x1800, rodando a 60 frames por segundom esse cálculo daria até mais 311.040.000 cálculos por segundo. Como os engenheiros gráficos resolveram esse problema?
|
||||
|
||||
|
||||
|
||||
É aí que o processamento paralelo se torna uma boa solução. Ao invés de ter uma dupla de microprocessadores grandes e poderosos, ou *tubos*, é mais inteligente ter um monte de pequenos microprocessadores rodando em paralelo ao mesmo tempo. É isso que é uma GPU - Unidade de Processamento Gráfico.
|
||||
|
||||
|
||||
|
||||
Imagine os minúsculos processadores como uma mesa de tubos, e os dados de cada pixel como sendo uma bola de ping-pong. 14.400.000 bolas de ping-pong por segundo podem obstruir quase qualquer tubo. Mas uma mesa de 800x600 pequenos tubos recebendo 30 ondas de 480.000 pixels por segundo pode ser manuseado suavemente. Isso funciona do mesmo jeito para resoluções mais altas - quanto mais hardware paralelo você tem, maior o stream que ele pode gerenciar.
|
||||
|
||||
Um outro "super poder" da GPU são funções especiais matemáticas aceleradas via hardware, de modo que operações matemáticas complicadas são resolvidas diretamente pelos microchips ao invés de serem por software. Isso significa operações trigonométricas e de matrix extra rápidas - tanto quanto a eletricidade pode ir.
|
||||
|
||||
## O que é GLSL?
|
||||
|
||||
|
||||
GLSL significa "openGL Shading Language", que é o padrão específico dos programas shader que você vai ver nos próximos capítulos. Existem outros tipos de shaders, dependendo do hardware and Sistema Operacional. Aqui vamos trabalhar com as especificações openGL reguladas pelo [Khronos Group](https://www.khronos.org/opengl/). Entender a história do OpenGL pode ser de muita ajuda para entender a maioria das convenções estranhas que ele tem, e para isso eu recomendo dar uma olhada em: [openglbook.com/chapter-0-preface-what-is-opengl.html](http://openglbook.com/chapter-0-preface-what-is-opengl.html)
|
||||
|
||||
## Por que os shaders são tão dolorosos?
|
||||
|
||||
Como o Tio Ben disse, “com grandes poderes vêm grandes responsabilidades,” e computação paralela segue essa regra; o design arquitetural poderoso da GPU vem com suas restrições e dificuldades.
|
||||
|
||||
Para rodar em paralelo, cada tubo, ou thread, precisa ser independente dos demais. Digamos que as threads são *cegas* para o que o resto das threads está fazendo. Esta restrição implica em que todo o dado deve fluir na mesma direção. Então, é impossível checar o resultado de outra thread, modificar os dados de entrada, ou passar a saída de uma thread para outra. Permitir comunicação entre threads coloca a integridade dos dados em risco.
|
||||
|
||||
|
||||
Além disso, a GPU mantém o microprocessador (os tubos) constantemente ocupado; assim que ficam livres, já recebem nova informação para processar. É impossível para uma thread saber o que ela estava fazendo no momento anterior. Ela poderia estar desenhando um botão da UI do Sistema Operacional, então renderizar uma parte do céu num jogo, e depois mostrar o texto de um email. Cada thread não é apenas **cega** mas também **sem memória**. Além da abstração requerida para codificar uma função geral que muda o resultado pixel a pixel dependendo de sua posição, as restrições de cegueira e falta de memória tornam os shaders pouco populares entre os programadores principiantes.
|
||||
|
||||
Não se preocupe! Nos capítulos seguintes, vamos aprender passo a passo como sair de um nível simples ao avançado nas computações de shaders. Se você está lendo isso com um browser moderno, vai poder brincar com exemplos interativos. Então, não vamos mais demorar com a diversão, e aperte *Próximo >>* para pular para o código!
|
||||
@ -0,0 +1,2 @@
|
||||
# Começando
|
||||
## O que é um shader?
|
||||
@ -0,0 +1,53 @@
|
||||
## Hello World
|
||||
|
||||
Geralmente, o exemplo do "Hello world!" é o primeiro passo para aprender uma nova linguagem. É um programa simples de uma linha, que exibe uma mensagem alegre de boas-vindas.
|
||||
|
||||
No mundo da GPU, renderizar texto é uma tarefa complicada demais para um primeiro passo, então, ao invés, vamos escolher uma cor brilhante para mostrar nosso entusiasmo!
|
||||
|
||||
<div class="codeAndCanvas" data="hello_world.frag"></div>
|
||||
|
||||
Se você está lendo este livro num browser, o bloco de código antetior é interativo. Isso significa que você pode clicar e mudar qualquer pedaço do código que quiser explorar. Mudanças serão atualizadas imediatamente graças à arquitetura da GPU, que compila e substitui os shaders *on the fly*. Faça uma tentativa, mude os valores da linha 6.
|
||||
|
||||
Embora essas simples linhas de código não se pareçam muito, podemos inferir um conhecimento substancial delas:
|
||||
|
||||
1. Shader Language tem uma única função `main` que retorna uma cor no fim. Isso é similar ao C.
|
||||
|
||||
2. A cor final do pixel é associada à variável global reservada `gl_FragColor`.
|
||||
|
||||
3. Essa linguagem, do estilo do C, tem *variáveis* internas já construídas (como `gl_FragColor`), *funções* and *tipos*. Neste caso, acabamos ser apresentados ao `vec4` que é um vetor de quatro dimensões de precisão de ponto flutuante. Mais tarde vamos ver mais tipos como `vec3` e `vec2` juntos com os populares:`float`, `int` e `bool`.
|
||||
|
||||
4. Se olharmos de perto o tipo `vec4` podemos inferir que os quatro argumentos correpondem aos canais RED (vermelho), GREEN (verde), BLUE (azul) e ALPHA. Podemos também ver que esses valores são *normalizados*, o que significa que eles vão de `0.0` a `1.0`. Depois vamos aprender como a normalização faz com que fique mais fácil *mapear* valores entre variáveis.
|
||||
|
||||
5. Outra *característica do C* importante que podemos ver nesse exemplo é a presença de macros de preprocessador. Macros são parte de um passo da pré-compilação. Com elas, é possível definir (`#define`) variáveis globais e fazer algumas operações condicionais básicas (com `#ifdef` e `#endif`). Todos os comandos de macro começam com hashtag (`#`). A pré-compilação acontece logo antes de compilar e copia todas as chamadas a `#defines` e checa as condicionais `#ifdef` (é definido) e `#ifndef` (não é definido). No nosso "hello world!", só inserimos a linha 2 se `GL_ES` estiver definida, o que geralmente acontece quando o código é compilado em dispositivos móveis e browsers.
|
||||
|
||||
6. Tipos float são vitais em shaders, então o nível de *precisão* é crucial. Precisão mais baixa significa renderização mais rápida, ao custo da qualidade. Você pode ser detalhista e especificar a precisão de cada variável que usa ponto flutuante. Na primeira linha (`precision mediump float;`) estamos setando todos os floats para precisão média. Mas podemos escolher setar para baixa precisão (`precision lowp float;`) ou alta (`precision highp float;`).
|
||||
|
||||
7. Por fim, e talvez mais importantem o detalhe é que specs GLSL não garantem que as variáveis serão convertidas automaticamente. O que isso quer dizer? Os fabricantes têm diferentes abordagens para acelerar os gráficos que o cartão processa mas eles são forçados a garantir specs mínimas. Conversão automática não é uma delas. Em nosso exemplo “hello world!” o `vec4` tem precisão de ponto flutuante e para isso, ele espera que seja associado com valores `floats`. Se você quiser fazer um código bom e consistente e não gastar horas debugando telas em branco, acostume-se a colocar o ponto (`.`) em seus floats. Esse tipo de código não vai funcionar sempre:
|
||||
|
||||
```glsl
|
||||
void main() {
|
||||
gl_FragColor = vec4(1,0,0,1); // ERRO
|
||||
}
|
||||
```
|
||||
|
||||
Agora que descrevemos os elementos mais relevantes do nosso programa "hello world!", é hora de clicar no blodo de código e começar a desafiar com tudo o que aprendemos. Você vai notar que em caso de erros, o programa vai falhar a compilação, mostrando uma tela em branco. Existem algumas coisas legais que você pode tentar, por exemplo:
|
||||
|
||||
* Tente substituir os floats com inteiros, sua placa gráfica pode ou não tolerar esse comportamento.
|
||||
|
||||
* tente descomentar a linha 6 e não definir um valor de pixel na função.
|
||||
|
||||
* Tente fazer uma função separada que retorne uma cor específica e use a função dentro do `main()`. Como dica, aqui está o código para uma função que retorna a cor vermelha:
|
||||
|
||||
```glsl
|
||||
vec4 red(){
|
||||
return vec4(1.0,0.0,0.0,1.0);
|
||||
}
|
||||
```
|
||||
|
||||
* Há vários modos de contruit tipos `vec4`, tente descobrir outras formas. O seguinte é uma delas:
|
||||
|
||||
```glsl
|
||||
vec4 color = vec4(vec3(1.0,0.0,1.0),1.0);
|
||||
```
|
||||
|
||||
Embora esse exemplo não seja muito excitante, é o exemplo mais básico - estamos mudando todos os pixels dentro do canvas para exatamente a mesma cor. No próximo capítulo, vamos ver como mudar a cor do pixel usando dois tipos de entrada: espaço (o lugar do pixel na tela) e tempo (o número de segundos desde que a página foi carregada).
|
||||
@ -0,0 +1,61 @@
|
||||
## Uniformes
|
||||
|
||||
Até agora, nós vimos como a GPU gerencia um grande número de threads, cada uma responsável por associar a cor a uma fração da imagem. Embora cada thread paralela seja cega às outras, precisamos conseguir enviar entradas da CPU para todas as threads. Por causa da arquitetura das placas gráficas, essas entradas vão ser iguais (*uniform*) para todas as threads e necessariamente setadas como *read only*. Em outras palavrasm cada thread recebe os mesmos dados que pode ler, mas não pode mudar.
|
||||
|
||||
Essas entradas são chamadas de `uniform` em vêm na maioria dos tipos suportados: `float`, `vec2`, `vec3`, `vec4`, `mat2`, `mat3`, `mat4`, `sampler2D` e `samplerCube`. Uniformes são definidos com o tipo correspondente no topo do shader, logo depois de associar a precisão default.
|
||||
|
||||
```glsl
|
||||
#ifdef GL_ES
|
||||
precision mediump float;
|
||||
#endif
|
||||
|
||||
uniform vec2 u_resolution; // Tamanho do Canvas (width,height)
|
||||
uniform vec2 u_mouse; // posição do mouse em pixels da tela
|
||||
uniform float u_time; // Tempo em segundos desde carregado
|
||||
```
|
||||
|
||||
Você pode imaginar nos uniforms como sendo pequenas pontes entre a CPU e a GPU. Os nomes vão variar de uma implementação para outra, mas nessa série de exemplos eu sempre vou passar `u_time` (tempo em seguntos desde que shader começou), `u_resolution` (tamanho do 'letreiro' onde o shader está sendo desenhado) e `u_mouse` (posição do mouse dentro do letreiro, em pixels). Vou seguir convenção de colocar `u_` antes do nome do uniform para ser explícito sobre a natureza dessa variável, mas você vai encontrar todos os tipos de nomes para os uniformes. Por exemplo [ShaderToy.com](https://www.shadertoy.com/) usa os mesmos uniformes, mas com os seguintes nomes:
|
||||
|
||||
```glsl
|
||||
uniform vec3 iResolution; // resolução da viewport (em pixels)
|
||||
uniform vec4 iMouse; // coordenadas dos pixels do mouse . xy: atual, zw: clique
|
||||
uniform float iTime; // tempo de execução do shader (em segundos)
|
||||
```
|
||||
|
||||
Chega de papo, vamos ver os uniforms em ação. No código a seguir, usamos `u_time` - o número de segundos desde que o shader começou a executar - junto com uma função seno para animar a transição da quantidade de vermelho no letreiro.
|
||||
|
||||
<div class="codeAndCanvas" data="time.frag"></div>
|
||||
|
||||
Como você pode ver, GLSL tem mais surpresas. A GPU tem funções de ângulo, trigonométricas e exponenciais, aceleradas por hardware. Algumas dessas funções são: [`sin()`](../glossary/?search=sin), [`cos()`](../glossary/?search=cos), [`tan()`](../glossary/?search=tan), [`asin()`](../glossary/?search=asin), [`acos()`](../glossary/?search=acos), [`atan()`](../glossary/?search=atan), [`pow()`](../glossary/?search=pow), [`exp()`](../glossary/?search=exp), [`log()`](../glossary/?search=log), [`sqrt()`](../glossary/?search=sqrt), [`abs()`](../glossary/?search=abs), [`sign()`](../glossary/?search=sign), [`floor()`](../glossary/?search=floor), [`ceil()`](../glossary/?search=ceil), [`fract()`](../glossary/?search=fract), [`mod()`](../glossary/?search=mod), [`min()`](../glossary/?search=min), [`max()`](../glossary/?search=max) and [`clamp()`](../glossary/?search=clamp).
|
||||
|
||||
Agora é a hora de brincar de novo com o código acima.
|
||||
|
||||
* Diminua a frequência até que a mudança de cor seja quase imperceptível.
|
||||
|
||||
* Acelere até você ver cada cor sem efeito de flicker.
|
||||
|
||||
* Brinque com os três canais (RGB) em frequências diferentes para conseguir padrões e comportamentos interessantes.
|
||||
|
||||
## gl_FragCoord
|
||||
|
||||
Da mesma forma que a GLSL nos dá um output default, `vec4 gl_FragColor`, ela também nos dá um input default, `vec4 gl_FragCoord`, que contém aos coordenadas na tela do *pixel* ou *fragmento da tela* que a thread ativa está trabalhando. Com `vec4 gl_FragCoord`, sabemos onde uma thread está trabalhando dentro do letreiro. Neste caso, não chamamos de `uniform` porque ela será diferente de uma thread para a outra, então a `gl_FragCoord` é chamada de *variante*.
|
||||
|
||||
<div class="codeAndCanvas" data="space.frag"></div>
|
||||
|
||||
No código acima, nós *normalizamos* a coordenada do fragmento dividindo-a pela resolução total do letreiro. Fazendo isso, os valores ficarão entre `0.0` e `1.0`, o que torna mais fácil mapear os valores X e Y para os canais RED e GREEN.
|
||||
|
||||
Na "shaderlândia", não temos muitos recursos para depurar, além de associar cores fortes a variáveis e tentar fazer um sentido com elas. Você vai descobrir que, às vezes, codificar em GLSL é muito parecido com colocar navios dentro de garrafas. É igualmente difícil, bonito e gratificante.
|
||||
|
||||
|
||||
|
||||
Agora é a hora de tentar e desafiar nosso entendimento desse código.
|
||||
|
||||
* Você pode dizer onde fica a coordenada `(0.0, 0.0)` em nosso canvas?
|
||||
|
||||
* E as coordenadas `(1.0, 0.0)`, `(0.0, 1.0)`, `(0.5, 0.5)` e `(1.0, 1.0)`?
|
||||
|
||||
* Você consegue imaginar como usar `u_mouse` sabendo que os valores são em pixels e NÃO valores normalizados? Você pode usar isso para mover as cores ao redor?
|
||||
|
||||
* Você pode imaginar uma forma interessante de mudar esse padrão de cores usando as coordenadas `u_time` e `u_mouse`?
|
||||
|
||||
Depois de fazer esses exercícios, você poderia pensar em que mais poderia tentar seus novos poderes de shader. No capítulo seguinte, vamos ver como fazer sua própria ferramenta de shader em three.js, Processing, e openFrameworks.
|
||||
@ -0,0 +1,7 @@
|
||||
Aprenda como usar variáveis Uniform. Variáveis uniform, ou simplesmente *uniformes* são as variáveis que carregam informação acessível igualmente de todas as threads do seu shader. O [editor GSLS](http://editor.thebookofshaders.com/) tem três uniformes setados para você.
|
||||
|
||||
```glsl
|
||||
uniform vec2 u_resolution; // Tamanho do canvas (largura,altura)
|
||||
uniform vec2 u_mouse; // posição do mouse em pixels da tela
|
||||
uniform float u_time; // Tempo em segundos desde carregamento
|
||||
```
|
||||
@ -0,0 +1,190 @@
|
||||
## Rodando o seu shader
|
||||
|
||||
Como parte da construção deste livro, e minha prática de arte, eu fiz um ecossistema de ferramentas para criar, exibir e realizar curadoria de shaders. Essas ferramentas trabalham consistentemente em Linux, MacOS, [Raspberry Pi](https://www.raspberrypi.org/) e browsers sem a necessidade de mudar seu código.
|
||||
|
||||
**Exibir**: todos os exemplos ao vivo deste livro são exibidos usando o [glslCanvas](https://github.com/patriciogonzalezvivo/glslCanvas) que faz o processo de executar um shader standalone incrivelmente fácil.
|
||||
|
||||
```html
|
||||
<canvas class="glslCanvas" data-fragment-url=“yourShader.frag" data-textures=“yourInputImage.png” width="500" height="500"></canvas>
|
||||
```
|
||||
|
||||
Como você pode ver, só precisa de um elemento `canvas` com `class="glslCanvas"` e a url para seu shader no `data-fragment-url`. Aprenda mais sobre isso [aqui](https://github.com/patriciogonzalezvivo/glslCanvas).
|
||||
|
||||
Se você é como eum provavelmente vai querer rodar shaders diretamente da console, e nesse caso você deveria dar uma olhada no [glslViewer](https://github.com/patriciogonzalezvivo/glslViewer). Esta aplicação lhe permite incorporar shaders em seus scripts `bash` ou pipelines do unix e usá-los de modo similiar ao [ImageMagick](http://www.imagemagick.org/script/index.php). Também, o [glslViewer](https://github.com/patriciogonzalezvivo/glslViewer) é uma boa forma de compilar shaders no seu [Raspberry Pi](https://www.raspberrypi.org/), razão pela qual o [openFrame.io](http://openframe.io/) o utiliza para exibir artes em shader. Aprenda mais sobre essa aplicação [aqui](https://github.com/patriciogonzalezvivo/glslViewer).
|
||||
|
||||
```bash
|
||||
glslViewer yourShader.frag yourInputImage.png —w 500 -h 500 -s 1 -o yourOutputImage.png
|
||||
```
|
||||
|
||||
**Criar**: de modo a trazer mais luz para a experiência de codificação de shaders, eu fiz um editor online chamado [glslEditor](https://github.com/patriciogonzalezvivo/glslEditor). Este editor está embutido nos exemplos ao vivo do livro, e traz uma série de widgets bem convenientes para tornar mais tangível a experiência abstrata de trabalhar com código GLSL. Você também pode executá-lo como uma aplicação web standalone no endereço [editor.thebookofshaders.com/](http://editor.thebookofshaders.com/). Saiba mais sobre isso [aqui](https://github.com/patriciogonzalezvivo/glslEditor).
|
||||
|
||||
|
||||
|
||||
Se você prefere trabalhar offline usando o [SublimeText](https://www.sublimetext.com/) você pode instalar esse [pacote para glslViewer](https://packagecontrol.io/packages/glslViewer). Saiba mais sobre isso [aqui](https://github.com/patriciogonzalezvivo/sublime-glslViewer).
|
||||
|
||||
|
||||
|
||||
**Compartilhar**: o editor online ([editor.thebookofshaders.com/](http://editor.thebookofshaders.com/)) pode compartilhar seus shaders! Tanto a versão embedded quanto standalone têm um botão para exportar, onde você pode obter uma URL única para o seu shader. Eles têm também a capacidade de exportar diretamente para um [openFrame.io](http://openframe.io/).
|
||||
|
||||
|
||||
|
||||
**Curadoria**: Compartilhar o seu código é o começo para você compartilhar seus shaders como artwork! Além da opção de exportar para [openFrame.io](http://openframe.io/) eu fiz uma ferramenta para lhe permitir criar uam curadoria de seus shaders numa galeria que pode ser embutida em qualquer site, e seu nome é [glslGallery](https://github.com/patriciogonzalezvivo/glslGallery). Saiba mais [aqui](https://github.com/patriciogonzalezvivo/glslGallery).
|
||||
|
||||
|
||||
|
||||
## Rodando seus shaders em seu framework favorito
|
||||
|
||||
Para o caso de você já ter experiência em programar em um framework como [Processing](https://processing.org/), [Three.js](http://threejs.org/) ou [OpenFrameworks](http://openframeworks.cc/), você provavelmente está animado para tentar os shaders nessas plataformas que você se sente confortável. Os exemplos a seguir são formas de como configurar os shaders em alguns frameworks populares com os mesmos uniforms que vamos usar ao longo desse livro. (No [Repositório GitHub para esse capítulo](https://github.com/patriciogonzalezvivo/thebookofshaders/tree/master/04), você encontra o código completo para esses três frameworks.)
|
||||
|
||||
### Em **Three.js**
|
||||
|
||||
O brillhante e humilde Ricardo Cabello (aka [MrDoob](https://twitter.com/mrdoob) ) tem desenvolvido com outros [contribuidores](https://github.com/mrdoob/three.js/graphs/contributors) o que é provavelmente um dos mais famosos frameworks para WebGL, chamado de [Three.js](http://threejs.org/). Você vai encontrar muitos exemplos, tutoriais e livros que ensinam a usar essa biblioteca em JavaScript para fazer gráficos 3D muito legais.
|
||||
|
||||
Abaixo, um exemplo do HTML e JS que você precisa para começar com shaders em three.js. Preste atenção ao script `id="fragmentShader"`, é aqui que você pode copiar os shaders que encontrar neste livro.
|
||||
|
||||
```html
|
||||
<body>
|
||||
<div id="container"></div>
|
||||
<script src="js/three.min.js"></script>
|
||||
<script id="vertexShader" type="x-shader/x-vertex">
|
||||
void main() {
|
||||
gl_Position = vec4( position, 1.0 );
|
||||
}
|
||||
</script>
|
||||
<script id="fragmentShader" type="x-shader/x-fragment">
|
||||
uniform vec2 u_resolution;
|
||||
uniform float u_time;
|
||||
|
||||
void main() {
|
||||
vec2 st = gl_FragCoord.xy/u_resolution.xy;
|
||||
gl_FragColor=vec4(st.x,st.y,0.0,1.0);
|
||||
}
|
||||
</script>
|
||||
<script>
|
||||
var container;
|
||||
var camera, scene, renderer;
|
||||
var uniforms;
|
||||
|
||||
init();
|
||||
animate();
|
||||
|
||||
function init() {
|
||||
container = document.getElementById( 'container' );
|
||||
|
||||
camera = new THREE.Camera();
|
||||
camera.position.z = 1;
|
||||
|
||||
scene = new THREE.Scene();
|
||||
|
||||
var geometry = new THREE.PlaneBufferGeometry( 2, 2 );
|
||||
|
||||
uniforms = {
|
||||
u_time: { type: "f", value: 1.0 },
|
||||
u_resolution: { type: "v2", value: new THREE.Vector2() },
|
||||
u_mouse: { type: "v2", value: new THREE.Vector2() }
|
||||
};
|
||||
|
||||
var material = new THREE.ShaderMaterial( {
|
||||
uniforms: uniforms,
|
||||
vertexShader: document.getElementById( 'vertexShader' ).textContent,
|
||||
fragmentShader: document.getElementById( 'fragmentShader' ).textContent
|
||||
} );
|
||||
|
||||
var mesh = new THREE.Mesh( geometry, material );
|
||||
scene.add( mesh );
|
||||
|
||||
renderer = new THREE.WebGLRenderer();
|
||||
renderer.setPixelRatio( window.devicePixelRatio );
|
||||
|
||||
container.appendChild( renderer.domElement );
|
||||
|
||||
onWindowResize();
|
||||
window.addEventListener( 'resize', onWindowResize, false );
|
||||
|
||||
document.onmousemove = function(e){
|
||||
uniforms.u_mouse.value.x = e.pageX
|
||||
uniforms.u_mouse.value.y = e.pageY
|
||||
}
|
||||
}
|
||||
|
||||
function onWindowResize( event ) {
|
||||
renderer.setSize( window.innerWidth, window.innerHeight );
|
||||
uniforms.u_resolution.value.x = renderer.domElement.width;
|
||||
uniforms.u_resolution.value.y = renderer.domElement.height;
|
||||
}
|
||||
|
||||
function animate() {
|
||||
requestAnimationFrame( animate );
|
||||
render();
|
||||
}
|
||||
|
||||
function render() {
|
||||
uniforms.u_time.value += 0.05;
|
||||
renderer.render( scene, camera );
|
||||
}
|
||||
</script>
|
||||
</body>
|
||||
```
|
||||
|
||||
### Em **Processing**
|
||||
|
||||
Iniciado por [Ben Fry](http://benfry.com/) e [Casey Reas](http://reas.com/) em 2001, o [Processing](https://processing.org/) é um ambiente extraordinariamente simples e poderoso para você dar seus primeiros passos no código (pelo menos, pra mim, foi). [Andres Colubri](https://codeanticode.wordpress.com/) tem feito atualizações importantes no openGL e video em Processing, facilitando ainda mais que nunca o uso e diversão com shaders GLSL nesse ambiente amigável. O Processing vai procurar pelo shader chamado `"shader.frag"` na pasta `data`. Tenha certeza de copiar os exemplos que encontrar aqui para essa pasta, e renomear o arquivo.
|
||||
|
||||
```cpp
|
||||
PShader shader;
|
||||
|
||||
void setup() {
|
||||
size(640, 360, P2D);
|
||||
noStroke();
|
||||
|
||||
shader = loadShader("shader.frag");
|
||||
}
|
||||
|
||||
void draw() {
|
||||
shader.set("u_resolution", float(width), float(height));
|
||||
shader.set("u_mouse", float(mouseX), float(mouseY));
|
||||
shader.set("u_time", millis() / 1000.0);
|
||||
shader(shader);
|
||||
rect(0,0,width,height);
|
||||
}
|
||||
```
|
||||
|
||||
De modo a fazer o shader funcionar em versões anteriores à 2.1, você precisa de adicionar a seguinte linha no começo de seu shader: `#define PROCESSING_COLOR_SHADER`. De modo que se pareça com isso:
|
||||
|
||||
```glsl
|
||||
#ifdef GL_ES
|
||||
precision mediump float;
|
||||
#endif
|
||||
|
||||
#define PROCESSING_COLOR_SHADER
|
||||
|
||||
uniform vec2 u_resolution;
|
||||
uniform vec3 u_mouse;
|
||||
uniform float u_time;
|
||||
|
||||
void main() {
|
||||
vec2 st = gl_FragCoord.st/u_resolution;
|
||||
gl_FragColor = vec4(st.x,st.y,0.0,1.0);
|
||||
}
|
||||
```
|
||||
|
||||
Para mais informações sobre os shaders no Processing veja esse [tutorial](https://processing.org/tutorials/pshader/).
|
||||
|
||||
### No **openFrameworks**
|
||||
|
||||
Todo mundo tem um lugar onde se sente confortável, e no meu caso, ainda é a [comunidade openFrameworks](http://openframeworks.cc/). Esse framework C++ envolve o OpenGL e outras bibliotecas opensource C++. De muitas formas, é bem parecida com o Processing, mas com as complicações óbvias de se lidar com compiladores C++. Da mesma forma que o Processing, openFrameworks vai procurar o seu shader no diretório data, então não se esqueça de copiar os arquivos `.frag` que quiser usar, e mudar o nome quando for carregar.
|
||||
|
||||
```cpp
|
||||
void ofApp::draw(){
|
||||
ofShader shader;
|
||||
shader.load("","shader.frag");
|
||||
|
||||
shader.begin();
|
||||
shader.setUniform1f("u_time", ofGetElapsedTimef());
|
||||
shader.setUniform2f("u_resolution", ofGetWidth(), ofGetHeight());
|
||||
ofRect(0,0,ofGetWidth(), ofGetHeight());
|
||||
shader.end();
|
||||
}
|
||||
```
|
||||
|
||||
Para mais informações sobre shaders em openFrameworks, vá nesse [excelente tutorial](http://openframeworks.cc/ofBook/chapters/shaders.html) feito por [Joshua Noble](http://thefactoryfactory.com/).
|
||||
@ -0,0 +1 @@
|
||||
## Rodando o seu shader
|
||||
Loading…
Reference in New Issue