Approx Survey Markers

[debanjanDC]

Hi David,

Thanks for making this amazing solver. This reminds me of Rhythm&Hues "Voodoo".

recently I have tried this solver in few shots, which actually gave a decent solve.But there are few limitations I have noticed ( possibly,I may not know how to use it and the solver is also at the early stage of development ).

1. Is there a way to solve few bundles as survey free or approx survey?I tried manually pushing the points through screenZ for approx survey,but while solving i have noticed there was a huge gap between the respective marker and the bundle.Wondering if we can tell the solver to find the best possible depth while solving?
2. for continue surveyed points throughout the frame range , the solver does an amazing job,but when a point ends at any frame,the solver throws off the solve for camera and for object tracks sometimes it change its world position too.

Can you please help me with any workarounds for the above two issues?
Also it will be really great if we can solve for focal lengths too.

A huge thanks again for the awesome solver.

Best Regards,
Debanjan

[david-cattermole]

Hello Debanjan,

Thank you very much for submitting this issue, and thank you for using mmSolver.
I have never used "Voodoo".

Is there a way to solve few bundles as survey free or approx survey?I tried manually pushing the points through screenZ for approx survey,but while solving i have noticed there was a huge gap between the respective marker and the bundle.Wondering if we can tell the solver to find the best possible depth while solving?

mmSolver doesn't have a concept of "survey free" because mmSolver will always use the given bundle position as an initial guess, so it's a closer concept to "approximately surveyed". However, yes you can solve bundle positions.

By default, the "Solver Step" (in the GUI section Solver Options) in mmSolver v0.2.3 is set to "Animated". To solve a bundle position (which usually has "static" attributes), you need to to change the Solver Step to "Static + Animated".
However, should not add many frames to the Solver Step - 2 or more frames may be used, but try not to add more than ~5, as each new frame slows down the solver. These frames for "Static + Animated" is similar to the concept of "Root Frames" in other software, but most software uses 2 root frames, mmSolver can use 2 or more (except it gets really slow with more frames).

However, if you add 2-5 frames, how will you solve 100s of frames? You need to add second Solver Step with "Animated" attributes set to solve.

For example, here is a screenshot:

The screenshot shows two "Solver Steps", # 1 and # 2. # 1 will solve first, then # 2.
This list of Solver Steps is compiled down into the instructions:

1. Solve animated and static attributes using frames 1, 30, 60, 90 and 120 frames.
2. Next, solve only animated attributes on all frames 1 to 120.

"Solver Steps" are being deprecated in v0.3.0, because they are too confusing for most people. This issue is being addressed in issue #57.

For more information on Static and Animated attributes, take a look at this documentation:
https://david-cattermole.github.io/mayaMatchMoveSolver/solver_design.html#time-static-and-animated-attributes

for continue surveyed points throughout the frame range , the solver does an amazing job,but when a point ends at any frame,the solver throws off the solve for camera and for object tracks sometimes it change its world position too.

Yes, I'm aware of this problem, but I don't have any solid solutions, instead I have multiple solutions that should fix some of the problem.

As a kind of hack, you can animate the "weight" attribute on a Marker to fade out so the marker does not pop off.

Otherwise, I have added a feature into the latest development version (not released) to allow bad markers/bundles not to influence the overall solve. I have added this in issue #66.

Also it will be really great if we can solve for focal lengths too.

This is already supported. Select a camera shape node, and select the "Focal Length" attribute in the Channel Box, then press the "+" button to add the Attribute to the mmSolver GUI.

I hope this addresses some of you problems.

David

[debanjanDC]

Thank you so much David for the detailed explanation. Will give it a try and will update you on the same

[debanjanDC]

Hi David,

I have used the hacks which you told and it worked perfectly.
They are just life saving and what i was looking for.
However by doing so I came accross few bugs..

If a marker has no keyframes after a certain frame range ( say -frame 50 of a 100-frame shot).I keyed the weight value as 1 on -f50 and 0 at -f100 to blend the weight and kept active/Enable throughout the frame range. I have seen the solver was considering the marker and trying to keep the bundle close as possible to the feature but was not able to solve the first and last frame.. However this got fixed after I hit the solve button 3-4 times. Wondering if the solver actually tried to throw minimum error/best possible solution after 3-4 itteration or this is a bug?

I tried the same step again by keying the weight value 1 on -f50 and 0 at -f51.. The solver then just worked fine.. However in both the above cases I got the same solve.

All the above result I tried on a simple shot,but will try the same on a bit complex one and will get back to you.

Thanks again for the help..

Debanjan..

[debanjanDC]

One more doubt:
What will happen if I don't lock the bundles? Does it change its 3D position while solving (if two"Solver steps" been applied) .
However I didnt found any difference by locking or keeping it unlock during solve.
Curious what the lock state does..

[david-cattermole]

Hello Debanjan,

I'm glad two Solver Steps has helped your first problem.

If a marker has no keyframes after a certain frame range ( say -frame 50 of a 100-frame shot).I keyed the weight value as 1 on -f50 and 0 at -f100 to blend the weight and kept active/Enable throughout the frame range. I have seen the solver was considering the marker and trying to keep the bundle close as possible to the feature but was not able to solve the first and last frame..

Just to be clear, are you saying the first frame that did not solve was frame 50 or frame 1?

For example,
shot frame range: 1-100
Marker enable frame range 1-100 (all frames are "1" value)
Weight value: frame 1 to 50, value is 1.0, frame 50 to 100, the value blends to 0.0.

And you are saying that both frame 1 and frame 100 do not solve?

I would expect the solver not to solve on frame 100. By setting a weight value of 0.0 (exactly zero), the Marker has no contribution to the solve, therefore it is not enabled, and the Solver treats the Marker is disabled for frame 100.

I would not expect either frame 1 or frame 50 not to solve. That sounds like a bug.

However this got fixed after I hit the solve button 3-4 times. Wondering if the solver actually tried to throw minimum error/best possible solution after 3-4 itteration or this is a bug?

Needing to press "solve" multiple times to get the minimum error is currently a bug in v0.2.x, but has been addressed in v0.3.0 beta.

Obviously, for a Marker to use weighting, there must be another Marker used in the solve. The weight attribute simply scales the given marker overall as importance.
For example, if you have two Markers A and B, A.weight = 10 and B.weight = 1.0 the solver will normalise the weight values across both Markers.
So effectively, Marker A.weight = 1.0 and B.weight = 0.1 - they are the same thing.

[debanjanDC]

Hi David,

As I have mentioned, will get back to you with a complex shot result using the above method.Here it is below:

• If I am animating a point weight from 1 to 0 ( for a point getting off after few frames and coming back) the solver is giving a pop/slip at the same frame where the mentioned point goes off and comes back. However I have added few more points nearby to help the solver.Even though it is giving pop/slip at the same frames. Can you please suggest any workaround ?.

• While solving Object Tracks which includes character rigs, the solver is taking a lot time to solve the controller added as Output Attributes. Any fix for this?

Thanks again

Regards
Debanjan.

[debanjanDC]

So here is the above hack I found while solving any object track.
If you keep any object/controller/locator parent under a Dummy camera and solves the bundles(for Dummy camera). The solver think it as a camera and solves it pretty fast .

Let me know if you have any other alternate..For now this is working great.
Thanks.

[david-cattermole]

Hello Debanjan,

If I am animating a point weight from 1 to 0 ( for a point getting off after few frames and coming back) the solver is giving a pop/slip at the same frame where the mentioned point goes off and comes back. However I have added few more points nearby to help the solver.Even though it is giving pop/slip at the same frames. Can you please suggest any workaround ?.

I can think of a few different techniques, but no "silver bullet", I have had this problem myself recently. I'll need to think of better solutions.

Technique A) If the frame range of the Marker is disabled for short duration, try "splining" the Marker by animating the "enable" attribute. This is an annoying hack and will not work when Markers are disabled for a long duration.

Technique B) Set the surrounding Marker weights to be higher, so the Marker that causes a 'pop' has a smaller effect.

Technique C) Ensure the Bundle 3D position is accurate, any miss-aligned bundle will cause popping (the same as any solver).

While solving Object Tracks which includes character rigs, the solver is taking a lot time to solve the controller added as Output Attributes. Any fix for this?

Yes, although in mmSolver v0.2.x, the fix is manual.
To fix this problem, you must stop the solver from solving the rig controls directly, and create locators that will constrain back to the rig controls. The locators must pivot/rotate/translate/scale from the same position as the original rig control in the rig.

v0.3.0 will contain a new "Create Controller" tool to make this workflow easier.

So here is the above hack I found while solving any object track.
If you keep any object/controller/locator parent under a Dummy camera and solves the bundles(for Dummy camera). The solver think it as a camera and solves it pretty fast .

If I understand correctly, you are saying that using a dummy transform node, constrained to your tracked camera is somehow causing Maya to evaluate faster?

Am I correct to assume the "dummy camera" is not used in the solve at all, and has a constraint on it? Therefore all objects parented underneath the dummy would inherit the motion of the camera?

I'll test if this works on my end, with the latest solver version. If it works for animated bundles, it will not work for static bundles, however.

Ultimately, the fix for all performance problems of this nature is #114. The feature is planned for 0.4.0, as it will require a lot of work to do. Basically, I will need to re-write the Maya DAG hierarchy into my own code. This will allow me to fully fix any Maya evaluation problem, and the extreme slowdown caused by solving rig controls.

David

[david-cattermole]

There is not much more to say about this issue.
I believe we should close this, or perhaps revisit it after v0.3.0 is released.