GLTF file experiences?


#1

Does anyone have any first hand experience with GLTF files? A less over engineered, less hampered by interop related junk alternative to FBX is appealing — as is a plain text format that can be text-diffed in a pinch. On the other hand the Kronos group also gave us Collada, so my hopes are not high.

Anything to report? Is it really the “JPEG of 3D?”


#2

Seconded, would really like to get the thoughts of others on using this.


#3

Am very interested in this format too - no first hand experience but one drawback for my use ATM ( when i investigated about the format ) was the lack of mobile hardware oriented texture compression formats ( ETC2, ASTC etc ) . Given that this area will evolve, but currently it lacks on that front

Microsoft started a DDS texture format extension

With mobile texture formats supported, this would be a great platform for dynamic runtime 3d asset loading


#4

There are 2 camps on the GLTF front, I think Kronos wants it to become a next gen collada/dds hybrid. Basically a runtime format that can be loaded directly by engines. The rest of the industry wants it to be an FBX replacement.

Due to the way its written, the extensions make it possible for the industry to do whatever they want and leave the “Core GLTF” alone, which is what is making it super appealing to me.

A good example is that GLTF doesn’t support quads, because it’s a runtime format. BUT you could easily make an extension that is an array of triangle pairs to determine which points are quads.

I’d say that the more pressure the industry puts on the format to fulfill its potential then it’s more likely it’ll happen. It’s an open source project, so worst case you have what MS is doing and just forking it and making their own extensions.


#5

Hello,

I am currently working for Airbus Defence & Space, and glTF 2.0 take an important place in the pipeline.
In Airbus Defence & Space they use glTF2.0 to load Digital MockUp into a realtime environment (visualization on laptop, in VR and AR). These models are also used to generate CG renders (pictures, animations…) of products with Blender.

glTF 2.0 is very important for the pipeline because of free/open specifications. Khronos already developed an exporter for Blender, and I am currently developing a importer (https://github.com/julienduroure/gltf2-blender-importer)
A plugin already exists for Unity (used for VR application)

Julien

PS: This is my first post here. Hi all :slight_smile:


#6

Is there any way to do meaningful text diffs on GLTF files?


#7

From what I’ve seen, we could diff the json-scene-description part, but actual asset data is stored in various binary formats, so much less diff-able.


#8

Furthermore, the animation support in glTF is insufficient for accurately reproducing animations created in most popular modeling software due to the requirement that time be linear for cubic spline interpolation.

This in itself is a blocker for us… Granted we bake everything in FBX so it wouldn’t make much of a difference, but I wouldn’t spend time refactoring a pipeline that works unless there are clear advantages (especially in terms of animation).

At the risk of sounding ignorant, what is over-engineered in the FBX format?


#9

My main complaint is that they problem they tried to solve – “seamless” exchange between very different apps – is extremely hard. Different packages have such different affordances that even with all of the complexity they layer on to handle, say, the difference between Max animation controllers and Maya animation channels you can’t really rely on the results. Viewed as a way to, say, round trip data between Maya -> Max -> Maya again FBX is pretty bad, you can’t even rely on something like a custom numeric attribute going and coming back with the same name. But the exported data is full of extra information intended to support that project, which you have to either ignore or wade through when trying to debug a file or to interpret one.

If you simply said “hey – it’s triangle meshes, vertex animations, material assignments, and bones-over-time – but it works reliably and fast and the same data always encodes the same way!” I’d be a lot happier. Export is a great chance to normalize data, so that people downstream of the export don’t know or care about how the data was made, only what it says. In FBX getting to that point is not trivial.

It’s true that the problem is not super easy – the biggest issue is convention driven stuff like handedness flips. But its not an insoluble problem as long as you say “the point of exporting is to get data that’s unambiguously like so”. When you add in all the degrees of freedom added by deformers, animation controllers, constraints, material models, rigs… it goes from soluble-but-hard to what we have: never reliable enough to forget about.