 |
Author |
Topic: Setting opacity in fill()? (Read 582 times) |
|
narain
|
Setting opacity in fill()?
« on: May 4th, 2004, 8:03am » |
|
This may be a bug, or it may be something I'm doing wrong.
I'm trying to draw transparent shapes overlaid on each other and the background.
But if I add an alpha parameter in fill(), ie if I do fill(color(r,g,b),alpha), I get transparency all right but the fill color becomes black! Not using the alpha in fill(color(r,g,b)) gives me the right color, btw.
Am I using alpha for the wrong purpose? Is this a bug? What's the right way to draw shapes with transparency in Processing?
|
|
|
|
|
mKoser
 
|
Re: Setting opacity in fill()?
« Reply #1 on: May 4th, 2004, 11:41am » |
|
yeah, this problem occurs when trying to use an alpha-value that is too low.
i just tried to find exactly where the breaking-point is by changing the alphaVal-variable from 1 and up .... on my screen the difference between left and right are actually visible all the way up to the mid-50's!
Code:
int alphaVal = 15;
void setup(){
size(300, 300);
background(255);
noStroke();
}
void loop(){
fill(255, 0, 0, alphaVal);
rect(0, 0, width/2, height);
fill(255, 0, 0);
rect(width/2, 0, width, height);
}
|
|
this problem has been reported... i don't remember seeing a solution/hack for it though!
+ mikkel
|
mikkel crone koser | www.beyondthree.com | http://processing.beyondthree.com
|
|
|
mKoser
|
Re: Setting opacity in fill()?
« Reply #2 on: May 4th, 2004, 11:50am » |
|
hmm...
i guess you'd be able to do somewhat of a work-around by manipulating the pixel-buffer pixels[] directly:
Code:
int alphaVal = 2;
void setup(){
size(300, 300);
background(255);
}
void loop(){
// fade
for(int i=0; i<pixels.length; i++){
pixels[i] = color(red(pixels[i]), green(pixels[i])-alphaVal, blue(pixels[i])-alphaVal);
}
}
|
|
|
mikkel crone koser | www.beyondthree.com | http://processing.beyondthree.com
|
|
|
fry
|
Re: Setting opacity in fill()?
« Reply #4 on: May 4th, 2004, 4:44pm » |
|
anyone have any suggestions on a better fix for this?
one method to fix would be that we could require a decimal place on gray values:
fill(128.0); // that means 50% gray
this would be a little confusing since:
fill(128 ) would no longer work properly (this would be black with a 50% alpha), yet fill(128, 0, 0) works just fine.
outside of that, we'd have to change the language  which would be ideal, but we don't have anyone to work on the parser/compiler (it's a big job).
|
| « Last Edit: May 4th, 2004, 4:45pm by fry » |
|
|
|
|
TomC
|
Re: Setting opacity in fill()?
« Reply #5 on: May 4th, 2004, 6:25pm » |
|
on May 4th, 2004, 4:44pm, fry wrote:
fill(128 ) would no longer work properly (this would be black with a 50% alpha) |
|
Wouldn't it be 50% blue I thought you were packing as ARGB
I'm still not sure what's wrong with my solution of catching values with alpha (and assuming that they are colors) and catching values < 255 (and assuming they are gray). The only hitch would be if someone made a color with e.g. myblue = color(0,0,someBlue,0), and then tried to up its alpha using fill(myBlue, 10) or something.
I suppose strong-typing of color is out of the question (the aforementioned 'big' compiler job)
|
| « Last Edit: May 4th, 2004, 6:26pm by TomC » |
|
|
|
|
fry
|
Re: Setting opacity in fill()?
« Reply #6 on: May 4th, 2004, 8:25pm » |
|
50% blue.. actually you're right.. whups. it'd be 50% blue, but 0% alpha, so invisible.
your solution is the one that's been in processing all along, but it's not perfect. it also breaks down when odd colorMode() settings are used (we can't assume that it's always gonna be < 255.. but it uses the max of the colorMode params). there may also be bugs in the current implementation, but that's what it's *supposed* to be doing.
strong typing of color is the compiler stuff, yep. i'd far prefer that, but it's an entire project to get a better compiler in there.
|
|
|
|
|
TomC
|
Re: Setting opacity in fill()?
« Reply #7 on: May 5th, 2004, 12:39am » |
|
OK, an 'aha' moment. I hadn't considered what you would be up to with colorMode. Ick... *steps aside*
How difficult, actually, is the compiler problem? (A tough cookie that's been tried and failed, or just one that nobody wants to think about for now?) It a case of a preprocessor that can find anywhere a color is declared and change fill/stroke/color/background calls where that color is an argument to color specific ones? (Still stood to the side by the way, just gaping out of morbid curiosity).
Or how about a color(color,alpha) function? Or would the opposite problem be destined to occur when someone asked for color(gray,alpha)?
Thinking out loud... (for a change...)
|
|
|
|
|
narain
|
Re: Setting opacity in fill()?
« Reply #8 on: May 5th, 2004, 1:53pm » |
|
"...find anywhere a color is declared and change fill/stroke/color/background calls where that color is an argument to color specific ones..."
Then you have issues of scope... In one block, a variable "c" may be an float, in another it may be a color, so you have to figure out which one's being used... Ick indeed.
I suppose colors as int[4] arrays is out of the question for performance issues...
|
|
|
|
|
|
