API proposal for 3D mesh smoothing

[fprotais]

Summary of Changes

This PR contains the first version of:

• User manual
• Code documentation
• Code base
• Working examples

for the proposed 3D mesh smoothing package.

Release Management

• Affected package(s): Mesh_smoothing_3
• Feature/Small Feature (if any): https://cgalwiki.geometryfactory.com/CGAL/Members/wiki/Features/Mesh_smoothing_3
• License and copyright ownership: GPLv3 & Inria

TODO

• filter out extra files from history (@sloriot)

[afabri]

You write "API proposal", as for now you propose concepts, and the models are "only" in examples, right?

[afabri]

A first feedback

[fprotais]

You write "API proposal", as for now you propose concepts, and the models are "only" in examples, right?

While the code and examples are already working, this PR was put mainly before the API freeze. Maybe the wording was confusing and I should have detailed that. I have several examples of implementation of the concept, they are in the PR, but undocumented. I wanted to focus on the concept and the C3t3_smoother that could already be of use in GF applications.
At a later stage, I will develop the documentation of "helper tools" in the package, for example to support mixed element meshes.

Thanks for the feedback, I'll do the corrections.

[afabri]

I think the real question is if we do not want to be similar to the BGL API.

[sloriot]

I think the real question is if we do not want to be similar to the BGL API.

IMHO for this version, I would target something only working for c3t3 and existing CGAL types which would not block the introduction of something more general in the next version (without breaking the API).

[fprotais]

I addressed some of the comment, not all, but it is in progress.

Regarding BGL, I can see changing some of the naming convention to match better, but why not match more to Triangulation_3 and C3t3 instead? From my understanding, BGL does not support tetrahedral meshes which is the first focus of my code. Having different "framework" for the different concepts (Volume, surface and curves) could be confusing.

[afabri]

Can you make me collaborator?

[afabri]

std::size_t must be backticked.

[afabri]

What do you mean with "optional" ? That it may also be int or even void ?

[fprotais]

What would be the "less wordy" way to have a "size_type" instead of std::size_t? Triangulation_3 use its own typedef, but here I would see it as unecessary. Do I just use std::size_t?
(Regarding the backticked, I didn't find another example, it would just be std::size_t ?)

[afabri]

Suggested change

	Manual
	Manual
	SMDS_3

[fprotais]

Right now I am not using anything, but that will change later. I will remove everything here and add back progressively.

[afabri]

It would be good to not call your branch "main" but for example "Mesh_smoothing-fprotais"

[afabri]

You should also remove trailing whitespace. In emacs I has a hook when saving the file. vscode can also do it. In case there are tabs in your files, you must also replace with blanks.

[github-actions]

The documentation is built. It will be available, after a few minutes, here: https://cgal.github.io/9576/r2/Manual/index.html