multipass rendering at real-time rates impossible without framebuffer object?

[CousinGilgamesh]

If you're coding for something older than OpenGL 2.0, you can't render directly to a texture. If you want to come in for a second pass and do fragment program post-image processing, like bloom or depth of field, you have to copy the information from the back buffer over into a texture using glCopyTexImage2D in order to apply it to the screen-size quad for the second pass. This function is really expensive, and slows down my very simple shader testing program to below real-time, which makes it useless in my game.

I know with newer machines you can make use of a Frame Buffer Object (I think it's called render target in DirectX), which allows you to render to your texture directly eliminating the need for copying the buffers, and I think this is how newer games achieve these effects real-time. I was really hoping I could keep compatibility all the way back to OpenGL 1.4 machines, in part because my '07 macbook only supports up to OpenGl 1.4, and development would be tough if I couldn't use my laptop.

So here are my questions.

-is there another way to do fast multipass rendering that would be compatible for OpenGL 1.4 machines? I'm guessing that I'm just dreaming and I'll have to either up the hardware requirements or give up those effects.

-from a consumer standpoint, do I lock out a lot of potential customers by requiring at least OpenGL 2.0?

[lightassassin]

I'm not sure of the solution (as I'm currently facing the same issue). But as for the market that uses what, the netbook I own with intergrated intel graphics only supports upto opengl 1.5 and from what I've seen this is the level one can expect to be supported in most intergrated chips, or only as high as 2.0 from intel.

Hope you find something, and if I figure something out I'll let you know. Otherwise I'm just going to try optimize what I have and cut it down (beats not supporting people I guess).

[vjvj]

You can accomplish the same thing with pbuffers, which were introduced to OpenGL much earlier (I can't remember which version, though). The API is a lot more convoluted than it is for FBOs, though, and you have to be careful about the expensive context switch when switching back and forth between render targets. But for pre-2.0 GL, they are your only option AFAIK.

[PoV]

I actually ran in to a case where an OpenGL ES 2.0 driver said it supported FBOs (Samsung FIMG-3DSE v1.5), but didn't at all. It seems PBuffers are also part of the EGL spec, so I was at least able to use those to get the same effect. It was a bit of a hassle as I had to recompile my shaders for both contexts.

[CousinGilgamesh]

Originally Posted by vjvj

You can accomplish the same thing with pbuffers, which were introduced to OpenGL much earlier (I can't remember which version, though).

So Wikipedia says GL_ARB_pixel_buffer_object isn't introduced until OpenGL 2.1, but the ARB_pixel_buffer_object extension reads OK on the glewinfo for my crappy integrated gpu, and the extension's official spec makes it look like it should work in many pre 2.0 machines. This looks like a good place to start. I'll report back if I get it to work. Thanks Vjvj!

[lightassassin]

I believe the pbuffers he was speaking of is WGL_ARB_pbuffer which turned up in ogl 1.2 I think. Edit: Sorry forgot you were using mac, you might look at GL_APPLE_PIXEL_BUFFER it would prob suit you better. Unfortunately it means different extensions for each os.

Hope this helps you, either way I intend on supporting 1.4 as a min for my games, mostly because I know a lot of teenagers now sport their Netbooks for schooling reasons, and I remember when I was a kid this is excatly how I got access to a PC at school.

Let me know how you get on with it =)

[CousinGilgamesh]

Originally Posted by lightassassin

I believe the pbuffers he was speaking of is WGL_ARB_pbuffer which turned up in ogl 1.2 I think. Edit: Sorry forgot you were using mac, you might look at GL_APPLE_PIXEL_BUFFER it would prob suit you better. Unfortunately it means different extensions for each os.

Yeah, I am using a mac, but I'm going for multiplatform support, hopefully with linux too (I actually dev on a vista boot on my mac). So far I've been using glut and only standard OpenGL 1.4 to keep it totally portable and compatible. I guess as long as there's an extension for each platform, I can keep it portable, it'll just be more of a pain than having an all-encompassing arb extension that works on all platforms.

So will it be a problem that I'm using glut instead of wgl when I need to use WGL extensions?

[vjvj]

Originally Posted by lightassassin

Edit: Sorry forgot you were using mac, you might look at GL_APPLE_PIXEL_BUFFER it would prob suit you better. Unfortunately it means different extensions for each os.

Doh, I also missed that part about him using a Mac. Thanks for getting the extension right!

So will it be a problem that I'm using glut instead of wgl when I need to use WGL extensions?

I think Glut just uses WGL internally, so I don't think it should be a problem. That said, I'm not a big fan of Glut and would recommend something like SDL or GLFW, instead (we use SDL).

Also, for dealing with extension queries, I'd look into GLEW or GLEE to simplify this. I use GLEW, but Applewood recommends GLEE for its simplicity and I intend to try it out when I have a chance.

Let us know how it goes!

[CousinGilgamesh]

Originally Posted by vjvj

I think Glut just uses WGL internally, so I don't think it should be a problem. That said, I'm not a big fan of Glut and would recommend something like SDL or GLFW, instead (we use SDL).

Wow SDL looks pretty cool. I basically just use glut because it was used in all the examples in the red book when I was learning OpenGL. I was sort of aware that there were other options, but never really bothered to check it out. It looks like SDL just does so much more.

[PoV]

Originally Posted by vjvj

Applewood recommends GLEE for its simplicity and I intend to try it out when I have a chance.

From what I saw, GLEW is also extremely out of date. GLEE has treated me well.

[CousinGilgamesh]

So as an update, in order to create a pbuffer using the wgl extension, you need a handle to the device context, which of course you'd have if you were using wgl. But the whole point of glut is that it abstracts you from platform-specific concepts, like device contexts. You can't get an HDC through glut, but you can call GetDC() if you have a handle to window. You can get the topmost window's handle by calling GetForegroundWindow(), but what about if you're in fullscreen mode? I seem to remember reading somewhere that if you pass NULL to GetDC, it'll just return you the HDC of the screen. Maybe that'll work. Anyway, it's a total hack, but it still might be possible.

I guess this is what I get for using glut. I wonder if there would be the same problem in SDL.

Anyway, I'll update if I make any progress.

[vjvj]

Originally Posted by CousinGilgamesh

So as an update, in order to create a pbuffer using the wgl extension, you need a handle to the device context, which of course you'd have if you were using wgl. But the whole point of glut is that it abstracts you from platform-specific concepts, like device contexts. You can't get an HDC through glut, but you can call GetDC() if you have a handle to window. You can get the topmost window's handle by calling GetForegroundWindow(), but what about if you're in fullscreen mode? I seem to remember reading somewhere that if you pass NULL to GetDC, it'll just return you the HDC of the screen. Maybe that'll work. Anyway, it's a total hack, but it still might be possible.

I guess this is what I get for using glut. I wonder if there would be the same problem in SDL.

Anyway, I'll update if I make any progress.

Yeah, the reliance on platform-specific window systems is one of the many problems with pbuffers that was addressed in the FBO spec.

In SDL you get around this problem with SDL_GetWMInfo(), which returns a platform-specific structure with all the info you need. There might be a pbuffer demo out there that uses Glut, though... I haven't looked

[PoV]

Originally Posted by vjvj

In SDL you get around this problem with SDL_GetWMInfo(), which returns a platform-specific structure with all the info you need.

Oh neat. I'll definitely have to check that out too.

[CousinGilgamesh]

Originally Posted by vjvj

In SDL you get around this problem with SDL_GetWMInfo(), which returns a platform-specific structure with all the info you need. There might be a pbuffer demo out there that uses Glut, though... I haven't looked

Well, it's looking more and more like it'll be worthwhile to go back and replace glut with SDL in my program. I think my glut code is localized enough that it won't be totally impossible. I think I could use the windows or wgl functions to get an HDC, but mixing API's and going behind glut's back both sound pretty sticky. With SDL, you can do it all in the same package.

[vjvj]

Originally Posted by CousinGilgamesh

Well, it's looking more and more like it'll be worthwhile to go back and replace glut with SDL in my program. I think my glut code is localized enough that it won't be totally impossible. I think I could use the windows or wgl functions to get an HDC, but mixing API's and going behind glut's back both sound pretty sticky. With SDL, you can do it all in the same package.

Yeah, SDL is pretty thin itself, so hopefully it won't get too ugly.

Here's the reference page for the WMInfo struct. I'm not sure how Mac OS fits into that... But you can see the Windows struct has the HWND and RC available...

http://www.libsdl.org/cgi/docwiki.cgi/SDL_SysWMInfo

[CousinGilgamesh]

So as a follow up, just in case anyone is interested, I've found that in order to render to a pbuffer and apply it as a texture for a second pass without changing contexts, you need your gpu to support two extensions, WGL_ARB_pbuffer and WGL_ARB_render_texture. I glewinfo'd a bunch of machines to see how widely these extensions are supported. I found that although WGL_ARB_pbuffer was supported on pretty much every machine I tested, not a single integrated-gpu machine I tried supported WGL_ARB_render_texture. This includes both a 2.5 year old macbook and a very new netbook. I ultimately decided that the multipass shader effects I wanted to do weren't worth the sacrificed compatibility, and If I was willing to sacrifice compatibility, the whole thing would probably be easier using FBO's instead. So there you have it.