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