[GEM-dev] vertex_array branch

[IOhannes m zmoelnig]

chris clepper wrote:
> On Aug 10, 2004, at 11:35 AM, IOhannes m zmoelnig wrote:
> 
> [vertex_color scale] [vertex_color set] might be another way too?  Put 
> all of the color, texcoord and normal stuff in a single object for each 
> function.  

actually this would be like having a signal-object [~] and a 
float-object [f] and you could send them messages on how to operate...

not really the paradigm of pd (but hey, we are talking about Gem and not 
necessarily pd ;-))

> 
> Another idea would be to have more generic objects:
> 
> [vertex_scale color]  (or [vertex_mult])
> [vertex_set vertex]
> [vertex_blend texcoord]
> [vertex_random normal]
> 
> The object would also respond to messages regarding which part (color, 
> normal) of the arrays to work on, and multiple states could possibly be 
> active at once.  Maybe this would be both more generic in the hip trend 
> of 'matrix' processing and also still allow for enough focus to make 
> development more streamlined and end use easier?  Of course some 
> exceptions would naturally apply that throw the whole thing off.

i like this idea.
it is probably simplest to do (in terms of programming) and makes it 
quite clear what is going on (int terms of patching)

and while i don't think that changing the operation via a message is a 
good idea (like in [vertex_color scale]), but changing the "channel" 
(normal, texcoord) sounds fine to me.

> Hell, maybe we just need to break down and write a GEM specific 
> scripting format!  I'm only half-joking about this.

somebody has asked me to do a [mtx_expr] a while ago (which i consider 
unnecessary as matrix-elements can well be accessed from pd itself)

this and your half-joking idea leads to [pix_expr] and [vertex_expr]. neat.


mfg.a.sdr
IOhannes