khronosgroup / gltf-project-explorer Goto Github PK
View Code? Open in Web Editor NEWTool to provide a filterable registry of glTF community projects.
License: Apache License 2.0
Tool to provide a filterable registry of glTF community projects.
License: Apache License 2.0
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"
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
?
(The missing ones don't seem to be strictly necessary, that's why I'm not sure...)
We need a script to validate that the data file is not malformed. At a minimum I believe it should:
name
field is required.https://github.com/nvpro-samples/vk_raytrace
This project is a glTF 2.0 sample viewer using Vulkan ray tracing.
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
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.
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...)
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
, oroptimize
.
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?
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
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)
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.
@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.
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:
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.
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?
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...)
On the Project Explorer Page page the <model-viewer> is rendering as <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:
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.
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.
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.
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 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...)
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:
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.
To add to glTF Project Explorer.
Avatar creator with glTF export
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."
Ready to use CCO glTF models
via https://twitter.com/NikkitaFTW/status/1394701707435728898
Godot is already in Project Explorer because of its glTF import. Can we also add that it does export?
Add https://www.youtube.com/watch?v=MoYshrfCkNw&t=19s (or https://animech.com/en/unreal4web-2/ ) to the list
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
@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.
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.
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
.
This is an issue to brainstorm what V2 should be and to discuss what features we want.
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.
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)" ],
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)
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.
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.
Perhaps it is a few different entries in Project Explorer
CC @bghgary for suggestions or corrections.
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?
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.
Datasmith has glTF import
Under "Other CAD/CAID Formats"
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.
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.
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.
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.
Similar to how we use to track glTF ecosystem projects in the glTF GitHub repo's README, presentations and articles are still there:
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?
When linking to the project explorer tool from social media or forums, we don't get much of a preview currently:
Twitter: (https://cards-dev.twitter.com/validator)
Adding the four basic OpenGraph meta tags would be a quick fix for this:
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:
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.