Implementation Wrap ScalableFM

[gviga]

I'have implemented a function in wrap in which I wrapped the functions of Scalable FM imtegrated with our Hiarchical mesh approach.

Note: This is mainly a test on how to work. Some bad practices will be changed in the future.

[luisfpereira]

Quick note on linting (see c886676): I expect linting to be automatically done by ruff. In visual studio you (@GiLonga, @gviga) can accomplish that by installing this extension.

[luisfpereira]

@gviga, I'll try to justify the changes I've done in 415cd8d. Please let me know what you think (I'm open to undo anything you don't agree with).

As we've discussed in the last meeting, if we sample, we need a Sampler (something that has a sample method taking a shape and outputting an array). Therefore, I've added: BaseSampler, PoissonSampler, and NearestNeighborIndexSamplex.

As you would expect, we do not implement any PoissonSampler, but instead wrap pymeshlab for that. I've registered it, so we can do e.g. PoissonSampler.from_registry(n_samples=1000).

Additionally, I've realized LargeMesh.process_mesh does not expect coordinates coming from a sampler, but indices. Therefore, I've added NearestNeighborsIndexSampler, which takes a Sampler and then finds the closest points in the original mesh to the samples.
I find the naming quite misleading here, but I'm not inspired to come up with something better. All ears for ideas!

With the current approach there's not a lot of changes: we delete LargeMesh.knn_query and LargeMesh.poisson_sample and replace two lines of code in LargeMesh.process_mesh by a simpler one.
Nevertheless, I find this approach appealing for the following reasons:

1. we can sample any mesh without having to instantiate LargeMesh

2. we can easily plug in a different sampler (who wants to implement e.g. farthest point sampling?!)

3. due to 1., testing of samplers becomes much easier

4. we clearly know what parameters are used for what (e.g. n_samples is used to instantiate a sampler at init and not at process_mesh time; for this is obvious, but it is not always the case)

I already have other ideas on how to improve this code... but leaving that for another day.

[GiLonga]

@luisfpereira @gviga About 2) I was thinking to add a sampler based on distance functions, similar to what’s done in pyfm, with both Geodesic and Euclidean options. This addition is also useful for our S4A project. Just a thing, I was thinking of farthest point sampling as a method of the Shape class, and then the euclidean distance for PointCloud and finally the geodesic for TriangleMesh (and the TriangleMesh would inherit from PointCloud).

[luisfpereira]

@GiLonga, my two cents on this:

Great idea to have a sampler based on distances.
If distance is computed explicitly, I think we should follow a geomstats-like format, i.e. a distance/metric is something we can equip a Shape (seen as a manifold/metric space) with. This because there's a multitude of distances we can put on a shape, so we want to do it by composition instead of inheritance.

I don't see sampling as a method of the Shape class, though later, if you really want that, we can do something like:

class Shape:
  def sample(self):
    return self._sampler.sample(self)

(btw, really appreciate the suggestions! adding it to our tasks)