[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