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