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.
- [polygon_smooth]
enables polygon smoothing
i think this is better than having to add the "blend" method to all Geos. So users can decide what they need. (and they need to know about it anyhow)
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.
i think [polygon_smooth] is a bad name. but which one would be better ?
still no suggestions for the name... maybe wrapping [alpha], [color] and [polygon_smooth] up in an abstraction called [geo_blend] would be something to try?
cgc
someone brought up the issue of using float vs int arguments to the pix_ objects, but i can't find the mail right now.
i have been thinking about it a bit and there's really not any way to use one or the other for every pix object. [pix_gain] makes sense to have a float arg for the gain value since this mirrors gain in the audio realm, but when dealing with exact pixel values such as arguments to color correction or keying then the integer values of the pixel need to be used. the exact RGB or YUV integer value in certain objects is much more precise than using a float and it saves conversions.
an object like [pix_offset] should use integer arguments rather than floats for example. some of the objects i have committed need to be changed from ints to floats as well.
cgc
chris clepper wrote:
someone brought up the issue of using float vs int arguments to the pix_ objects, but i can't find the mail right now.
that was me. i think it was in a personal email to you.
be used. the exact RGB or YUV integer value in certain objects is much more precise than using a float
true
and it saves conversions.
well, i guess one conversion per processing a whole picture (or better: one conversion when setting a value) is not that bad.
an object like [pix_offset] should use integer arguments rather than floats for example.
int is surely the "right" way. but i though it more convenient to use floats (0..1) which "maps" automagically to ints when using negative numbers (-1 .. -255). But of course, that's not correct in mathematical terms....
and then we have all these compatibility issues with old patches...
mfg.ads.r IOhannes
chris clepper wrote:
someone brought up the issue of using float vs int arguments to the pix_ objects, but i can't find the mail right now.
that was me. i think it was in a personal email to you.
be used. the exact RGB or YUV integer value in certain objects is much more precise than using a float
true
and it saves conversions.
well, i guess one conversion per processing a whole picture (or better: one conversion when setting a value) is not that bad.
right, but my point is more about precision and ease of use. i'm about to commit [pix_chroma_key] which has R G B (or Y U V) for the key value as an int, which makes more sense to use than a float. to my mind it's easier to work with R=100 G=10 B=135 rather than figure out the percentage 135 is of 255. of course you can add a few [/ 255] before the object but that seems like a wasteful method. also, i'm working on some objects that move pixels around in various ways and it's just insane to use a float 0..1 to describe a 4:3 image. you'll go mad trying to keep the numbers straight (in fact, GL is now moving away from float texture mapping to int).
an object like [pix_offset] should use integer arguments rather than floats for example.
int is surely the "right" way. but i though it more convenient to use floats (0..1) which "maps" automagically to ints when using negative numbers (-1 .. -255). But of course, that's not correct in mathematical terms....
i do think that floats make sense for most objects and in GEM as a whole since both audio and GL use floats. but there are certain cases where ints work better than floats.
and then we have all these compatibility issues with old patches...
good point, so maybe there really is no need to change existing objects. in fact, [pix_offset] might work just as well using floats since it does make sense to subtract 6% from blue or add 15% to red, etc. so just new objects need to have the option of using ints as arguments? it really makes using some of the objects i'm working on a whole lot easier..
cgc
mfg.ads.r IOhannes
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
-
chris clepper -
IOhannes zmoelnig