[bin] meshroom_batch: Remove --cache option

[jikbb2]

Description

This PR fixes a critical bug where running meshroom_batch with both --save and --cache arguments simultaneously creates a nested cache directory (e.g., test_cache/test_cache).

This incorrect structure is not just a cosmetic issue; it breaks the pipeline execution. Subsequent nodes fail to locate their input files from previously completed nodes because they search in the expected (non-nested) path instead of the actual nested one. This causes a failure to reference intermediate results and halts the computation.

Features list

• Fix nested cache creation bug. Fixes [bug] Nested cache directory created when using meshroom_batch with --save and --cache simultaneously #2889

Implementation remarks

The root cause was a redundant graph.save() call at the beginning of executeGraph() in meshroom/core/graph.py. This call used the default argument setupProjectFile=True, which incorrectly re-triggered the project's automatic cache setup logic, conflicting with the user-provided --cache argument.

The implemented solution is a minimal, targeted change: the problematic call is modified to graph.save(setupProjectFile=False).

This preserves the intended functionality of saving the graph's progress during computation while disabling the specific logic that caused the path conflict. This ensures the user-provided cache path is respected as the single source of truth.

To test this fix:

Follow the "Steps to Reproduce" from issue #ISSUENUMBER.

Run the command: meshroom_batch -p photogrammetry -i ./images --save test.mg --cache test_cache.

Verify that a single, non-nested test_cache directory is created and the pipeline completes successfully without errors.

[fabiencastan]

@jikbb2 Thanks for the PR!
What do you think about completely removing the --cache option?
As the "--save" already defines where all the data will be stored.
And when we will reopen the project.mg file, Meshroom will look into the relative MeshroomCache folder.

Or do you have a need in your use cases to put the cache and the project file in different places?

[fabiencastan]

I've checked the cache is not stored in the project. So when you will reload the computed Meshroom scene, it will not find the MeshroomCache.
So I think, we should remove the --cache option.
@jikbb2 : Could you update your PR with that?

[jikbb2]

Hi @fabiencastan ,

Thanks for your feedback. I'd like to clarify the implementation to make sure I get it right.

Which of these two options do you prefer?

Disallow simultaneous use: Add a check to prevent using --save and --cache together, but still allow --cache to be used by itself.

Completely remove: Remove the --cache argument entirely from meshroom_batch, as you suggested.

Additionally, should this PR also cover updating the command's help text and any other user-facing descriptions to reflect the change?

[fabiencastan]

Hi @jikbb2 ,
Sorry for the delay to answer.
I think, the second option would be better. We can fully remove the --cache option and update the command line help accordingly.

[jikbb2]

I've updated the PR according to your feedback. The --cache option has been completely removed from meshroom_batch as requested.

Thanks again for the guidance! @fabiencastan

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.01%. Comparing base (912a71d) to head (b890f61).
⚠️ Report is 3 commits behind head on develop.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #2890   +/-   ##
========================================
  Coverage    82.01%   82.01%           
========================================
  Files           69       69           
  Lines         9310     9310           
========================================
  Hits          7636     7636           
  Misses        1674     1674           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[cbentejac]

Hi @jikbb2, sorry it took so long for this to be reviewed! I took the liberty of rebasing your branch on top of develop to avoid having the intermediate merge commits in the history.

Thanks a lot for your contribution!