Rendering to a texture

Well there's several ways to do it in OpenGL. One is via PBuffers which is currently the fastest way to do it, another couple of ways are using glReadPixels to get a copy of the framebuffer pixels and then using glTexImage to create a texture from them (this will be horribly slow) and then there's glCopyTexImage and glCopyTexSubImage which copy an image from the framebuffer into a texture for you. This PDF may be of some use to you.

There's also a new extension which I can't remember the name of ATM and can't find in the registry which is meant to make all of this a whole lot easier but IIRC it's not actually implemented by anyone yet.

Quote:

There's also a new extension which I can't remember the name of ATM and can't find in the registry which is meant to make all of this a whole lot easier but IIRC it's not actually implemented by anyone yet.

Superbuffers?

Quote:

Original post by tool_2046 Quote: There's also a new extension which I can't remember the name of ATM and can't find in the registry which is meant to make all of this a whole lot easier but IIRC it's not actually implemented by anyone yet. Superbuffers?

No, framebuffer_object.

Quote:

Original post by Monder Well there's several ways to do it in OpenGL. One is via PBuffers which is currently the fastest way to do it, another couple of ways are using glReadPixels to get a copy of the framebuffer pixels and then using glTexImage to create a texture from them (this will be horribly slow) and then there's glCopyTexImage and glCopyTexSubImage which copy an image from the framebuffer into a texture for you. This PDF may be of some use to you.

Slight correction, in my own tests I've found that using a pbuffer is infact SLOWER than doing a glCopyTexSubImage from the frame buffer. This is due to the context switches needed when going from the frame buffer to the pbuffer and back (which arent cheap).
Granted, if you need a texture large than the frame buffer than you've no choice in the matter, currently pbuffers is the only way forward (soon to be replaced by the framebuffer_object extension ofcourse), but if you can get away with the same size or smaller than the current framebuffer than copying should be faster.

Quote:

Slight correction, in my own tests I've found that using a pbuffer is infact SLOWER than doing a glCopyTexSubImage from the frame buffer.

Fair enough, I was just going off what the NVidia PDF I linked to said and actually looking at it again it just says PBuffers are potentially optimal.

barakus: If the framebuffer_object extension is not available I'd use glCopyTexSubImage it should be easier to use than PBuffers (which can be a bit of a pain to setup/use) and acording to _the_phantom_ faster.

Quote:

Original post by _the_phantom_ Slight correction, in my own tests I've found that using a pbuffer is infact SLOWER than doing a glCopyTexSubImage from the frame buffer. This is due to the context switches needed when going from the frame buffer to the pbuffer and back (which arent cheap).

Well, it depends on the amount of data we're talking about. There is a breakeven point: the copy gets slower, as the copied data area grows, while the context switch overhead is pretty much constant. Also, the bandwidth for the copy can hinder other parallel accesses to the framebuffer memory, and can create annoying sync issues. So, in practice, one should test this for each specific case.

It's getting time for FBO driver support, which will solve all these issues.

ah yes, good points indeed, I probably should have said it was just with simple shadow mapping/reflection test code I'd noticed this, I dare say with more load thinigs might well change.

There is already a leaked driver with alpha support for NV hardware out there, there is a thread about it over on opengl.org where people have reported varying degrees of sucess with it.
ATI's next driver release should be in about 2 weeks time (however they caught everyone out with an early release this month so maybe sooner), which works for me as I should definately have my X800XT PE by then [grin]

Quote:

Original post by _the_phantom_ There is already a leaked driver with alpha support for NV hardware out there, there is a thread about it over on opengl.org where people have reported varying degrees of sucess with it.

I'm afraid of installing this leaked thing onto my dev machine, from the posts on opengl.org, it looks a little too beta for my taste... I guess, I'll wait a couple of weeks more for the next official release. I've already coded the FBO path into my engine from the specs, now I need a more or less reliable driver to test them out.

thanks for the help guys.
Ill try to put these methods into use.

Quote:

Original post by Yann L ... I've already coded the FBO path into my engine from the specs, now I need a more or less reliable driver to test them out.

God Damn. this guy never ceases to amaze me.

welcome back (again) Yann :)