FB_ngon_encoding extension used in GLB conversion

Hi guys,

we are using the simple ImportExport example from the Exchange package (v2024.2.0) to convert a DWG file to a GLB file.

Unfortunately, the resulting GLB file seems to be kind of corrupt.

First, we notice the FB_ngon_extension, that is being used. Any way to suppress that?

gltf-transform inspect raum.glb

 OVERVIEW
 ────────────────────────────────────────────
┌────────────────────┬────────────────────────────────────────────────────┐
│ key                │ value                                              │
├────────────────────┼────────────────────────────────────────────────────┤
│ version            │ 2.0                                                │
├────────────────────┼────────────────────────────────────────────────────┤
│ generator          │ File produced by TechSoft3D HOOPS Exchange v24.2.0 │
├────────────────────┼────────────────────────────────────────────────────┤
│ extensionsUsed     │ KHR_materials_volume, FB_ngon_encoding             │
├────────────────────┼────────────────────────────────────────────────────┤
│ extensionsRequired │ none                                               │
└────────────────────┴────────────────────────────────────────────────────┘


warn: Missing optional extension, "FB_ngon_encoding".

error: Cannot read properties of null (reading 'getCount')

Furthermore, when using for example gltf-transform to do some optimization etc. we get an error like properties of null. GLTF viewers like gltf.report or babylonjs can draw the model, but they cannot access the properties :confused:

The conversion from dwg to glb looks from within the logs good. nothing suspicious here (see attached log)

log.zip (7.9 KB)

-------------------------------------------------------------------
---------- Summary           --------------------------------------
-------------------------------------------------------------------

Standard:

           TO BE PROCESSED        |   FAIL  |         CREATED                 
  ----------------------------------------------------------------------------
  |    454 Solid                  |    0    |     454 Faceted solid          |
  |     32 Open shell             |    0    |      32 Faceted surface        |
  |     55 Curve                  |    0    |      55 Curve                  |
  ----------------------------------------------------------------------------
       541                        |    0    |     541 TOTAL                   

Number of meshes     : 553
Number of nodes      : 885
Number of Materials  : 18

Any advices or hints are very welcome.

Well, I have been digging around to this specific problem and was able to convert the GLB file from Exchange to a GLB without the FB_ngon_extension.

Workaround is to use Blender → Implement FB_ngon_encoding extension by scurest · Pull Request #622 · KhronosGroup/glTF-Blender-IO · GitHub … they seem to handle it fine.

Big question for me right now:

Is there any way to disable the FB_ngon_extension for the Exchange conversion process? I have been looking into the A3DRWParamsExportGltfData structure, as well as into the A3DRWParamsLoadData structure but did not find something suitable for the Triangulation / Tesselation.

Help is much appreciated in preventing the usage of the FB_ngon_extension here.

Thanks,
Ron