PDA

View Full Version : Render to texture, without FBO



JoshKlint
03-29-2011, 11:41 PM
I have an Intel GMA 3150 I am testing on that only supports OpenGL 1.4. I don't see the framebufferobject extension in the extensions string.

Is there any other alternative to allow rendering to a texture? I don't care if it's slow, but it needs to be reliable on all cards. Is the pixel buffer thing usable? I have always used FBO in the past.

mfort
03-30-2011, 12:31 AM
You can use old PBuffer (see WGL_ARB_pbuffer) and then copy the content to the texture with glCopyTexSubImage2D.

NVIDIA even has an extension to render directly to texture without FBO. It is called WGL_ARB_render_texture but I doubt this is supported by Intel.

Alfonse Reinheart
03-30-2011, 01:24 AM
NVIDIA even has an extension to render directly to texture without FBO. It is called WGL_ARB_render_texture but I doubt this is supported by Intel.

As the name suggests, it's not an NVIDIA-specific extension. But it is a really horrible extension to actually use. Avoid it under any circumstances; it's better to just copy the pixel data.

dukey
03-30-2011, 03:29 AM
just render to the back buffer then do glCopyTexSubImage2D
done !

BionicBytes
03-30-2011, 08:06 AM
just render to the back buffer then do glCopyTexSubImage2D
done !
...remebering to set the view port size to the size of your texture (which can't be larger than your backbuffer dimensions)

mfort
03-30-2011, 10:27 AM
it is a really horrible extension to actually use. Avoid it under any circumstances;.
I was using it before FBO with no major issues. Back then it was the only way. There is also NV specific extension for rectangle texture that works well.

mhagain
03-30-2011, 11:37 AM
just render to the back buffer then do glCopyTexSubImage2D
done !
...remebering to set the view port size to the size of your texture (which can't be larger than your backbuffer dimensions)
Your texture actually can be larger and you can glCopyTexSubImage2D to a portion of it; it works Just Fine, is very fast, and is probably eminently suitable for simpler use cases.

Alfonse Reinheart
03-30-2011, 12:53 PM
I was using it before FBO with no major issues.

That doesn't mean it isn't a terrible extension. It "functioned", but that doesn't mean that the extension isn't unintuitive.

V-man
03-30-2011, 03:31 PM
Intel should implement GL_EXT_framebuffer_object. It is simpler than that p-buffer mess.
p-buffer + rendertexture is an even bigger mess.
And all the other crap extensions around p-buffers.

You would get better performance with glCopyTexSubImage2D than p-buffer which is essentially a context switch.

JoshKlint
03-30-2011, 03:39 PM
If pixel buffers are reliable, I don't care how hard it is to code. Performance is also irrelevant.

Rendering to the back buffer is not an option because my engine API states that my "buffers" are separate rendering targets that do not interfere with the back buffer.

ZbuffeR
03-31-2011, 01:03 AM
About old pbuffers, the most annoying is the OS-dependant code needed, that limits the cross-platform aspect. But it is better than backbuffer if you have no other choice.

Even using only the backbuffer, you can still 'state' buffers are separate, before doing clean then actual rendering to the backbuffer.

mhagain
03-31-2011, 03:30 AM
These Intels actually do support RTT under D3D so the hardware is certainly capable. I suspect that the problem may be that GL_EXT_framebuffer_object includes glGenerateMipmap, which Intel have historically seemed to have difficulties with (in D3D as well as OpenGL).

JoshKlint
03-31-2011, 11:22 AM
I need users to be able to render to the back buffer and any other buffers, in any order.

For example, this could cause a problem:
-render to back buffer
-render to other buffer
-swap back buffer

I suppose I could copy the back buffer to a temp texture, render to the back buffer, copy the back buffer to the target texture, then copy back from the temp texture to the back buffer.