Right now, for every project there's only one URL that points to the project's main site.

If possible, I would like the table to include these entries:

• An URL for issue reporting, if available.
• If the project is an exporter, the generator name prefix, ex: "babylon.js", "Sketchfab" , etc.

These two entries could be useful to add this functionality:

When an importer validates a glTF and finds errors, it can use the "generator" entry to find the project that produced the asset, and from there, report the Issue notification URL.

In other words, what I want to do is, when I load a glTF with errors, to be able to tell the user:

The file xxxxx.gltf is malformed.
Errors found: ....
Warnings found ....
Please, report these issues to http://www.somefancygltfexporter.com/issuereporting.html

Notice that, although many projects are reported as "exporters", under the hood they're using some other third party exporter, in these cases, I would either don't set the "generator", or I would point to the actual project that exports the asset as a dependency.

The README currently says that for the inputs/outputs should at least include glTF 1.0 or glTF 2.0, indicating the glTF version that is supported. Some entries also explicitly list GLB.

Should differentiate between glTF and GLB somehow?

(My 2 cents: I think that there are not so many libraries that do not support GLB (and if they don't one could argue that they don't really support "glTF" at all...)

https://www.3ds.com/products-services/3dexcite/?linkId=119564867

#glTF export straight out of @Dassault3DS #3DEXPERIENCE with appearance consistency ensured by #EnterprisePBR and glTF #PBRNext.

via https://twitter.com/bsfea/status/1397120960873078784?s=27

There were some issues getting the data to show up promptly with the new data file from PR #56. We should append a timestamp in a query parameter to the call to fetch the data file. That should prevent the browser cache from holding onto the data file.

https://github.com/nvpro-samples/vk_raytrace

This project is a glTF 2.0 sample viewer using Vulkan ray tracing.

According to feedback via mail, searching for a title should be case-insensitive. (There are many variations of glTF, GLTF, gltf... so this certainly makes sense).

From my understanding, it should be sufficient to change the line https://github.com/KhronosGroup/glTF-Project-Explorer/blob/master/src/store/results/Sagas.ts#L67

return projects.filter(p => p.name.includes(titleSubstring));

to

return projects.filter(p => p.name.toLowerCase().includes(titleSubstring.toLowerCase()));

Any issues with that?
(An alternative would be some RegEx magic, but that shouldn't be necessary here...)

Currently there is a vulnerability in the version of serialize-javascript used by our build process. This is a dependency of Create React App and only used at build time, so there is no active threat to our application.

The CRA devs are currently working on a fix:

facebook/create-react-app#8100

As soon as the fix is finished and the new CRA version is released, we should update.

glTF import

https://sparkar.facebook.com/ar-studio/learn/articles/fundamentals/supported-file-formats/

As mentioned in this comment on the glTF repo we need some better filtering logic than we currently have, which is an OR of every selected filter.

Ideally, we should have some logic that makes sense given the use case of the filtering. I'm proposing:

For each dimension (tasks, types, licenses, etc.) we OR multiple selected values, and between dimensions we AND. An example:

User selects export and load from the tasks filters, and C from the language filters. This turns into effectively the logic: (export || load) && C. This provides the user with a result that includes all projects written in C that support export or load.

We can do a few smaller changes to marginally improve search. This should work as a stop gap until we get a V2 of Project Explorer.

TODO: Fill out details for this issue.

The task field of the entries currently has this description:

An array of strings, describing the basic tasks that are supported by the project.

Common examples of tasks are view, load, import, export, validate, or optimize.

This is somewhat rooted in the original structure of the projects list in the glTF README, where the projects had been in sections like "Viewers", "Importers", "Loaders", "Exporters" etc.

In general, it is sometimes hard to figure out a sensible value for this field. We might have to add some clarification here: Most of the current entries try to use one of the examples mentioned above, and I think that this makes sense to some extent. People can easily search for "view" when they just want a viewer.

We could, however, consider to either allow/foster more differentiation here, or add something like a "tags" or "keywords" field, which could basically be free-text, and be taken into account when typing something into the main search field. The description could then be:

Keywords that cause the project to be found during a search operation.

_{And yes, we will have to prevent people from adding a 10-million-entry list like "a", "aa", "ab", ... "zzz"... at some point - the keywords should be "reasonable"....)}

Are there any thoughts or ideas on that?

@weegeekps @javagl any thoughts on how we should do this?

E.g., new JSON for a standalone database of the KTX 2.0 ecosystem, just start simple with a new boolean field in the current project JSON, etc.

Datasmith has glTF import

Under "Other CAD/CAID Formats"

https://www.unrealengine.com/en-US/datasmith

Godot is already in Project Explorer because of its glTF import. Can we also add that it does export?

via KhronosGroup/glTF#1986

To add to glTF Project Explorer.

https://nomadsculpt.com/

Mobile sculpting and painting app. glTF import/export

by @stephomi

I'm not deeply familiar with the build- and deployment infrastructure, but apparently, the build system is currently broken. The relevant output of a recent build ( https://app.travis-ci.com/github/KhronosGroup/glTF-Project-Explorer/builds/239599668 ) is

Skipping a deployment with the pages provider because this branch is not permitted: main

@weegeekps If this is just a matter of updating https://github.com/KhronosGroup/glTF-Project-Explorer/blob/main/.travis.yml#L14 to say main, then I can do this.

http://www.cgchannel.com/2021/05/download-the-free-v-ray-gltf-viewer/

Chaos – the company formerly known as Chaos Group – has released the V-Ray glTF Viewer: a free collection of Python scripts for rendering models in glTF format using its V-Ray renderer.

https://github.com/ChaosGroup/vray_gltf

Please edit the glTF-Project-Explorer entry for COMSOL Multiphysics to add the following property:description pairs:

"language" : "MATLAB"
and
"input": "DWG" , "IPT" , "IAM" , "PRT" , "ASM" , "RVT" , "PAR" , "SLDPRT" , "SLDASM" , "3MF" , "SAT" , "SAB" , "ASAT" , "ASAB" , "DXF" , "CATPART" , "CATPRODUCT" , "MPHTXT" , "MPHBIN" , "IGS" , "IGES" , "PRT" , "X_T" , "X_B" , "XMT_TXT" , "XMT_BIN" , "STEP" , "STL" , "GDS" , "VRML" , "WRL" , "CVG" , "XML" , "ZIP" , "TAR" , "TGZ" , "TAR.GZ" , "DEM"

glTF import

https://docs.omniverse.nvidia.com/app_view/app_view/features.html

https://market.pmnd.rs/

Ready to use CCO glTF models

via https://twitter.com/NikkitaFTW/status/1394701707435728898

On the IProjectInfo interface we have a link for some projects. We should use that to link out to the project when the user clicks the title.

As part of this we'll need to implement styles for links on the site. I'm thinking black with a dashed line that turns solid on hover. I'll play with it and come up with something that looks good.

Right now performance is fine but not great. Depending on the computer, initial load and clearing all filters is noticeably slow, taking about 250ms-400ms in my own testing. I've tracked this down to DOM repaint performance; we have a lot of nodes on the page, so we should try to reduce that count.

I'm currently favoring pagination to limit the number of results we show at once. It tends to be more accessible than infinite scrolls and is easier to implement and maintain. A count of about 30 records per page seems good to me, but an open question I have is if we should have the ability to allow users to adjust this?

This discussion started in KhronosGroup/glTF#1699.

@lexaknyazev had a great idea to add a field to Project Explorer specifically for loaders, to indicate what form of JSON parsing they use for the manifest. Most JSON parsers use DOM parsing, but this begins to falter when you exceed a certain threshold (generally based on the computer's available memory) and streaming, SAX-style, JSON parsers often fill this space. Jackson is a good example of a streaming JSON parser that I am immediately aware of.

I've proposed two options so far:

• A boolean flag indicating the loader supports parsing large manifests (threshold around ≥100MiB? higher?)
• A field describing how the JSON parsing works? Is it using a DOM parser or a streaming parser?

And @lexaknyazev voiced interest in the more descriptive field that indicates explicitly using a DOM parser or a SAX/Streaming parser.

I'm currently more a fan of the field as well, but I would urge us to go with "streaming" over SAX as while many of the streaming JSON parsers are SAX-style, some very popular parsers are not. JSONStream comes to mind.

@javagl @weegeekps

I appreciate the instructions in the README on how to add a new glTF project to Project Explorer:

In order to add your project to the project list, you can fork this repository, add your project information to the glTF-projects-data.json file, and submit a pull request with the changes. Alternatively, you can also open an issue that contains the relevant project information as described below.

I often run into new (or new to me) glTF adoptions in the wild (like this https://www.youtube.com/watch?v=MoYshrfCkNw&t=19s) but I rarely have the time to fully research it and open a pull request.

Is it possible for us to start/re-start a lightweight way to track a backlog of projects to add?

When we were just using the glTF GitHub repo's README.md to track the ecosystem, we used a GitHub issue to track the backlog: KhronosGroup/glTF#1058

Perhaps we should continue with that issue (and also go through it for new projects to add here) or start a new issue in this GitHub repo?

Open to any and all ideas. I feel like the ecosystem is growing much faster than we are tracking. Good problem, but a lightweight way to backlog would be game changing.

Similar to how we use to track glTF ecosystem projects in the glTF GitHub repo's README, presentations and articles are still there:

• https://github.com/KhronosGroup/glTF#all-presentations-and-articles
• And automatically mirrored at https://www.khronos.org/gltf/

However, we/I are not tracking them as much as we use to.

Should there be a Project Explorer-ish approach to this? Or is it simply a matter of keeping the README.md up-to-date?

To add to glTF Project Explorer.

Avatar creator with glTF export

https://readyplayer.me/

Unreal Engine 4 instructions: https://docs.readyplayer.me/integration-guides/unreal-engine-4

This uses glTFRuntime, which is already in Project Explorer. The description for that project should be updated to state that it is for Unreal Engine 4, right now it just says "runtime."

• https://github.com/rdeioris/glTFRuntime-docs

The README should contain a short summary of how new projects may be added. During one of the previous calls, the options that have been mentioned have basically been

• Fork and open a PR with the updated data JSON (preferred)
• Open an issue with the required project information, so that one of the maintainers may add it

For both cases, the fields (i.e. the properties that are available in the JSON, and the possible values) should be explained briefly.

_{(I'll write a few words here ASAP and open a PR - this issue is rather a reminder, and to allow comments of what other information should be added)}

When visiting http://github.khronos.org/glTF-Project-Explorer/, I see instructions for contributing but not a list of projects — have I missed the URL for that? Or is there an issue or PR to track making that list available?

To help understand the ecosystem and to create some fun social media content, it would be interesting to do some D3-like data visualizations with the content in glTF Project Explorer, e.g., map of what programming languages are used; export vs. import tools; web vs. desktop; etc.

For inspiration, see the D3 graphics gallery. I've also seen this type of taxonomy done on GitHub projects.

@weegeekps @emackey @javagl @lexaknyazev and other interested parties: heads-up that we propose to rename the default branch of this repository to 'main' in late August 2021, following emerging Khronos & github practice (for Khronos members, see internal khronos-general issue 106). This will have very little impact, although if you have a checked-out repository clone, you may want to follow the simple instructions github will pop up on the repository webpage describing how to do the same locally.

If there is a concern about this, please raise it here by 2021-08-23.

Wow.

https://twitter.com/donrmccurdy/status/1415308852405407750

Sharing a new web-based tool for working with @glTF3D models: https://gltf.report is a 3D viewer with a built-in script editor. Clean up problems, tweak materials, or add Draco compression — no installation required.

via @donmccurdy.

The data file for the the project explorer has been initialized with the data from the tables in the README and the entries from the "Late Breaking" issue at some point. It has been updated just before the Project Explorer went public. But there have been other additions to the README table and the Late Breaking issue in the meantime.

For the final migration, there are some tasks:

• The additions to the README that have been done have to be added to the data JSON file. (This may involve some manual work, going through the commit history...)
• The additions to the Late Breaking issue have to be added (these should only be a few, IIRC)
• The "Late Breaking" issue should be closed, with a comment pointing to the README of the Project Explorer where the process of adding new entries is explained. (For short: They can be added by opening issues, or also via PRs of the edited data JSON file)
• The tables in the README should be removed and replaced with a comment and a link to the Project Explorer

The last one raises some issues:

During the call, I mentioned the anchors. For example, people may have existing links like that:

Here are some Python libraries for glTF

The link here is https://github.com/KhronosGroup/glTF/blob/master/README.md#python, and jumps directly to the "Python" table via the #python anchor. When the table is removed, the same link will point to the top of the README file. But it should (preferably) jump to the section that originally contained the table, but now only contains the link to the Project Explorer

Very roughly speaking, I thought about sneaking anchors into the README like that:

• A list of anchors that are not visible in the rendered README:

    [](https://github.com/KhronosGroup/glTF/blob/master/README.md#typescript)
    ...
    [](https://github.com/KhronosGroup/glTF/blob/master/README.md#rust)
  

• Followed by a common pointer to the Project Explorer:

The tables that have been shown here have been replaced with the glTF Project Explorer, at http://github.khronos.org/glTF-Project-Explorer/

But I'm not sure whether this will work as expected.

@weegeekps I think you even suggested to pass the "anchors" as filter information to the explorer. If I understood this correctly, this would very roughly by done with something like a "query parameter"...:

    [Python](http://github.khronos.org/glTF-Project-Explorer/?language=python)

Is that correct?
This could be a handy functionality anyhow, but I have to clue about how complicated this is (and it's not strictly necessary for the pure replacement of the README tables...)

We need a script to validate that the data file is not malformed. At a minimum I believe it should:

• Validate the JSON is not malformed.
• Ensure that the name field is required.
• Throw warnings for very long names of filterable values, such as Input Methods, Output Methods, etc.

Context: https://twitter.com/lewy_blue/status/1224887143291441153

This appears to be an instance of a known grid height bug in Chrome. We'll need to come up with a workaround.

Some projects contained links in the input/output fields, pointing to sites where the supported file formats had been listed. These have been broken during the conversion, and resulted in things like

"inputs" : [ "[Multiple](https:", "", "blackthread.io", "gltf-converter", "#supported-formats)" ],

(see https://github.com/KhronosGroup/glTF-Project-Explorer/blob/master/public/data/glTF-projects-data.json#L1225 )

Assuming that input/output should not contain markdown, these links should be fixed, and where applicable, the link should be added to the description.

^{(I'll tackle this ASAP, this issue is rather a reminder)}

On the Project Explorer Page page the <model-viewer> is rendering as &lt;model-viewer> in the title. It appears to render correctly further down on the page when mentioned in the description for three.js glTF loader.

We're to a point where we need to start getting the deployment going with GitHub Pages. This issue is for discussion of deployment strategy.

Current ideas I have:

• Deploy to GitHub Pages.
• GitHub Actions are going to be released later in November, we should be able to automate deployment on merge.

This is rather a discussion point, and a somewhat difficult one...

Currently, there are some odd entries are at the top of the JSON data file - e.g. entries for glTF support in some browsers, which eventually have not really been implemented...

^{Yes, that's my fault - I just added the entries in the order in which they appeared at that point in the "Late Breaking" list...}

Some questions that we might have to think about:

• Should we edit the data file to move the "odd" entries to the bottom?
• More generally: Should we apply some arbitrary order to the other projects, based on a vague gut feeling (a mix of subjective "importance", "activity", "maturity"...?)
• Project authors who submit their project via PRs may (likely) try to add their projects prominently at the top...

For example, I'd rather like to see things like the glTF validator at the top when opening the project explorer, because it is an important and unique Khronos-owned project. Similarly, for the Khronos-owned converters or the reference viewer. But beyond that, I'd hesitate to dictate any sort order...

I think during the calls, we also considered some sort of "featuring/starring" for recommended projects, but we haven't really thought about an approach for this.

The description blocks are written in Markdown and should be presented to the user as HTML. We need to pick a markdown parsing library (https://marked.js.org/ maybe?) and implement a generic component to handle the parsing and display.

glTF loader

https://groups.google.com/g/webgl-dev-list/c/DWnsJnbS4Po

GitHub Actions was released on the 13th of November, and we should set it up to handle our deployments.

I hope to have this done by the 19th of November.

When linking to the project explorer tool from social media or forums, we don't get much of a preview currently:

Discourse Forums:

Twitter: (https://cards-dev.twitter.com/validator)

Adding the four basic OpenGraph meta tags would be a quick fix for this:

https://ogp.me/

This is an issue to brainstorm what V2 should be and to discuss what features we want.

Add https://www.youtube.com/watch?v=MoYshrfCkNw&t=19s (or https://animech.com/en/unreal4web-2/ ) to the list

When running depcheck in the main directory (after a yarn global add depcheck), there are some unused and missing dependencies reported:

Unused dependencies
* @types/jest
* @types/node
Missing dependencies
* eslint-config-react-app: .\package.json
* babel-eslint: .\package.json
* eslint-plugin-import: .\package.json
* eslint-plugin-flowtype: .\package.json
* eslint-plugin-jsx-a11y: .\package.json
* eslint-plugin-react: .\package.json
* eslint-plugin-react-hooks: .\package.json
* @redux-saga/core: .\src\index.tsx

^{(Where one of the "unused" dependencies caused some issues in another context).}

Can somebody who is more familiar with dependency management confirm that

1. the unused dependencies can safely be removed
2. it makes sense to add the missing dependencies

?

(The missing ones don't seem to be strictly necessary, that's why I'm not sure...)

Perhaps it is a few different entries in Project Explorer

• 3DS Max export, https://github.com/AsoboStudio/FlightSim-glTF-exporter (and https://github.com/AsoboStudio/FlightSim-3dsMax-tools?)
• Blender exporter, https://www.fsdeveloper.com/wiki/index.php?title=Blender2MSFS
• Importers?
• FlightSim runtime itself

CC @bghgary for suggestions or corrections.

Being able to search by title is both easily implemented and useful for a tool like this.

This feature needs to provide an accessible text field which allows the user to search by a substring. We should have the ability to clear the field and it should be debounced 150ms to allow the user to type the full string before we fire off the search for performance reasons.

To add to glTF Project Explorer.

https://github.com/spiraloid/Spiraloid-Toolkit-for-Blender-3DComicToolkit

This is a 3D Comic toolkit for Blender that allows you to save out your own scrolling 3D Comic websites like https://3dcomic.shop

by @spiraloid

I've taken down my old site blackthread.io. Can you please remove the tool from the list?

The loader and converter are now hosted here:

loader.lewy.blue
gltf-converter.lewy.blue

Including these links for reference. However, both tools a bit long in the tooth and need to be rebuilt, so until I get around to that please don't include them in the list.

From KhronosGroup/glTF#1058 (comment) , quoting @dmurdoch :

I've started a project rgl2gltf to read .gltf/.glb files and display them in rgl in R, and to export rgl scenes to .gltf/.glb file formats.