Updated minor versions in CMakeLists.txt. New files added to GTMathematics. Fixed an incorrect library name in GTMathematicsGPU.

The major revision is based on running the code analysis tools for Microsoft Visual Studio 2019 16.11.8 and for ClangCL. The reported issues were addressed with the exception of some incorrect warnings from MSVS 2019. For now, the incorrect warnings are encapsulated by pragma commands and will be removed in the GTL development track.

The MSVS code analysis tool is not robust. Sometimes warnings occur in both the Output and Error List windows. Sometimes they occur in only one or the other window but not both. And sometimes they do not occur in either window, but the 3-dot markers show up in source files that are opened after which the warnings show up in the Error List window. As I discover source files where the warnings show up only when the source file is opened, I will fix the issues. I believe most of these will be warnings about potentially uninitialized variables, typically for class objects whose default constructors should be called but MSVS seems to believe the class members are not initialized. This is the case for the Vector classes, but in the code using these classes, the members are set soon after the declaration. I was hoping the tool would figure out that the member initialization was deferred. If I were to allocate a  td::vector of Vector with a very large number of elements, and the code fills them in by loading data from a file, it would be a shame to waste all that time having the constructor initialize the members only to fill them in again from the loaded data.

Another tool issue occurred with SymmetricEigensolver.h, in the GetEigenvector function. I have comments in that file about why the tool report is incorrect. For a long time I have been able to ignore the warning because code using it compiles fine, even with "treat warnings as errors". The warnings occurred as part of a regular source-code build. For the first time I ran the code analyzer explicitly from the MSVS IDE menu on a source file that contains only the include of the aforementioned header file. The report now includes more warnings that appear to be based on the same incorrect diagnosis. The original warning was about a potential out-of-range index, and the Error List window allows you to drop-down a list of steps and assumptions to support the diagnosis. The new warning is about the same issue but for some reason displays a list of line numbers that show up in the drop-down list. After these new warnings occurred, I can no longer successfully build code using the eigensolver. I had to add pragma commands to prevent the warnings. After that, a couple of other files generated similar warnings that had to be disabled using pragma commands.

I had also spent a lot of time eliminating the warning about preferring scoped enumerations over unscoped ones. The unscoped ones typically defined enumerants that were used as array indices in the DX11 and GL45 engine code. This is not allowed with scoped enumerations. I replaced the unscoped enumerations with nested structs, each structure containing constant expressions of the form "static uint32_t constexpr someName = someValue;". MSVS 2019 and ClangCL provided with MSVS 2019 allowed this modification, but unfortunately gcc on my Linux boxes did not. Searching stackoverflow, it appears that C++ considers such structs to be "incomplete". I actually got linker errors about the various constants referenced by the sample applications but not found in the libraries linked to the applications. I restored the unscoped enumerations and disabled the code analysis warning number
in the project settings.

A couple of the sample applications use BSRational<UIntegerFP<N>> where N is large. These lead to code analysis warnings about "/analyze:stacksize numKBs" indicating that numKBs is larger than the maximum stack size and the you should consider moving data from the stack to the heap. The samples have run correctly without stack overflow errors, so it is not clear to me what the problem is. Regardless, I modified the project settings and specified numKBs large enough to avoid the warnings. When I switched to using ClangCL, the compiler complains it cannot find files named "/analyze:stacksize". It appears that ClangCL does not understand this analysis tool option. Unfortunately, with "treat warnings as errors", those sample applications will not compile. So I removed the setting of numKBs and then disabled the code analysis warning number in the project settings.

The latest code updates, bug fixes and documentation.

This is a major update. I removed the logging aspect of the "logger" system. Now all that Logger.h exposes are macros for assertions and errors that throw exceptions. This avoids duplicate symbol error messages from a linker when the Logger.h constructor is not inlined in all modules that are linked together. Also, I started the process of ensuring constructors initialize all members (using MSVS 2019 code analysis to find such issues). Many files have been modified as a result of the changes, although the LogAssert and LogError statements still exist (but only throw exceptions). To see a full list of changes, visit my Geometric Tools downloads page and click on the GteUpdateHistory.pdf file.

The pushes before the tag of GTE 5.13 should have included modified CMakeLists.txt files (with minor version changed from 12 to 13).

Most of the distance subsystem of GTE was revised or rewritten, mainly to avoid the LCP solver which was a performance problem when object features were (nearly) parallel. The subsystem consists of linear algebraic objects: point, line, ray, segment, triangle, rectangle, plane, box. The Result objects now have constructors that initialize the members explicitly, and the member names are consistent among files. Derivation of distance queries involving aligned boxes and oriented boxes was removed by factoring out canonical boxes, which are aligned boxes with centers
at the origin. An aligned box can be reduced to a canonical box by a translation. An oriented box can be reduced to a canonical box by a rotation and a translation. Unit tests were updated, and some classes needed unit testing. Validation of the unit-test results was performed using convex quadratic programming in Mathematica (via NMinimize).

Several bugs were discovered and fixed. DistPointOrientedBox.h had a template alias using AlignedBox when it should have used OrientedBox. DistSegment3OrientedBox3.h had segExtent instead of -segExtent in the last else-block. DistSegment3Rectangle3.had segExtent instead of -segExtent in the last else-block.

AlignedBox has a new member function GetVertices.

Hyperplane has a new member 'origin', a point on the hyperplane.

DistPoint3Rectangle3.h is obsolete, replaced by DistPointRectangle.h (distance in any dimension). DistPoint3Plane3 is obsolete, replaced by DistPointHyperplane.h (distance in any dimension).

DistPointTriangleExact.h is obsolete, its code moved into DistPointTriangle.h DistSegmentSegmentExact.h is obsolete, its code moved into DistSegmentSegment.h.

GTE 5.11 has been posted to the Geometric Tools website.

Also removed the old installation/release notes and added the new notes.

The projects now include the just-added incremental insert/remove for Delaunay triangulation.

Modified the copyright notices to include 2021.

Updated projects, makelists and release notes.

Incremented the GTE_MINOR_VERSION to 4.

The ConstrainedDelaunay2 class had two bugs that needed to be fixed. The first bug was incorrect handling of adjacent triangles during retriangulation of the triangle strips containing the constrained edges. This problem shows up when the triangle strip snakes around and has a shared edge with another triangle that is not its immediate predecessor in the strip. The second bug was an incorrect computation of the pseudosquared distance function. This problem shows up when locating the closest vertex of a boundary polygon to the base polygon edge. In particular, the bug was exercised when the projections of the candidate vertices to the base edge of the polygon contained at least one projection on the segment and one projection outside the segment.

This code is approximately 13 years old and was complicated to read and debug. It discarded the mGraph member from the Delaunay triangulation and instead used the compact arrays mIndices and mAdjacencies. I rewrote ConstrainedDelaunay2 to continue using the mGraph member, in the process simplifying the implementation to be readable. Many comments were added, but I plan on adding a PDF to the website describing the pitfalls of the retriangulation and how to avoid them. The original code was based on an online research paper that discussed the simplest retriangulation configuration, but had no discussion about the pitfall cases. The various file changes are described next.

GTE/GTMathematics/ConstrainedDelaunay2.h: Reimplemented ConstrainedDelaunay2 according to the aforementioned comments.

GTE/GTMathematics/Delaunay2.h: Factored out some code into a new function UpdateIndicesAdjacencies. This code occurred after the Delaunay triangulation to synchronize the information in mGraph with the compact arrays mIndices and mAdjacencies. To support ConstrainedDelaunay2, the factored function can be called after a user-determined set of edges have been inserted one at a time.

GTE/GTMathematics/ETManifoldMesh.h: Added two helper functions to ETManifoldMesh::Triangle, namely, GetAdjacentOfEdge and GetOppositeVertexOfEdge. I will continue to encapsulate commmon operations and add them to ETManifoldMesh. These operations tend to occur as in-application code, but that code should be shared.

GTE/GTMathematics/TriangulateCDT.h: The modifications to ConstrainedDelaunay2 required a small modification to the polygon triangulation that uses constrained Delaunay triangulation. The code copies the Delaunay mGraph object to the local graph object.

GTE/Samples/Geometrics/ConstrainedDelaunay2D/ConstrainedDelaunay2DWindow2.cpp: The insertions are not batched; rather, they are executed one at a time based on key strokes. The application now needs to call UpdateIndicesAdjacencies after each edge insertion.

The modifications allow versions of CMake before 3.12 to compile the code.

Added support to the Linux distribution for CMake executed from a command line and for Visual Studio Code. Please read the installation and release notes on how to build the libraries and samples on Linux.

The shared-library executables in the Linux distribution were crashing on exit from  the main program. Using gdb and the core dump, the problem appeared to be in the destruction of global objects in the gtapplications shared library. The singleton TheWindowSystem was actually created 3 times because of the way shared libraries are linked and loaded. I had added -rdynamic to the makesample.gte link line (suggested by a poster at stackoverflow). This eliminated the multiple creations of TheWindowSystem. Unfortunately, on-exit crashes still occurred, this time in the destruction of global objects in the gtgraphics shared library. The only global objects are several class-static members. To diagnose with a visual debugger, I decided to add Visual Studio ...