Quoting IOhannes m zmoelnig zmoelnig@iem.at:
no! [vertex_add] and [vertex_offset] are not the same (for now): [vertex_offset] adds a single vector to all vertices. [vertex_add] adds 2 vertex-arrays. [vertex_mul] multiplies 2 vertex-arrays (so you can really "square" a model)
Oh I get it... Good thing at least one of us is paying attention.
right now they are hard casts to integer. it was fastest to write (not to execute). i have no objections to any speed up too...
There's an Altivec op that changes floats to ints without the memory access. I might try to build a loop to fill an array of indexes (wild stuff) if the counter conversions become problematic. I think proper scheduling of the conversion one loop iteration or more ahead will alleviate most problems.
countint = (int) countf;
while (countint < maxcount){ //adjust to keep the counter in the right place for the next iteration nextcount = (int)countf + interval;
//do stuff
countint = nextcount; }
Any super-scalar machine with decent OOOE will be able to handle this without stalls. If the code is all vector ops then there will be no reason for stalls in the floating point unit either.
one of my alltime favourites is of course, grabbing data from pd's offers: mapping signals to vertices (i have done some 3d spectral visualisation (normal "scientific" waterfall-plots) just this week with [pix_sig2pix~] and [imageVert] and it was kindof slow) and mapping tables to vertices.
Personally, I've never been a fan of direct mapping of audio to image data or vice-versa. Instead I extract some useful element of the audio/video to use as control data. The kids really love the direct mapping from what I hear, as it's apparently a major selling point of some commercial video objects for Max that will remain nameless. ;)
I'm all for working on these objects - I might be convinced of their usefulness some day.
cgc
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.