Core Solver - Use In-Memory Representations of Bundles and Cameras

[david-cattermole]

Feature

The solver currently sets Maya node attribute values and then queries the world-space position of the bundles and cameras. If a camera or bundle's attribute is being solved, and there is no hierarchy values being solved, it is possible to avoid setting Maya node attributes and instead creating Maya MTransform API objects "in-memory" and setting and querying these objects instead. This should prove faster than setting Maya node attributes directly as we will not need to query the Maya DG.

There are a number of conditions that a attribute must meet before being considered for this optimization:

• The attribute must be a translate attribute on a Bundle node or a translate, rotate or focal length attribute on a camera.
• The Bundle node's parent must be world/root, or cannot be changed by the solver (for example it is locked or connected).

The Bundle's parent node transform must be queried across all frames needing to be solved and used as the transform space for the MTransform object internally.

The Bundle's translation X, Y and Z attributes do not need to be added to the solver together, solving independent transform axis is possible.

It may be possible to extend this optimization feature to all transform node attributes, in the future, but the first priority is Bundles and cameras.

This feature should be able to be turned on/off with a flag given to maya.cmds.mmSolver.

Expected behavior:
This is a performance optimization only. The results of the solver output should not change if using or not using this feature.

This feature should greatly speed-up camera-based solves, since querying the Maya DG is by-far the slowest aspect of the solver.

[david-cattermole]

This feature can be extended to a more general use of "in-memory" calculations, rather than using Maya's DAG network.

We should not limit ourselves to only world space attributes and nodes, but instead we should convert the entire Maya DAG / DG into an exact representation entirely by mmSolver defined classes.

As a starting point for this feature we should write a Maya API function that will convert a list of nodes into internal solver objects. This test command should then return a mapping of node attributes and values. These values must match Maya perfectly, and we will assert this in our unit tests.

After we are sure our test nodes match Maya we can start manipulation of the internal solver objects and create a flag to mmSolver command to allow using the "in memory" solver objects.

I expect by writing our own solver objects we will be able to gain a lot of performance.

Matrix classes should probably use the C++ Eigen headers, and we will build our own transform nodes on top of this.

[david-cattermole]

Here is the current state of this issue...

Lower-level core library:

• Construct a flat Scene Graph matching Maya's DAG.
• Construct a Scene Graph with hierarchy matching Maya's DAG.
• Library (written in Rust) added to CMake build system.
• Expose the Rust library features as C++ library to the mmSolver Maya plug-in.
• Support static attributes
• Support dense multi-frame animated attributes
• Support sparse animation curve data.
• Support connections between nodes.
• Support trivial constraints between nodes.
• Support custom nodes (by baking values only).
• Support smoothness and stiffness deviation.

higher-level Maya wrapper:

• Translate a basic Maya DAG into a MM Scene Graph representation.
• Automatically detect Maya DAG to MM Scene Graph translation failures and revert to Maya DAG.
• Allow the mmSolver command to optionally use the new Scene Graph or not.
• Allow users to choose to use MM Scene Graph or Maya DAG (via the Solver UI)
• Support hierarchies of nodes nodes by Maya wrapper.
• Support multi-frame evaluation with arbitrary/non-sequential frame numbers (such as the "Standard" solver)
• Support smoothness and stiffness attribute details.

[david-cattermole]

Closing. This has been released in v0.4.0.

There are some missing features. These will be added as needed in future versions of mmSolver.