chris clepper wrote:
[vertex_add] would be same as [vertex_offset] and [vertex_scale] = [vertex_mul] right? I'm fine with the name changes since the add/mul is probably more informative.
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)
I made the object [vertex_combine] to try and blend between two arrays. I never got around to doing the interpolation for arrays of different sizes however. I
which is what has inspired me for [vertex_add] and the like
think the easiest way is to have a float counter var that's a positive ratio between the two arrays (like 3.33:1) and then coerce it back an int. It's a very crude way to do it, and it has to be scheduled in a way that the processing ops don't stall waiting for the conversion. I'm open to any ideas about interpolation as long as they are fast. ;)
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...
We should discuss the development of the vertex_stuff in more depth. For example, what are some ideas for vertex generation objects? On the one hand, I think vertex_model handles a whole lot of the old static Geos since it's pretty
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.
these will be very generic solutions
easy to find a model of a sphere or cube, but way more possibilities exist. Check this and tell me that it's not a completely bad-ass, must-have object:
ok. we'll do it ;-)
mfg.ads.hzt IOhannes