Hello,
I have read a lot of papers about offscreen rendering using pBuffers. Those all lead to the use of the extension WGL_ARB_render_texture. Which is supported by most of the graphics cards. I can remember that someone told that this extension was not supported by Apple drivers. Well it hasn't the same name but it works. The replacement extension name is: AGLSurfaceTexture. And it work pretty well.
For those who are interested here is the sample use page: http://developer.apple.com/samplecode/AGLSurfaceTexture/AGLSurfaceTexture.ht...
Greetings Ronan
------------------------------------------------- This mail sent through IMP: http://horde.org/imp/
On Sep 17, 2004, at 6:46 AM, r.leboite.pm@birdsinplane.com wrote:
I have read a lot of papers about offscreen rendering using pBuffers. Those all lead to the use of the extension WGL_ARB_render_texture. Which is supported by most of the graphics cards. I can remember that someone told that this extension was not supported by Apple drivers. Well it hasn't the same name but it works. The replacement extension name is: AGLSurfaceTexture. And it work pretty well.
...thanks for the reminder ;-) I've had a very rough time using apple's pBuffer api in various cases, and there also seems to be plenty of card-specific problems, too (fr'example, single context pBuffers work on my old tiBook, but not my brand new powerbook, yet shared contexts seem to have no problem)...
...certainly this is a way to go, but I also looked at the WGL_ARB_render_texture api, and it just seems to expose similar stuff to the APPLE_pixel_buffer extension (strictly speaking, "AGLSurfaceTexture" isn't an extension)...so this opens the door to a presumably easy implementation of what you've done already: I'll be trying that this weekend...
...there is also the normal, non-extension-based method of render to texture that uses glCopyTexImage(), as described in nehe's tutorial 36 "radial blur": I've used this to good effect, and am still not 100% convinced that pBuffers buy us a whole lot of other stuff (especially if we're just sharing a context)...
...your Cg wrapper stuff looks good on the face of it, and I do have Cg installed, so will try that this weekend too...I'm just shy about using it because anything but the simplest shaders seems to produce unusable code for ati cards (they have a bit different structure): however, nvidia is aware of this and seem to be very responsive to fixing it!
thanx, james
Selon James Tittle II tigital@mac.com:
...there is also the normal, non-extension-based method of render to texture that uses glCopyTexImage(), as described in nehe's tutorial 36 "radial blur": I've used this to good effect, and am still not 100% convinced that pBuffers buy us a whole lot of other stuff (especially if we're just sharing a context)...
When i coded Max/MSP - Jitter objects i did try the glCopyTexImage() command. This is a good way to implement this feature but this is not a good performance solution. In this case, texture copy use to be stored in the computer RAM, this leads to the AGP bus bottleneck problem. My frame rate just use to drop from 200 (or more) to 30-40. With a single 512*512 texture, or 256*256... i cant remember. With the pBuffer, i see no particular difference, even with mutiple 1024*1024 textures :p
...your Cg wrapper stuff looks good on the face of it, and I do have Cg installed, so will try that this weekend too...I'm just shy about using it because anything but the simplest shaders seems to produce unusable code for ati cards (they have a bit different structure): however, nvidia is aware of this and seem to be very responsive to fixing it!
Well, yes... i have fixed the problem i had a few days ago by implementing a Base class, GemShaderBase from which all the Cg wrapper objects will inherit. I hope to get new Vertex and Fragment shader objects as soon as possible. As well as cgGLSetParameter* (dont know yet for vector params but basic ones for sure).
What you said about ATI cards interrests me a lot, i know there is at leat 2 ways to declare IN parameters for a Shader. Maybe thats why some people cant use the simple vertex programs i included in my sources.
Greetings Ronan
------------------------------------------------- This mail sent through IMP: http://horde.org/imp/
On Sep 17, 2004, at 9:04 AM, r.leboite.pm@birdsinplane.com wrote:
Selon James Tittle II tigital@mac.com:
...there is also the normal, non-extension-based method of render to texture that uses glCopyTexImage(), as described in nehe's tutorial 36 "radial blur": I've used this to good effect, and am still not 100% convinced that pBuffers buy us a whole lot of other stuff (especially if we're just sharing a context)...
When i coded Max/MSP - Jitter objects i did try the glCopyTexImage() command. This is a good way to implement this feature but this is not a good performance solution. In this case, texture copy use to be stored in the computer RAM, this leads to the AGP bus bottleneck problem. My frame rate just use to drop from 200 (or more) to 30-40. With a single 512*512 texture, or 256*256... i cant remember. With the pBuffer, i see no particular difference, even with mutiple 1024*1024 textures :p
...after writing that I also remembered one of the main reasons I want pBuffers: floating point buffers! I don't think you can do that with glCopyTexImage()...of course, I'm sure the acceleration pathway will be nice, too :-)
Well, yes... i have fixed the problem i had a few days ago by implementing a Base class, GemShaderBase from which all the Cg wrapper objects will inherit. I hope to get new Vertex and Fragment shader objects as soon as possible. As well as cgGLSetParameter* (dont know yet for vector params but basic ones for sure).
...and from this it probably would be trivial to add wrappers for glBindProgramARB(), glProgramEnvParameter4fvARB(), etc. for Vertex_Program_ARB...
l8r, jamie
-
James Tittle II -
r.leboite.pm＠birdsinplane.com