-
Notifications
You must be signed in to change notification settings - Fork 211
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add blend parameter #2061
Add blend parameter #2061
Conversation
16d094c
to
d9095d1
Compare
if (parameters.blendColorOperation === 'none' || parameters.blendAlphaOperation === 'none') { | ||
gl.disable(GL.BLEND); | ||
} else { | ||
gl.enable(GL.BLEND); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because neither WebGL nor WebGPU enables blending for color and alpha separately from the other, the answers to what is the default value of blendAlphaOperation
or what happens with blendColorOperation='add' + blendAlphaOperation='none'
are getting a bit complicated. I wonder if we should:
- (A) disallow 'none' for blendAlphaOperation, only use blendColorOperation to enable/disable blending
- (B) add a separate boolean parameter to enable/disable blending
if (parameters.blend === true) {
const colorEquation = convertBlendOperationToEquation(
'blendColorOperation',
parameters.blendColorOperation || 'add'
);
// ...
} else {
// ...
}
I lean toward (b), but not a strong preference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I initially proposed adding a none
option when I was notified of the problem, after reviewing the PR and thinking more about it, I am also thinking that a separate blend
enable type parameter seems cleanest.
d9095d1
to
49ec4bf
Compare
49ec4bf
to
c6b6fc3
Compare
@@ -10,6 +10,7 @@ | |||
}, | |||
"references": [ | |||
{"path": "../core"}, | |||
{"path": "../engine"}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there anyway we can avoid this?
|
||
if (parameters.blendColorOperation || parameters.blendAlphaOperation) { | ||
gl.enable(GL.BLEND); | ||
if (parameters.blend === undefined) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This auto-enabling seems subtle.
- Is there any reason not to require
blend: true
to be set and remove the auto-enable? - If some good backwards compatibility reason then maybe add a comment explaining that so that when we invariably refactor this next time, we don't break things in deck without knowing?
Co-authored-by: Ib Green <ib@foursquare.com>
Per[ oboarding checklist,](openjs-foundation/project-status#65) adds luma.gl code of conduct to match openjs/vis.gl
Co-authored-by: Ib Green <ib@foursquare.com>
@Pessimistress merging, but removed the auto-enabling. we can open a separate PR with those changes if you feel they are important enough. |
Allow WebGL render pass to explicitly disable blending
Since WebGPU render pass has blending disabled by default this value will be safely ignored?
Change List