Replace GL enum values (eventually)

[donmccurdy]

Mentioned briefly in #1302, and filing here to keep track. I suggest we consider it a longer-term goal to replace GL enums in the format with something API-agnostic. This is a breaking change, and can't happen in the 2.X lifecycle. Prior discussion that lead to the current design (#96, #148) predates glTF 2.0 and our support for other graphics APIs. While GL enums certainly don't prevent anyone from rendering a glTF 2.0 model on DirectX, Metal, or Vulkan, they do give an impression that probably is no longer in the long-term interest of the format.

In the meantime, new extensions (like KHR_blend) should aim to be API-agnostic and not rely on GL enums. Presumably KHR_techniques_webgl is the exception here.

My preference would be for human-readable string enums (like OPAQUE, BLEND, MASK), but also open to other suggestions.

[emackey]

I'm not sure if this change would provide enough benefit for the amount of churn involved. I feel like the API-agnostic message has been fairly well received, with new Vulkan and Direct3D implementations popping up every so often. The numeric enums can be easily viewed and edited in VSCode, for the few people who want to manipulate them by hand.

I do agree that new extensions, when not named explicitly after WebGL, should avoid adding new WebGL-derived enums.

[donmccurdy]

I feel like the API-agnostic message has been fairly well received...

Yes, but between the enums and the name of the format there's definitely still room for confusion, and there have been some negative reactions to that.

I wouldn't want to change the enums in isolation, definitely. But eventually there will be a 3.0 release with other breaking changes, and this is something I'd want to reconsider (perhaps in light of how much other churn we have, or lack thereof) when that happens.

[javagl]

The ratio between "incompatiblity" and "benefit" does not looks soooo good for me right now - to some extent, because the latter is "zero": We could rename the constants, but for what purpose? The primary target for glTF still is GL, so I don't see a direct advantage in such a drastic change....

[donmccurdy]

The ratio between "incompatiblity" and "benefit"...

I'd argue that both technical incompatibility and technical benefit are 'zero' here. 😅 By and large, glTF parsers are not issuing WebGL commands internally, and these enums are being mapped to engines' own enums.

The possible benefit is readability and perception. If that doesn't seem worth a breaking change, though, I'm fine with leaving enums alone in glTF 3+, too.

The primary target for glTF still is GL...

I would rephrase this, the "most common" target for glTF is still GL. But with OpenGL deprecated on macOS, newer graphics APIs should be at least as important as design considerations going forward.

[lexaknyazev]

I'm strongly in favor of replacing GL enums going forward. Possible alternatives:

Strings
A convention in DOM APIs (usually lowercase).
Pros: readability, easy maintenance.
Cons: potential encoding ambiguities, slightly slower parsing, disk / network consumption.

Scoped integers
Like C enums.
Pros: familiar concept for native apps, efficient parsing, no arbitrary values (like in GL).
Cons: harder to read without specialized editor, extending allowed values may require reserving ranges in advance.

I think we should explore supporting both options for glTF 3.0+:

• .gltf (.gltf3?) uses JSON with strings;
• .glb (.glb3?) is fully binary (no string-based JSON for the core) and uses integer enums.

[javagl]

I agree that readability is an issue. Although one memorizes the most common GL constants sooner or later when manually inspecting glTF files, the fact that I once thought that a https://javagl.github.io/GLConstantsTranslator/GLConstantsTranslator.html might be a good idea shows that there's room for improvement.

But we know that strings bring their own issues, e.g. whether it is "Triangle" or "Triangles", or "triangle". Also, one should have a clear idea how to ensure extensibility and possible ambiguities.

However, I assume that the "first shot" on this would be to basically take the GL_* constant names and replace them with the corresponding "camelCase" strings, right?

[donmccurdy]

I don't like the idea of separate enums for the .gltf and .glb extensions very much – minimal binary/JSON differences make it (happily) very easy to handle both with the same parsing code. Using different enums would seem like an unnecessary complication.

Why camelcase? glTF has several string enums already – LINEAR/CUBICSPLINE/STEP, OPAQUE/BLEND/MASK, and (sort of) the attribute semantic names. I'm happy enough with those, except that they're inconsistent with the rest of glTF's (GL-based) enums. 🙃

[lexaknyazev]

Using different enums would seem like an unnecessary complication.

I proposed separate enums in case GLBv3 doesn't use JSON at all. Our existing serialization approach doesn't work well for cases with lots of objects - e.g., 1k meshes using 3k accessors. Each accessor object always contains "componentType" string that takes storage, network, and parsing bandwidth. It would be interesting to explore more aggressive instancing (e.g. shared attribute formats) and using binary buffers for more properties.

[donmccurdy]

I see. That seems like a much longer discussion, if substantial changes to the binary format were to be in V3. We could discuss alternatives (e.g. FlatBuffers) in another issue, and compare storage/network/parsing numbers there. If enum design should be dependent on that, I don't mind setting this question aside until some future date when we have more time to consider V3. For now I've just opened this issue to ensure I don't forget about it before then. 🙂

[coderofsalvation]

So afaik this is a force-field between open humanreadable datastructure (JSON) and size-optimization (binary).
I for example, really like the .gltf (JSON) embedded version (bit sad to see it go in blender export honestly).
It has huge advantages for the server / glTF-file generation, to modify custom properties before serving the final JSON.
Though from a support point of view, I see the issue of having to maintain 2 ways of importing/exporting.
Perhaps JSON decorators called JSON references would be the best of both world: by scanning for $ref in "extras" of each node.
You'd have a binary-first JSON-later glTF, very easy to implement:

custom properties ("extras") like "$ref": "/.my.json" or "$ref:" "/generated/by/server?foo=1 could be a cool way to have servers extend the glTF dynamically, in a progressive enhancement way.