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]

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