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