-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SolverAffects Pre-Solve Fails on Container-based Rigs #183
Comments
I suspect this problem is probably caused by the reduction of the full dot-separated attribute path. I need to check and test the assumptions of a single dot in the node names, and see if we don't need to expand/shorten the full attribute name path. |
Here is another example of a similar bug with a different rig:
The error message is slightly different, but is failing in almost the exact same place. |
Thanks @ktonegawa, Would it be possible to share the rig in question that triggers the error? I believe there are two different errors, but they may be related. Error 1 might be caused by nodes that have an array attribute:
Error 2 might be caused when using containers:
I'll dig further... David |
I can also reproduce error 1 using the "Mr. SuRuj 0.0.1 for Maya" rig. |
Hi @david-cattermole , yes that is exactly the rig I used to produce that error. |
After having a closer look with @ktonegawa at "Error 1" it appears that For example, for a This appears to be a limitation of Maya's command and we'll need to workaround this some way. @ktonegawa is going to look at this further. David |
It is possible that we'll need to use the Maya Python API (v2.0) to replace the need for For example, this function from the |
So i have been looking into this the entire day today and my head just hurts. But here are my findings so far. As @david-cattermole mentioned, some of the issues stemmed from a "dot reduction" path, and more specifically I realized it was due to the fact that To get around this, I so far came up with this solution, which probably is not that elegant, but at least now in this particular scene I am using for testing the second reported error no longer pops up: ktonegawa@fb300cf#diff-de0658a556f4949d497f61f71f915e4b98ba36167e48556b6958325cdb1c0e35R253-R262 Now the next issue I am seeing, is when attempting to solve for the current frame, I interestingly get two different errors from when using Maya GUI:
From this though, I suspect what is happening is due to the solver's native method of trying to initially disconnect the animation curve from the desired node to perform the solve, it fails to really deduce where the animation curve is. In this specific rig, the And when trying to add any of these custom attributes from this "Character Node" into the solver we get this error:
I haven't quite looked into this yet, but I was thinking then maybe if we can before the solve process actually kicks in if a feature can be implemented to detect if an attribute is driven, then traversing back a few connections and see if the connected node has some attributes that can be used to still utilize within the solve. I saw that the main part where this detection of whether an attribute was either animated or connected was done via In the end, I don't really know if any of this gets closer to answering the original issue at hand, or how to move forward with all of this information. Feedback would be appreciated... |
Hello @ktonegawa, It's not a simple problem and I'm a little embarrassed about the complexity of the I think you've gotten to the bottom of a lot of the problems, and I have commented on the commit you've made: Firstly, this traceback really confuses me, I don't understand how that could happen unless the node has been deleted - no where in that function are we deleting any nodes, it will only disconnect attributes:
The second error (
The first thing you should do is simply delete the Character Set from the rig, up-version the rig and try to solve again with the new rig. If Character Sets do need to be supported... I think we can handle it in the Solver UI, so the solver doesn't need to know about the special use-case. When a user clicks "+" (Add Attribute) into the
You are correct, the attribute state is looked up as needed, and the error is triggered from that Does this help? I will do some tests of my own later today. David |
Hey @david-cattermole, as you suspected, deleting the Character Set node from the original and testing with that seems to allow for the solver to function properly: ktonegawa@2d0bbb8 Clearly my initial idea of using And to answer your question, no I have never seen Character Set nodes being used in at least Matchmove/Roto-Anim rigs, but I've also never seen Container nodes be used either. I heard from a Rigging friend that Container nodes are not really a great way to manage assets anyways, and that there are "better ways of doing it" (not sure what they are but irrelevant to this conversation). I guess it means every studio probably has some kind legacy workflow/procedure that is so embedded with their pipeline its hard to adjust. If we wanted to take the route of not really bothering with coming up with a solution for this since like you say it is indeed complicated, perhaps adding a LOG message or some kind of pop that warns the user that the solve has failed due to related circumstances, and instead off some other suggesting such as utilizing this plugin's Tools>Create Controller feature and solving for that controller instead (sounds silly but it does work). By the way, I noticed a super annoying bug while testing, and seems like the solver does not run properly if there are no keys set on the desired output? Is this intentional? I think it would be really good to have it so that it can work for both Static and Animated attributes...
Regarding this error, it would be great if the reported user can test with latest commit and submit any new changes in traceback error output. |
Hello @ktonegawa, Your commit ktonegawa@2d0bbb8 looks good to me. It would be good to remove the unneeded commented lines before a final PR, otherwise, it's great!
FYI, the function
Agreed. Unless I hear otherwise, I think we should leave Character Sets "unsupported".
We can perhaps detect Character Sets and print an error to the user. That's not a bad idea, although I do think we shouldn't waste much time on it since I'm pretty sure Character Sets are unlikely to be used. If that's the case,
Do you mean that Animated attributes need to have keyframes?
I'm not sure I understand. To solve Animated and Static Attributes, you'll need to use the "Standard" solver tab. |
I don't think its entirely necessary to be creating an error message specifically for Character Sets, but a general one for attributes that may be driven or just attributes that this solver cannot necessarily find the appropriate attributes to solve for.
Well when I tested to just solve the current frame for the IK hand controller when no keys were set, it "solved" without any errors, but the resulting solve had a max deviation of 0.0 which clearly means it didn't actually do anything (and the controller in question had no changes), but as soon as I added a key and solved, it solved correctly. So what I was asking was if it is intentional to have "Static Attributes" to not solve? Buuut, I just did a quick test on just a really simple object and indeed it seems like you should be able to solve for static attributes as well, which probably means this is some kind of bug. I can take a look into it later in the future if you'd like... |
Hmm, I see your point. I'll edit the issue #198 and see if I can summarise the idea properly.
When using the Standard Solver, both Animated and Static attributes should be solved, even on single frame solves. Basic Solver: mayaMatchMoveSolver/python/mmSolver/_api/solverbasic.py Lines 303 to 304 in 01dc00c
Standard Solver: mayaMatchMoveSolver/python/mmSolver/_api/solverstandard.py Lines 769 to 770 in 01dc00c
If for some reason that's not correct it's a bug and should be logged and fixed. |
@ktonegawa the original reporting user is in the process of testing to confirm your fix is working. I think we can consider the original bug(s) are (probably) fixed - none of the changes you've made make me think anything new would break - the code is just handles more use-cases that I didn't think about. Would it be possible to remove the excess commented code and we can merge this into the |
Great to hear, hope it works out on the reporting user's end too. And of course once we get that confirmed and sorted I will do a proper PR with the commented lines removed :) |
Hello @ktonegawa, I think there is some confusion for the reporting user about installing the fix. This weekend I will merge your Otherwise I might just release a proper version, as I don't think your fixes have any negative side affects. David |
This bug fix will be included in v0.3.12, but I will keep this issue open until I get confirmation that the problem is fixed. I suspect the issue will not present itself anyway by default since I have added a new checkbox "Evaluate Object Relationships" (#187), which is disabled by default. |
Hi @david-cattermole, sure, why don't I create a PR that which has all of the commented lines and logs cleaned up so it is ready for you to pull. |
Thanks @ktonegawa, but it's ok, I have pulled your changes into the latest release v0.3.12 :D The only thing left is to get confirmation from the reporting user that the change fixes the problem. That being said, it was requested that a "pre-solve" checkbox be added #187 to allow disabling of the "affects" code, so that the solver will start faster. I added the check-box (named Evaluate Object Relationships), and by default it's disabled. It's very unfortunate, as I wanted the feature to be turned on by default without the need to turn it off - ever. David |
@ktonegawa I have confirmation that your bug fix works perfectly in v0.3.12 with the custom rigs (that happen to use Containers). In summary the bug was caused by my code:
I'm closing this as it was confirmed to be fixed! |
Problem
I have a single Bundle, a child of the wrist rivet. I am solving for Wrist IK tx/ty.
The status of the Marker and the wrist tx/ty in the mmSolver Solver GUI is showing as Invalid
The rig is using Maya Containers.
Here is the error message.
Software Versions
The text was updated successfully, but these errors were encountered: