[GEM-dev] Offscreen naming poll!

[james tittle]

On Dec 3, 2005, at 11:44 AM, B. Bogart wrote:
> This sounds pretty good to me,
>
> Do the gemhead priorities effect what is happening in the buffer? If I
> offscreen gemhead 10-15, then does 10 get rendered first into the
> offscreen followed by 11, and so on?
>
> If so this is great.

...yeh, that's the idea:  [gem_offscreen] would act as a kind of book- 
end or wrapper around several gemchains...

> If not then maybe a single tag could work and be perhaps a little more
> friendly:
>
> [gemhead 1]              [gemhead 2 mybuffer]
>  |                        |
> [pix_offscreen mybuffer] [pix_video]
>  |                        |
> [pix_texture]            [shader_stuff]
>  |
> [square]
>
> something like this?

...ok, I'll try to draw out what I've got atm:

[gemhead 1]      [gemhead 3]              [gemhead 2]
  |                |                        |
[glsl_vertex]    [glsl_vertex]            [pix_image noise.tif]
  |                |                        |
[glsl_fragment]  [glsl_fragment]          [pix_texture]
  |                |                  ________________|
[glsl_program]    [glsl_program]    /
  |                |                /           [gemhead 4]
[gemframebuffer] [gemframebuffer]_/__________	|
  |             \  |              /           \  |
[pix_film]      [pix_multitexture]           [pix_multitexture]
  |               |                            |
[pix_texture]   [pd QuadUsingGLWrappers]     [pd QuadUsingGLWrappers]
  |
[rectangle]


...so what this is supposed to show is a film that gets rendered  
offscreen to a rectangle while a glsl effect is added...then this  
offscreen is passed to another chain where it's also textured to  
another rectangle and has a 2nd effect applied...then finally this  
2nd offscreen is textured to a rectangle for display in the onscreen  
window...

...cool thing is, this works right now!  But, I'm still trying to  
cobble together some functionality in [pix_multitexture] (and  
possible [pix_texture] or some not-yet-created object) to more easily  
allow "texture state" to be passed between chains...atm it's quite  
hack-y and dependent on the gl wrappers...

> Again this buffers would just me textures, so that they would probably
> only have pix_ objects in the chain?

...well, yes and no:  yes, they are textures, but no, as in "not cpu- 
side" texture memory like we use in the pix_ objects (usually)...for  
the offscreen's to work within the pix-system, another object would  
need to be created to readback the texture info, either by  
glReadPixels or using pixelbuffer objects...

> I'm really REALY looking forward to a couple example patches.

...hope the above can stand in for now ;-)

jamie