[GEM-dev] vertex_array

[B. Bogart]

*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 at iem.at wrote:
>
>> Quoting "B. Bogart" <ben at 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
>
-------------- 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/20050816/6c7a3f2f/attachment.pgp>