Blender export error Blender 5.1 mmSolver 0.7.0 Linux 64 Maya 2024

[samhodge-1972]

Using version 0.7.0 with Blender

I get

Python: Traceback (most recent call last):
  File "/home/sam/.config/blender/5.1/scripts/addons/mmSolver_blender_addon/mmsolver_2d_tracks_export.py", line 58, in execute
    clip, cam, tracks = utils.get_selected_clip_objects(context)
                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^
  File "/home/sam/.config/blender/5.1/scripts/addons/mmSolver_blender_addon/utils.py", line 34, in get_selected_clip_objects
    cam = clip.tracking.camera
          ^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'tracking'

What I was doing was selecting all the tracks and choosing export

tracking_soccer_cones.blend.zip

Other associated data here:
https://drive.google.com/drive/folders/1E1aYIfuPg9Wew1RVNTV6MtTtSKfT6TMT?usp=sharing

Includes 16bit Depth Passes from Depth Anything v3.0

6077698-uhd_3840_2160_25fps_depth.mp4

[samhodge-1972]

Tagging @david-cattermole Whenever you get a chance I would love your help on this.

[david-cattermole]

Hey @samhodge-1972, I've taken a look.

I haven't been able to install Blender 5.1 yet, however my initial testing is on Blender 5.0.1 installed via Flatpak on AlmaLinux 9.x.

I found that I can select all the "Tracks" (what mmSolver calls Markers) with CTRL + A or (Select menu > All), and then export the markers with no error.

Here is a screenshot:

Would you be able to test with Blender 5.0.x and confirm it works for you too?

---

I then copied Markers (from the exported file) into Maya, and ran a solve with default values (except I set the log output to "info" level), and this is the stdout:

Loading solver settings from: /home/username/maya/projects/default/data/mmSolver_camerasolver/camerasolver_camera1.mmsettings
Using 4 rayon thread(s) for parallel work (auto-detected).
Using mmcamera defaults from: /home/username/maya/projects/default/data/mmSolver_camerasolver/camerasolver_camera1.mmcamera
Loading UV markers from: /home/username/maya/projects/default/data/mmSolver_camerasolver/camerasolver_camera1.uv
Loaded 71 markers:
  Format version: Version4
  Frame range: 1 - 230
  Using frame range: 0 - 230
Warning:   UV file contains only distorted marker positions but no lens file was provided. Solving will use distorted positions which may reduce accuracy.
Camera parameters:
  Focal length: 35 mm
  Lens center: (0, 0) mm
  Image size: 2048x1556 pixels
  Film back: 35.99999999999999x20.250000000000004 mm
Running camera solve...
[Phase 0]  Time | Solve: 231 total frames, 71 total markers
[Phase 0] ----- | Frame range: 0 to 230
[Phase 1]  0.0s | Frame analysis: 24 markers selected, 21 common frames.
[Phase 2]  0.0s | Initial reconstruction: frame pair (17, 36)
[Phase 2]  0.0s | Triangulated 10/24 bundles (42%)
[Phase 2]  0.0s | Mean px | Median px | Frames | Bundles | Stage
[Phase 2] ----- | ------- | --------- | ------ | ------- | -----
[Phase 2]  0.0s | 492.419 |   438.385 |      2 |      24 | Root frame pair
[Phase 2]  0.1s |   2.499 |     2.412 |      2 |      22 | Root frame pair BA
[Phase 3]  0.1s |   9.226 |     2.543 |    110 |      22 | Round 1 (final): PnP +108 cameras
[Phase 3] 57.7s |   5.190 |     2.610 |    110 |      15 | Round 1 (final): BA
[Phase 3] 57.7s |   4.981 |     2.735 |    112 |      21 | Round 2 (final): PnP +2 cameras
[Phase 3] 106.2s |   3.911 |     2.322 |    112 |      18 | Round 2 (final): BA
[Phase 4] 125.5s |   4.638 |     2.535 |    112 |      20 | Global BA
[Phase 5] 125.5s |   4.200 |     2.616 |    112 |      30 | Final result
[Phase 5] 125.5s | Transforming to origin frame 0.
[Phase 6] 125.5s | Camera solve completed!

Camera solve completed!
  Solve time: 125.465s
  Frames solved: 112
  Frames unsolved: 119
  Bundles triangulated: 30
  Final reprojection error: mean=4.200 px, median=2.616 px
  Solved frames: 1-112
Solve completed in 125.47s: 112 cameras, 30 bundles, mean_err=4.2000px
Solve completed!
  Cameras solved: 112
  Bundles triangulated: 30
  Mean reprojection error: 4.2000 pixels
  Median reprojection error: 2.6162 pixels
Writing Kuper file to: /home/username/maya/projects/default/data/mmSolver_camerasolver/camerasolver_camera1_camera.kuper
  Wrote 112 frames
Writing bundle file to: /home/username/maya/projects/default/data/mmSolver_camerasolver/camerasolver_camera1_bundles.mmbundles
  Wrote 30 bundles
Writing mmcamera file to: /home/username/maya/projects/default/data/mmSolver_camerasolver/camerasolver_camera1_camera.mmcamera
  Wrote 112 frames (mmcamera)
Writing residuals file to: /home/username/maya/projects/default/data/mmSolver_camerasolver/camerasolver_camera1_residuals.mmresiduals
  Mean: 4.2000 px, Median: 2.6162 px, Count: 2203
=== Timing Summary ===
  Camera solve:         125.47s  100.0%
  File I/O:               0.00s    0.0%
  Total time:            125.48s (2.09 minutes)
Done! Total time: 125.48s

So we get an average of 4.2 pixel residual error from a 36mm x 20.25mm sensor size with a default 35mm lens, but only the first 111 frames were solved, in ~125 seconds. Performance could be a lot better, but that's not my primary goal right now.

I can see some poor tracking markers (Track.30) which the solver will not like - it expects good data only (garbage in, garbage out), which could be cleaned up.

Would you mind if I use this example footage as test data and diagnose why it's not solving the full frame range, and see if I can get a better solve?

---

I've attached all the inputs and outputs from this process to this comment.

Marker File exported from Blender 5.0.1:
tracking_soccer_cones.uv.json

mmsolver-camerasolve inputs (generated by Maya):
camerasolver_camera1.mmsettings.json
camerasolver_camera1.mmcamera.json
camerasolver_camera1.uv.json

mmsolver-camerasolve outputs):
camerasolver_camera1_solve.log
camerasolver_camera1_residuals.mmresiduals.json
camerasolver_camera1_bundles.mmbundles.txt
camerasolver_camera1_camera.kuper.txt
camerasolver_camera1_camera.mmcamera.json

Note to get these files to update to GitHub, I needed to add .txt or .json to the file names. Rename the files to remove this extension if that causes issues.

Thanks,
David

P.S. Blender has a frustrating history of breaking their Python API in non-backwards compatible ways (for example #282), so I may need to add support for the newest 5.1.x version if that is the case - blame the Blender developers.

[samhodge-1972]

Oh I thought you could export the 2d markers only once I did a solve everything kinda worked better.

[samhodge-1972]

Oh I really a a silly little rabbit.

Your diagram underlines a button that may have well worked for 2d tracks only.

The File > Export > MMM (.uv) menu only works in you have 3d bundles.

I will go back and try now with the highlighed button.

[samhodge-1972]

Yeah it totally works, I would have never found that Track tab on the right of the Clip Window in Blender, it defaults to Footage tabe and Blender is pretty unfamiliar to me.

That is life in the big city, sometimes you get lost.

[david-cattermole]

Sorry, I didn't even realise there was a "File > Export" feature exposed.

The documentation for the Blender tool explains the workflow that I have tested:
https://david-cattermole.github.io/mayaMatchMoveSolver/tools_inputoutput.html#copy-2d-tracks-from-blender

Yes, the tool is fairly hidden, but it was the best place I could find that would have the correct "context". Blender seems to orient around the idea of "context" where if you call the same code in different contexts, it can change behaviour - in this example if you don't call the tool from the expected 2D Tracking context it won't know which "clip" you are using, and so it will error.

I'll see what I can do to either hide the "File > Export" feature, or at least detect the problem and pop-up a warning, instructing the correct tool and a link to the documentation.