Skip to content
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

Adobe_render_order extension proposal #1604

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

Jaswant99
Copy link

I'd like to propose an extension to leverage various applications of render order, depthTest, depthWrite and colorWrite. To avoid Z-fighting in two coplanar meshes render order is needed with depth writing and depth testing options. It could be helpful while drawing three-dimensional translucent objects to get different appearances.

@emackey
Copy link
Member

emackey commented Apr 30, 2019

This looks like a good start. Can certainly see the use for realtime rendering of translucent geometry.

@MiiBond
Copy link
Contributor

MiiBond commented Apr 30, 2019

Ideally, we could at least make this a EXT extension, if there are other interested parties. It would be very useful in conjunction with the already proposed KHR_blend extension #1302

@donmccurdy
Copy link
Contributor

This might also be a reasonable place to include a "visible": false or "render": false property, as discussed for EXT_property_animation.

@MiiBond
Copy link
Contributor

MiiBond commented May 3, 2019

Just some thoughts after the call on Wednesday:
The issue was raised that this extension feels too much like it's telling the renderer explicitly how to behave (with depthWrite flags, etc.) rather than defining what the end results should look like. So perhaps redefining this extension in terms of mesh/material layering rather than render order is more appropriate.
There are two primary use cases that this extension is designed to handle so maybe we should consider them separately and that may help us arrive at the best solution.

  1. Transparency Render Order. This is basically layered materials. Perhaps each mesh primitive could specify an array of materials and each of those materials is free to use the KHR_blend extension to define how each layer blends on top.
  2. Z-fighting. This can occur between between any meshes and feels like maybe it should be a separate extension from layered materials. The Adobe Animate situation is pretty extreme as they have many, many animated meshes interacting on essentially a 2D plane. To display this properly, it's a matter of the viewer being setup to use logarithmic depth and/or drastically restricting the camera's clipping planes. Unfortunately, most viewers don't even look at the cameras that are defined in the glTF and there's, or course, no way to specify that logarithmic depth is required to view the asset.

@lexaknyazev
Copy link
Member

Since colorWrite: false corresponds logically to colorMask(0, 0, 0, 0) which is usually seen as a part of blend state, I think it may be useful to evaluate this proposal in a more broad context of describing desired pipeline state.

So far, it seems that we may be interested in controlling some of these options (based on other open issues):
image

Notes on features support:

  • MIN and MAX blending operations require EXT_blend_minmax extension when using OpenGL ES 2.0 / WebGL 1.0.
  • Alpha-to-One requires EXT_multisample_compatibility extension when using OpenGL ES; requires alphaToOne feature when using Vulkan; no support on D3D.
  • Depth Bias Clamp requires EXT_polygon_offset_clamp when using OpenGL ES or OpenGL <4.6; requires depthBiasClamp feature when using Vulkan.

We have a somewhat similar issue with the proposed KHR_blend extension.

/cc @donmccurdy

@MiiBond
Copy link
Contributor

MiiBond commented Jun 26, 2019

Is there any concern that explicitly defining rendering state is a little too low level for glTF? Is this abstract-enough to apply equally well to ray-tracers, for example? Maybe it is.
Basically, the feature that we want to add is the ability to define various layers and how they combine.
EXT_render_layers?

@aaronfranke
Copy link
Contributor

For what @donmccurdy mentioned above about visibility, there is KHR_node_visibility.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants