[GEM-dev] vertex_array branch

[IOhannes m zmoelnig]

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