macumber
commented
2 years ago Were the tiny edges co-linear (like multiple vertices on the same line)? I think Topolys should remove those.
Closed brgix closed 2 years ago
macumber
commented
2 years ago Were the tiny edges co-linear (like multiple vertices on the same line)? I think Topolys should remove those.
brgix
commented
2 years ago "Were the tiny edges co-linear (like multiple vertices on the same line)? I think Topolys should remove those.". No, they weren't. They're what I can slivers : any longish surface (e.g. 2m in length, 20m in length) yet 9mm or 10mm in height. They're usually unintentional mishaps or artefacts, but need to be dealt with. The proposed fixes here and here work for now, yet TBD should be catching such minuscule edges WAY earlier in the process (i.e. they shouldn't make their way to Topolys in the first place). So the catch might evolve over a few iterations.
When processing tiny or very narrow OpenStudio surfaces (edge lengths < 10 mm), Topolys has safeguards to avoid generating invalid objects (e.g. minuscule normal vectors) or calculating invalid dimensions (e.g. minuscule vector magnitudes). This can only come from bad OpenStudio input, either from modeller negligence or faulty (automated) translations from third-party software packages (unbeknownst to the modeller). It happens. In such cases, TBD should catch invalid input (when they indeed affect TBD/Topolys operations), ignore such icky surfaces, and log errors for users. Recent tests on a third-party model (translated from GBXML), showed that TBD misses catching such bad input in (at least) 2 places (when calculating polar angles of surfaces around a common edge), triggering Ruby missing methods. This is quite uninformative for users - shouldn't happen. Initial code inserts/tests fixes the issue. Automated RSpec tests are required to finalize the fix before merging/releasing.