[GEM-dev] Offscreen naming poll!

[james tittle]

>> 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