Shape Model (Geometry/Topology) Paradigms

[EAzari]

Hi all,

glTF supports "triangular meshes" and "primitive.mode," so, is there any plan to support more shape (geometry/topology) paradigms? In the engineering environment, there's a need to support more paradigms than "triangular meshes" especially for emulation, simulation and analysis purposes

Kind regards, Ehsan

[donmccurdy]

@EAzari could you say more about the types of topology you are looking for?

As for official glTF spec and extensions, we are focused on topology suitable for realtime rendering on current and next-generation hardware. Triangular meshes are the standard there, although we're also considering quads, mostly for the purpose of eventually enabling subdivision surfaces (https://github.com/KhronosGroup/glTF/issues/1362).

If triangles and quads do not meet your needs for emulation/simulation/analysis, you may also be able to customize glTF by defining custom extensions for your applications.

[EAzari]

Thanks @donmccurdy For sure these two "triangular and quads" are two standard parts today (Tessellated)

However, I think there are some others too:

1. NURBS (Surface) (or even T-Splines (Surface)) and B-Rep (Solid) (or CSG (Solid))
2. Parametric and Feature-based (which mainly combines with CSG, ...)

[EAzari]

I should ask another question too: Do you use implicit modeling techniques? No/Any Topology?

[janbrouwer]

I would stick with hardware supported geometry. Woudn't everything else have big impact on performance(especially webgl) and ease of implementation? But yeah, if it works it would be cool.

[donmccurdy]

Yes, NURBS, T-Splines, Parametric surfaces, and CSG in general cannot generally be represented directly on the GPU. The conversion to triangles must happen before rendering, and as a rendering transmission format glTF requires the tool writing the glTF file to do that conversion, rather than placing the burden on the client loading the file. I think that continues to be our philosophy, with quads and SubDiv as possible exceptions.

If you need features that are not suitable for realtime rendering, for some specific domain like BIM, you may want to consider defining custom vendor-specific extensions for glTF. For moving CSG-style data around losslessly, without any conversion to a realtime-compatible data format, the official glTF standard is probably not what you are looking for.

[EAzari]

Hope someday find that why did they disappear after OpenGL v3? However, thank you

[neuro-sys]

@donmccurdy (and @EAzari)

For moving CSG-style data around losslessly, without any conversion to a realtime-compatible data format, the official glTF standard is probably not what you are looking for.

Any suggestions as to what format to use for this other than inventing your own?

[UltraEngine]

@donmccurdy (and @EAzari)

For moving CSG-style data around losslessly, without any conversion to a realtime-compatible data format, the official glTF standard is probably not what you are looking for.

Any suggestions as to what format to use for this other than inventing your own?

OBJ can handle this.

[alteous]

We're proposing a boundary representation extension for solid models in https://github.com/KhronosGroup/glTF/pull/2343, notably for engineering applications. The approach taken is to provide topology information as supplementary data. This provides the best of both worlds: a tessellation for real time rendering and an exact representation for analysis, manufacturing, etc.

@donmccurdy, do you think this is an acceptable compromise?

[donmccurdy]

I have not personally been following any recent discussions on topology metadata, subdiv, or EXT_manifold, but I appreciate the proposal's keeping tessellated geometry for runtime, and have no objection to the approach. 👍🏻