[GEM-dev] vertex_array branch

chris clepper cgc at humboldtblvd.com
Tue Aug 10 20:04:44 CEST 2004


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 at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/gem-dev





More information about the GEM-dev mailing list