Fix #10656 - PolygonClipping: CLIPLINE produces NaN when line to clip is parallel to the maxX of the clip window

[jmarrec]

Pull request overview

• Fixes PolygonClipping: CLIPLINE produces NaN when line to clip is parallel to the maxX of the clip window #10656

Use the Liang-Barsky algorithm

• Loosely adapted from https://en.wikipedia.org/wiki/Liang%E2%80%93Barsky_algorithm
• Rewrote it until performance is optimal

I used microbenchmarking: https://github.com/jmarrec/CppBenchmarks/blob/94f0e1594ff17f9833a0547f0725d68c561311a1/bench_clipline.cpp

BM_CLIPLINE is the current E+ algorithm. BM_liang_barsky_clipper3 is my final version that I used here, and which is 15% faster than the original while being actually correct. in the edge cases

-------------------------------------------------------------------
Benchmark                         Time             CPU   Iterations
-------------------------------------------------------------------
BM_CLIPLINE                     567 ns          566 ns      1231826
BM_Clip2                        703 ns          703 ns       991672
BM_liang_barsky_clipper         588 ns          588 ns      1199750
BM_liang_barsky_clipper2        490 ns          490 ns      1430600
BM_liang_barsky_clipper3        482 ns          482 ns      145236

Pull Request Author

Add to this list or remove from it as applicable. This is a simple templated set of guidelines.

• Title of PR should be user-synopsis style (clearly understandable in a standalone changelog context)
• Label the PR with at least one of: Defect, Refactoring, NewFeature, Performance, and/or DoNoPublish
• Pull requests that impact EnergyPlus code must also include unit tests to cover enhancement or defect repair
• Author should provide a "walkthrough" of relevant code changes using a GitHub code review comment process
• If any diffs are expected, author must demonstrate they are justified using plots and descriptions
• If changes fix a defect, the fix should be demonstrated in plots and descriptions
• If any defect files are updated to a more recent version, upload new versions here or on DevSupport
• If IDD requires transition, transition source, rules, ExpandObjects, and IDFs must be updated, and add IDDChange label
• If structural output changes, add to output rules file and add OutputChange label
• If adding/removing any LaTeX docs or figures, update that document's CMakeLists file dependencies

Reviewer

This will not be exhaustively relevant to every PR.

• Perform a Code Review on GitHub
• If branch is behind develop, merge develop and build locally to check for side effects of the merge
• If defect, verify by running develop branch and reproducing defect, then running PR and reproducing fix
• If feature, test running new feature, try creative ways to break it
• CI status: all green or justified
• Check that performance is not impacted (CI Linux results include performance check)
• Run Unit Test(s) locally
• Check any new function arguments for performance impacts
• Verify IDF naming conventions and styles, memos and notes and defaults
• If new idf included, locally check the err file and other outputs

[jmarrec]

Simple test, was enough to produce a NaN for #10656

[jmarrec]

Bunch more testing to ensure whatever algorithm I ended up with was actually correct.

I test from from one zone to another

    // We break the plane into 9 parts, where region (4) is the clipping region
    //
    //  6 │ 7 │ 8
    // ───────────
    //  3 │ 4 │ 5
    // ───────────
    //  0 │ 1 │ 2

And I also test on boundary lines, where the line is parallel (and on) the boundary of the clip window

[jmarrec]

I expose it so I can test it. I'm also handling the rev inside the routine, makes no sense to leave the caller to deal with it

[Myoldmopar]

I'll mark it approved but actually I will remove the SCOPED_TRACE if that actually adds outputs during the test runs.

[Myoldmopar]

This is fantastic. So much cleaner!

[Myoldmopar]

Does this always emit the current position? I will see it locally if so, just asking to remind myself to look I guess.

[jmarrec]

SCOPED_TRACE will emit everytime another assertion fails. So it emits nothing if the test passes, but if it something goes wrong in the lambda with the EXPECT statements, you know which iteration of the loop triggered it.

[Myoldmopar]

OK, that's great. I thought it was just emitting info by calling the macro itself. I now see it is just registering the extra data to report in case of a failure. This is great, thanks.

[Myoldmopar]

OK, let's go for it.

[Myoldmopar]

OK, that's great. I thought it was just emitting info by calling the macro itself. I now see it is just registering the extra data to report in case of a failure. This is great, thanks.

[Myoldmopar]

I pulled develop, and made sure it was still happy. I'll get this merged so that I can resolve conflicts in #10578. Thanks @jmarrec , merging.