Maya Tool - 2D Center tool should allow relative X/Y offsets while centering

[david-cattermole]

Feature

When using the 2D centering tool the center of the viewport is locked to the transform.
It is helpful to be able to offset the center of the viewport while still keeping the centered transform's relative motion stable.

The current tool's documentation is here:
https://david-cattermole.github.io/mayaMatchMoveSolver/tools_generaltools.html#center-2d-on-selection

Expected behavior:
We would like to center on a transform node (for example a head control), and then move the center of the screen to the ear, then press the play button to see the relative offset between the current viewport center and the head control center is maintained.

Actual behavior:
Right now, we cannot offset the center of the viewport when a transform is offset.

Steps to Reproduce

1. Select transform node (such as a rig controller)
2. Activate viewport.
3. Run the center 2D tool.
4. With the native 2D pan/zoom tool, move the viewport to another part of the viewport.
5. Press "play" to see the transform node from 1 animate, and the relative position of the viewport is maintained.

Software Versions

• mmSolver version: all future versions

• Maya version: All supported Maya versions.

• Operating System (OS): All supported operating systems.

[david-cattermole]

Ideas for Implementation

The existing center 2D tool uses connections with a mmReprojection node. Unfortunately this approach means the user cannot change the 2D pan position - it is locked.
There are 2 solutions to this:

1. Do not use a node connection to control the 2D pan position
2. Create a new node that can handle the relative offsets logic, AND a custom Maya "tool context" to control and set the node.

2 seems complicated to me. I prefer 1 because it's more flexible.

My idea is to use Maya on-frame-changed callbacks and store "what needs to be centered on" in an Object Set.
The Object Set needs to be connected to the camera (via a message attribute connection for example).
There can only ever be 1 Object Set for each Camera.
The Object Set may contain any number of vertices and transform nodes.

When the user plays the timeline, the callback is run each frame. The callback must find the Object Set and Camera, then query the world-space position on the current frame. Once we have the world-space positions, we can convert these to screen-space using the maya.cmds.mmReprojection command.
Here is an example use of the maya.cmds.mmReprojection command.

The difficulty for this approach/tool is the mapping between Object Set and Camera, and ensuring the callbacks do not slow down Maya or cause unexpected problems.

Another big unanswered question is how to perform the "relative" offsets, what are we relative to?
Do we need the user to specify a "hero frame"?

Usage Steps

This is how I think the usage steps should be:

1. Select node or vertex.
2. Add node/vertex to the "current" camera.
   • This will add the node/vertex to an Object Set node that is linked to the camera.
3. Move your 2D view in the camera's viewport.
   • This is using the native Maya 2D Pan/Zoom tool.
4. User presses play, next/previous frame or clicks on a different frame number in the Maya timeline.
   • Get the new and current frames (these could be completely different, either forward or backward.)
   • On the "current" frame (the frame Maya was on before the frame changed)...
     • Compute or get the (cached?) 2D average position.
   • On the "new" frame....
     • Compute the 3D positions for all nodes/vertices in the Object Set.
     • Average all the 3D positions into a single 3D position.
     • Convert the averaged 3D position into a 2D position, for the current camera.
   • Use the difference between the "current" and "new" 2D positions to compute the new position.
   • Store (cache) any needed data on the Object Set for future use.
5. Go back to step 1, 2, 3, or 4.

2D Rotation and 2D Scale (future)

A future improvement we could think about is stabilizing and calculating a relative 2D rotation and 2D scale.

For example, we select 3 vertices on the face of a character, left ear, right ear and nose, when moving from frame to frame, the 2D rotation and 2D scale is stabilised.

[ktonegawa]

Hi David,

When I looked into this feature I figured that a good simple solution this would be to add another attribute that is modifiable like an Offset X and Offset Y attr and have that act as a factor that drives the final values of the Out Coord/Out Pixel attrs. What would be the foreseeable issue in this solution? Am I misunderstanding the intent behind this issue...?

[david-cattermole]

Hello @ktonegawa,

Yes, that is the simplest implementation and it would achieve the original requirement.
I thought that needing to manually set attributes via the channel box wouldn't be very "user friendly".
The tool I had in-mind was completely mouse driven (except for enable/disabling).

Using extra Offset X/Y values would allow the offset to be animated, which would be a good feature.

What do you think? As a user do you think you'd only want/need the extra Offset X/Y attributes?
As someone implementing the tool, do want to spend all the time re-creating such a tool using a (potentially) untested implementation?
You should do whatever you have time for, and feel comfortable with, and whatever you feel is most beneficial for users - what's a good time/effort trade off?

David

[ktonegawa]

Hi David,

For a time sake, I would assume taking first a small step of just adding those extra attributes, regardless of it being a bit of a hassle to adjust, can be done.

And then maybe, from what you're describing, since I have personally never implemented mouse movement events to an action (I have seen examples of such), but I would hope that by assigning a very specific set of hotkeys, would allow for a user to mouse drag within viewport to allow for the increment/decrement of these newly created Offset X/Y attributes. And then eventually start implementing the same feature the way you suggested, so that it allows for future features like 2D Rotation/Scale (which can be extremely useful in some cases).

But as a user, just having that attribute that allows for any kind of offset would be beneficial for now. Do you believe what i just described would have significant performance issues...?

[david-cattermole]

Hello Kazuma,

Yes, I agree you're idea is good. Sometimes I am too ambitious.
I will make a new issue, and copy my remarks above.

Do you believe what i just described would have significant performance issues...?

There will be no performance problems with your implementation, it is simple and effective.
I expect your implementation would use only DG nodes and attributes, there will be no performance problems.

Have fun, and let me know if you have any questions or problems - I'm happy to help.

David

[ktonegawa]

@david-cattermole has merged pull request #209 to develop_v0.3.x. Its current features are still very basic. Next step I assume is to work towards issue #190

[david-cattermole]

Yes, @ktonegawa, exactly.

I think we can consider this issue finished. It will be released in v0.3.13.