On Nov 30, 2005, at 12:22 PM, IOhannes m zmoelnig wrote:
could it be an option to make an alternative(!) [gemhead] out of this object?. so people could decide whether an entire gemchain is onscreen ([gemhead]) or offscreen ([???]). if so, i would vote for something really clumsy like [gemhead_os] ("clumsy" since i cannot think of a better name, not because the object _should_ be named clumsy of course)
...hmm, hadn't thought about replacing the [gemhead]: I'll look into it...IIRC, I did use [gemhead] as the template originally, so...
...ok, I'm really warming up to the idea of a new [gemhead], because [gemframebuffer] just sets up the buffer, then render occurs, then it textures it; and this maps well with what a [gemhead] does, without the texturing part...the limitation here is that it's just for one render chain...
...ultimately, we'd like to be able to have several renderchains go to one offscreen buffer, then be able to texture those results in a later gemchain...this suggests that the behaviour should be more like [pix_buffer] in that it's just an object on the canvas without a direct attachment to any chain...so I think one way to do this is to have [gem_offscreen 10 20], where the numbers refer to a continuum of [gemhead] priorities that would be rendered into the offscreen, then the gem_offscreen object would output a texID and dimensions (and possibly other texture-based info) from it's right outlet...in other words, any gemhead's with a rendering priority between 10 and 20 would go to the offscreen...this would require some change to gemman and an alternative gemhead object that has a postRendering() that doesn't get called until after a set of other gemchains had been rendered...
...hmm...this is getting a bit more complicated than my initial sketch of an easy way to get offscreen rendering: I think it'd be better to go ahead and get the code I do have into cvs so others can play with it rather than wait until we've hammered out all the possibilities it could touch...
...so, we currently don't have an object that displays a texture solely from a given texture ID: it might be necessary to have the textureID outlets also output the texture dimensions in a list, and then there could be another object that accepts these and produces the correct texcoords and such for passing onto a geo...?
...this is still up in the air, but seems to be leaning toward creating a kind of "texture_state" that would be a message outside of the gem_state that could be passed between render chains, and would perhaps include some of the following: format, type, dimensions, textureID...[pix_texture] could receive this via a right inlet as suggested before, but would treat this differently than the a GemState pix info, because it already has a lot of "texture setup" done...or maybe this should be an addition to the GemShape class?
hmm, jamie