[GEM-dev] Offscreen naming poll!

[B. Bogart]

Hi Jamie,

Good to hear we're thinking alike.

Could the texture ID be passed directly to a pix_tecture object via second
inlet? I think this would match the current way things work, rather than
getting the pix_ from pix_image we get it then from the object that sends
the buffer IDs. Maybe the idea of associating each buffer with a symbol is
better as its connectionless...

or to be a pix_ object... but then thats getting really complex.

Maybe the buffer stuff could be unified to a pix_buffer [type] be it a
depot, a multi-image, a pbuffer and so on...

again just more talking w/ only a little thinking.

could you send a patch so I really understand the problem? (rather a
screenshot of how it works now, and I can see if I can think of a nice way
to name/position it...)

b.


> On Nov 30, 2005, at 12:22 PM, IOhannes m zmoelnig wrote:
>
>> B. Bogart wrote:
>>> gembuffer ?
>>> gembuf? (gemwin)
>>> james tittle wrote:
>>>> name it, and where it should go in the folder hierarchy?   Currently
>>>> it's named [gemframebuffer], but really I think  [gemoffscreen]
>>>> would be
>>
>> as you state correctly, the name [gembuffer] would be coherent
>> with  the name [gemwindow], so the functionality should be coherent
>> too. (imo, the same goes for [gemframebuffer] and [gemoffscreen].)
>> i foresee nameclashes with the multiple_windows (whenever they will
>> come...)
>
> ...[gembuffer] or [gemoffscreen] I can see being used in
> multiple_windows as equivalents to [gemwindow]...using a specific
> name for either framebuffer or pbuffer seems silly because they
> basically do the same thing; the difference being that one is easier
> to do than the other...perhaps it should be [gem_render2texture]?
>
>>>> ...also, on my harddrive I put it in src/controls (it would be
>>>> inserted
>>>> into a gemchain after [gemhead]), but I guess it could also  go in
>>>> src/manips, or even src/Nongeos?
>>
>> 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...
>
> ...the bigger question I'm wrestling with is how to use it best once
> it's available?  Somewhat the same problem with [pix_texture] and
> [pix_multitexture]...[pix_texture] and [gem_offscreen] both output a
> texture ID from their right outlet, ostensibly for use in a later
> render chain...currently I've used glwrappers to create the vertices
> to display these textureID's, but this only really works if you
> already know the texture size (and use TEXTURE_RECTANGLE) or if you
> use TEXTURE_2D and power of 2 dimensions...
>
> ...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...?
>
> ...or is there a way to do this already that I'm not seeing?
>
> james
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev
>