Kissualizer Update: Inspection Mode and more Keybindings

[l00p3]

I want to propose some new feature for the visualizer, also following the request in #383 .
First, keybindings also to show/unshow point clouds:

Second, more interesting, an inspection mode:

This pops-up only when you are in "pause mode" and allows you to pick-up poses on the trajectory to check the position and show the voxel grid. Once you press play all the things done in inspection mode disappear. This to avoid over-computation while playing the sequence. Also because I think you never need to check the voxel grid in "play" mode but only frame by frame (at the best using "next frame"). Switch from global to local is supported of course.

I also added to orthographic view option to check the voxel grid. It has only a problem with zoom, probably someone can help me to solve this, right now it is very difficult to zoom in and out as it is only changing the camera field of view not actually zooming, and it seems that the pybinded version of polyscope does not allow you to do so much for this.

[l00p3]

Sorry for the messy commit history, my main branch was not aligned with PRBonn:main. Now everything should be fine. In case I can "re-do" this pull request to have a cleaner history.

[benemer]

As long as the diff is clean, it is fine :)

I like the new voxel visualization, although the visualizer class has become quite large now.

In my view, the orthographic view is not needed and, anyway, not nice to use with the zoom, as you said. If you want to inspect the voxel grid from the top, it should be fine to just use the mouse for navigation.

[benemer]

Another feature could be to also visualize the correspondences, what do you think?

[l00p3]

Orthographic view removed as suggested by @benemer, It was too messy and without it also the code lines are reduced quite a bit.
@benemer I will give a try to associations also, worst case we can just roll back the commits.

[l00p3]

@benemer you can now visualize the associations. Let me know if you like it!

[benemer]

Thank you so much for adding this feature, I love it! This can help when debugging the map density or association threshold.

However, Tiziano and I are now unsure if this can cause some memory overload when storing the correspondences in the registration class vs. only having them in the for loop, and they go out of scope. What do you think @nachovizzo?

[tizianoGuadagnino]

@benemer @nachovizzo @l00p3

Just FYI there is a runtime difference when using the visualizer (-v option in the python CLI)

Without Visualizer

With Visualizer

If I disable multi-threading the problem seems to be less visible, which make sense to me. I am not bashing the viewer, and probably it is also not critical, but we should discuss if we want to investigate more.

[l00p3]

In defence of Polyscope:

These the result using the old visualizer (Open3D) with the "-v" argument:

This without (on the same sequence, MulRan KAIST01):

All tested on the commit "12905ecf8505b634069e015e7098927340ca6c26", before the introduction of Polyscope.

It seems that this is an issue that was in Kiss since before. Probably a good idea to indicate that numbers can differ in terms of execution if launched with visualization, especially if people want to use your number in paper, to not underestimate Kiss power.
What if we put this disclaimer in the visualizer? ;)

Btw, for completeness I put here the results, on the same machine (mine) with the same dataset but with the last commit (so with Polyscope already introduced), to check that the difference is not worst with polyscope but more or less the same.
With visualization (polyscope):

without:

[nachovizzo]

Thank you so much for adding this feature, I love it! This can help when debugging the map density or association threshold.

However, Tiziano and I are now unsure if this can cause some memory overload when storing the correspondences in the registration class vs. only having them in the for loop, and they go out of scope. What do you think @nachovizzo?

I feel like the system is so lean that is worth to pay the price in memory. If for some application is required to reduce the memory footprint, this can be removed... we struggle so many times with this that would be totally valuable to have a way to visualize and debug correspondences. Besides the current investigations we have done in this regard, and remembering how the adaptive threshold started, don't forget that everytime we plot the correspondences we see a new bug #300 :)

The only thing I might not like is storing this as a class member.... But it's an easy and effective solution. The registration can only happen if we have correspondences...

[benemer]

What if we put this disclaimer in the visualizer? ;)

Another idea: We can also modify the pipeline such that you only print/log the FPS when the visualizer is turned off.