Re: Generating textures on the fly

New Message Reply Date view Thread view Subject view Author view

Amaury Aubel (aubel++at++lig.di.epfl.ch)
Wed, 25 Jun 1997 17:47:48 -0600


On Jun 24, 3:34am, Ran Yakir wrote:
> > I want to generate textures on the fly in my app. These textures are
> > then
> > loaded into TRAM using the PFTEX_SOURCE_FRAMEBUFFER load mode (thanks
> > Anita
> > btw:-)
> >
> > 1) Ideally, the generated textures should not be visible so they
> > should be
> > rendered off-screen.
> > Yet, from what I understand it is not possible to render something
> > off-screen
> > using hardware acceleration, right?
> >
>
> Wrong. You can render either to a pbuffer (look for pbuffer commands in
> /usr/include/GL/glx.h), or to an AUX buffer.AUX buffers are easier to
> handle - you allocate them in you attribute list for a pfWindow, and
> then switch using glDrawBuffer (GL_AUXn), where n is 0 and up.
> You will have to allocate alpha bitplanes for your window, also in the
> attribute list, in order to support semi-transparent_8 textures..
> The advantage of pbuffers is that they can have different size and
> attributes from your window, unlike the aux buffers.

First of all thanks for your help.

I was not aware there was such a thing as pbuffers.
But how could I load something from the pbuffer into the TRAM? That puzzles me
most...

I could use glXMakeCurrentReadSGI to tell openGL to use the pbuffer as a source
for all subsequent glReadPixels, glCopyPixels etc.
But I strongly doubt this will apply to a texture load specified as follows:

    pfTexLoadMode(tex, PFTEX_LOAD_SOURCE, PFTEX_SOURCE_FRAMEBUFFER);
    pfTexLoadSize(tex, WIN_X, WIN_Y);
    pfLoadTex(movie->tex);

Does anyone have an idea of what would happen?

An alternative solution would be to transfer a block of pixels from the pbuffer
into CPU memory and then load it to TRAM with a pfTexImage(). Seems awfully
complicated (and slow).

Any idea of how I could do this?

Amaury.
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
            Submissions: info-performer++at++sgi.com
        Admin. requests: info-performer-request++at++sgi.com


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:55:30 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.