-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
KHR_blend #1302
KHR_blend #1302
Conversation
For Babylon.js, we actually exposed only required and used ones. Not a big deal to add more but no user ask for them so far |
Thanks, good to know that it hasn't been a common request, but that implementing more is an option. I'm open to trimming this down; my requirements are basically just additive blending right now. But as-written the extension isn't that complex, so writing additional extensions later for additional blending modes feels a bit silly. Would welcome more opinions here. /cc @stevesan |
Thanks, Don. Additive is definitely the big one, but multiplicative can be useful too for darkening things in an order-independent way. For example, for Blocks glass rendering (example: https://poly.google.com/view/atB26Z6BPd0), we use both a multiply pass and an additive pass. |
For multiple lights, what will happen in this scenario if Multi-pass lighting (forward rendering): for light in lights {
/* additive blending for other lights */
if light != firstLight {
glDepthFunc(GL_EQUAL);
glEnable(GL_BLEND);
glBlendEq(GL_FUNC_ADD);
glBlendFunc(GL_ONE, GL_ONE);
}
renderForLight(light);
} if material needs multi-pass then the blend equations would make sense here: for light in lights {
/* Step 1: render material to FrameBuffer */
for pass in material->passes {
if pass != firstPass {
/* set blend options specified in `EXT_blend`extension */
}
}
/* Step 2: use/bind FrameBuffer texture as material (IF IT IS POSSIBLE FOR EVERY CASE) */
/* Step 3: Additive Blending for other lights */
if light != firstLight {
glDepthFunc(GL_EQUAL);
glEnable(GL_BLEND);
glBlendEq(GL_FUNC_ADD);
glBlendFunc(GL_ONE, GL_ONE);
}
renderForLight(light);
} otherwise I don't know how to render Also some Order-Independed Transparency techniques e.g. Weighted-Blended OIT requires additional blending operations it may cause blending-conflicts too |
@recp I think you may need to separate transparent passes from your multi-pass lighting. If I remember correctly, UE3 (which did multi-pass lighting as you describe) didn't allow dynamic lighting on transparent objects for this reason. Perhaps you could render transparent objects in a single pass with a clamped number of lights? Or, require baked lighting for transparent objects? I'm sure there are better options too. These are implementation details and they really depend on how your runtime is handling its rendering. I'm not sure that the spec of KHR_blend can specify how to implement it in every case. |
@MiiBond thanks for your advices, Actually I render scene in three passes if transparency is active and it is working, it uses Weighted, Blended OIT (for now):
Full implementation: https://github.com/recp/gk/blob/master/src/transp/builtin/oit/weighted_blended.c#L91 I'll update lighting design after implementing morph/skin animations to support custom blending options in materials, then I can support this extension. Also will this extension be valid for opaque objects too (alphaMode != BLEND)? If opaque means that pixels/fragments behind opaque surfaces are completely invisible then why do we need to specify blending for that surfaces? Maybe it should only be valid if |
@donmccurdy I don't see FUNC_MULTIPLY as an option. Was that intentional? I think it's pretty important for modeling things like light absorption. |
So far this extension uses the equation and factor basics of OpenGL, which are combined for different effects. For example multiplicative blending would be:
Common blend types mentioned in Unity docs:
^All assume the blend equation is "add". Probably more of these details should be in the extension spec. 🙂 |
Maybe if this extension is enabled we could have some options:
Having 1 and 2 could be an option, or just 3. I couldn't see FUNC_MULTPLY in GL reference: https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glBlendEquation.xhtml Is FUNC_MULTIPLY DirectX feature? I don't know about DirectX, but in OpenGL if know correctly multiplicative blending (if you meant this) is |
@donmccurdy Yeah, I need to have more coffee this morning. It's been a while since I've looked at blend equations. For some reason, I remembered there being an explicit multiply. @recp I'm not sure that we'd want the presence of an extension to change the default on another property. I think we should just require the author to set the |
To fill in details for any future readers, the core equation is:
Where:
So in the multiplicative example above, we get this, which simply multiplies the two fragment colors:
This article was helpful for me, I'm having to read up on this as well. 😅 |
What about It seems WebGL also supports it: https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/blendFuncSeparate Since EXT_Blend allows custom blending equations it could also support |
@recp it is already covered — because |
@donmccurdy thanks for clarification, I was thought that it is On CPU side But my render engine's state manager can replace |
Hi @donmccurdy and all, we have plans to support this extension in gltf-pipeline (PR CesiumGS/gltf-pipeline#387 (comment)). Are there any more updates expected here? |
Additionally, is |
Renamed to The more likely updates to this extension are those mentioned in #1302 (comment). Most importantly, whether we should move away from the flexible but low-level approach here, toward just allowing a few common blend states. For example, only define Unreal only supports those two blend modes (in addition to the three already in glTF: opaque, masked, translucent), unless there is a mechanism to use more modes than Unreal docs describe here, so that's an argument for simplifying. On the other hand, Unity's docs claim the following modes are "the most common blend types":
|
Thanks @donmccurdy! We'd be fine with ether the abstracted blend states or the low level blend functions. |
From the perspective of Adobe Dimension, we will most likely only need the simple additive and multiplicative blending. The Adobe Animate team are interested in this extension as well and have more complex uses. So, I think Adobe would prefer to keep this full specification rather than simplify it. |
I think #822 (comment) makes an argument that |
Combining alpha blending with alpha cutoff seems practical, and probably worth including with this extension... If so: core material |
@donmccurdy is this ready to merge once it has a JSON schema? @MiiBond have you implemented this? If not, does it look like it will meet your needs and should we wait for you to implement it? @ggetz did we implement this in Cesium? |
There's an implementation of this extension in glTF-Pipeline, at least. I'm still not really confident whether the low-level blend modes here are the right choice, or whether we want discrete named states like: Add, Subtract, Multiply, Screen, Divide, Difference, Darken, Lighten, Overlay, Dodge, Burn, Hue, Saturation, Value, Color, Soft Light, Linear Light, ... Before we merge the extension, additional feedback (@MiiBond, @AurL, others?) would still be welcome. It also seems important to know whether model sources like Sketchfab or authoring tools are likely to implement it, or whether it's just engines interested so far. I think Google Poly will likely use the extension, but need to re-confirm on that. |
One other thought – I'm very tempted to pull the GL integer constants out in favor of string enums. In general I think new extensions should likely shift that way. |
I have the same concerns. Let's discuss on the next call. For the reference, here's the current state of API-level options. Factors
There are additional four factors for "Dual-Source Blending" that are supported by modern pipelines. They require specific fragment shader outputs, so we cannot expose them. Operations
Advanced OperationsThere are 46 more blending operations available in It's worth noting that Khronos-ratified version of the OpenGL extension (
|
This is implemented in Cesium as of #1302 (comment) in CesiumGS/cesium#6805. #1302 (comment) would just need to be addressed. |
We have not implemented this in Dimension and are unlikely to at this point, I think. My feeling is that it's probably still a useful extension but I'd want the ability to control render order in glTF before it would become really useful. |
Thanks @lexaknyazev, good points. Let's discuss more this week. In that list of 15 blend modes, I'm surprised not to see additive blending. Have I missed something, or are those 15 meant to be an addition to other blend modes? Thanks for the update @MiiBond! Agreed about render order, and perhaps also depth test for that matter. I wonder if that should be in scope for this extension, or considered in parallel. I'm not opposed to the low-levelness so much as the possibility that many tools may only support certain discrete blend modes. If users write an arbitrary combination of factors and operations, the result won't load in most DCC tools but might be OK in most engines. And even if we stick with low-level modes, we shouldn't be too OpenGL-specific. |
Yes, since they are defined in an extension. Original NVIDIA-proposed 46 modes include a full set of "high-level" blending operations including those that can be represented with low-level factors/operations.
I think there are two distinct questions here:
Just for reference, all OpenGL ES 3.0 blending modes have 1:1 mappings in other graphical APIs. |
Closing this PR for the time being. Currently we are more focused on the extensions listed here: https://github.com/KhronosGroup/glTF/tree/master/extensions#in-progress-khronos-and-multi-vendor-extensions |
Posting comments from a recent conversation in the KhronosDevs Slack. Would be nice to mimic the SparkARStudio BlendMode settings: I created this chart a few years back when I was developing for the Wii (not using glTF). I found it useful when making shaders in Unity as well. I'd love to see this available in glTF someday, so powerful. |
Is there any interest in reviving an extension like this? |
Hi. I'd like to add my voice in favour of needing additive blending. I think reducing the scope of this to being purely about additive would maybe help move things forward. Other modes have far less utility and are used much less commonly. My strongest argument would be that it is present as a core option in nearly every material editor I've ever used. It's essential to recreate many common effects and far beyond what has been referred to as "particle effects" (itself an incredibly broad area in terms of application) Along with unlit - additive is used for many things where you want to model elements that aren't solid surfaces. It can be used for light beams, fog, a cheap glow/bloom, planet atmospheres, halos, fire and so on. It's critical for us on Open Brush - most existing artworks make extensive use of additive brushes. But I suspect we're not alone in this respect. |
Complement to #1296, in the hope that blending can be kept WebGL-agnostic. DirectX supports many blend operations that GL does not; currently those are omitted from this extension for compatibility. I also did not attempt to include
gl.blendColor
.BabylonJS and Unreal appear to skip many of these blending equations. I wouldn't be opposed to cutting back to just the intersection, but would like to get more feedback on this first. @bghgary any preference, or rationale behind Babylon's choices here? Found this thread.
TODO:
alphaMode == BLEND
requirement. Is extension invalid when this is not the case, or simply ignored? Do we allowalphaMode === MASK
, too?blendFactors
.References:
Reference: https://user-images.githubusercontent.com/1848368/38159786-bca1e3ea-3464-11e8-9d3b-9d1a1e8cac74.jpg