Do not make "instanceTechnique" mandatory in "materials". "technique" at all should be just optional.

[McNopper]

In my opinion, "instanceTechnique" should be just optional in materials and it should be somehow possible to directly set the material values (see a modified example from duck.json at the end).

Also, I want to have the "technique" element just to be optional. This field and the tree behind it binds the asset to strong to the version of the GL API, the render technique and also makes the JSON file unnecessary big and complicated.

"materials": {
"blinn3-fx": {
"values": {
"ambient": [
0,
0,
0,
1
],
"diffuse": "texture_file2",
"emission": [
0,
0,
0,
1
],
"shininess": 38.4,
"specular": [
0,
0,
0,
1
]
},
"name": "blinn3"
}
}

[fabrobinet]

Thanks for the feedback - it looks like you have nice stuffs on your repo :).

Since you do not want to worry about instanceTechnique, I assume your engine or the middleware you are using (or maybe GL fixed pipeline) is able to deal with the parameters and all the necessary shaders will be available for you already... but that's not the general case.

I completely understand the desire to simplify, but in order to be able to render fully a asset using GL and glTF, glTF has to provide every data including shaders and gl states and doing so you have to be tied to a specific GL API. (and providing them involves using techniques/passes).
One way to see glTF is a declarative & serialization layer on top of a specifc GL API along the minimal higher level concepts (like node hierarchy, skinning...) to be able to render assets.
This is especially true for adopters who just want to implement a simple data driven glTF renderer (not relying on a middleware able to generate shaders...)

Also, normally you should still dive into the instanceTechnique, but using the -d options with the convert all the meta informations needed to regenerate gl shaders and gl states stored in the pass are listed in the details property.
One decision we took some months ago, was to always provides shaders and states and optionally provide the details property. It could have been different like providing shaders OR details or both...
About the size, the JSON compresses extremely well and the text response you get from the HTTP server is compressed, so I am not too worried about the size at this point.

[fabrobinet]

BTW, About the JSON size, there are also many things we can do (and began to do) to reduce the memory footprint (once uncompressed) like not outputting properties to their default value.

[McNopper]

Thanks for looking at my repo :-)

I understand your points but please rethink it:
Please make glTF and its mandatory fields as small as possible, where the Engine has the freedom, how to render the asset and that the asset can be reused between different OpenGL versions. Make everything else optional to keep the functionality you explained.

E.g. create a "tiny glTF" and a "glTF" profile.

[pjcozzi]

Thanks for the feedback @McNopper.

This is something worth discussing since other folks have also want to use glTF piecewise. The case that comes to mind was using glTF just for materials - but I can also see it being used just for geometry.

One downside to, for example, making the material property in mesh/primitive optional is that now many engines won't know what to do with a glTF file that doesn't have this property, which significantly fragments glTF content. This may not be a problem since glTF is a runtime format so most content used by an engine will go through its pipeline (perhaps built on COLLADA2GLTF).

Your suggestion of a "tiny profile" could work so engines could say which profile they support, but this adds some complexity to the spec. glTF is all about lowering complexity.

I don't feel to strongly one way or the other, but we need to carefully consider the flexibility/simplicity/fragmentation tradeoffs.

[McNopper]

I am currently working on a glTF exporter (and later importer) for my OpenGL based Graphics Engine. Meanwhile, I did see, that some fields are not mandatory and I just implemented it. Still, I do not like, that I do have two different glTF assets for e.g. OpenGL ES 2.0 and OpenGL 4.4.

[fabrobinet]

That's great @McNopper ! . Please let me advise you to watch out for coming format change to spare you some work maintenance.
We will make a new converter release with format changes early july. After that we should not have much changes until v1.0.

To you concern, say you want to convert a mesh with millions of polygons, on OpenGL ES 2.0 you'll have to split it (to satisfy indices constraints), but not on OpenGL 4.4. (just talking about core spec, but yes extensions can help here).

So, if you convert to the lowest common denominator like OpenGL 2.0, and if as you mentioned earlier, and if you don't plan to use the provided shaders (since you don't plan to use the techniques), then your asset will work everywhere, but geometry might be unnecessary splitted for OpenGL 4.4. By adding support for some GL extensions (needs to add ways in the converter), then you could have probably the same geometry and I believe this is what you'd want, your profile would be OpenGL ES 2.0 with extensions, would this work for you ?

[McNopper]

Well, I think it just needs some time for me to get comfortable with the concept of glTF :-) But thank you for your explanation and response.

[pjcozzi]

@fabrobinet any action here for 1.0?

[fabrobinet]

no I believe based on the discussion we can close this.