Add alpha coverage details

[sbtron]

Adding details on alpha coverage as per #822
Also added doubleSided property from common materials extension to core spec since it can be used across multiple material models.

Doc: https://github.com/sbtron/glTF/tree/2.0Transparency/specification/2.0#alpha-coverage
Schemas:
https://github.com/sbtron/glTF/blob/2.0Transparency/specification/2.0/schema/material.schema.json
https://github.com/sbtron/glTF/blob/2.0Transparency/specification/2.0/schema/material.pbrMetallicRoughness.schema.json

@AurL @cedricpinson could you review and ensure this meets your needs so you no longer have to use the extras field.

[bghgary]

This seems a bit out of place. Double sided has nothing to do with alpha coverage?

[bghgary]

nit: a material --> the material (to be consistent with the rest of the descriptions)

[AurL]

@sbtron It looks good, we don't need the extra field anymore, and the doubleSided field will be useful for us as well. We will include these changes in the next update.
Thanks a lot for this.

[emackey]

Agreed glTF needs doubleSided particularly to enable/disable back-face culling. But we should be careful not to confuse this with the choice of single-sided lighting vs. double-sided lighting (specifically, should the back side of a material, if not culled, should render with the front side's normal vector or the opposite of that. Typically, thin translucent materials will use the front side's normal, and thicker opaque materials will flip the normal).

[bghgary]

@emackey We should clarify this in the spec. Should this be an option or should we pick one for the spec?

[emackey]

I wonder if people would agree to an enum here? There could be one enum value to cull the back face, another value to render it with single-sided lighting (using the front face's normal vector) and another option to render it with double-sided lighting (flip the normal vector, after applying the normal map etc). Edit: Changed my mind, see below.

[emackey]

glTF 1.0 had backface culling as an option CULL_FACE in an enum in technique.states. It didn't need to address the single/double-sided lighting question, as that was an implementation detail of the supplied shader.

[bghgary]

I don't have data here. How common is singled-sided lighting vs. double-sided lighting?

[emackey]

I don't have data from the outside world. My company does maintain a collection of aerospace-related models that use both lighting models for different circumstances. But I can't speak for the graphics industry in general.

Ye olde fixed-function OpenGL did this with a parameter named GL_LIGHT_MODEL_TWO_SIDE.

https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/glLightModel.xml

https://msdn.microsoft.com/en-us/library/windows/desktop/dd373582(v=vs.85).aspx

(And if I recall, back then it was rumored to be a small performance hit, so you would never turn on GL_LIGHT_MODEL_TWO_SIDE if you were also going to enable CULL_FACE.)

[emackey]

In WebGL we use gl_FrontFacing to detect which side is being rendered in the fragment shader. Any shader that doesn't pay attention to that effectively uses single-sided lighting when backface culling is turned off. That does keep the shader simpler if we ignore that, so I wouldn't be strongly opposed to omitting the option for two-sided lighting on double-sided materials.

[lexaknyazev]

In #822, we agreed on using alpha for coverage only. Single-sided lighting with double-sided rendering refers to light transmission scenario which we wanted to avoid.

[emackey]

Single-sided lighting with double-sided rendering refers to light transmission scenario which we wanted to avoid.

True, but I may have opened a can of worms here. Take a look at the various sample PBR implementations that have been posted here, do any of them use gl_FrontFace in the fragment shader? I haven't found one that does. ThreeJS.MeshStandardMaterial doesn't support it. Two-sided lighting may be a concept that's fallen out of use, and would require new code paths to support.

In the name of simplicity for the runtime engine, then, we could just offer a boolean for backface culling, but not add the complexity of two-sided lighting. It could be added in an extension later, if needed.

[bghgary]

Single-sided lighting with double-sided rendering refers to light transmission scenario which we wanted to avoid.

What about opaque materials? Should be able to support double-sided and flipped normals on the back?

[lexaknyazev]

What about opaque materials? Should be able to support double-sided and flipped normals on the back?

Yes.

[bghgary]

Should have been more clear with my previous comment. Is the following statement correct?

"Normals should always be flipped on the backside for lighting calculations when doubleSided property is true."

This is the exact opposite of what @emackey said with #864 (comment)?

[emackey]

What about opaque materials? Should be able to support double-sided and flipped normals on the back?

Yes.

No, please, do some research before you jump on this. My own examples were from the 1990's fixed-function days, and looking around today I have yet to find any shaders doing this in modern times. I now think this could become a roadblock to writing conformant glTF renderers.

Remember, the goal of glTF is to deliver something that's easy and practical to render -- not to uphold some purist notions about alpha being used only for coverage. Sometimes we need to be practical.

[emackey]

I hope I didn't derail this with my old memories of two-sided lighting. Having an option to enable/disable backface culling is needed, as is the alpha settings that make up the original point of this PR. Perhaps the lighting issue could be addressed separately.

[bghgary]

I'm working with @BeardedGnome to ensure that it is reasonable to implement double-sided lighting in WebGL, using BabylonJS. If it is reasonable, then I think double-sided materials should imply double-sided lighting (i.e. the normals are flipped on the back side). Thoughts?

[emackey]

It's probably not a huge burden, I think you just test gl_FrontFacing in the fragment shader and then flip the back-facing normals. I just think it may be uncommon these days.

There will be 3D artists who insist on using alpha as non-coverage translucency, as they have no other means to achieve that effect, and some option for single-sided lighting on non-culled back faces will be quite important to them. I'm still under the impression that "modern" rendering engines generally only offer single-sided lighting, so they may expect this quite strongly.

[lexaknyazev]

It's probably not a huge burden, I think you just test gl_FrontFacing in the fragment shader and then flip the back-facing normals. I just think it may be uncommon these days.

@emackey Just to summarize, are you OK with doubleSided bool flag?

There will be 3D artists who insist on using alpha as non-coverage translucency

I think that we should limit the scope of 2.0 material model to opaque (with coverage) materials only. Translucency effects are still important, so future glTF updates should address some of them.

[emackey]

are you OK with doubleSided bool flag?

I want the flag, but I think it would be clearer to name it backfaceCulling or such, although this would change the true/false sense of it.

I don't like the idea of switching both the lighting model and the culling option with a single boolean value, as they are quite separate concerns to the engine. In OpenGL/WebGL, the choice of culling is a simple state enable/disable, but the lighting model requires an extra if block with some vector math in the fragment shader, plus a uniform if you want control of that.

[bghgary]

It looks like Unreal 4 supports two-sided materials with two-sided lighting and they don't have an option to turn two-sided lighting off. Here is what it looks like:

From the top (front of the plane):

From the bottom (back of the plane):

Here is what it takes to implement two-sided lighting in BabylonJS:
BabylonJS/Babylon.js#1930

Here is a live example of what it looks like in BabylonJS:
https://bghgary.github.io/glTF/two-sided-lighting

Given this, I think it's clear that two-sided lighting works and it should be okay for us to assume it is always on since Unreal does it too.

I'm okay with calling it backfaceCulling instead of doubleSided.

Thoughts?

[emackey]

Sounds good. Thanks for looking into UE4.

[bghgary]

We are planning on leaving the name doubleSided since it implies backface culling is off and double-sided lighting is on. This is analogous to UE4 where they have a property called Two Sided on their materials.

[emackey]

If you're doing both from the same flag, then yes, that makes sense.

[McNopper]

FYI, some tools (e.g. Blender) store a similar flag per mesh and not material.

[emackey]

Blender defaults to double-sided, but has a number of options that apply or don't apply to its various rendering engines. Blender Original, Blender Game, Cycles renderer, and the OpenGL/GLSL preview render, as well as the "Multitexture" preview render, all can behave differently or support options that others don't support inside of Blender itself. The OpenGL/GLSL one does make a distinction between double-sided lighting and backface culling, but it may be alone in that distinction.

Anyway, I've agreed to having a single doubleSided flag in glTF. I don't think we should continue to hold up progress on 2.0 for this minor issue. It can always be tweaked with extensions if it turns into a problem later.

[sbtron]

Added explanation of doublesided lighting to readme and schema. @emackey can you review?

[emackey]

Added explanation of doublesided lighting to readme and schema

The new explanation looks correct to me. Thanks!

[McNopper]

Good for me as well.
My comment was more about, that the value is assigned to a mesh and not the material. But as I said, I am fine with this.

[emackey]

@McNopper Ah I see, but, I think the flag does "belong" on the material more than the mesh. Lightwave does this IIRC. Blender does some very odd things like associating its backface culling toggle with particular viewports instead of either meshes or materials. I think associating it with the material makes the most sense, particularly for engines that are trying to minimize render state changes.

[bghgary]

specified should be specifies