*sigh*
Anyone have any hints for creating a curve3d (draw control) like plane of faces where the alpha of each vertex can be controlled?
I could dynamic patch an array of squares, or polygons but then I would need to use some fancy pix_coordinate stuff so that I can create the illusision that the array of objects is textured with one seamless image..
I suppose I could mess with some crazy pyext/numarray stuff to control pix_data.... that is probably slowwwww.
320x240 squares or polys or pixels would be a ok starting point.
Of course I could make this an opportunity to try the GL wrappers...
Thanks for jumping in Jamie, I was not aware of the conflicts. Maybe we should have a gem-dev meeting on #dataflow?
B.
james tittle wrote:
hmmm,
...welcome back IOhannes! Hope ya had a good break: I'm still looking for one myself :-\
On Aug 16, 2005, at 10:09 AM, zmoelnig@iem.at wrote:
Quoting "B. Bogart" ben@ekran.org:
Hey again.
Well it seems my fresh vertex_array checkout is not helping with compiling on OSX. The build system clearly does not match the new autoconf one. Anyhow:
yes the new autoconf (in Gem/src instead of Gem/src/Gnu) has no notion of the vertex_array. in theory you just need to add "Vertex" to the GEM_TARGETS in Make.config (after configure), but i have no way to test this right now.
so i gues it is really time to make the vertex_array stuff ready for the main branch (even if there are different types for color/vertex/ texcoord/...; this could be changed later on if need is at hand; or do costy conversions between those arrays at the user's own choice)
...yeh, ben, you've opened an unfinished project, so proceed very carefully! When last we left (as I recall), IOhannes, chris, and I were bickering about IOhannes' latest change to the vertex_array branch: he had made all "arrays" equal at 4 floats: the idea being that we can then plug anything into anything and let someone else sort it out later...
...chris and I didn't (and I presume still don't) like this, firstly because there's no such thing as a 4 element normal, texcoord, color, etc....as a matter of fact, only vertices can have 4 elements...so, you're put in the position of potentially doubling the amount of data being used, potentially for some undefined flexibility...
...the whole matter was left there when IOhannes said "show me some numbers" about how big a slowdown we're talking about, and I never got around to actually doing that...
...I guess until the benchmarks are done and we can all fall on one side or the other, I'd like to point out that if we use vertex buffer objects (or any kind of buffer objects), and we do want to use them, it should be noted that you can't map a buffer for 4 elements to two...maybe can't is too harsh a word: let's say that it's experimental at best, and expects alot from the gl driver, especially considering we're dealing with multiple platforms, gpus, etc...
ok? jamie