GitLab

Now it corresponds more closely to a "minimum allowed xy-distance
between lines and object.

See feature request for why we added this:
line-collision-detector#8

We do this because it gives the user better control over what the
program will do.
It also saves time because it avoids having to analyze more layers
than the user asked for.

It saves 20-50% of execution time on "No collision found"-runs.

This saves about 17% of execution time during benchmark
time run linc/test-models/broken/3DBenchy_scale15.7.binary.stl linc/params-example

This saves ca 3% of execution time during benchmark
time run linc/test-models/broken/3DBenchy_scale15.7.binary.stl linc/params-example

This saves ca 3% of execution time during our benchmark
time run linc/test-models/broken/3DBenchy_scale15.7.binary.stl linc/params-example

Splits Mesh constructor into one simpler constructor
and one reset function.
This is easier to follow when reading the code.

This saves ca 40% of execution time during our benchmark run
time run linc/test-models/broken/3DBenchy_scale15.7.binary.stl linc/params-example

This saves ca 2% of execution time during our benchmark run
time run linc/test-models/broken/3DBenchy_scale15.7.binary.stl linc/params-example

This saves around 7% of execution time during benchmark
time run linc/test-models/broken/3DBenchy_scale15.7.binary.stl linc/params-example

This saves ca 3% of execution time during benchmark
time run linc/test-models/broken/3DBenchy_scale15.7.binary.stl linc/params-example

This saves ca 10% of execution time during our benchmark run
time run linc/test-models/broken/3DBenchy_scale15.7.binary.stl linc/params-example

This is to easier change between float, double, and long double
later if needed.

I used it to test if float is faster than double.
It's about 1-2% faster, but not worth it since we're loosing half
of our precision.

We saw that some triangles were added who had one corner in the origin,
and it looked obvious that they shouldn't have.
We're not really sure how to catch this in unit testing, but it
should have been.

This saves ~12% of execution time during our benchmark
time run linc/test-models/broken/3DBenchy_scale15.7.binary.stl linc/params-example

This saves ~2% of execution time during benchmark
time run linc/test-models/broken/3DBenchy_scale15.7.binary.stl linc/params-example

This saves a stunning 12% of execution time on benchmark
time run linc/test-models/broken/3DBenchy_scale15.7.binary.stl linc/params-example

This saves ~5% of execution time during our benchmark
time run linc/test-models/broken/3DBenchy_scale15.7.binary.stl linc/params-example

We don't need to store that information,
and we save ~5% of execution time during
time run linc/test-models/broken/3DBenchy_scale15.7.binary.stl linc/params-example

This makes code less complex

This saves us yet another tad of ~1% execution time during
time run linc/test-models/broken/3DBenchy_scale15.7.binary.stl linc/params-example

Saves some memory and about 1% of execution time in benchmark
time run linc/test-models/broken/3DBenchy_scale15.7.binary.stl linc/params-example

Calculate the normals when we need them instead, that is both
more correct, uses less memory, and executes faster.

Saves ~1% execution time on our benchmark:
time run linc/test-models/broken/3DBenchy_scale15.7.binary.stl linc/params-example

This information is better calculated on the fly since computation
is cheaper than malloc/free of cached values.

We save ~1% of execution time in our benchmark example:
time run linc/test-models/broken/3DBenchy_scale15.7.binary.stl linc/params-example

This really belongs in the adjustTriangles algorithm.

We also save ~1% of execution time in our benchmark:
time run linc/test-models/broken/3DBenchy_scale15.7.binary.stl linc/params-example

This is because it really belongs inside the updateIntegrity algorithm.

We also save ~1% of execution time in our benchmark:
time run linc/test-models/broken/3DBenchy_scale15.7.binary.stl linc/params-example