Passing multi-dimentional arrays in PD? WAS: Re: Re: [GEM-dev] curve3d acts very very odd with lots of control points OSX+Linux)
chris clepper
cgc at humboldtblvd.com
Sun Jul 24 17:41:35 CEST 2005
On Jul 24, 2005, at 9:10 AM, B. Bogart wrote:
>
> In vertex arrays (Chris, correct me where needed) I think the problem
> is
> that the current objects are very easy to control and very fast BUT
> since the arrays are in C we still have to use PD messages to control
> them. Looks like the approach in vertex_arrays is to have one message
> control multiple vertexes. Problem with this is that you loose the
> individual control (rather if you had a range of vertex 1 to 1 then you
> would be back to the same problem of many many messages). I posted some
> ideas about more complex ranges, and the ability to rotate/translate/..
> vertexes based on their normal rather than global axes.
The vertex_array objects do allow for a single point (vertex, color,
texcoord, normal) to be modified as well as a range. It's very easy to
do this by offsetting the pointer and counting from there. This does
not allow for selecting two non-contiguous ranges or do anything more
programmatic like skip every third point. You could use [repeat] to
iterate through the same array each render pass but that is probably
not very efficient.
Once you start loading models of any complexity into vertex_array
chains it becomes apparent that these objects need to be very
efficient. A model with 10,000 vertices has a 40k vertex array, a 40k
color array, a 30k normal array and a 20k texcoord array. That is
130,000 floats or 520,000 bytes per frame to process. Multiply by 30
or 60 frames per second and that is moving a lot of data.
That example also points out the trouble with giving a user some sort
of representation of all of that data. I don't think any of Pd's
objects or external libraries are designed to deal with structures of
this size.
cgc
More information about the GEM-dev
mailing list