Request for C3D vendor prefix

[rpnzl]

Hiya! We'd like to request the C3D vendor prefix.

Prefix: C3D
Company: Core3D, Inc.
Website: https://core3d.io/

The first application / extension is to support embedding additional metadata from out next-gen editor for accurate reproduction of designs produced on our platform -- this is currently in development, we'll plan to officially register the extension once we reach a stable 1.0.

[javagl]

A PR for adding the prefix has been opened at #2265

When you say that you intend to develop an extension that is related to metadata, note that there already are some extensions or proposals that deal with metadata in various forms. There is a ratified one, namely KHR_xmp_json_ld, and several open pull requests for alternative forms of metadata.

With a disclaimer: Getting an overview here is harder than it should be. One can search for metadata in the issues/PR and take a deep dive, trying to find out whether there are extensions that are "similar" to what one has in mind, but that can be tedious (depending on the maturity of the proposals there). Streamlining the extension development process and organizing it better is one of the goals of #2225 , but that's also still in an early stage.

[rpnzl]

Thanks for opening up the PR!

Noted re: the existing KHR_xmp_json_ld extension, as well as the query for existing metadata-related issues. I did use the term "metadata" in my original text and it may not have been the right word -- we're encoding additional UV transform data (specifically, the center of rotation) that isn't covered by KHR_texture_transform but is required to reproduce designs across target environments. I did search for existing extensions that already encode this information but I wasn't able to find anything (please let me know if I've missed something, though).

Thanks again!

[javagl]

... but I wasn't able to find anything

Yeah, that's the difficult part. And ... I frankly cannot provide specific guidance here.

There are many open PRs with extension proposals, but there is not yet an established process for the "lifecycle" of extensions. The current approach often seems to be that some vendor develops something, internally, for a specific application case, and then throws it over the fence as a PR with a supposedly 1.0.0 version, saying "Here, merge that!". But for many reasons, it's important to let the development take place publicy. I know, vendors often don't like that: "It's our extension! It's our system. We want it that way! 😢". But I think one of the foundations of the success of glTF is ... well, 93010f0 basically: 11 years ago, it started, and everything happened publicly.

You could consider to describe the goal of your extension in an issue (as an "Extension Idea"), or publish the current state as a Draft PR ("Draft Extension Proposal"), so that others can provide feedback. Again, the process is not very streamlined, but maybe it will improve soon...