[GEM-dev] offscreen rendering

r.leboite.pm at birdsinplane.com r.leboite.pm at birdsinplane.com
Fri Sep 17 15:04:16 CEST 2004


Selon James Tittle II <tigital at 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/




More information about the GEM-dev mailing list