[BrunoLevy01]

Thank you very much for discussing about geogram ! To answer some of the questions I see in the comments:

TL;DR: if you need a generalist library, use CGAL or libigl, if you have very specific needs of performance / compactness of the code / low memory consumption for specific functionalities, then you may need Geogram.

1) comparison between geogram and other libraries (CGAL, libigl)

Is is very difficult to compare different "swiss army knives" that have a completely different set of blades. Geogram specificities are:

- focusing on a small set of algorithms and use cases, and optimizing them (whereas the other libraries are more general-use). This includes:

- Delaunay/Voronoi/Power diagrams in 2D and 3D, with optional periodic conditions. For instance, it is used in my research on cosmology, that has diagrams of astronomical size, with hundred millions points (the other libraries no longer fit in memory). The price to pay: geogram does not support vertex suppression (if you need that, you can use CGAL).

- Mesh parameterization and segmentation, texture generation

- Baking (transfer attributes between textured meshes / generate normal maps)

- Mesh repair

- Remeshing

- Restricted Voronoi diagrams for surfaces and volumes embedded in space of arbitrary dimension. Not everybody will need that, but it is used internally by the surface remesher (that works in dimension 6)

- Semi-discrete optimal transport

Some features are presented here: https://github.com/BrunoLevy/geogram/wiki#mini-tutorials-and... It does not have mesh deformation (you can use libIGL if you need them)

It also has lower-level components:

- sparse linear solver OpenNL CPU/GPU

- easy-to-use 3D graphics API on top of OpenGL3

- minimalist framework around Dear ImGui to develop applications with GUIs

- focusing on portability and ease of compilation Geogram works on Linux/Mac/Windows/Emscripten/Android

You can run some demos in your browser (thanks to Emscripten): https://github.com/BrunoLevy/geogram/wiki/compiling_Emscript...

- programming API and design choices

Geogram has nearly no dependency. Geogram does not use Boost (that I don't like, I find it too heavy, that's personal choice). Geogram is not a "header only" library and moderately uses modern C++ constructs. Design choices are explained in this presentation: https://fr.slideshare.net/BrunoLevy4/the-joy-of-computer-gra...

In the end, the compiled library is very small (a few megabytes) and can be easily embedded in other applications (a list here of usages in industry and academy: https://github.com/BrunoLevy/geogram/wiki/Publications)

- It has an interactive application here: https://github.com/BrunoLevy/GraphiteThree (you can load your meshes, repair them, remesh them etc...)

2) Does it support exact geometric computations ?

Of course ! It has exact predicates and exact geometric constructs. They are implemented using arithmetic expansions (https://brunolevy.github.io/geogram/multi__precision_8h.html) (that uses array of doubles internally), and it is fast. It has its tool to automatically generate exact geometric predicates from their formulas.

3) Boolean operations ?

They are on their way (https://twitter.com/BrunoLevy01/status/1623347815307960321). Current version is here: https://github.com/BrunoLevy/Experiment (Graphite plugin). Most models from Thingy10K are OK, currently focussing on a couple of "monsters" that push the limit.

4) I want to only use a subset of the library

Geogram has a system to extract "pluggable software modules", that is, a .h/.cpp pair with a single functionality. There are PSMs for:

- exact arithmetics and predicates https://github.com/BrunoLevy/geogram.psm.Predicates

- Delaunay triangulations https://github.com/BrunoLevy/geogram.psm.Delaunay

- OpenNL linear solver (CPU and GPU) https://github.com/BrunoLevy/geogram.psm.OpenNL

[Const-me]

PSM includes the dependencies, instead of getting rid of them. Not flexible enough.

An example is logging. Geogram includes a logger implementation which uses console streams. GUI apps don't have these streams, they sometimes even deadlock, when an app prints too many characters no one is reading on the other end of the pipe. Geogram includes another file logging implementation in FileLogger class. It uses std::string for path, which doesn’t work on Windows because Windows paths are using UTF-16 encoding.

Also, many parts of Geogram are bypassing the logger API, they directly printing text into std::cerr.

Here’s a possible example of an API which allows to inject custom loggers into DLL libraries:

    // Log level for messages
    enum struct eLogLevel : uint8_t
    {
        Error = 0, Warning = 1, Info = 2, Debug = 3
    };
    // C function pointer to receive log messages from the library. The messages are encoded in UTF-8.
    using pfnLoggerSink = void( __cdecl* )( void* context, eLogLevel lvl, const char* message );

[BrunoLevy01]

Thank you very much for this feedback, it is super useful. Do not hesitate to post this type of comment to geogram's github (https://github.com/BrunoLevy/geogram/issues)

Please note that the Logger mechanism can be redirected to a GUI, it is used for instance in the GUI applications made with Geogram (https://github.com/BrunoLevy/geogram/wiki/Applications) and in Graphite (https://github.com/BrunoLevy/GraphiteThree)

About using std::string as path under Windows, I understand that it may cause some problems with users who use general characters in their directories, but it does not prevent the application from running and from loading/writing files. In the future, when std::filesystem is well standardized, I plan to get read of my FileSystem implementation.