[GEM-dev] offscreen rendering

James Tittle II tigital at mac.com
Fri Sep 17 15:41:54 CEST 2004


On Sep 17, 2004, at 9:04 AM, r.leboite.pm at birdsinplane.com wrote:

> 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

...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





More information about the GEM-dev mailing list