When using the Solver UI, any Markers that are not being used directly, the Markers in the UI should be greyed out or disabled.

A Marker may be disabled if none of the attributes in the UI are connected to the Attribute.

This requires evaluating the connections of the DG and DAG networks.

Using "Solver Steps" is not intuitive for users, and is quite advanced.

Instead of the current "advanced" mode, we should define an algorithm that works most of the time and provide a set of parameters to tune this in the Solver UI. The "advanced" should still be available to users, but the simplifed UI should be shown by default.

The algorithm should be defined in Python, not inside the mmSolver command.

Parameters:

• Root Frames - A list of integer frame numbers.
• Frame Range - with options "Single Frame", "Time Slider (Inner)", "Time Slider (Outer)" or "Custom".
• "Solve Everything at Once" option - On or Off
• "Solve Root Frames Only" option - On or Off

We should not need to give control to users for error conditions, iteration count or solver type.

We should add support for the "cminpack" library for optimization.

http://devernay.free.fr/hacks/cminpack/

CMinpack is stable and robust and has been used for many years.
CMinpack has no dependencies (unless users wish to optionally use BLAS with it).
CMinpack has a CMake build script, which will be easy to integrate into mmSolver.

Both CMinpack and levmar libraries should work together in the same plug-in. Only one library should be required. If one library is not available the other library will be used instead.

Depending on performance, CMinpack may become the new default solver (replacing levmar), if both solvers are availible

Adding support for CMinpack will require:

• Re-writing the Build System.
• Writing new build instruction documentation
• Making sure the Maya plug-in includes the correct code for each solver (probably use preprocessor definitions driven by CMake)
• Test cases to be changed.
• An optional override (at the Maya Module level) to force the default solver to be something else.

When adding attributes to the Solver UI window, there is a lag. The cause is Maya Callbacks. This is being addressed in #18, however until that is fixed and Callbacks become stable, we should make a "Refresh" button the user can press to update the UI.

The "Refresh" button and Callbacks are not needed together, but we should enable the option to use Callbacks, if the user wants to. The Callbacks will be turned off by default.
Therefore we should add a module configuration option to turn this feature on/off.

For testing and development, it is recommended to turn on Callbacks, so we find and refine bugs.

If you add a Rotation attribute into the solver and it contains a value of 0.0, the cminpack_lm solver will not change the value.

This might be caused by using the "mode=1" attribute of CMinpack lmdiff_ function.

mode is an integer input variable. If mode = 1, the variables will be scaled internally. If mode = 2, the scaling is specified by the input diag. Other values of mode are equivalent to mode = 1.

A likely fix is to add an internal offset value to the attribute value, and let the solver use that value, then remove the offset value before setting back into Maya. This offset value may need to change for different attributes, rather than using a specific offset value for all attribute types (rotation verses translation for example).

While solving time consuming solves, Maya appears to "hang", as it does not update.

The UI should:

• Display a progress bar (and update it)
• Display the current solved error level (in the status line)
• Tell the user they can exit the solve by pressing "Esc" key.

To do this, we must call Python code inside the mmSolver Plug-in command.

When using the mmSolver.logger module, printing a warning prints to the Maya Script Editor. Ideally we should print to the console / Terminal / Maya Output Window (on MS Windows).

We might need to use this Maya API command OpenMaya.MCommandMessage.addCommandOutputFilterCallback to detect stuff to be sent to the terminal, so we can log errors and warnings to the terminal.

Reported by Anil.

"I have selected bundles along with the group in outliner and this function "filternodes.get_bundle_nodes(selection)" returns the group transform also."

"it suppose to filter the bundle nodes only right ?"

Bundles are supposed to be just a transform node. It could be anything. This logic should be reconsidered when working with users. Perhaps user-facing tools should use a different logic, and Bundles should be a special node type or have a special locator or hidden attribute.

Whatever change we make, it must be backwards compatible with previous versions.

After performing a solve with "Animated Only" attributes, and Per-Frame strategy (the only strategy supported), and then performing an undo, the undo slowly progresses from the last frame to the first frame. Each frame takes approximately 2 seconds to iterate over.

This is too slow! Undo should be instant.

This has been tested using cminpack_lm solver type, not levmar.
The test environment was Maya 2017, on CentOS 7.x.

The expected cause is that keyframes are set using maya.cmds.setKeyframe, and the tool traverses the timeline using maya.cmds.currentTime. Instead we could try storing the animated attributes solved per-frame, then setting all values at once using Maya API MFnAnimCurve.

When a user selects a node, but does not select any attributes in the channel box, a default set of attributes should be added.

The default set of attributes from a node is dependent on the type of node detected.

• For a Bundle node, the translateX, Y and Z should be added.
• For a Camera, the Translate X, Y, Z, Rotate X, Y, Z (and possibly focal length) should be added.
• For a regular transform node, Translate X, Y, Z, Rotate X, Y and Z will be added, unless they are hidden from the channel box (which would be common on a rig control).

This tool is for smoothing selected keyframes.
There are 3components to this tool:

• UI - The User Interface
• Tool - The underlying user functions that can be run, with "user logic".
• Library - The underlying functions to perform the computations.

Usage:

1. User opens Smooth Keyframes UI
2. User selects object.
3. User opens Graph Editor
4. User selects keyframes that have "noise" or are bumpy.
5. In the Smooth Keyframes UI, user presses "smooth" button.
6. The selected keyframes are now smoothed and blended into the surrounding keyframes.

It would be nice to show a diagram of the smoothing options on example data updated in real-time, as an example of what will be done when the function is run.

Tool Options:

• Type of Smoothing Function - Average, Gaussian or Fourier
• Type of Smoothing Kernel - Box, Triangle, etc (only for Fourier algorithm)
• Width of the blur - Measured in frames
• Blend smoothed and non-smoothed values using a mask
• Width of blur

This tool uses the mmSolver.utils.smooth module for the underlying algorithms.

Make Marker, MarkerGroup and Bundle keyword arguments consistent.

Marker(name=’node’) and Bundle(node=’node’) is inconsistent.
Change Marker to have ‘node’ as a keyword.
name keyword should still be kept for backwards compatibility.

Look at other classes in mmSolver._api and and make likewise changes.

Using the Solver UI, and setting a Solver Step to:

• Attributes = "Static + Animated"
• Strategy = "Per-Frame"

This combination causes an traceback.

This traceback is correct, static attributes cannot be solved for using per-frame strategy.
However, setting this combination should not be possible.
We must make sure Per-Frame is not a valid option, in the Solver UI.

Full Traceback:

# Traceback (most recent call last):
#   File "/home/davidc/maya/2017/modules/mayaMatchMoveSolver-0.2.0-maya2017-linux/python/mmSolver/ui/uimodels.py", line 472, in setData
#     set_attr_func(value)
#   File "/home/davidc/maya/2017/modules/mayaMatchMoveSolver-0.2.0-maya2017-linux/python/mmSolver/tools/solver/ui/solver_nodes.py", line 180, in setStrategy
#     self.setStepNode(n)
#   File "/home/davidc/maya/2017/modules/mayaMatchMoveSolver-0.2.0-maya2017-linux/python/mmSolver/tools/solver/ui/solver_nodes.py", line 117, in setStepNode
#     lib_collection.set_named_solver_step_to_collection(col, node)
#   File "/home/davidc/maya/2017/modules/mayaMatchMoveSolver-0.2.0-maya2017-linux/python/mmSolver/tools/solver/lib/collection.py", line 315, in set_named_solver_step_to_collection
#     set_solver_step_list_to_collection(col, step_list)
#   File "/home/davidc/maya/2017/modules/mayaMatchMoveSolver-0.2.0-maya2017-linux/python/mmSolver/tools/solver/lib/collection.py", line 351, in set_solver_step_list_to_collection
#     sol_list = compile_solvers_from_steps(col, step_list)
#   File "/home/davidc/maya/2017/modules/mayaMatchMoveSolver-0.2.0-maya2017-linux/python/mmSolver/tools/solver/lib/collection.py", line 363, in compile_solvers_from_steps
#     tmp_list = step.compile(col, override_current_frame=use_cur_frame)
#   File "/home/davidc/maya/2017/modules/mayaMatchMoveSolver-0.2.0-maya2017-linux/python/mmSolver/tools/solver/lib/solver_step.py", line 212, in compile
#     strategy,
#   File "/home/davidc/maya/2017/modules/mayaMatchMoveSolver-0.2.0-maya2017-linux/python/mmSolver/tools/solver/lib/solver_step.py", line 80, in _solve_all_attrs
#     raise ValueError(msg % strategy)
# ValueError: strategy is not supported: strategy='per_frame'

When running print bundle, we do not get a useful display of the internal data.

We should print out helpful information about the node, such as UUID and full node path.

Override the __repr__ of the Marker and Bundle classes (and others), to display something more helpful when printing.

Currently we display the overall solved error in the Script Editor, this is not ideal.

To allow better understanding and solver debugging for users, we should show the error (deviation) overall, and for each marker.

Ideas:

• Give feedback to user about solve quality.
• We can use animCurves to show error over time! We should create attributes on the Collection which keyframe error over time.
• We can create per-marker errors as keyframes on specially named attributes.
• After each successful solve, the previous errors are removed and replaced with the new Python SolveResult objects. This will store various debug information, so developers can debug scene files, and save the information in the Maya scene.

Ideally, this Error Graph would be visible inside the Solver UI.

To support .uv files with both distorted and undistorted position data #37, we should also add a Checkbox to the UI to allow users this choice of data loading.

The default value will be to load 2D data as undistorted. If we eventually add live lens distortion inside mmSolver in Maya, we should change this to load distorted data by default.

Solving with CMinpack in the latest release can cause the following traceback, if the error values are NaN.

# Traceback (most recent call last):
#   File "C:\Users\Anil Reddy\Documents\maya\2019\modules\mayaMatchMoveSolver-0.2.0-maya2019-win64\python\mmSolver\tools\solver\ui\solver_window.py", line 421, in apply
#     lib_collection.run_solve_ui(col, refresh_state, log_level, self)
#   File "C:\Users\Anil Reddy\Documents\maya\2019\modules\mayaMatchMoveSolver-0.2.0-maya2019-win64\python\mmSolver\tools\solver\lib\collection.py", line 511, in run_solve_ui
#     status_fn=status_fn,
#   File "C:\Users\Anil Reddy\Documents\maya\2019\modules\mayaMatchMoveSolver-0.2.0-maya2019-win64\python\mmSolver\tools\solver\lib\collection.py", line 445, in execute_collection
#     status_fn=status_fn,
#   File "C:\Users\Anil Reddy\Documents\maya\2019\modules\mayaMatchMoveSolver-0.2.0-maya2019-win64\python\mmSolver\_api\collection.py", line 816, in execute
#     solres = solveresult.SolveResult(solve_data)
#   File "C:\Users\Anil Reddy\Documents\maya\2019\modules\mayaMatchMoveSolver-0.2.0-maya2019-win64\python\mmSolver\_api\solveresult.py", line 97, in _init_
#     self._error_stats[name] = typ(value[0])
# ValueError: invalid literal for float(): -nan(ind)

The core mmSolver does not currently support "box constraints" (minimum and maximum values).

Such support is important for solving Camera focal length and other such bounded attributes. Box Constraints could be used to ensure a solve does not stray too far away from the expected values.

Box constraints can also be used automatically as a "hint", similar to other software that allows users to give a bound to the solved attribute.

The mmSolver command already has the ability to set min/max values, but these are not respected.

We need to support the different combinations of min/max values.

• A minimum value is specified, maximum is not.
• A maximum value is specified, minimum is not.
• Both minimum and maximum values are specified.
• Both minimum and maximum values are not specified.
  When a minimum or maximum value is not specified, it should be set to +infinity or -infinity.

In addition, we must add unit tests for the Box Constraints, with working solves.

Supporting Box Constraints will likely require changing the CMinpack function used from "lmdif" to "lmder" and will force us to calculate our own jacobian matrix.

Some pages with possible help:

• https://lmfit.github.io/lmfit-py/bounds.html
• https://quantsrus.github.io/post/constraints-in-levenberg-marquardt-least-squares-optimization/
• http://devernay.free.fr/hacks/cminpack/ ("Simulating Box Constraints" section)

Simulating box constraints

Note that box constraints can easily be simulated in C++ Minpack, using a change of variables in the function (that hint was found in the lmfit documentation).

For example, say you want xmin[j] < x[j] < xmax[j], just apply the following change of variable at the beginning of fcn on the variables vector, and also on the computed solution after the optimization was performed:

for (j = 0; j < 3; ++j) {
real xmiddle = (xmin[j]+xmax[j])/2.;
real xwidth = (xmax[j]-xmin[j])/2.;
real th = tanh((x[j]-xmiddle)/xwidth);
x[j] = xmiddle + th * xwidth;
jacfac[j] = 1. - th * th;
}

This change of variables preserves the variables scaling, and is almost the identity near the middle of the interval.

Of course, if you use lmder, lmder1, hybrj or hybrj1, the Jacobian must be also consistent with that new function, so the column of the original Jacobian corresponding to x1 must be multiplied by the derivative of the change of variable, i.e jacfac[j].

Similarly, each element of the covariance matrix must be multiplied by jacfac[i]*jacfac[j].

For examples on how to implement this in practice, see the portions of code delimited by "#ifdef BOX_CONSTRAINTS" in the following source files: tlmderc.c, thybrj.c, tchkderc.c.

This issue builds on #9.

Getting a Attribute error while pressing center button in mmSolver shelf, if any object is already centered, clear the selection and press the center button its giving a below error.

Error: AttributeError: file C:\Users"USER"\Documents\maya\2018\modules\mayaMatchMoveSolver-0.1.1-maya2018-win64\python\mmSolver\tools\centertwodee\tool.py line 128: 'unicode' object has no attribute 'objExists'

-Anil Reddy

As a developer of the project, trying to debug why the solver isn't behaving as expected is quite difficult.

I propose we add a flag to the maya.cmds.mmSolver command to write solver debug information to a file somewhere.

For example; maya.cmds.mmSolver(..., debug='/home/user/solver_debug.txt') would write out debug information to the "solver_debug.txt" file. This file could be JSON formatted (so we'll need a JSON writer for C++).

We want to store the following information per-solve evaluation (minimum).

• Function Evaluation number.
• Is jacobian evaluation (or "normal" evaluation)
• Parameter values
• Error values
• Average error value
• Min error value
• Max error value
• Frame number for each parameter
• Marker node name per-error
• Attribute name per-parameter

We should then have utility debug functions (in python) to convert this "solver core debug dump" files into other formats that we can visualise easily.

By default debug output should be turned off.

This will help debugging #53, #54 and #26.

Same as the shelf we have already, we should also create a menu, as some users prefer menus.

Features:

• Run dynamically at startup (unless the studio doesn't want that)
• Add all tools into the menu.
• Add environment variable (controllable in the module file), to enable or disable. By default the menu is enabled
• Build menu(s) from config files (JSON).

If you have 2 collections, A and B, then delete B.
The UI does not update, and does not correctly switch to A.

Closing the UI and re-opening it does not select an active collection, and therefore fails to update the UI.

This also causes the following traceback error (sometimes):

# Traceback (most recent call last):
#   File "C:\Users\catte\Documents\maya\2019\modules\mayaMatchMoveSolver-0.2.0-maya2019-win64\python\mmSolver\ui\uimodels.py", line 420, in data
#     value = get_attr_func()
#   File "C:\Users\catte\Documents\maya\2019\modules\mayaMatchMoveSolver-0.2.0-maya2019-win64\python\mmSolver\tools\solver\ui\solver_nodes.py", line 184, in attrs
#     n = self.stepNode()
#   File "C:\Users\catte\Documents\maya\2019\modules\mayaMatchMoveSolver-0.2.0-maya2019-win64\python\mmSolver\tools\solver\ui\solver_nodes.py", line 112, in stepNode
#     n = lib_collection.get_named_solver_step_from_collection(col, name)
#   File "C:\Users\catte\Documents\maya\2019\modules\mayaMatchMoveSolver-0.2.0-maya2019-win64\python\mmSolver\tools\solver\lib\collection.py", line 296, in get_named_solver_step_from_collection
#     step_list = get_solver_steps_from_collection(col)
#   File "C:\Users\catte\Documents\maya\2019\modules\mayaMatchMoveSolver-0.2.0-maya2019-win64\python\mmSolver\tools\solver\lib\collection.py", line 289, in get_solver_steps_from_collection
#     ensure_solver_steps_attr_exists(col)
#   File "C:\Users\catte\Documents\maya\2019\modules\mayaMatchMoveSolver-0.2.0-maya2019-win64\python\mmSolver\tools\solver\lib\collection.py", line 264, in ensure_solver_steps_attr_exists
#     attrs = maya.cmds.listAttr(node)
# ValueError: No object matches name: collection2

This is using Maya 2019.

The current "Aim At Camera" tool rotates the selected object(s) to aim at the camera. This is a bad implementation.

Instead, we should create a tool that switches to the "Move" tool, and aims the manipulator (using a custom axis), at the camera.
This approach will not change the rotations of the object.
Using this approach we should make sure the "Pin Component Pivot" option is turned on in the move tool, and then released back to the previous value once the tool has finished.

Additionally, we should keep the up-vector aimed at "scene-up" (not camera up), so we can also move up or down based on the scene orientation.

We should keep the older "Aim At Camera", but deprecated and removed from shelves and menus.

This tool is meant to create a Maya node network for solving
Create Node Network for "Solve Bundle position along NURBs curve".

Usage:

1. Select Bundle and NURBs curve (the order does not matter).
2. Run tool, the bundle is selected by the tool
3. The user adds selects the a dynamic attribute in the channel box and adds it into the Solver UI.
4. User solves the dynamic attribute to drive the 3D bundle position.

Expected features:

• Bundle is attached to curve, with dynamic attribute on the bundle allowing to be solved.
• Min/Max values should be specified for the dynamic attribute, so the solve cannot go outside the bounds of the min/max values.
• The tool name could be "attach bundle to curve", or something similar.

When using the Solver UI, it is often difficult for users to understand how the options they choose will affect the solver.

Therefore, we should try to highlight this information in the UI.

I propose we print out the "Errors vs Unknowns" near the "solvers" section of the Solver UI.
This intends to show users how they adjust the final number of Errors vs Unknowns, and allow users to make decisions about whether to add more or not.
A feature like this allows users to understand why a solve doesn’t have enough data, for debugging.

Sometimes the solver will give static values for all frames, when solving with "All Frames" strategy.

There is a test scene file named "cameraTrackRnD_afterBefore.ma" and "cameraTrackRnD_afterSolve.ma", showing the before and after.

This test used Maya 2019.

Rather than using a hardcoded Python file to run and generate the mmSolver shelf, we should allow use a configuration file to build the shelves (and pop-up menus) automatically.

Using a configuration file allows separate users and sites to customize the shelf as needed, adding custom tools or re-organising the shelf, changing commands or changing icons as they wish.

This ticket must use a configuration module, common to mmSolver for it's configuration reading needs.

In Maya 2019, pressing the "Solver" shelf button allows users to open multiple UI windows.

This is a bug. Only one UI should be open at once.

In the "Object" pane of the Solver UI, we should display icons for Markers, Camera and Bundle nodes.

Each icon should have a distinctive colour or shape, as the icon will be fairly small.

This needs to be connected to the Qt UI.

The Collection "Select" button in the Solver UI does not work correctly. It should select the Collection node itself, not the contents of the Collection.

Steps to Reproduce:

1. Open Solver UI
2. Create new Collection (File > New)
3. Click the "Select" button, next to the Collection combo-box.
4. The contents of the Collection are selected, not the collection (set) node itself (as is intended).

Note: The code is already using maya.cmds.select(noExpand=True), to stop the expansion, but it still happens.
Using a normal set node, and running identical commands in the Script Editor does not reproduce the problem, only with the Qt button.

Add a test transform node (inheirt from MPxTransform.

Each time the matrix evaluation is called, a message is printed and a number is incremented (atomically).

This node is only for testing, looking to reduce evaluation overall.
We could count the number of transform evaluations easily this way.

The plug-in node type would be named mmTestTransform.

The "Attributes" pane of the Solver UI is very dull. We should display the states if the attributs with different colours and / or icons.

The different states are:

• Locked (or connected)
• Static
• Animated

Locked should be grey.
Animated should be the same colour as keyframes in Maya (red).
Static should be a blue colour (because it's opposite to red).

Add a feature to solve only existing keyframes on an attribute (rather than all frames).
This feature will be called "refine existing keyframes only", (unless we can come up with a better name).

Enabling the option on the attribute will limit the keyframe times being solved. For example, the user sets three keyframes on the focal length of a camera; first, middle and last keyframes. These keyframe times will be solved for this attribute, but the position / rotation of the camera (other attributes in the solve) will be solved on all frames specified by the solver parameters.

This feature allows using interpolated keyframe values as part of a solve. The interpolation should probably be hard-locked to linear for solve stability and predictability reasons, but we should test this.

When the user adds a new keyframe, the solver can then adjust this. This means the user can adaptively add detail to the camera curves while working with the solve. Each attribute can have arbitrary keyframe numbers. For example, for shots with an almost linear camera position, we can add keyframes at the start and end frames on translate XYZ, but then solve rotate XYZ per-frame.

Storing the Value

This feature will work by storing a toggle on the collection, per-attribute.

• This value will be stored on the collection node as extra data; key=“node_uuid.attr”, value=bool
• The value itself is stored because in future we may want to change the default value. It might make sense to always have this feature on, then turn it off sometimes. If we invert the default, we need to keep backwards compatibility, hence we store the value.

Users with SynthEyes may like to directly export their 2D tracking data to Maya and mmSolver.

We should be able to write a script to export .uv files into .UV format, either version 1 or version 2 format.

SynthEyes supports Swizzle and Python scripts.

UV format version 1 is trivial, and we can use a script generously contributed by a user as a starting point.

UV format version 2 will need to use the Python script support in SynthEyes.

Users with Blender may like to directly export their 2D tracking data to Maya and mmSolver.
As Blander is a open source software, users can easily track 2D points and export
We should be able to write a script to export .uv files into .UV format,

When opening the Solver UI, and there is no detected Collection in the scene file, the UI could automatically create a Collection node with a default name.

Rather than making the user turn on or off distortion, we should delay the choice until the user can detect the problem... in Maya.

Therefore we should publish out both distortion and undistortion positions from 3DEqualizer (or any other software). The .uv file should support both positions being stored per-frame. If an application does not support either mode, the exporter is responsible for writing out both channels of data (which will be identical).

When loading into Maya (using Load Markers UI), we must add a checkbox to allow using undistorted, or distorted.

This file format change must not break existing .uv files. This change adds a version 3 .uv format (using JSON), and .uv format importers must support version 1, 2 and 3.

Looking at the Attributes pane in the Solver UI, we should easily see details based on the colours of the nodes.

We will be solving transform (translate, rotate, scale) attributes very often, these attributes should be colour coded.

For example colour Attributes could be different colours for different axis:

• Red = X
• Green = Y
• Blue = Z

We could also colour "translate", "rotate", "scale", and "other" attribute types. ("other" is just all other attributes, not transform attributes)

When loading Markers into Maya users may wish to add the Markers into a new Marker Group.
If there are multiple Marker Groups, the user may wish to choose which Marker Group the new Markers are created under.

Additionally, when creating a new Marker Group, the Marker Group may have an overscan value applied. A UI widget should be added to the Load Markers group to specify this value. Of course the user may choose to modify this option later by changing the overscan value on the Marker Group manually (in the Maya channel box).

A configuration option (as expected from #17) should be used for a default Overscan value in the Load Markers UI.

Could someone please compile the maya 2018 for lixux?

Thank you!

The new functions should enable the following features:

• Specifying mouse button to use for activating the shelf button menu (for example left, middle or right mouse buttons).
• Creation of sub-menus.
• Creation of menu separators (with labels).
• Creation of menu items (with commands, labels, etc).

We should probably add these functions to the mmSolver.ui.shelfutils Python module.

The "No Attributes" choice of the Solver UI "solver steps" should be removed, it is confusing for users.

The node name should probably be mmMarkerShape.

The mmMarkerShape should have the following features:

• The node should only display to the camera that it parented under.
• The node should be easily selectable.
• The node should have it's own custom display status in the Maya "Show" menu.
• Allow the node to be drawn in any colour (RGB, 0.0 - 1.0 values)
• The Marker should draw on-top of all other nodes, right in front of the camera near-clipping plane.
• The node of the marker should be drawn as a (red) horizontal / vertical cross with a dot in the middle.
• The node should always draw as the same size in screen-space.

If possible, we should draw a line (in the viewport) between the Marker and Bundle nodes.

As a hint, maybe we can use the perCameraVisibility to make the marker only visible under a specific camera.
https://help.autodesk.com/cloudhelp/2016/CHS/Maya-Tech-Docs/Commands/perCameraVisibility.html

We should support Viewport 2.0, in Maya 2016, 2017, 2018 and 2019. If viewport 1.0 support is easy, we should also support it, but not if it's difficult.

Similar to a "Re-Parent" tool, but exclusively for markers.

This tool is for transferring markers from one camera FOV into another, where the FOV may differ.

The world space position of the markers may matter, and so we should allow a "world-space" option to convert the positions "as we see them" in the Maya scene, directly into another camera. This is more of a traditional "Re-Parent" tool concept.

Options

• Source Markers
• Destination Camera
• World Space (checkbox)
• (frame range is automatically chosen for marker)

It has been reported that bundles very far from camera (10,000+ units) do not solve correctly. Usually they are not detected.

A theory we have is that the solver is not moving the attributes (and hence the object) enough to detect a change in the attribute. The value change is being masked by objects closer.

Therefore we propose to "scale" the attributes that are attached to objects that are far from camera up, so as to normalize the screen-space movement. This should allow distant objects to be detected and fix the problem.

Ideas

Scale all “unitDistance” attributes (like translateX) based on the distance to camera point.
For example, we add a few members to the Attribute c++ class, enabling a scale factor range (becoming “normalized”).
This scale range should approximate an optimized range of values and should be used to scale the get and set method values.
Internal to the solver, the value is always normalized, but when set in Maya, the value should be unnormalized.
We may also add an offset value (used by rotateAngle attributes) to offset away from 0.0.

Tests should be made with the CMinpack solver library. CMinpack has a feature to automatically scale the attributes internally.

This tool is designed to help users setting hotkeys.

The difficulty in this task will be working with Maya's hotkey setting mechanisms, and creating a tool that can work with-in a studio's pipeline.

For hotkeys, the logic will be that users need to set them, but will have recommended defaults. Hotkeys are a user's choice.

Needed features:

• Allow user to disable hotkeys or not.
• Allow users to set hotkeys on current custom hotkey set, or make a new one called mmSolver.
• This tool will require a "manager" UI. The UI will query and set hotkeys for mmSolver only, and will list all the allowed hotkeys in mmSolver.
• Each hotkey will have a default value, but a user can override it.

Ideas:

• If a user has no hotkey sets, we'll create one named "mmSolver".
• If the user is already using a custom hotkey set, we'll create it in that.

Open questions:

• How do we add hotkeys in Maya with scripts (runtime commands and name comments)? (ideally this would be wrapped in function.)
• Should we write a config file for the hotkeys?
• How would a config file be distributed with mmSolver? Perhaps stored in <project root>/config/hotkey.json?

When adding or removing many nodes with many frames, the solver UI is especially slow.

This is caused by the "solver steps" needing to compile down to individual keyword arguments, for each frame. This loop in Python is much slower than anticipated when it was written.

We should:

1. Diagnose the slow-down of the Python loop
2. Refactor the feature and push the loop into code that can execute faster.
3. Or, if all else fails as a short term fix, we can provide an "update" button the user must click to update the UI.

We also need to investigate the possible problems caused by using Maya callbacks to update the UI perhaps we can intelligently process the updates once, rather than each time a node is added.

When you open the Solver UI for the first time, all the buttons are enabled.
This confuses users as they think they can use these buttons, but they cannot use these buttons because there is no collection node.

Before a valid Collection node is given, we should disable all the Add / Remove buttons for sections objects, attributes and solver steps.

The icons on the mmSolver shelf are mostly default Maya icons. We should make the the icons distinctive and give some nice polish.

A few of our tools need to have config files to read from and write to (hotkey manager, shelf and menus)

There are many places to store and read data from in Maya.

• A Maya node
• The Maya scene file.
• The Maya preferences
• The user's home directory (by-passing the Maya preferences)
• Configuration options in the install Maya module (configured for everyone).

This module needs to handle a number of use cases:

• Module to read/write config values.
• Store data in the scene file.
• Store data on a Maya node.
• Store data in the user’s home directory.
• Store data in the Maya preferences.
• Read data from the config directory “MM_SOLVER_CONFIG”