Support for desktop OpenGL features

[NicolBolas]

I know that glTF is focused primarily on WebGL (based on GL ES 2.0). But what is the chance of getting more OpenGL support for desktop OpenGL 3.0+?

Rendering states are missing numerous recent features like:

• Handling for multiple fragment output colors, including:
  • Blend enable/disable per output color (OpenGL 3.0)
  • Blending parameters per output color (OpenGL 4.0)
  • Write masking per output color. (OpenGL 3.0)
• Multiple viewports and scissor boxes (OpenGL 4.1)
• Logical operations (OpenGL 1.0!)
• Stencil test (OpenGL 1.0!)

Per-program settings are missing things like:

• Transform feedback parameters (OpenGL 3.0)
• Shader stages other than vertex and fragment (OpenGL 3.2, 4.0)

Technique parameters do not have the ability to:

• Operate on input/output/uniform locations rather than names. GL 3.3 gave shaders the ability to specify input/output locations, and GL 4.3 gave this to uniforms as well.
• Handle multiple fragment shader outputs (OpenGL 3.0)
• Deal with uniform buffers (OpenGL 3.1)
• Deal with shader storage buffers (OpenGL 4.3)
• Handle image variables. (OpenGL 4.2)
• Operate on sampler variables by texture image unit index rather than by name (OpenGL 4.2)

There is a lot missing from glTF that desktop OpenGL is capable of doing. That makes glTF not really viable for desktop applications that are looking to yoke its strengths.

At the very least, glTF should support OpenGL ES 3.2-level features (which includes most of the above).

[pjcozzi]

Thanks for the writeup. I agree there is a lot to add to glTF to take full advantage of OpenGL. You are welcome to propose extensions in this direction if you get to it before us. :)

[ParticlePeter]

TransformFeedback does not require the Fragment Shader, hence this stage should be optional as well. This cannot be managed via extension.
Moreover its not possible to specify a Shader file with multiple Shader stages. Such a file could be parsed and split up by the underlying engine. But, again, Vertex and Fragment Shaders are unfortunately mandatory. This should be changed to optional in the core spec.

[NicolBolas]

But, again, Vertex and Fragment Shaders are unfortunately mandatory. This should be changed to optional in the core spec.

I believe vertex shaders are mandatory for any rendering operation. Fragment shaders are of course optional.

Oh, and the single-file/multiple-stages thing will become especially important with SPIR-V. Not just because that will allow people to use whatever shading language they want. But because SPIR-V itself explicitly supports that style.

[ParticlePeter]

I believe vertex shaders are mandatory for any rendering operation. Fragment shaders are of course optional.

I aggree, but my concern was about the glTf spec of a program which forces you to specify at least one vertex shader file and one fragment shader file.

Oh, and the single-file/multiple-stages thing will become especially important with SPIR-V. Not just because that will allow people to use whatever shading language they want. But because SPIR-V itself explicitly supports that style.

And there is no way/token to specify either a binary SPIR-V or a multi-stage glsl text file. Morover, if such tokens would (will) be added the vertex shader must not be mandatory.

[NicolBolas]

To be fair, the OpenGL Shading Language does not provide support for a "multi-stage glsl text file". Some people may create such a thing via a pre-processing step, but that would be their own shader format, not GLSL.

Morover, if such tokens would (will) be added the vertex shader must not be mandatory.

I'm curious as to what the use case would be for a program that had no vertex shader.

[pjcozzi]

glTF has a profile object with api and version properties, e.g., ("WebGL", "1.0.3"). When we introduce an OpenGL profile, we can make the fragment shader option for it.

[ParticlePeter]

@pjcozzi On second thoughts, if one wants to standardize file exchange, it makes sense to guarantee that data is correctly rendered. Best way is to ship the relevant shaders, so keep it. I have not considered profiles and this seems to be an elegant approach.

@NicolBolas

To be fair, the OpenGL Shading Language does not provide support for a "multi-stage glsl text file". Some people may create such a thing via a pre-processing step, but that would be their own shader format, not GLSL.

Let me correct you, OpenGL does not provide support for any kind of shader FILE. You create a shader (stage) with passing c-string(s) to glShaderSource (I guess it is similar with WebGL). Hence this "pre-process" is always involved just by opening and reading a file and converting to a string. A specification that a GLSL FILE must be this and that does not exist, this is already reflected in all the different file extensions in use like .vert, .frag, .vs, .fs, .vp, .fp, .glsl ... and in essence they are just all text files.
https://www.opengl.org/discussion_boards/showthread.php/169878-GLSL-Shader-File-Extensions
http://stackoverflow.com/questions/6432838/what-is-the-correct-file-extension-for-glsl-shaders

I admit, one file per stage is the most common and straight forward to open and pass to the driver, but no-one forces you to use that path.

That being said, I never argued that OpenGL does not need a vertex shader, the argument was about the glTF spec. Surely you agree that when a SPIR-V file is referenced in glTF file additional reference to a vertex and/or fragment file would be redundant.

Oh, and the single-file/multiple-stages thing will become especially important with SPIR-V. Not just because that will allow people to use whatever shading language they want. But because SPIR-V itself explicitly supports that style.

Btw, I couldn't find any hint that SPIR-V can contain multiple shader stages, neither in the spec nor via google. However, I honestly hope you're right, but could you point me to your source please?

Sorry for kind of hijacking this issue, but I feel it has relevance for glTF if OpenGL and Vulkan are supposed to be first class citizens.

[NicolBolas]

@ParticlePeter

Let me correct you, OpenGL does not provide support for any kind of shader FILE.

I'm well aware of that; perhaps you should look at the name on the accepted answer on that Stack Overflow question you cited ;)

My point is that glTF data basically goes straight into OpenGL. And therefore, it needs to work the way OpenGL works. If OpenGL cannot accept a single string as being used for multiple shader stages, then glTF should not allow you to specify a single "file" that is used by multiple shader stages.

GLSL does not have a way to take a single shader string and use part of it as the vertex shader and part as the fragment shader. Therefore, if glTF is going to allow you to do that, it would need to define a mechanism to detect which parts of a shader file/string/whatever-you-want-to-call-it were the vertex shader and which parts were the fragment shader.

That's not something glTF ought to do.

Btw, I couldn't find any hint that SPIR-V can contain multiple shader stages, neither in the spec nor via google. However, I honestly hope you're right, but could you point me to your source please?

Sorry for being so late with this, but my source is the SPIR-V specification itself.

1. A SPIR-V file can have multiple entrypoints. There are no exceptions made for this. While Vulkan or OpenGL-bound SPIR-V could explicitly override this, there is nothing in the SPIR-V spec that suggests that this would be the case.
2. SPIR-V execution models are associated with entrypoints, not with the module itself. This means that each entrypoint specifies which shader stage it is associated with.
3. SPIR-V entrypoints must explicitly state which input variables they read and which output variables they write. This makes it easy for the compiler to detect which inputs/outputs are part of which shader stages. Even though it makes it much harder for modules to be able to define their own inputs/outputs.

All of these were explicit changes made to SPIR-V between older 0.99 versions and 1.0. Older SPIR-V versions only allowed multiple entrypoints in a module if your module used the Kernel execution model, and execution models were bound to a module, not an entrypoint.

[pjcozzi]

• Related: "Accessor is missing "normalized" property", Accessor is missing "normalized" property #344

[NicolBolas]

glTF 2.0 effectively obsoletes this bug, by going to a standardized surface description. Well, standardized once Appendix B is finished, that is ;)

Most aspects of this bug are outside of the domain for glTF 2.0. We might benefit from a few more blend modes, but that can go into a more specific bug/feature request.