Volume computation from repaired STL-derived solids is unreliable in OCCT wasm (gprop unavailable / inflated fallback)

[0x46y]

Summary

In our browser-based OCCT wasm pipeline, volume computation for STL-derived
geometry is not always reliable.

Sometimes exact OCCT volume computation is unavailable (gprop_unavailable).
In fallback cases, approximate volume estimates can become significantly
inflated compared to the expected scale of the model.

This occurs after mesh repair and solidification steps applied to STL meshes.

Environment

• OCCT: wasm build used in browser integration
• Runtime: Chrome (browser worker)
• Input: STL mesh (complex mesh with multiple holes and repair steps)

Pipeline used:

mesh repair → sew/heal → force closure → solidify → volume computation

Observed behavior

Typical diagnostics from our tooling include:

• volumeStatus = gprop_unavailable
• occtStatus = gprop_op_unavailable (in our diagnostics; indicates the GProp operation route is
  not available in this wasm build/profile)

In such cases our fallback estimation route reports large approximate volumes.

Example observation:

• fallback estimate: ~87.156 L
• expected scale from model dimensions: ~30 L

Another indicator from our diagnostics:

• bboxRatio ≈ 3.9

Here bboxRatio refers to the ratio between our approximate volume estimate
and the bounding-box volume in our diagnostics.

In some runs our diagnostics may classify the result as solid-type, but
downstream topology diagnostics (face count / sewing diagnostics) still
indicate that the result is not a reliable closed solid for volume
computation.

Expected behavior

If a valid closed solid is produced, OCCT volume computation via:

GProp_GProps / BRepGProp_VolumeProperties

should be available and consistent.

If exact OCCT volume computation is not possible, fallback estimates should
be clearly treated as approximate and ideally avoid obviously inflated
values.

Request

Could you clarify:

• What is the recommended approach for computing trustworthy volume from
  repaired STL meshes in OCCT?

• Are there known limitations for GProp_GProps or
  BRepGProp_VolumeProperties in current wasm/browser builds?

• Is there a recommended validation step before accepting a solid for
  volume computation (for example topology validity checks)?

Due to confidentiality we cannot share the original STL file,
but we can provide sanitized diagnostics, summary logs, and
reproducible parameter settings if helpful.

[0x46y]

Additional diagnostics update from my local tool:

• In a force-closure route that reaches a solid candidate, we observe:
  • topology: kind=solid, faceCount=12, shellCount=2, solidCount=1
  • shellFaceCounts: [6, 6]
  • approxSignedAbsRatio: ~4.57e-7
  • volumeStatus: gprop_unavailable
  • validity.checkerAvailable: false (BRepCheck_Analyzer unavailable in this wasm build)

Interpretation (from diagnostics): the signed/abs ratio is almost zero, which suggests
orientation cancellation/inconsistency in the repaired STL-derived solid.
At the same time, exact OCCT volume validation is unavailable in this wasm profile
(gprop_unavailable), so both geometry quality and wasm capability constraints appear to be
involved.