renderização fora da tela para um objeto buffer de tela fora da tela deve ser tão trivial, mas estou tendo um problema que não consigo entende

Meu programa de amostra completo (apenas 2D por enquanto!) Está aqui:

http: //pastebin.com/hSvXzhJ

Veja abaixo algumas descriçõe

Estou criando um objeto de textura rgba 512x512, vincule-o a um FBO. Nenhuma profundidade ou outros buffers de renderização são necessários neste momento, estritamente em 2

Os seguintes shaders extremamente simples são renderizados para esta textura:

Vertex shader:

varying vec2 vPos; attribute vec2 aPos;
void main (void) {
    vPos = (aPos + 1) / 2;
    gl_Position = vec4(aPos, 0.0, 1.0);
}

No aPos isso apenas obtém um VBO contendo 4 cordas xy para um quad (-1, -1 :: 1, -1 :: 1, 1 :: -1, 1)

Embora a resolução do buffer de quadros deva, teoricamente, 512x512, obviamente, o sombreador renderiza sua "textura" em um "quad de tela cheia (fora))", seguindo o paradigma das cordas GLs -1..

Fragment shader:

varying vec2 vPos;
void main (void) {
    gl_FragColor = vec4(0.25, vPos, 1);
}

Por isso, define uma cor totalmente opaca com vermelho fixado em 0,25 e verde / azul, dependendo de x / y em qualquer lugar entre 0 e 1.

Neste ponto, suponho que uma textura de 512x512 seja renderizada mostrando apenas o quadrilátero -1..1 full- (off), sombreado por fragmentos para verde / azul de 0.

Portanto, esta é a minha configuração fora da tela. Na tela, tenho outro quad real visível em tela cheia com 4 cordas xyz {-1, -1, 1 ::: 1, -1, 1 ::: 1, 1, 1 ::: -1, 1, 1}. Novamente, por enquanto isso é 2D, então não há matrizes e então z é sempre 1.

Este quad é desenhado por um shader diferente, renderizando simplesmente uma dada textura, estilo GL-101 de livro-texto. No meu programa de amostra vinculado acima, tenho uma simples alternância booleana doRtt, quando isso é falso (o padrão), a renderização para textura não é executada e esse sombreador simplesmente mostra o arquivo texture.jpg do diretório atua

This doRtt = false mode mostra que o segundo quad-renderizador na tela está "correto" para os meus requisitos atuais e executa a texturização como eu quero: repetido duas vezes na vertical e duas na horizontal (mais tarde será fixado, a repetição é apenas para aqui), caso contrário, será dimensionado sem filtro de textura ou mipmappin

Portanto, não importa como a janela (e, portanto, a porta de exibição) é redimensionada, sempre vemos um quad em tela cheia com uma única textura repetida duas vezes na horizontal, duas vezes na vertica

Agora, com doRtt = true, o segundo shader ainda faz seu trabalho, mas a textura nunca é totalmente dimensionada corretamente - ou desenhada, isso não tenho certeza, pois infelizmente não podemos apenas dizer "ei, gl salvar esse FBO em disco para fins de depuração ".

O RTT shader realiza algumas renderizações parciais (ou talvez uma completa, novamente não pode ter certeza do que está acontecendo fora da tela ...) Especialmente quando você redimensiona a viewport muito menor que o tamanho padrão que você vê nas quebras entre as repetições de textura, e nem todas as cores esperadas do nosso simples shader de fragmento RTT são realmente mostrada

(A): a textura de 512x512 é criada corretamente, mas não é mapeada corretamente pelo meu código (mas por que, com doRtt = false, qualquer arquivo texture.jpg usando o exato mesmo quad-shader texturizado simples que mostra muito bem

(B) ou: a textura de 512x512 não é renderizada corretamente e, de alguma forma, o rtt frag shader altera sua saída dependendo da resolução da janela - mas por quê? O quad fora da tela está sempre em -1..1 para x e y, o sombreador de vértice sempre mapeia isso para as cordas de fragmento 0..1, a textura RTT sempre fica em 512x512 para este teste simple

ota: AMBOS o quad fora da tela E o quad na tela nunca alteram suas cordas e sempre são "tela cheia" (-1..1 em ambas as dimensões

Novamente, isso deve ser tão simples. O que diabos estou perdendo?

Specs: OpenGL 4.2 (mas o código não precisa de nenhum recurso 4.2, obviamente!), Nvidia Quadro 5010M, openSuse 12.1 64bit, Golang Weekly, 22 de fevereiro de 201