Indicate glTF2.0-ready tools

[donmccurdy]

A couple formatting ideas, to ensure users can find recommended tools easily. Preferences?

---

UPDATED: Work-in-progress has been moved out of this comment to a branch. See: https://github.com/KhronosGroup/glTF/compare/donmccurdy-docs-tools-cleanup

[donmccurdy]

If one of these seems reasonable, I will create a PR and update the WebGL Engines section in the same way.

[lexaknyazev]

+1 for quickstart section with small description and direct links. Maybe, add drag-n-drop Validator to "For Developers".

I don't have a strong opinion about bullet list / table for exporters. Maybe would be possible to consistently organize all kinds of glTF software (exporters, importers, loaders, viewers, etc) so that it's clear what versions they support, and what their completeness is.

We should also provide drag-n-drop version of collada2gltf for artists. Is it possible to compile existing converter to WebAssembly module? This would allow hosting everything statically on GitHub. /cc @pjcozzi

[javagl]

We should also provide drag-n-drop version of collada2gltf for artists.

Technically, it's already there (also listed above) https://cesiumjs.org/convertmodel.html But it's not clear which COLLADA2GLTF version is working there in the background (currently, it's still outputting glTF 1.0)

[lexaknyazev]

That one is quite old. I'm in favor of pure client-side solution for these reasons:

• it could be hosted on official Khronos GitHub pages instead of using Cesium infrastructure;
• it doesn't require any ToS / load balancing / security / privacy management.

[emackey]

I've had some success using the Blender Importer with glTF 2.0 models:

https://github.com/ksons/gltf-blender-importer

/cc #867.

[Fabrice3D]

"Maybe, add drag-n-drop Validator to "For Developers". +1 If the current validator would next to the report also display the tested file that would help a lot.

[lexaknyazev]

If the current validator would next to the report also display the tested file that would help a lot.

@Fabrice3D What do you mean by "display the tested file"?

[Fabrice3D]

This validator http://github.khronos.org/glTF-Validator/ is very handy to validate the files. But tells you zip about how it should be rendered using the "official description".

On animations for instance, there is no way to check visually the results fast. The gifs provided are more or less the only visual reference you get. Having a list of preview tools is fine, assuming the preview tools do actually have the support for the feature you work on and that its implemented the way its supposed to be. Being in contact with the nice people of Sketchfab, they modified the upload validation/parser just a week ago based on my exports and your validator. They do not yet support morph (they will soon). Same applies to the Threejs parser. So I have now a problem to validate what I do.

So if the official validator page would not just validate, but also render the geometry/animation as it should be, this would help a lot, as your own examples could then be also played back. On my part, I'd go for a basic rendering. Similar to what macOS does for obj's or collada's in the finder.

[lexaknyazev]

We expect that at some point Babylon, three.js, and Cesium will properly support all glTF 2.0 features. There's also a WIP reference implementation of PBR models: https://github.com/KhronosGroup/glTF-WebGL-PBR

[Fabrice3D]

I understand you're not planning to build a renderer/engine just for a validator. The problem is that I can imagine the respective devs of these api's will not perse respect the guides lines because of their own engine constrains. So at the end of the day, you need take that in account for the exports. And if you playback using threejs as validator, you will not get same result on sketchfab, in babylon etc.

[lexaknyazev]

And if you playback using threejs as validator, you will not get same result on sketchfab, in babylon etc.

We're talking about rendering valid assets, right? While different engines could have certain differences (e.g. BRDF implementation, at-runtime tangent space handling, quality of reflections, etc), core concepts like reading binary data or performing geometry/node transformations must be consistent across all implementations.

Please, submit issues to the spec and/or engines repos if something isn't clear enough or doesn't work.

[Fabrice3D]

Performing geometry/node transformations must be consistent across all implementations.

That's exactly why I'd love a validator that becomes a sort of an official yard stick.

To illustrate. On sketchfab there are test models, https://sketchfab.com/features/gltf While I load/reproduce them all, the "luitenant head" one has a faulty transforms for some of the meshes when I load it in my program. The previous threejs loader was having similar problems with it.

I do not claim the model is wrong or anything! Its probably me. But what if there is a mistake in the player for the transforms or in the file itself? How do I tell without an official way to validate what is correct? So I can fix my error if its on my side?

[donmccurdy]

@Fabrice3D comparing to the preview tools listed above (built on three.js, BabylonJS, and Sketchfab) will be your best option for verifying that your own renderer is displaying the model correctly. Building a separate official renderer just for validation would be a large amount of work, and that time is probably better spent implementing glTF in these WebGL engines that are already used by developers.

If there are specific things you think would improve the validator or the preview tools, please feel free to open GitHub issues though!

[donmccurdy]

Maybe, add drag-n-drop Validator to "For Developers".

Sounds good, done.

Maybe would be possible to consistently organize all kinds of glTF software (exporters, importers, loaders, viewers, etc) so that it's clear what versions they support, and what their completeness is.

Yes, I am hoping the table format above will work (perhaps with extra columns for renderer features like PBR or animation). We could also not mark things as "glTF2.0" until they support some minimum features.

I've had some success using the Blender Importer with glTF 2.0 models:

Added, thanks!

They do not yet support morph (they will soon). Same applies to the Threejs parser. So I have now a problem to validate what I do.

@Fabrice3D THREE.GLTF2Loader does support both morph target and skinned animation. In the drag-and-drop glTF viewer, morphs will only play if you have animation clips associated with them. If you're running into bugs with either, could you file an issue on the associated GitHub repo? Thanks!

[Fabrice3D]

@donmccurdy THREE.GLTF2Loader does support both morph target and skinned animation Oh so its been updated again, great. Will check repo in a minute, thanks

As for the gltF viewer:

[donmccurdy]

@Fabrice3D I've opened a new github issue for that, https://github.com/donmccurdy/three-gltf-viewer/issues/18. The glTF viewer does not support Safari, because the Safari drag-and-drop API is not very complete.

[Fabrice3D]

No worries! Meanwhile tested the morph on the new 4 days old loader update --> works, awesome!

edit: it also shows the same issue with the model "lieutenant head" as in my program (no head).

[Fabrice3D]

Meanwhile I've been in contact with the dev at Sketchfab. Turns out there is an element that is skinned for this model and something goes wrong regarding encoding/transforms for it. Also he told me they've pushed an update for morphs as well, tho, not extensively tested yet.

So all good news. Glad that weird transform issue is solved, drove me nuts not being able to place it. That's mainly why I would have loved to have a way to compair.

[donmccurdy]

Good to hear!

For any other issues or questions about tools or models, let's start new GitHub issues — I'd like to keep this conversation focused just on how best to organize the tools in README.md.

[pjcozzi]

Thanks again for organizing this, @donmccurdy!

Big +1 to quick start section.

+1 to the table over bulleted list as I think it is easier to scan, but just roll with whatever feels best. It might not be obvious until you start organizing.

Also please incorporate the projects in the existing README.md as well as those in #867 and then we can close #867.

We should also provide drag-n-drop version of collada2gltf for artists. Is it possible to compile existing converter to WebAssembly module? This would allow hosting everything statically on GitHub. /cc @pjcozzi

Submitted https://github.com/KhronosGroup/COLLADA2GLTF/issues/58

[donmccurdy]

Still a bit of work left to do (I haven't got everything from #867 in yet), but work-in-progress is now on a branch: https://github.com/KhronosGroup/glTF/compare/donmccurdy-docs-tools-cleanup

Hoping to have that ready to open a PR in the next week.

[pjcozzi]

@donmccurdy wow, this is really looking fantastic; I love the glTF 1.0 and 2.0 badges.

I wonder if we should drop anything that is glTF 0.8 (except LibreOffice may have upgraded since I last checked).

Should we also add table of contents (like the spec itself) after the quickstart?

[donmccurdy]

Sounds good. I've dropped the glTF0.8 items, including LibreOffice (i couldn't find any recent information about it). Also added a TOC.