Question
Appendix D of the paper derives the chord-to-arc ratio criterion for the quadtree boundary decomposition and states "we empirically set tau = 0.995". However, the tokenization code this pipeline builds on (BRT, process/solid_to_triangles2.py) calls splitRectangle(face, rect, crvs, max_split=5) at both call sites without passing tol, and splitRectangle defaults to tol=0.7 (process/triangles3.py), which it forwards to chordErrorCheckInRect. The function default of chordErrorCheckInRect itself is 0.995, but it is shadowed by the caller default, so the shipped pipeline effectively runs at tau = 0.7 with max_split = 5.
Was Brep2Shape-250k tokenized with tau = 0.995 (per the paper) or with the shipped call-site default of 0.7?
Why it matters
tau controls how finely boundary-crossing quadtree cells are subdivided before the Bezier triangle fit. At 0.7 the trim curve can bend substantially inside a kept cell, so boundary triangles cover the wrong parametric region more often and the fitted control points land off the true surface on curved-boundary faces. This changes every face token on trimmed faces, so it affects both the pretraining loss floor and the comparability of reproductions.
While reproducing the paper we tokenized with the shipped defaults (0.7 / max_split 5) and matched your Table 1 statistics closely (for example MFCAD++: 29.6 mean faces / 154.8 mean edges vs the paper's 29.91 / 157.36), which suggests the released corpus may also have been built at 0.7. A one-line clarification (or passing tol=0.995 explicitly at the call sites, matching the paper) would remove the ambiguity for anyone reproducing the pipeline.
Happy to send the one-line PR to BRT or add a note to the README here, whichever you prefer.
Question
Appendix D of the paper derives the chord-to-arc ratio criterion for the quadtree boundary decomposition and states "we empirically set tau = 0.995". However, the tokenization code this pipeline builds on (BRT,
process/solid_to_triangles2.py) callssplitRectangle(face, rect, crvs, max_split=5)at both call sites without passingtol, andsplitRectangledefaults totol=0.7(process/triangles3.py), which it forwards tochordErrorCheckInRect. The function default ofchordErrorCheckInRectitself is 0.995, but it is shadowed by the caller default, so the shipped pipeline effectively runs at tau = 0.7 with max_split = 5.Was Brep2Shape-250k tokenized with tau = 0.995 (per the paper) or with the shipped call-site default of 0.7?
Why it matters
tau controls how finely boundary-crossing quadtree cells are subdivided before the Bezier triangle fit. At 0.7 the trim curve can bend substantially inside a kept cell, so boundary triangles cover the wrong parametric region more often and the fitted control points land off the true surface on curved-boundary faces. This changes every face token on trimmed faces, so it affects both the pretraining loss floor and the comparability of reproductions.
While reproducing the paper we tokenized with the shipped defaults (0.7 / max_split 5) and matched your Table 1 statistics closely (for example MFCAD++: 29.6 mean faces / 154.8 mean edges vs the paper's 29.91 / 157.36), which suggests the released corpus may also have been built at 0.7. A one-line clarification (or passing
tol=0.995explicitly at the call sites, matching the paper) would remove the ambiguity for anyone reproducing the pipeline.Happy to send the one-line PR to BRT or add a note to the README here, whichever you prefer.