Lower B-rep reconstruction valid rate than reported

[Qiuzd-meshyai]

Thanks for releasing the code. I'm trying to reproduce the reported B-rep reconstruction results using the released pipeline and default settings, but consistently get a lower valid rate.

Results
sample/: only 2/4 shapes reconstruct into valid solids. The other two fail on all 24 rotations (assembly failures, not timeouts), while the README says all four reconstruct into valid solids.
final_test (first 300 shapes): 123/300 (41%) have at least one valid reconstruction.

Is there any missing setup (e.g., OCCT/pythonocc version, checkpoint, preprocessing, or reconstruction parameters) required to reproduce the README/paper results? Or is ~40–50% the expected valid rate for the released pipeline?

Any clarification would be appreciated. Thanks!

[yilinliu77]

Hi, on the given dataset the validity of the autoencoder should be around 80%. What is your python-occ version?

[Qiuzd-meshyai]

Thanks for the quick reply!

We're using pythonocc-core 7.9.3 (conda-forge, OCCT 7.9.3) with torch 2.7.1+cu128.

We first tried the README-pinned 7.9.0, but the released code doesn't run there because ShapeAnalysis_FreeBounds.ConnectEdgesToWires(...) only accepts the 3-argument binding in 7.9.0, while the code calls the 4-argument version used by 7.9.3.

With 7.9.3, the released pipeline runs correctly, but using the default settings we obtain only about 41% sealed (final_test.txt), much lower than the paper.

Could you share the exact pythonocc-core/OCCT build (or package version/build string) used for your experiments? We'd be happy to rerun on the same environment.

[yilinliu77]

My OCC version is listed below:

occt 7.9.0 all_hf72cfef_204 conda-forge
pythonocc-core 7.9.0 all_hd6cc8dd_202 conda-forge

I will try to fix the 3/4 argument issue. I had a similar issue before, but right now it works fine with my 7.9.0 occ, so I cannot reproduce the issue. The OCC version does matter, as we have also observed degraded performance with another OCC version before.

[Qiuzd-meshyai]

Thanks for the clarification!

We also reran the evaluation on pythonocc-core 7.9.0. For evaluation, we used the first 300 models from the official DualBrep data/final_test.txt (4150 models in total), without any filtering. We also verified that our 300-model subset is identical to the official first 300.

On this setup, we obtain about 64% valid/sealed.

Could you let us know whether this number is roughly what you would expect, or are we still missing something in our environment or evaluation pipeline?

[yilinliu77]

Sorry for the confusion. Can you try setting --drop_num 2 when you run postprocess.py?

[Qiuzd-meshyai]

Yes, on the first 300 shapes, --drop_num 2 consistently improves the valid rate from 192/300 (64.0%) to 205/300 (68.3%). It also takes longer to run, as it evaluates additional face-drop combinations for cases that do not seal initially.

[yilinliu77]

Let me check again; The final metric should be around 76%