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