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...
mfg.as.rd IOhannes
ps:here is my last email regarding this, from 25/02/03:
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?
;-)
mfg.ads.r IOhannes
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
tigital wrote:
On Tuesday, July 22, 2003, at 05:06 AM, IOhannes m zmoelnig wrote:
hi
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...
do i hear some sarcasm? anyhow, great things you have done so far.
...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)?
hm. i cannot quite follow the example with all the numbers going in and out objects (that's the second mail today, i don't understand, maybe i get old ?) basically, you are saying, that it is preferrable to have smaller patches than bloated ones. this of course is true, but i don't think 2 additional objects will bloat a patch. then i think, a patch is clearer if its functionality is defined by its (graphical) structure (connecting [objects]) and not by internal states of objects (connecting with [messages( )
as for the inconsistency: back then in february, i added an argument to the [alpha] object which allowed the setting of the blending function. right now, there are only 2 blending functions (GL_ONE and GL_ONE_MINUS_SRC_ALPHA) and they are addressed arbitrarily with "1" and everything else - this is i find not very intuitive which i addressed as "inconsistent".
as for documentation: indeed gem has become big and undocumented (alas!, this is no news), when even the developers are not informed on features.
...don't recall this, and again, there is no help patch for polygon_smooth...
mfg.asrd IOhannes
On Tuesday, July 22, 2003, at 01:11 PM, IOhannes m zmoelnig wrote:
tigital wrote:
On Tuesday, July 22, 2003, at 05:06 AM, IOhannes m zmoelnig wrote:
hi
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...
do i hear some sarcasm?
...eeek, no! I was just stating my by now obvious limited knowledge of C++ features, such as "inheritance" and "polymorphism": didn't know them beyond buzzwords 3 days ago, but now understand...
anyhow, great things you have done so far.
...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)?
hm. i cannot quite follow the example with all the numbers going in and out objects (that's the second mail today, i don't understand, maybe i get old ?)
...only as old as ya feel! That sentence was a bit of a run-on...sorry...btw, I'm 37: how old are you other guys?
basically, you are saying, that it is preferrable to have smaller patches than bloated ones. this of course is true, but i don't think 2 additional objects will bloat a patch. then i think, a patch is clearer if its functionality is defined by its (graphical) structure (connecting [objects]) and not by internal states of objects (connecting with [messages( )
...I agree, it's nice when you can look at something and tell what it does or doesn't do...unfortunately, that's not the pd/Gem way, what with unlabeled inlets/outlets and sometimes cryptic object names...
as for the inconsistency: back then in february, i added an argument to the [alpha] object which allowed the setting of the blending function. right now, there are only 2 blending functions (GL_ONE and GL_ONE_MINUS_SRC_ALPHA) and they are addressed arbitrarily with "1" and everything else - this is i find not very intuitive which i addressed as "inconsistent".
as for documentation: indeed gem has become big and undocumented (alas!, this is no news), when even the developers are not informed on features.
....yep, it's as simple as that: I didn't know about the feature, yet knew how to add the blend function to the object...let's move on...uh, that is, after we decide: do we remove the blend message from geos that have it and advertise (and expand) the beauties of [alpha], or do we make it from the objects that have it now and make it an inheritable method?
l8r, jamie
ps: I like the fact that we're talking about this stuff, let's keep up the open dialogue
tigital wrote:
On Tuesday, July 22, 2003, at 01:11 PM, IOhannes m zmoelnig wrote:
do i hear some sarcasm?
...eeek, no! I was just stating my by now obvious limited knowledge of C++ features, such as "inheritance" and "polymorphism": didn't know them beyond buzzwords 3 days ago, but now understand...
anyhow, great things you have done so far.
still, you have done quite well (i dare say)
hm. i cannot quite follow the example with all the numbers going in and out objects (that's the second mail today, i don't understand, maybe i get old ?)
...only as old as ya feel! That sentence was a bit of a run-on...sorry...btw, I'm 37: how old are you other guys?
well, of course, and i was laughing at myself while typing in the sentence for the second time... anyhow, 27.
basically, you are saying, that it is preferrable to have smaller patches than bloated ones. this of course is true, but i don't think 2 additional objects will bloat a patch. then i think, a patch is clearer if its functionality is defined by its (graphical) structure (connecting [objects]) and not by internal states of objects (connecting with [messages( )
...I agree, it's nice when you can look at something and tell what it does or doesn't do...unfortunately, that's not the pd/Gem way, what with unlabeled inlets/outlets and sometimes cryptic object names...
yes, but what should we do ? get a hand on miller and...
as for documentation: indeed gem has become big and undocumented (alas!, this is no news), when even the developers are not informed on features.
....yep, it's as simple as that: I didn't know about the feature, yet knew how to add the blend function to the object...let's move on...uh,
and often i find features i have coded myself and didn't know ....
that is, after we decide: do we remove the blend message from geos that have it and advertise (and expand) the beauties of [alpha], or do we make it from the objects that have it now and make it an inheritable method?
personally i'd prefer the [alpha] object. it is just: manips are manips and geos are geos (for me geos are just drawable forms, they don't know anything about color and antialiasing and)
mfg.as.rd IOhannes
-
IOhannes m zmoelnig -
tigital