Hardware overlay plane on 6800DDL?

• Subject: Hardware overlay plane on 6800DDL?
• From: Shah Mozumder <email@hidden>
• Date: Wed, 24 Nov 2004 09:49:01 -0500
• Delivered-to: email@hidden
• Delivered-to: email@hidden

-bobby

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/mac-opengl/email@hidden

• Follow-Ups:
  • Re: Hardware overlay plane on 6800DDL?
    • From: "Andrew P. Lentvorski, Jr." <email@hidden>
  • Re: Hardware overlay plane on 6800DDL?
    • From: Glenn Anderson <email@hidden>

• Prev by Date: Re: Multi-context rendering On Nov 24, 2004, at 12:31 AM, James Milne wrote: On Tuesday, November 23, 2004, at 10:58PM, Nicholas Francis <email@hidden> wrote: A quick question: Is it possible to share the depth buffer between 2 drawables, where one is on-screen and one is offscreen? To elaborate: ------------------ I'm looking at a profile of our upcoming game, GooBall, and a glTexSubImage is literally jumping out at me. We use it for refraction through a glass sphere along these lines: Set up render-to-texture Render Scene. do a copyTexSubImage around the ball. Render ball with the texture copied above to fake refraction Set up rendering to screen. Post-process texture to main screen. We're already rendering to a texture & putting that on screen with various post-processing FX applied. What I would like to do would be something along these lines: Set up render-to-texture Render Scene Set up rendering to screen. Post-process texture to main screen. Render ball with texture generated above This would effectively eliminate my glCopyTexSubImage, but gives me one problem: when rendering to the main screen, I don't have the Z buffer from the actual scene, hence the ball would appear in front of any geometry that might be between the camera & the ball. I can live with the geometry getting refracted incorrectly (as it does in the current scheme), but I cannot separate the geometry between the ball and the camera. Any ideas? This is a tricky one. In DirectX, you can specify the depth buffer as a separate render target, and you can share it between offscreen colour render targets, and your on-screen render target. Unfortunately, the OpenGL APIs give us no way to specify a 'depth-stencil-only' pbuffer that could be attached to a context alongside a colour pbuffer. Yeah - I've been reading up on the frustrations ppl. are having over this on the OpenGL message board. Never thought I'd need it - just goes to show. Rather than do a glCopyTexSubImage, you could create another offscreen buffer to help your glass ball rendering. Nice - I can definately see that being potentially faster. I'd do this: - create two offscreen pbuffers of the same size - render your world into buffer 1 - render buffer 1 into the main buffer with your post-processing effects, etc. - switch to buffer 2, and using buffer 1 as the texture source (using aglBindPBuffer), draw a quad into buffer 2 which completely covers the draw surface (ie 640x480) - switch back to buffer 1, clear the colour channels and render your ball, using buffer 2 as the texture source - copy buffer 1 into the main buffer (with src-alpha to mask out everything but the ball) Good idea - I think I have a better one, though: Create 1 fullscreen buffer & 1 refraction buffer: render world in fullscreen buffer switch to refraction buffer & texture-quad over from fullscreen (for the area used) switch to fullscreen & render ball with refraction buffer FXBlit to s creen I use pbuffers to blit copies of my texture data around the GPU, and it is pretty efficient. I originally used the aglSurfaceTexture APIs to do this. With those, for each offscreen context, I could create another window (which I would hide), attach an OpenGL context to it, and use it as a texture source in another context by binding it to an OpenGL texture object in the target context using aglSurfaceTexture(). This is an option if you have to support a machine which for some reason doesn't do pbuffers; perhaps OSes < 10.3, for example- I'm not sure when pbuffer support came in. 10.3. Yes, we do target 10.2 but would happily add an extra codepath (we support Win32 as well, so are not really scared about specialcasing ; ) We are currently using the Cocoa interface for all our R2T needs. Did you notice any speed improvements using pBuffers over the aglSurfaceTexture API? We have it nicely wrapped in a platform-independent class, and are quite happy with it. If there is a way to reduce the overhead of context switchingRe: Multi-context rendering
• Next by Date: Re: Hardware overlay plane on 6800DDL?
• Previous by thread: Re: Multi-context rendering On Nov 24, 2004, at 12:31 AM, James Milne wrote: On Tuesday, November 23, 2004, at 10:58PM, Nicholas Francis <email@hidden> wrote: A quick question: Is it possible to share the depth buffer between 2 drawables, where one is on-screen and one is offscreen? To elaborate: ------------------ I'm looking at a profile of our upcoming game, GooBall, and a glTexSubImage is literally jumping out at me. We use it for refraction through a glass sphere along these lines: Set up render-to-texture Render Scene. do a copyTexSubImage around the ball. Render ball with the texture copied above to fake refraction Set up rendering to screen. Post-process texture to main screen. We're already rendering to a texture & putting that on screen with various post-processing FX applied. What I would like to do would be something along these lines: Set up render-to-texture Render Scene Set up rendering to screen. Post-process texture to main screen. Render ball with texture generated above This would effectively eliminate my glCopyTexSubImage, but gives me one problem: when rendering to the main screen, I don't have the Z buffer from the actual scene, hence the ball would appear in front of any geometry that might be between the camera & the ball. I can live with the geometry getting refracted incorrectly (as it does in the current scheme), but I cannot separate the geometry between the ball and the camera. Any ideas? This is a tricky one. In DirectX, you can specify the depth buffer as a separate render target, and you can share it between offscreen colour render targets, and your on-screen render target. Unfortunately, the OpenGL APIs give us no way to specify a 'depth-stencil-only' pbuffer that could be attached to a context alongside a colour pbuffer. Yeah - I've been reading up on the frustrations ppl. are having over this on the OpenGL message board. Never thought I'd need it - just goes to show. Rather than do a glCopyTexSubImage, you could create another offscreen buffer to help your glass ball rendering. Nice - I can definately see that being potentially faster. I'd do this: - create two offscreen pbuffers of the same size - render your world into buffer 1 - render buffer 1 into the main buffer with your post-processing effects, etc. - switch to buffer 2, and using buffer 1 as the texture source (using aglBindPBuffer), draw a quad into buffer 2 which completely covers the draw surface (ie 640x480) - switch back to buffer 1, clear the colour channels and render your ball, using buffer 2 as the texture source - copy buffer 1 into the main buffer (with src-alpha to mask out everything but the ball) Good idea - I think I have a better one, though: Create 1 fullscreen buffer & 1 refraction buffer: render world in fullscreen buffer switch to refraction buffer & texture-quad over from fullscreen (for the area used) switch to fullscreen & render ball with refraction buffer FXBlit to s creen I use pbuffers to blit copies of my texture data around the GPU, and it is pretty efficient. I originally used the aglSurfaceTexture APIs to do this. With those, for each offscreen context, I could create another window (which I would hide), attach an OpenGL context to it, and use it as a texture source in another context by binding it to an OpenGL texture object in the target context using aglSurfaceTexture(). This is an option if you have to support a machine which for some reason doesn't do pbuffers; perhaps OSes < 10.3, for example- I'm not sure when pbuffer support came in. 10.3. Yes, we do target 10.2 but would happily add an extra codepath (we support Win32 as well, so are not really scared about specialcasing ; ) We are currently using the Cocoa interface for all our R2T needs. Did you notice any speed improvements using pBuffers over the aglSurfaceTexture API? We have it nicely wrapped in a platform-independent class, and are quite happy with it. If there is a way to reduce the overhead of context switchingRe: Multi-context rendering
• Next by thread: Re: Hardware overlay plane on 6800DDL?
• Index(es):
  • Date
  • Thread