[GEM-dev] new message to [pix_texture] vote

[james tittle]

hey ben,

On Mar 6, 2006, at 9:41 AM, B. Bogart wrote:
> why not "decal" "replace" "blend" "add" "combine" etc..?

...because I'm lazy?  :-)  Really, I thought one of pd's design goals  
is that everything is addressable as a number, but come to think of  
it there wouldn't be too much of a problem just having it both ways,  
since the numbering is arbitrary...so, in this case, GL_REPLACE could  
be done with [env 0< or [env replace<...Is this cool?

> yes its more messages, but a heck of a lot more clear than something
> like "mode" which should really be "rectangular" or "square"  
> shouldn't it?

...I agree, but again it's just convenience...

> What do these functions actually do? "envmode" or "env_mode" are not
> very illuminating...

...get that RED BOOK, now!  Really, I'm not joking:  you won't regret  
it...in short, tho, there are different modes of texturing, which to  
be fully explained really need an examination of the graphics  
pipeline...suffice it to say that at some point we actually calculate  
a surface color, which can have many different parameters affecting  
it:  fog, lighting, multiple textures, material color, etc...since  
[pix_texture] deals with 2D maps, we can either REPLACE whatever's in  
the pipeline, DECAL over it, or ADD/COMBINE/MODULATE the existing  
fragment...the last few are the most interesting, of  
course...MODULATE has been the default, and can be seen in the new  
helpfile by my inclusion of the [color] gemobject:  change the color,  
and you modulate the 2D texture...ADD is similar, but different, and  
REPLACE makes the color change have no effect...

...of course this'll be more useful with [pix_multitexture],  
especially when we figure out an easy way to get all the geo's  
multitexcoord aware (either by hand or by automatic generation of  
texture coordinates)...

james