On Aug 10, 2004, at 11:35 AM, IOhannes m zmoelnig wrote:
seeing the as asterisk what about object names like [vtx_color] (for "color_set") [vtx_texcoord*] (for "texcoord_scale") [vtx_color+] (for "color_offset") ?
[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. Some of the other vertex_ objects, like [vertex_combine (blend?)], will eventually work on some combination of vertex, normal, color and texcoord data anyway, so that might be a point of confusion as well?
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.
Hell, maybe we just need to break down and write a GEM specific scripting format! I'm only half-joking about this.
at least we are not going into such problems as Gem.scale vs maxlib.scale with any of these names.
as for "number"-vs-"vertex"-messages this problem will of course be gone as soon as we create an explicit inlet for this data.
mfg.asd.r IOhannes
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev