-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Required top-level object properties #639
Comments
As soon as we agree on specifics:
Not sure about @pjcozzi What do you think? Is there any valid use case for explicit |
All looks good. As for the previously optional properties, I think we were just being too aggressive with defaults. I am tempted to require
What do you mean? Do you have an example? |
JSON values can be {
"buffers": {
"binary_glTF": {
"byteLength": 12345,
"uri": null // instead of "data:,"
}
}
} |
At the current state of spec, default material is defined as a material without Since default material doesn't have any
|
Ah, I see what you mean (#639 (comment)). I guess a property could be
All OK with me. |
If a property is missing, it is |
@lexaknyazev OK to close this? Or is there anything else to discuss about |
If there's nothing else for mandatory asset data, let's close this and discuss |
See #646 for |
I know this issue is closed, but I am befuddled that there is no rationale stated here. For our company we decided to adopt glTF 1.0 exactly for the reason that nothing was mandatory by default. This way, we are able to specify materials and all the transitively mandatory assets as needed, while the meshes are currently stored in a custom binary format and loaded by other means (i.e. not by a glTF loader). While we want to transition to glTF for all assets at some point, we cannot make this transition right now. We actually generate some more info and export directly to glTF with 3DSMax scripts. I'm totally fine with metadata being mandatory but what is the rational behind forcing the inclusion of at a non-empty dictionary of buffers and transitive dependencies? Is there another, more appropriate place to discuss this? |
I think it is a valid use case to use glTF for just materials, so I would be fine with loosening the 2.0 spec so that Also see #815 (comment)
|
@pjcozzi: thank you! |
For example, just asset metadata and geometry objects so a valid glTF asset doesn't need to include materials and friends.
@lexaknyazev would you be able to open a PR into the
1.0.1
branch with a proposal?The text was updated successfully, but these errors were encountered: