glTF is pretty great, to be honest. At work I am writing a tool to convert Creo View models to glTF 2.0 models and I am experiencing actual joy while doing it.
I looked at the COLLADA and glTF formats (I wanted something open) and very quickly chose glTF 2.
I don't have any 3D format implementation experience, and I implemented glTF 2 in Golang in a day, or less.
Anyway, it's a great format (AFAIK) and I wish more 3D modeling tools supported it. I imagine more will come on board as time passes.
It's important to separate the idea of editor formats vs. delivery formats. COLLADA/FBX vs glTF is very analogous to Photoshop PSD vs. PNG. Even if you could, you wouldn't fill a website with PSD-format images, right? Right? But, there have been misguided WebGL apps that tried delivering COLLADA/OBJ/STL files to web pages.
It's understandable. Before glTF, there really wasn't a good non-secret/proprietary format with which to deliver 3D content. But, now there is! Use it!
I don't need 3ds Max to support glTF as an editor format, I just need it to support the format at least as well as it supports minimal OBJ, which is the lowest common denominator of 3D file formats.
GlTF is a runtime transfer format and that's mostly how I'm going to use it. Others at my employer need to do VR work, and sometimes that requires the geometry to make a trip through something like 3ds Max. It would be nice if Autodesk acknowledged the existence and utility of glTF. People want to move away from FBX so Autodesk are unlikely to provide glTF support until it is demanded of them by a large enough portion of their audience.
Once I am done with this Creo View stuff I will look at writing a 3ds Max import plugin myself. It would definitely get used by my employer.
I am a 3ds Max user, excited about gITF, and would be interested in contributing to an importer. Is your Creo View project by any chance open-source? Would your Max importer be open-source?
No, but I bet someone could create a Creo View converter if they have access to PTC partner downloads. Specifically, the Creo View Files Tools that includes command-line tools to convert Creo View files to their ASCII representations.
Writing an importer for those ASCII files is easy, and when you have the binary and ASCII versions of the same files side-by-side, working out the binary file format is made much easier.
I'm a few years removed from 3D work so take this with a grain of salt especially since today was first time I've seen GITF. I've implemented several 3ds Max Game Asset importer/exporter tools for modding over past decade. While I like the look of GITF 2.0 quite a bit, it does seem to lack a number extension points that I would probably need for a generic importer/exporter for handling game asset round trips (import, edit, export). I would love to handle import/export in a generic way and have tried with FBX and collada to poor effect in the past. Really want to take asset convert to GITF then import to max edit and then export from max to GITF and then finally bake back to game format. The less stuff software you need between the game format and the GITF file the better but should allow for automation/customization.
You can get 80-90% there but miss quite a bit of fine detail needed as a interchange format (which is why this is a transmission format I guess). Extensions seem to be basic and I question how well they work in 3d editors but not really sure how that works and is probably editor specific. I've had a lot of issues trying to have a single file like collada be properly supported in multiple editors unless it was fairly basic model. That leads to a lot of wasted time for modelers trying to get the edited model back into the game and working correctly.
Back to GITF, collision seems to be missing. They admit that they dont have vertex compression implemented or animation for things like material colors or animation metadata (timelines, looping, ...) . Is there a way to describe a partial surface sort of like skinning for other reasons (for example Fallout 4 needs to tag certain surfaces/vertices as to say that they are part of the head or arm for decapitation in game). Anyway looks like a nice start as its all JSON (or binary) unlike GEX,obj,3ds,... which seems to need its own parsers to read and they did only claim to be an transmission format. Again only did cursory read of the format so I might have missed things.
I've always assumed that was an "L". Whoever named this thing and made the decision about capitalization needs to possibly think a bit harder next time.
I wonder if some of those are criticisms of glTF 1, rather than 2. GlTF 2 is a lot different and much more fully featured than v1 was.
Scene structure in v2 offers everything Creo View offers and pretty closely matches what is available in the Unity3D hierarchy, from what I've seen. You assign one or more meshes to a node element (rinse and repeat) and you arrange them in parent & child configurations. Transform matrices of parents pass down to children, and so on. If a child node has its own matrix specified, it is multiplied with the computed parent matrix, resulting in the final transform applied to whatever mesh(es) defined in that node. Exactly the same as what Unity or Unreal do.
So the scene structure criticism doesn't hold water for me.
Same for materials. GlTF v2 supports PBR materials with or without texture maps, normal maps, occlusion maps, and emissive maps. All of those are optional and you can set things like color and normals, opacity, and emissivity all without textures if you want.
Most glTF tools out there, including a lot of open source things like blender importers and exporters, assume that there will always be textures to define those material properties, and completely ignore non-texture material parameters like BaseColorFactor, which is incredibly annoying because NONE of the models at my work use textures for anything.
Things like lettering on placards is modeled, not textured, and no UV maps exist for anything. This will be an interesting/infuriating problem when it comes time to view these models in a game engine in a production setting. Optimization in game engines relies on things like textures and UV maps.
To that end I have a to-do item on my list to simply generate small map images for these things and set give each material one pixel on the maps and make all UV coords for a mesh with a given material point to that pixel. That will probably work, and it will probably appease the half-implemented open source stuff I've come across. Runtime lightmaps will not work this way, however.
I can't speak to the animation features of glTF, since I'm dealing with CAD data. Our models are individual parts assembled into whole assemblies or vehicles at runtime, and not stored as whole models.
> Optimization in game engines relies on things like textures and UV maps.
I think for lettering and similar things (high-complexity but essentially flat) you're right. You could probably use quads here to give you easy UV mapping and script the creation of textures.
What else have you modelled which would ideally be done via textures in a real-time engine?
I looked at the COLLADA and glTF formats (I wanted something open) and very quickly chose glTF 2.
I don't have any 3D format implementation experience, and I implemented glTF 2 in Golang in a day, or less.
Anyway, it's a great format (AFAIK) and I wish more 3D modeling tools supported it. I imagine more will come on board as time passes.