[GEM-dev] vertex_array branch

[IOhannes m zmoelnig]

chris clepper wrote:
> 
> On Aug 10, 2004, at 2:26 AM, IOhannes m zmoelnig wrote:
> 
>>
>>> what i do not understand on [color_set] is
>>> a) the name: wouldn't [vertex_color] fit better (to see what it is 
>>> meant for, like [part_color])
>>> b) the message "number": why is it "number" and not "vertex" as in 
>>> [vertex_offset] ? i think the 2 are so similiar that 2 different 
>>> messages for the same behaviour is non-intuitive.
>>
>>
>> any comments on these ?
>> i would like to release this as soon as possible (to not start 
>> releasing for 3 years again...)
>>
>> would it make sense to put it in a separate directory (just like 
>> particles) ??
> 
> 
> The idea is to have all of the color manipulations separate from the 
> vertex position ones.  So color_set just sets the color value, 
> overwriting the current data, while the not-yet-existing color_scale 
> would multiply the color values by a value (useful for alpha-blending 
> and fading perhaps?).  The naming convention would continue to 
> texcoord_scale, normal_set, and so on.

i think i understand.
but the color-manipulations we are talking about apply just to 
vertex-arrays (?).
so what i meant was that i wouldn't have thought that [color_set] did 
something with the Geo i loaded via [vertex_model] -- to be honest in my 
first attempt to make the vertex-stuff going i haven't even compiled 
color_set, because i have only added all the vertex_* files to my makefile.

eventually one could incorporate the [color_set]-features into [color] 
and [colorRGB] (if a colorArray is present use it, else just call 
glColor()) - but this would probably be even more confusing.
and [color_scale] (which i think is a good idea) would not work at all 
with "normal" geos.

so what i meant is, that each object that only makes sense in connection 
with "vertex-data" should be prefixed with a terse identifier (i agree 
that [vertex_color_set] or even [vertex_texcoord_scale] is a bit clumsy)
[vtx_*] might be better (although "vtx" probably needs more time to get 
familiar with than "vertex")

seeing the as asterisk what about object names like
[vtx_color] (for "color_set")
[vtx_texcoord*] (for "texcoord_scale")
[vtx_color+] (for "color_offset")
?

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