Hi Chris,
Good to hear. Is there an example patch that shows how to offset each vertex by 0.1 units out along its normal?
Just as a point of discussion one of the arguments for numarray is that it is more efficient with arrays larger than 20,000 elements. I have a patch that simply subtracts 0.1 units from the Z access of a particular control point. What has amazed me is that I needed no interpolation because the numarray code ran fast enough to create smooth movement.
Indeed these are issues worth discussing. Also between iemmatrix, gridflow and VASP (numarray/python) seems arrays are "IN". ;)
Oh and here is some numarray info:
http://www.stsci.edu/resources/software_hardware/numarray
Thanks for the clarification Chris, I'll have to do update of my vertex stuff.
:)
chris clepper wrote:
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