[GEM-dev] Offscreen naming poll!
james tittle
tigital at mac.com
Thu Dec 1 18:39:31 CET 2005
>> 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
More information about the GEM-dev
mailing list