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:
- 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:
- [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.
- [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