Portuguese version. intro to chapter 4.

00/README-pt.md

@@ -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.
+
+![Gutenberg's press](gutenpress.jpg)
+
+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.
+
+![Journey by That Game Company](journey.jpg)
+
+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.

00/TITLE-pt.md

@@ -0,0 +1 @@
+# Introdução

01/README-pt.md

@@ -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?
+
+![From Letter-by-Letter, Right: William Blades (1891). To Page-by-page, Left: Rolt-Wheeler (1920).](print.png)
+
+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.
+
+![Chinese movable type](typepress.jpg)
+
+## 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*.
+
+![CPU](00.jpeg)
+
+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?
+
+![](03.jpeg)
+
+É 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.
+
+![GPU](04.jpeg)
+
+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!

01/TITLE-pt.md

@@ -0,0 +1,2 @@
+# Começando
+## O que é um shader?

02/README-pt.md

@@ -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).