Quad support

[Peach1]

Quads are an essential part of the modern 3D industry.

3D Artists make models where quad topology is THE aspect being shown

For glTF to be more widely used as a cross application 3D viewing format, it needs to easily have an option to be exported/imported as quads.

Sites like sketchfab show wireframe previews on quad meshes, but when you download as GLTF and try to reupload, there is no way to preserve the quad topology of the model.
Likewise you can't export as glTF and upload quads right now

glTF is seen as a viable alternative to FBX, because glTF is one of the first open 3D file formats supporting animation to actually have 3D exporters and viewers that work.

glTF is huge on sketchfab, they support glTF for every downloadable assert.
Sketchfab is used by professionals to view, share, and upload 3D models.
In the 3D industry, quad topology is essential to a model review process.

glTF will become FAR more complete of an industry standard if it supports the quad topology storage that the industry has been using for the past 20 years now
There is already a proposed extension for quads in GLTF:

• Adds no extra filesize
• GLTF viewers display the quad mesh correctly even without implementing the extension
• This is already implemented in Blender, and Blender is a significant glTF authoring tool

The earlier GLTF and Quads 'just work', the better

What's preventing this quad support from becoming an accepted extension exactly?

Besides topology viewing, Quads for a 3D runtime format has a LOT of use cases like runtime adaptive subdivision level of detail, and voxel and 3D grid mesh extraction
A lot of 3D data inherently is meant to be viewed/processed with quads

Modern 3D modeling workflows are extremely quad oriented for topology and subdivision, projects like OpenSubdiv from Pixar literally cannot use GLTF because this format doesn't support quads yet. For the purpose of wider 3D industry adoption, GLTF really needs to support quads.

[donmccurdy]

Thanks @Peach1 — I believe we're generally supportive of adding quad support, with the primary goal of enabling SubD. However, note that lossless DCC-to-DCC transfer (without any structural alteration) is not a top-level goal of glTF, as it would often conflict with efficient runtime processing. So, for example, it is entirely possible the solution we end up with will allow quads but not arbitrary ngons.

The proposal you linked to is effective as a vendor extension, but broader support in the glTF ecosystem will require an official extension, and there are further issues to solve before that can happen (see #1620). I don't think we'll be merging vendor extensions into the Blender exporter at this time, so that PR will also need to wait for an official extension.

[cesss]

I'll also be needing quads in GLTF quite soon. If by that time they are not in an official extension yet, I'll be using the FB_ngon extension, although I'd prefer an official extension instead.

[Peach1]

Any update to quad support in GLTF? What issues remain that need to be addressed? #1620 Had a working implementation of glTF quads but it was told to wait for an official quad extension. What remains to be solved for officially having quads in GLTF?

[donmccurdy]

@Peach1 while our official tools will likely not merge extensions that aren't official, that doesn't mean you can't use a vendor-prefixed version in the meantime.

The questions mentioned in #1620 are what need to be addressed, feedback on that thread is welcome. I am currently focused on other areas of glTF.

[arodic]

Are there any updates on quad support in glTF?

Looking at various PRs and issues across the ecosystem it looks like FB_ngon_encoding extension is dead in the water. Blender PR has been closed, #1620 has been stalled for a couple of years and it doesn't look like extension was ever implemented in FBX2glTF tool.

Has there been any progress on EXT or KHR version of this extension?

[donmccurdy]

I think that #1620 is still the thread to follow here, but note that Facebook is no longer involved. There are more recent comments (a few months ago) from Adobe.

[virtualritz]

As mentioned, subdivison support really requires quads at least. But preferably n-gons would be supported too.

The industry standard is the Catmull-Clark scheme. Which works fine with n-gons.

If you use real time subdivision of a coarse mesh with static topology, e.g. a deforming character with something like Pixar's OpenSubiv, you need quads at least because Catmull-Clark is what the artist making the asset will have used to preview.
Everyone is d'accord on this, I guess.

But what's more, they may use n-gons to keep the topology lighter.

Forcing quads will mean subdividing any n-gon containing asset once (for each n-gon, n quads will result – on a quad mesh with a few n-gons you get over four times the topological data). I.e. this blows up asset size considerably.

The alternative is manually changing the topology painstakingly, to avoid n-gons. Something VFX modelers had to do lots in the 1990's and early 2000's when using NURBS patches; before subdiv modeling became widely available. Believe me, we don't want to go back there.

P.S. As a workaround, currently one can use Loop subdivison with glTF meshes. But topology created with Catmull-Clark in mind and then triangulated and sent through Loop just doesn't look that great.

[cesss]

It's a pity that there's no progress in adding quads support. I find it one of the limiting points when adopting glTF.

[cesss]

By the way, I just had a quick thought, but maybe is a dumb one: Is there any drawback in using TRIANGLE_FANs to describe quads? Wouldn't they take the same file size as quads? Do you see any problem in this approach? (as I said, maybe it's a dumb thought, but I had to say it).

Also, regarding n-gons, do subdiv surfaces take concave n-gons, or just convex? If they must be convex, maybe the TRIANGLE_FANs workaround could work too...

[virtualritz]

Also, regarding n-gons, do subdiv surfaces take concave n-gons, or just convex?

Define subdivision surfaces. They use a subdivision scheme and what kind of input that accepts depends on the scheme's particulars.

For example, Catmull-Clark doesn't care. But in case of concave polygons the resulting limit surface will extend outside the polygon's area in some places.

Loop scheme subdivision surfaces only take triangle meshes as input etc.

[nyue]

Does the recent announcement between AOUSD and Khronos give additional impetus in providing Quad support in gltf ?

https://www.khronos.org/blog/building-bridges-in-3d-aousd-and-khronos-collaborate-on-openusd-and-gltf-interoperability