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