Off screen rendering
by Justin DuJardin · in Torque Game Builder · 04/25/2005 (8:17 am) · 6 replies
Perhaps this sounds a bit odd, but allow me to elaborate a bit.
I've been working on getting terrain deformation working for my scorched earth clone (when i can manage to find time) and as of this weekend it's 95% done. However, I do need to figure out a way to take the chunks out of the terrain png file.
What I planned to do was take my terrain png and a circular png (of only alpha) then render it (after scaling for radius) on top of my terrain png which would in effect set all the pixels alpha's to 0. I'm stuck there though, here's what I'm wondering how to do (can it be done?)
I want to use dgl to render my terrain texture into a buffer then I want to render my brush texture on top of it. After this I want to be able to grab that buffer and put it back into a gbitmap or texturehandle for use.
Unfortunately my dgl experience is limited mostly to drawing gui components and I am not sure where to look/get started with trying to do something like this. Any help would be very appreciated!
TIA,
Justin DuJardin
I've been working on getting terrain deformation working for my scorched earth clone (when i can manage to find time) and as of this weekend it's 95% done. However, I do need to figure out a way to take the chunks out of the terrain png file.
What I planned to do was take my terrain png and a circular png (of only alpha) then render it (after scaling for radius) on top of my terrain png which would in effect set all the pixels alpha's to 0. I'm stuck there though, here's what I'm wondering how to do (can it be done?)
I want to use dgl to render my terrain texture into a buffer then I want to render my brush texture on top of it. After this I want to be able to grab that buffer and put it back into a gbitmap or texturehandle for use.
Unfortunately my dgl experience is limited mostly to drawing gui components and I am not sure where to look/get started with trying to do something like this. Any help would be very appreciated!
TIA,
Justin DuJardin
#2
As Smaug says, pbuffer is the only decent option atm, if you want off-screen rendering (there are also platform-specific extensions via GLX, WGL, etc... and there are auxillary buffers, but those go unsupported). At GG, we've used pbuffers for our previous implementations that have required this functionality, but we've never been happy to have to do that. Also, using pbuffers will remove DX support, with dgl as it stands now. As Smaug says as well, they require context switches too. :(
FBO will be nice if/when it comes online with hardware support (which I've read should happen in the summer-ish timeframe). Even so, FBOs are not part of even the OGL2 spec, nor have they been ARB-adopted, so they currently stand as a largely unsupported GL_EXT that won't help on low-end hardware support.
Smaug's suggestion of a workaround using the frame bruffer and copysubtext is good too. There might be other workarounds possible though... just to make sure I understand correctly, you basically want to render circular pieces of the sky over pieces of the terrain, right? If so, maybe we can think of some more workarounds.
04/25/2005 (4:59 pm)
Smaug's summary of rendering off-screen in GL is a good one. GL sucks for off-screen rendering, unfortunately. :) Been lots and lots of hullabaloo over this, but no good official solution yet. As Smaug says, pbuffer is the only decent option atm, if you want off-screen rendering (there are also platform-specific extensions via GLX, WGL, etc... and there are auxillary buffers, but those go unsupported). At GG, we've used pbuffers for our previous implementations that have required this functionality, but we've never been happy to have to do that. Also, using pbuffers will remove DX support, with dgl as it stands now. As Smaug says as well, they require context switches too. :(
FBO will be nice if/when it comes online with hardware support (which I've read should happen in the summer-ish timeframe). Even so, FBOs are not part of even the OGL2 spec, nor have they been ARB-adopted, so they currently stand as a largely unsupported GL_EXT that won't help on low-end hardware support.
Smaug's suggestion of a workaround using the frame bruffer and copysubtext is good too. There might be other workarounds possible though... just to make sure I understand correctly, you basically want to render circular pieces of the sky over pieces of the terrain, right? If so, maybe we can think of some more workarounds.
#3
04/25/2005 (5:25 pm)
Pretty sure I did my rend to texture stuff in somethign I Did using the glCopyTex method or somethign similiar and it worked fine, but then it wasn't being run very often at all. It was mainly to cache the output of a render that was only sdemi-dynamic.
#4
Well FBO itself doesn't have anything specifically in it that should prevent low-end hardware that is at all capable of render-to-texture from doing so. If the TNT 2, for example, can actually render directly to a texture in hardware, it should be quite possible to access this through FBO.
Though FBO is a rather complex extension that's definately going to take time for IHV's to implement and fully debug.
As for FBO being only an EXT extension, I think this is a very good idea on the ARB's part. I'd hate for them to immediately throw such complex technology directly to core GL without having several implementations out there in significant use. It's virtually impossible to fix something that's broken in the core, but when promoting an EXT to an ARB or to core, it's easy to make modifications where necessary.
I do think that the days where RTT will be the bane of OpenGL are numbered; its just that there are probably more digits on those numbers than we'd like ;)
04/25/2005 (6:32 pm)
Quote:so they currently stand as a largely unsupported GL_EXT that won't help on low-end hardware support.
Well FBO itself doesn't have anything specifically in it that should prevent low-end hardware that is at all capable of render-to-texture from doing so. If the TNT 2, for example, can actually render directly to a texture in hardware, it should be quite possible to access this through FBO.
Though FBO is a rather complex extension that's definately going to take time for IHV's to implement and fully debug.
As for FBO being only an EXT extension, I think this is a very good idea on the ARB's part. I'd hate for them to immediately throw such complex technology directly to core GL without having several implementations out there in significant use. It's virtually impossible to fix something that's broken in the core, but when promoting an EXT to an ARB or to core, it's easy to make modifications where necessary.
I do think that the days where RTT will be the bane of OpenGL are numbered; its just that there are probably more digits on those numbers than we'd like ;)
#5
I agree too that extensions should be put through their paces before going into the official spec, I was just indicating that it'll be a while before we can expect full, official support. Re: hardware support and low-end hardware, I mean that we don't expect IHVs to offer official driver support for this extension back very far in their hardware lines. :)
04/25/2005 (9:48 pm)
Smaug, I agree, the days are definitely numbered, and I'm anxiously counting them down. :) Way overdue, but such is life. I agree too that extensions should be put through their paces before going into the official spec, I was just indicating that it'll be a while before we can expect full, official support. Re: hardware support and low-end hardware, I mean that we don't expect IHVs to offer official driver support for this extension back very far in their hardware lines. :)
#6
Thanks again for the great info :)
-justin'
04/25/2005 (10:09 pm)
Smaug, Josh, thanks for the input. I did a bit of my own research and came up basically with what you fellas are eluding to. It's not gonna work (well) for me to try and use gl of any sort to do my rendering. As it so happens I managed to get it working alright using a simple iteration through the GBitmap pixels to brush the image over. You can see the result (though it's not too impressive) in my .PLANThanks again for the great info :)
-justin'
Torque Owner Smaug
There are potentially 3 ways of doing it. The slowest, but guarenteed to work, is to do this:
* Render the image you want to render to into the framebuffer. The destination image. In your case, the terrain.
* Render the stuff you want to render on top of that (the source image) into the framebuffer. In your case, the circle.
* Use a glCopyTexSubImage (I think that's what it's called) call to copy the region of the framebuffer corresponding to your image into the destination image (your terrain).
This will work (as long as there is nothing in the framebuffer you want to keep. You'll need to do this at the beginning of a frame after a clear operation), but it is slow. To avoid the slowness, you're going to need to use some extensions.
The best method would be to use EXT_framebuffer_object. However, FBO is not well implemented these days; only nVidia has an implementation, and it's pretty experimental. As such, you can't really rely on it. Maybe by Christmas, IHV's will have decent FBO implementations.
The other method involves the use of the WGL/GLX extensions for rendering to pbuffers: WGL_ARB_pbuffer, and WGL_ARB_render_texture. These will be functional, but they involve lots of context switching, which will provide a non-trivial slowdown. They're also not the easiest extensions to work with.
I'd suggest sticking with the glCopyTex method for the time being. It works, and it probably isn't too slow. Just make sure that the internal format of the destination texture is RGBA8, and it should work OK.