1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
// This Source Code Form is subject to the terms of the Mozilla Public
// License, v. 2.0. If a copy of the MPL was not distributed with this
// file, You can obtain one at https://mozilla.org/MPL/2.0/.
//! Direction-aware plane-distance tolerance for the CSG clipper.
//!
//! Extracted from `csg/mod.rs` so the tolerance-sizing concern — and the two
//! doc comments carrying its reasoning and its known limitation — lives in one
//! place. Ported from the TypeScript `ProjectedPlaneEps` / `epsForPlane` pair
//! in `packages/clash/src/contact/{narrow-phase,tri-tri}.ts` (#2661), itself
//! following the LOCAL-vs-world tolerance sizing in `section-cutter.ts`
//! (#2622). Deliberately the same formulation as the clash narrow phase, not
//! a new one.
//!
//! This does NOT mean the crate now has a single plane-epsilon formulation.
//! Two neighbours keep their own, both pre-existing and untouched here;
//! converging either needs its own change with its own evidence:
//!
//! - `router/voids/aabb_clip.rs` — max over axes, scaled by `1e-6` rather than
//! `2^-22`, against a hand-rolled copy of `clip_triangle`'s body that does
//! not route through [`clip_triangle_with_epsilon`].
//! - `processors/boolean/halfspace_cap.rs:87` — `on_plane_eps =
//! (diag * 1e-5).max(1e-6)`, evaluated immediately after this clip on the
//! half-space path. It is sized by a different quantity (the mesh's bounding
//! box DIAGONAL, i.e. its size) than the one here (the mesh's coordinate
//! MAGNITUDE, i.e. its offset), so no fixed ratio holds between them: for a
//! mesh near its local origin `diag * 1e-5` is ~42x looser
//! (`1e-5 / 2^-22 ~= 41.9`), while for a far-offset mesh this module's
//! epsilon overtakes it. Either way there is no interaction to reason about
//! — it runs on the clip's OUTPUT and only decides cap-ring membership; it
//! never revisits a front/back verdict.
//!
//! # The floor, and its known unit-divergence limitation
//!
//! [`super::ClippingProcessor::epsilon`] supplies [`PlaneEps`]'s floor. It is
//! a raw `f64` constant that is never rescaled by `unit_scale`, so WHICH unit
//! it is denominated in is decided entirely by the caller — and the two
//! production `clip_mesh` callers differ:
//!
//! - FILE UNITS (pre-scale): `processors/boolean/mod.rs`
//! (`IfcHalfSpaceSolid` / `IfcPolygonalBoundedHalfSpace`) clips inside
//! `BooleanProcessor::process`, which the router dispatches at
//! `router/processing.rs:818` and only unit-scales afterwards at `:846`.
//! Both mesh and plane are in the file's native unit there — millimetres for
//! most IFC files, not metres.
//! - METRES (post-scale): `router/layers.rs:569-570` (layered-material band
//! splitting) clips a `base_mesh` returned by `process_element_with_voids`,
//! which routes through `process_element` and has therefore already run
//! `scale_mesh` and `apply_placement`. Its interface planes are built from
//! `thickness_m`, `offset * scale` and the metre-valued `rtc_offset`
//! (`layers.rs:246-273`). Both operands are in metres.
//!
//! KNOWN LIMITATION (pre-existing, not introduced by the magnitude-scaling
//! fix; applies to the FILE-UNIT boolean path — the layers path is always
//! metres, so it has no unit variance of its own, only the fixed `1e-6 m` =
//! 1 micrometre floor): because the floor is a fixed constant with no unit
//! attached, identical physical geometry can classify differently depending on
//! whether the file is authored in metres or millimetres. The projected term
//! overtakes the floor at a projected noise amplitude of about 4.19 file units
//! (`1e-6 / 2^-22 ~= 4.194304`) — above that both unit choices converge on the
//! same scaled epsilon. Below it a metre-authored file stays floored at a
//! constant `1e-6 m` regardless of how small the operand gets, while a
//! millimetre-authored file's scaled term keeps shrinking with the operand
//! (its floor, `1e-6 mm`, is a nanometre and is essentially never reached).
//! For a real-world projected noise amplitude of `E` metres below the
//! crossover the two therefore differ by a factor of `1e-6 / (E * 2^-22) =
//! 4.194 / E` — about 4x at `E = 1 m`, about 42x at `E = 0.1 m`, and unbounded
//! as `E` shrinks. (Earlier prose here quoted a flat "~40x"; that is the
//! `E ~= 0.1 m` case only, not a bound.) Both sides remain sub-micrometre, and
//! no building-scale corpus fixture has exercised it. Left undone
//! deliberately: rescaling this floor by `unit_scale` is exactly the kind of
//! tolerance change that needs its own PR with its own corpus evidence, not a
//! fold-in-on-review-comment fix (see the 122x-looser-floor mistake avoided by
//! not reusing `near_band_from_extent`).
//!
//! # Why not `near_band_from_extent`
//!
//! Despite sharing the `2^-22` term, `near_band_from_extent`
//! (`kernel/near_band.rs`) is not reused here: its floor (`8*SNAP_GRID`
//! ~= 1.22e-4) is sized for the exact kernel's snap grid and is only overtaken
//! past ~512 m, so at building extents it would flatten the epsilon 122x
//! looser.
use crateMesh;
use Vector3;
use ;
/// f32-ULP scale factor for a "worst-case" single-precision coordinate: for a
/// value with magnitude in `[2, 4)` the true float32 ULP is `2^-22`, and for
/// larger magnitudes the ULP only grows. Same `2^-22` term (and reasoning) as
/// `NearBand` in `kernel/near_band.rs` and `F32_ULP_SCALE` in
/// `packages/clash/src/contact/narrow-phase.ts` — kept local rather than
/// shared because plane-distance tolerance and penetration-depth tolerance are
/// different jobs, even though both derive from the same f32 ingestion floor.
const F32_ULP_SCALE: f64 = 1.0 / 4_194_304.0;
/// Per-axis f32 rounding-noise amplitudes plus a floor, resolved into a scalar
/// tolerance per plane by [`PlaneEps::for_normal`].
///
/// The classification epsilon must scale with the operand's coordinate
/// magnitude rather than stay a fixed `1e-6`: the plane is f64, vertices are
/// f32-native, and the f32 ULP exceeds `1e-6` above 16 m, misclassifying
/// on-plane vertices.
///
/// Crucially the magnitude must be tracked PER AXIS and projected onto the
/// plane's own normal, not collapsed to a single max over all three axes. A
/// signed plane distance is `dot(v - p, n)` for a unit normal `n`, so each
/// coordinate's rounding noise enters it weighted by that axis's normal
/// component; an axis orthogonal to the normal contributes nothing.
///
/// A max-over-axes scalar (this module's predecessor, an inline
/// `mesh_plane_extent` in `csg/mod.rs`) is compared against a quantity it was
/// not derived from: it scales the tolerance to the operand's distance from
/// the LOCAL frame's origin along whichever axis happens to be largest, even
/// when that axis is irrelevant to the plane being tested. A site-offset model
/// at x = 1e6 mm clipped by a horizontal plane through a wall spanning
/// z = 0..3000 mm got `eps = 1e6 * 2^-22 ~= 0.238 mm`, inflated entirely by
/// the irrelevant x axis, where the real f32 rounding step at that z is about
/// 2.4e-4 mm: roughly 1000x too loose on the only axis that matters.
pub
/// Classify `triangle`'s vertices against `plane` within the tolerance band
/// `eps` and split accordingly.
///
/// Same as [`super::ClippingProcessor::clip_triangle`], but with an explicit
/// classification epsilon instead of the processor's fixed floor.
/// [`super::ClippingProcessor::clip_mesh`] uses this to pass a per-call
/// epsilon resolved by [`PlaneEps::for_normal`] against the plane's own
/// normal, without mutating `self` through a `&self` API. Takes no `self`:
/// every tolerance it consults arrives in `eps`.
pub