glTF should specify more aspects of assets about gltf

[pjcozzi]

I struggled with this, but our guiding principle is that glTF is for rendering, so it doesn't carry the same payload that COLLADA does.

I can justify including copyright or displayText/displayImage because when I implement a glTF renderer, I may be required to display credits for the model just like I do for other datasets. However, I don't see how authoring_tool, etc. fit the rendering use case. If an application wants it, perhaps an online model repo, it can include it in an extra property. When a glTF asset is deployed for a game, for example, the game doesn't care about the authoring_tool.

Remember, glTF strives to balance simplicity and completeness. We strive not to bloat the schema. We only add features that are generally useful, and allow the extensibility needed for assets used in different vertical markets. If we start to think, for example, than we could write an optimizer that removes unnecessary parts of glTF for deployment, e.g., authoring_tool, then we are suddenly turning glTF back into COLLADA.

Despite my personal need for geographic_location, I can also make the same argument here (despite my previous arguments). Need to think through this more.

[pjcozzi]

We should also gave a property to specify which converter is being used to produce a given glTF asset.

Potentially useful for debugging

[RemiArnaud]

this is a very small footprint, so just include it all.

copyright, description, author, usage, keywords are definitely really
useful. Those files will end-up on a web server, and will be indexed for
search. copyright, author should always be in any media file.
for debugging, have the full content pipeline chain described. Not only
copy the information you get from COLLADA header, but aslo add the
information from the COLLADA2JSON converter, including version,
parameters....

[tparisi]

I'm with @RemiArnaud on this one. The payload is tiny so there are negligible performance concerns. Why not have all the info there, it could be valuable for all the reasons stated above.

[pjcozzi]

Starting to sound like a kitchen sink, right?

It's not just about payload; it's about spec and schema complexity. glTF is focused on the runtime. How many of these fields are included in runtime formats already used in engines? Other than the converter tool reference for debugging, probably none.

I'm not that opposed, but this clearly goes against what glTF strives for. I laid out the argument above. What is the runtime use-case for properties beyond copyright/displayText/displayImage and authoringTool (or whatever)? All these other fields fit the market for a model repo, which could trivially put these in an extra property so joe-game-engine-developer doesn't need to think about them ever.

[RemiArnaud]

I don't see how this will impact anybody. Just do not look at it if you don't want to.

[tparisi]

Good counter-argument Patrick. Sigh now I'm on the fence. Sorry to be lame but I guess I don't care too much... ?

[fabrobinet]

IMO the essential aspect of asset for us is to track where it comes from.
So I would put in there for now just converter informations and copyright.

Then wait for developers input, right here.

[pjcozzi]

To recap, for now we will:

• Keep copyright.
• Add generationTool or whatever for the converter info
• Drop geographicLocation as I suggested above.

Users are free to use the extra property, of course, and we will reconsider others based on community feedback.

[fabrobinet]

sounds good.
yes generationTool or just generator ?..

[fabrobinet]

I just added asset with generator, to be refined.

[pjcozzi]

I suggest we close this for the draft 1.0 spec.

[pjcozzi]

No additional schema update needed for 1.0. See https://github.com/KhronosGroup/glTF/blob/spec-1.0/specification/schema/asset.schema.json

I believe you dropped an element of the initial argument: "Convert kml/kmz orientation and scale to a transform." I'm using GIS software to convert shapefiles into buildings for CesiumJS. Unfortunately, when exporting the model, the software places the unit scaling in the kml instead of creating properly scaled geometry. Seeing as kml/kmz and collada are such close format friends, I feel it's worth accounting for the Scale factor at least.

[pjcozzi]

@tpendergrass the glTF asset should always be in meters, which is also what Cesium expects. If you think there is a bug in COLLADA2GLTF or Cesium, please submit a bug in the corresponding repo with sample data.