BRepBuilderAPI_MakeSolid returns solid-type result with zero faces in OCCT wasm pipeline

[0x46y]

Summary

In our browser-based OCCT wasm pipeline, BRepBuilderAPI_MakeSolid
sometimes returns a solid-type object without an explicit failure,
but the resulting topology contains zero faces.

Recent diagnostics show that both patterns can occur depending on the
post-solidification route: some routes produce empty-topology results,
while others produce non-empty solid candidates.

As a result, the returned object cannot be used as a valid solid for
downstream operations such as volume computation.

Environment

• OCCT: wasm build used in browser integration
• Runtime: Chrome (browser worker)
• Input: STL-derived geometry after mesh repair

Pipeline used:

STL mesh → sew/heal → force closure → shell → BRepBuilderAPI_MakeSolid

Observed behavior

Across multiple post-solidification attempts we repeatedly observe
diagnostics similar to:

• ret = solid/1
• topo = 0/1/1 (face/shell/solid counts)

These diagnostics are generated by my own diagnostic tool.

This indicates that a TopoDS_Solid object is returned, but the
topology effectively contains:

• 0 faces
• 1 shell
• 1 solid container

Because the face count is zero, our pipeline rejects the result
as not a usable solid for downstream geometry operations.

This can occur even when earlier closure diagnostics report no open
edges after the force-closure stage.

Expected behavior

If BRepBuilderAPI_MakeSolid returns a solid object, the resulting
topology would normally represent a usable closed solid (i.e.
non-zero face topology).

Alternatively, if the shell cannot produce a valid solid, it may be
preferable for the operation to fail explicitly.

Request

Could you clarify:

• Is this behavior expected in some situations when using
  BRepBuilderAPI_MakeSolid?

• Are there recommended validation checks after MakeSolid
  before treating the result as a valid solid?

• Are there known prerequisites for STL-repaired shells before
  calling MakeSolid in OCCT (particularly in wasm builds)?

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

[0x46y]

Related background issue: #127

Issue #127 discusses OCCT wasm build/API consistency
(exports, wrapper format, binding signatures, and supported workflows).

Our current hypothesis is that part of the debugging difficulty in this
area may be related to differences between wasm artifacts or build
configurations.

[0x46y]

Additional diagnostic example

Across multiple post-solidification routes we observe cases where a
solid-type result is returned but the resulting topology contains zero
faces.

Representative diagnostics from our tooling:

ret = solid/1
topo = 0/1/1 (face/shell/solid counts)

[0x46y]

Additional diagnostics update (with stage-level logs)

I added stage-level topology diagnostics in my local tool (tag: topology-stage) and observed the
sequence below in a recent run:

• force_closure:post_sew -> shell, faceCount=6, shellCount=1, solidCount=0, freeEdgesAfter=0
• force_closure:pre_make_solid -> shell, faceCount=6, shellCount=1, solidCount=0
• force_closure:post_make_solid -> solid, faceCount=12, shellCount=2, solidCount=1
• force_closure:final_candidate -> solid, faceCount=12, shellCount=2, solidCount=1,
  volumeStatus=gprop_unavailable (as reported by my diagnostics)

So in this route, MakeSolid did not produce an empty-topology solid.

However, the final output in my local pipeline still falls back to shell because volume validation
remains unavailable (gprop_unavailable in my diagnostics), and some post-solidify variants are
still classified by my tool as unusable solids.

This suggests at least two failure modes may be present:

• topology/selection failures in some post-solidify variants
• volume validation unavailable in wasm (GProp route unavailable) even when a non-empty solid is produced

Questions:

• Is GProp volume computation expected to be unavailable in some wasm builds/profiles for solids produced this way?
• If yes, what validation/acceptance criteria do you recommend instead of GProp for browser wasm pipelines?
• Do you recommend a specific post-MakeSolid gate for STL-repaired shells when the exact volume route is unavailable?

[0x46y]

Additional diagnostics update for MakeSolid behavior:

In at least one route, MakeSolid does return a non-empty solid candidate:

• pre_make_solid: shell, faceCount=6, shellCount=1
• post_make_solid: solid, faceCount=12, shellCount=2, solidCount=1
• shellFaceCounts on candidate: [6, 6]

So this route is not an empty-topology result.

However, downstream usability still fails for volume workflow:

• approxSignedAbsRatio: ~4.57e-7 (near-total signed cancellation in our diagnostics)
• volumeStatus: gprop_unavailable
• BRepCheck_Analyzer unavailable in this wasm build (checkerAvailable=false)

This suggests route-dependent outcomes: some post-solidify variants are still unusable, and even
non-empty solid candidates can remain non-actionable for volume in current wasm conditions.