[GEM-dev] Re: "blend"-messages

[tigital]

On Tuesday, July 22, 2003, at 05:06  AM, IOhannes m zmoelnig wrote:

> hi
>
> i just noticed, that jamie has committed changes to the "cube"-Geos, 
> to allow a [blend 1/0( message.
>
> however, to avoid restarting this and to save everyone a lot of 
> programming time, i would suggest:
> 1) using inheritance rather than putting the same piece of code in 
> each Geo.
> 2) (more important): why not use [alpha] and [polygon_smooth] ?
> i think this has been discussed.
> [alpha] certainly needs more attention to make the 
> blending-style-setting more consistent.
>
> i don't think, that there is any performance-issue in this, and it 
> could save us all (jamie) a lot of time...

...sure, I'd love to save some time:  who wouldn't?  I've actually been 
reading stroustrup to bone up on c++ stuff (remember:  I was schooled 
as a neurobiologist, not a computer scientist); when I started the 
porting of GEM to OSX last year (and we are about at it's one year 
mark), I knew nothing beyond c...

...chris and I actually talked about this blending stuff last weekend;  
we knew that alpha was a possibility, but didn't know if it was a full 
replacement...also, it takes less space in a patch to have a number 
going into a blend message than it does to have a number going into a 
colorRGB that goes into alpha that goes into the geo...I was just 
uninformed of other ways to do blending and needed a transparent 
cube...but at the same time you mention that alpha is somehow 
inconsistent:  how so?   Does it allow internal transparancy (back to 
front & front to back)?

ps:here is my last email regarding this, from 25/02/03:
>
...don't recall this, and again, there is no help patch for 
polygon_smooth...

> chris clepper wrote:
>
> >> and another two changes:
> >>
> >> 1. [alpha]
> >> now you can set the blending-function
> >> 0..GL_ONE_MINUS_SRC_ALPHA that's the (old) default
> >> 1..GL_ONE (as would be enabled by the "blend" message to various 
> objects.
> >
> >
>
> > perhaps we should add some of the other options for glBlend and 
> allow both the source and destination to be changed.
>
>
> yes definitely.
> it was just done very quickly.
>
> >
> >> 2. [polygon_smooth]
> >> enables polygon smoothing
> >>
> >
> > the only difference i found is that [polygon_smooth] sets blending 
> for the entire render chain it's attached to while the "blend" method 
> would actually work on individual objects in the same chain.  it's 
> probably not a big deal, and maybe not even a big feature to warrant 
> keeping "blend".  it's definitely easier to do the [polygon_smooth] 
> rather than add glBlend to each Geo.
>
>
> it enables aa'ing for everything that comes below the 
> [polygon_smoothing].
> Maybe we should just add a another state that disables aa'ing:
> suggestion:
> 1 .. enable smoothing
> 0 .. disbale smoothing
> -1 .. leave unchanged
>
>
> >> i think [polygon_smooth] is a bad name. but which one would be 
> better ?
> >
> > still no suggestions for the name...  maybe wrapping [alpha], [color]
>
> well, yes it is not that bad. (at least better than [pix_a_2grey])
>
> > and [polygon_smooth] up in an abstraction called [geo_blend] would 
> be something to try?

l8r,
jamie