[GEM-dev] Offscreen naming poll!

B. Bogart ben at ekran.org
Sat Dec 3 17:44:29 CET 2005


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.

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?

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

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

b.

james tittle wrote:
>>> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20051203/20f81592/attachment.pgp>


More information about the GEM-dev mailing list