RTT-chain with frame buffer objects

Started by
1 comment, last by bmies 16 years, 2 months ago
Hi, i have a stack with ~8-20 textures that has to be updated all x frames and where every texture is updated in dependency of its parent. At the moment i'm creating the first texture on the cpu and using a fbo for each remaining texture. Within the update-process, a fragmentshader is sampling the first texture and rendering to the second one (attached to the first fbo). Then i use for the same program this texture as source and render to the next texture, attaced to the second fbo and so on, going through all textures. I'm getting strange behaviours depending on the number of textures (artefacts, blinking fragments...), so i'm not sure if the basic update-cycle is correct: (The fbos are tested and working each for itself)

createTexture0;
renderLoop
{
	if(update)
	{
		fbo0.renderToTexture(in tex0, out tex1)
		fbo1.renderToTexture(in tex1, out tex2)
		...
		fboN.renderToTexture(in texN-1, out texN)
	}

	normal rendering (using the textures)

	swapBuffer();
}

renderToTextureN( in texIn, out texOut )
{
	bindFramebuffer( this )
	{
		bindPrograms
		bindTexture
		renderToTexture
	}
	bindFramebuffer( 0 )
}

I'm not sure if its valid to use a texture, modified by a fbo as sampler for another fbo within the same render-cycle? Beside this problem: would it be more reasonable using a few fbos with as many textures attached to them as possible (6 attachments available on my system)?
Advertisement
It's possible todo it with a single FBO; it just involves removing and adding textures as required, which less expensive than swapping FBOs but not as cheap as swapping targets.

As for your problem, it should all work fine, the only time you are likely to get undefined behaviour is when trying to use the same texture as source and destination at the same time.
thank you. i will change it to a single fbo and hunt down the bug.

This topic is closed to new replies.

Advertisement