Passing multi-dimentional arrays in PD? WAS: Re: Re: [GEM-dev] curve3d acts very very odd with lots of control points OSX+Linux)

[B. Bogart]

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
>
>
-------------- 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/20050724/17508999/attachment.pgp>