PDA

View Full Version : render to texture



robert
01-09-2003, 11:09 PM
What's the best way to render to texture? pbuffer or does glCopyTex2D do the same thing?

I'm guessing pbuffers are used so that a scene can be changed, and glTexSubImage2D()is for getting straigt from the framebuffer?

[This message has been edited by robert (edited 01-10-2003).]

T
01-10-2003, 02:16 AM
If I understand it correctly, the render-to-texture extension literally allows you to render into a texture image (the pbuffer). Alternatively you can render to the backbuffer and then pixel copy into a texture. I assume the extension provides a performance increase.

Korval
01-10-2003, 08:21 AM
I assume the extension provides a performance increase

Well, at the moment, nVidia drivers don't actually provide a performance increase with the render-to-texture extension. This is for an unspecified reason that should, hopefully in the near future, be corrected.

Asgard
01-10-2003, 10:38 AM
Actually the performance of render-to-2D-texture with WGL_ARB_render_texture is quite ok in newer NVIDIA drivers (gives still worse performance than DX 8 though). But rendering to a cube map is still horrible.

Btw, another important occasion for using pbuffers is when you're rendering to a window (and not in full screen mode), or when the size of the texture you want to render to is bigger than the framebuffer. In these cases, copying from the framebuffer won't work.

cass
01-10-2003, 02:39 PM
There's also discussion going on about a non-pbuffer based render-to-texture. The new-style API would make rendering to texture a lot simpler.

Humus
01-10-2003, 04:23 PM
That would be really great. Render-to-texture is pretty much the only thing where the Direct3D interface is better.

jwatte
01-10-2003, 07:07 PM
If you're fixing that, how about also allowing attaching various depth surfaces to various render targets, and perhaps multiple render targets, too? DX9, which is now released, does both of those pretty well.

Tom Nuydens
01-10-2003, 10:00 PM
Originally posted by Asgard:
Btw, another important occasion for using pbuffers is when you're rendering to a window (and not in full screen mode), or when the size of the texture you want to render to is bigger than the framebuffer. In these cases, copying from the framebuffer won't work.

Also, with a pbuffer you can control FSAA separately from your main window. You don't necessarily want 4x FSAA enabled while you're rendering to a texture.

-- Tom

rgpc
01-11-2003, 03:56 PM
Originally posted by Asgard:
But rendering to a cube map is still horrible.

Phew! Here I was thinking it was just me... http://www.opengl.org/discussion_boards/ubb/frown.gif

davepermen
01-12-2003, 07:03 AM
Originally posted by cass:

There's also discussion going on about a non-pbuffer based render-to-texture. The new-style API would make rendering to texture a lot simpler.



my dreams come true?
you're jokeing, right? http://www.opengl.org/discussion_boards/ubb/biggrin.gif

PH
01-12-2003, 07:15 AM
This is exactly what I was hoping for. Actually, I was expecting some of those "GL2" extensions to be made available ( again, in one form or another ). I'll be surprised if it's something not related to GL2.

pbrown
01-13-2003, 05:25 PM
Originally posted by PH:
This is exactly what I was hoping for. Actually, I was expecting some of those "GL2" extensions to be made available ( again, in one form or another ). I'll be surprised if it's something not related to GL2.

There are a whole set of issues with the current pbuffer extensions (potential need for separate contexts, windowing system dependencies), that aren't insurmountable, but are annoying. The current solutions also lack some flexibility (e.g., you might need a Z buffer when rendering to a render-texture pbuffer, but you don't need it after the final image has been rendered). We've also recently added several pieces of interesting functionality that suffers from the same general problems (rendered shadow maps, floating-point pbuffers). This is an area of interest of several OpenGL vendors.

The closest thing in "GL2" whitepapers appears to be image buffers in the memory management whitepapers, but it doesn't seem to be obviously connected to render texture, pbuffers, and the like.

I personally think this is very important functionality that I'd like to see in an OpenGL 1.5, OpenGL 2.0, or whatever you want to call it.

pbrown
01-13-2003, 05:27 PM
Originally posted by Asgard:
But rendering to a cube map is still horrible.



Originally posted by rgpc:
Phew! Here I was thinking it was just me... http://www.opengl.org/discussion_boards/ubb/frown.gif


My understanding is that rendering to a cubemap should be significantly better in the next NVIDIA driver release.

[This message has been edited by pbrown (edited 01-13-2003).]

[This message has been edited by pbrown (edited 01-13-2003).]

MZ
01-14-2003, 08:33 AM
pbrown:
I personally think this is very important functionality that I'd like to see in an OpenGL 1.5, OpenGL 2.0, or whatever you want to call it.
I fully agree, but I also would like to clarify one thing:
The closest thing in "GL2" whitepapers appears to be image buffers in the memory management whitepapers, but it doesn't seem to be obviously connected to render texture, pbuffers, and the like"OpenGL 2.0 Objects" v1.2 paper describes glAttach/DetachBufferObject() functions, which could allow achieving the same affects as with DX9's SetRenderTarget().

This is how, according to the proposal, RTT with sharing depth+stencil buffer might look like:



// initialisation:
GLhandle WindowFrameBuffer = glCreateFrameBufferObject(...); /* main FB */
GLhandle OffscreenFrameBuffer = glCreateFrameBufferObject(...); /* 'pbuffer' */
GLhandle DepthAndStencilBuffer = glCreateBufferObject(GL_DEPTH, ...);
GLhandle RenderTexture = glCreateTextureObject(...)

GLhandle OffscreenColorBuffer = /* acquire GL_FRONT_LEFT_BUFFER_HANDLE from the
OffscreenFrameBuffer, proposal doesn't say
how to do this, there is no GetObjectParameter()
returning values of GLhandle type */
glAttachImageObject(RenderTexture, OffscreenColorBuffer, 0);
(...)

// rendering loop:
{
// dettach depth+stencil from the window:
glDetachObject(WindowFrameBuffer, DepthAndStencilBuffer);
// attach depth+stencil to the 'pbuffer':
glAttachBufferObject(OffscreenFrameBuffer, DepthAndStencilBuffer);
// set render target:
glUseFrameBufferObject(GL_DRAW, OffscreenFrameBuffer);

// now render to the 'pbuffer'
(...)

// dettach depth+stencil from the 'pbuffer':
glDetachObject(OffscreenFrameBuffer, DepthAndStencilBuffer);
// attach depth+stencil to the window
glAttachBufferObject(WindowFrameBuffer, DepthAndStencilBuffer);
// set render target:
glUseFrameBufferObject(GL_DRAW, WindowFrameBuffer);

// now render to the window

(...)
// bind the 'pbuffer' as texture:
glUseTextureObject(RenderTexture, /*texture unit*/);
(...)
}

IMO GL2 proposal includes solutions for all RTT-related problems i'm aware now.

PH
01-14-2003, 08:44 AM
Originally posted by pbrown:
There are a whole set of issues with the current pbuffer extensions (potential need for separate contexts, windowing system dependencies), that aren't insurmountable, but are annoying. The current solutions also lack some flexibility (e.g., you might need a Z buffer when rendering to a render-texture pbuffer, but you don't need it after the final image has been rendered). We've also recently added several pieces of interesting functionality that suffers from the same general problems (rendered shadow maps, floating-point pbuffers). This is an area of interest of several OpenGL vendors.

The closest thing in "GL2" whitepapers appears to be image buffers in the memory management whitepapers, but it doesn't seem to be obviously connected to render texture, pbuffers, and the like.

I personally think this is very important functionality that I'd like to see in an OpenGL 1.5, OpenGL 2.0, or whatever you want to call it.

I would definitely like to see this in GL 1.5 ( the sooner the better http://www.opengl.org/discussion_boards/ubb/smile.gif ). The reason I mentioned GL2 was because I think it would make sense to get this solved once and for all. If this new API replaces the proposed GL2 buffer objects then that's fine with me too. And like MZ mentioned, GL2 proposed a method that seems to be just as flexible as DX9.

Anyway, do you have an approximate timeframe for this ? Are we talking a few months or more / less ?

Asgard
01-14-2003, 09:51 AM
It's really good to hear that work is done on a better render-to-texture solution for OpenGL.
I'd much prefer it if any new extension is not just created as an interim solution, but rather as PH and MZ suggest with regard to an upcoming GL 2.0, so that the functionality can be integrated into core OpenGL 2.0 in the future.

davepermen
01-14-2003, 10:10 AM
so lets hope to see a vao and a rendertexture soon..

i am currently in love with the clean and awesome easy way to work with dx9, but i see that i always step back to gl anyways, its fun http://www.opengl.org/discussion_boards/ubb/biggrin.gif.. can't wait to see gl without its bugs (wich i did started to lovehate..)

i hope the only os-specific thing in gl will be a common frontbuffer, to blit to (or a front/back buffer pair to swap then..), and thats it. no other wgl/xgl/macgl/****ing****someotherosgl functions, please. there is no need for any others.. just look at d3d9, i think it would be very easy to port actually.. only one function actually needs a hwnd.. (except some gdi access to render with gdi.. but you don't actually need that), and thats about it..

thats what i want to see from gl again, too.. gl should be portable.. wgl kills that

jono_123
01-14-2003, 11:58 PM
www.gametutorials.com (http://www.gametutorials.com) has a tutorial on render to a texture http://www.opengl.org/discussion_boards/ubb/smile.gif

djdjdjdjdj
01-17-2003, 01:34 PM
Can render2texture be done with pbuffers under Linux using the latest Nvidia drivers?

pkaler
01-17-2003, 01:50 PM
Originally posted by djdjdjdjdj:
Can render2texture be done with pbuffers under Linux using the latest Nvidia drivers?

The 41.91 drivers support GLX_SGIX_pbuffer. So I am assuming so.

chrispy
01-18-2003, 09:16 AM
I think I've foung a bug in using pbuffers on Windows. When I create a pbuffer and make it current the first time, wglMakeCurrent returns TRUE but it gives an error of ERROR_INVALID_WINDOW_HANDLE. In the nvidia demo simple_render_texture if you write wglGetLastError() after the pbuffer is first made current, you can see the error. Strange that wglMakeCurrent reports an error but returns TRUE.

Pup_Tentacle
01-20-2003, 04:40 AM
I have found the same spooky error. The first usage always flags an invalid window handle, and thereafter everything works fine.

JelloFish
01-22-2003, 05:21 PM
Originally posted by Asgard:
Actually the performance of render-to-2D-texture with WGL_ARB_render_texture is quite ok in newer NVIDIA drivers (gives still worse performance than DX 8 though). But rendering to a cube map is still horrible.

Is the performance better than just rendering and doing copy tex subimage? Just a couple driver versions ago I switched back to strait copytexsubimage without pbuffers because the performance loss of switching pbuffers was huge.

Asgard
01-23-2003, 12:14 AM
Rendering to a 2D texture using WGL_render_texture with the latest NVIDIA drivers has gotten faster, but it's still not as fast as pbuffer+copy on my machine. Looks to me the driver just internally does a copy when using WGL_render_texture and then something else which still causes a drop in performance. I haven't done any intensive testing though.
Rendering to a cube map, however, is incredibly slow and it's waaaay faster when I just render to the pbuffer and do the copy myself (we're talking about 15-20 times faster here on my machine).

In any case, due to the "design issue" of requiring a separate rendering context with WGL_render_texture I doubt you'll ever get better performance using a pbuffer compared to rendering to the framebuffer + doing a copy.
In my case, I can't do that though for the various reasons laid out in the above posts http://www.opengl.org/discussion_boards/ubb/frown.gif