Joining development efforts

[natowi]

How about joining the development efforts for one Meshroom Blender Add-in?
@tibicen (meshroom2blender) (I chose to post on your Issues by random as I had to ask this somewhere)
@SBCV (https://github.com/SBCV/Blender-Addon-Photogrammetry-Importer)
@Stwend (https://github.com/Stwend/MeshroomTools)
@stuarta0 (https://github.com/stuarta0/blender-photogrammetry)

All the Add-ins are slightly different and would benefit from a joined development.

[Stwend]

Sounds like a good idea.
I could contribute the texture packing functionality (UDIM to single texture) and the manual scan alignment tools - the import functionality I have is already there in @tibicen 's plug-in, I think. The UI will probably need some adjustments, too.

[SBCV]

While such efforts are in general a good I idea, I think in this case there are several things that should be consider.

A) Since the addons blender-photogrammetry and Blender-Addon-Photogrammetry-Importer are not restricted to Meshroom, the scope of a joined addon should be more general as well.

B) I think joining blender-photogrammetry and Blender-Addon-Photogrammetry-Importer will be difficult. The first relies on pre-built executables while the latter uses import scripts written in python. Each approach has its own advantages / disadvantages. (However, since these dependencies are quite heavy, I do not think that I want to join them with my addon, which is rather lightweight.)

C) Does the addon meshroom2blender contain some functionality that is not contained in blender-photogrammetry or Blender-Addon-Photogrammetry-Importer?

D) I've seen that meshroom2blender and blender-photogrammetry use this point cloud blender addon. Does that still make sense, considering that the current blender API supports the gpu module? With the gpu module point clouds can be visualized with a fraction of code using the previous API - see for example here. (If you are aware of any downsides of the gpu module, please let me know.)

E) As far as I can see MeshroomTools provides some extended texturing functionality. That could be a nice completion to the other addons. How does the addon determine the textures? Does the addon load camera poses etc. as well? @Stwend could you comment on that?

[natowi]

A) The idea is to have one go-to addon for photogrammetry with good Meshroom support

B) We do not need to merge all the projects, just pick the best features from each and put it into one.

C) Yes, reading project.mg files

[stuarta0]

Hi all! I understand the want to join them together as it's a little tricky for users to know which one to use. At the same time @SBCV has hit the nail on the head. For general use, Blender-Addon-Photogrammetry-Importer would be the one to use as it covers most formats.

My addon was borne from a need to generate point clouds from manually or predefined sparse matches, including from the blender motion tracker. And since others on our project team wanted to try it (who had little experience with Blender or python), I bundled executables to make the installation as simple as possible. But this makes the addon needlessly large, and will get outdated with new releases to those software packages. It also evolved into a kind of pick and mix for reconstruction, allowing sparse reconstruction from one software to be densely reconstructed by another.

I may refactor at some point to have settings for executable paths so users can use their own installed versions and thus lighten the size of the install at which point I'd consider it a bit more suitable for consolidation. If so, we'd need to iron out the common use cases and workflows to best suite everyone.

For now I'd be happy with updating my README to direct users to the most suitable addon if you guys think that would be of help?

I have used some code from your projects to achieve my goals (especially from @SBCV, so thanks!), and you're welcome to use mine (obviously, since it's GPL'ed).

[Stwend]

@SBCV The addon ignores everything but mesh and texture data, and the "extended" texturing functionality is just a packing feature - it takes the UDIM textures and automatically bakes them into a single square texture (2x2 for up to 4 textures, 3x3 for up to 9, etc) of user-defined size. I added it mostly because loading several huge UDIMs each time took ages and impacted performance.

Most of the work went into the alignment tools since my workflow at that time was to import a mesh from Meshroom that I would then align to a cluster of already-aligned scans. Since that's not technically a Meshroom exclusive it could also be ported to a more generic "Photogrammertry suite" you mentioned in A).

If we decide to merge the addons, I suggest we put together one list of features we want the addon to have for importing data from Meshroom and one list of features we want for processing the imported data inside Blender (e.g. getting camera positions would be on the import side, turning them into a camera animation path would be a processing feature).

[SBCV]

@natowi The latest version supports now *.mg files as well. Is there something missing?

@Stwend Thank you for your explanation and sorry for the late reply - was quite busy.

When testing your addon, I observed that the packing step produced some strange results.

Packed result:

Original result:

Have you seen such effects before?

[natowi]

@SBCV Thank you, now we only need to add MeshroomTools support and we have a really good addin for Meshroom. (Maybe you could enable loading the Mesh by default for mg files, as it can be assumed that most users want all the files when loading a project mg file)
The only things I can think of that could be added are those listed on the to do list for the meshroom2blender addin:

• seach through node tree and give option which elements import (for more sphisticated node threes)
• if node is not computed then put some info about it

[SBCV]

I've been already thinking about enabling the option by default. However, the default ply- and obj-importer of blender are incredible slow. And I'm afraid that new users could get the impression that the addon is not working. However, you can use the Operator Presets above the import options to store your preferred import options.

[Stwend]

@natowi The latest version supports now *.mg files as well. Is there something missing?

@Stwend Thank you for your explanation and sorry for the late reply - was quite busy.

When testing your addon, I observed that the packing step produced some strange results.

Packed result:

Original result:

Have you seen such effects before?

That's new to me - any chance I could get your test data to replicate the behaviour?

[SBCV]

I've send you an email with a download link to the reconstructed mesh via email