Adobe_render_order extension proposal

[Jaswant99]

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]

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

[MiiBond]

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]

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

[MiiBond]

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]

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):

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]

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]

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