Closed evanatherton closed 2 years ago
evanatherton
commented
3 years ago At a high level: I imagine a separate shelf button that would launch a little pop-up window just for setting/saving/importing preferences that would have all of the options in a single place, then would save the settings to a JSON
evanatherton
commented
3 years ago DEFAULT_ROBOT [Default is empty. If there's a user input, it will place that robot at the top of the drop-down list in the setup tab]
NOMINAL_LIMIT [Dictionary holding velocity/acceleration/jerk limits that are added to the robot in case none are already assigned. These are nominal as the values aren't typically given by the robot manufacturers]
These control all of the default user input setting in the main Program tab
DEFAULT_POST_PROCESSOR = '' # E.G. 'KUKA EntertainTech'
DEFAULT_TEMPLATE_NAME = 'template'
DEFAULT_OUTPUT_NAME = 'output'
DEFAULT_SAMPLE_RATE_VALUE = 1
DEFAULT_SAMPLE_RATE_UNITS = 'frames' # 'seconds' or 'frames'
OPTS_IGNORE_WARNINGS = False
OPTS_OVERWRITE_EXISTING_FILE = True
OPTS_PREVIEW_IN_VIEWPORT = False
OPTS_REDUNDANT_SOLUTIONS_USER_PROMPT = False
This is where a user can set the default "checked" state of the post-processor specific "Advanced" settings by adding user_option_name=True
DEFAULT_USER_OPTIONS = configure_user_options(use_nonlinear_motion=True, include_axes=True)
hsouders
commented
3 years ago wowser. Ok! I'll take a look at implementing this. I was thinking similar functionality. Will probably generate a default-prefs and a user-prefs file. This way user-prefs will be portable and there shouldn't be any problems adding new prefs and breaking user prefs.
evanatherton
commented
3 years ago From user on Slack:
"I am not so concerned about long term preferences perse, but a lot of the minor settings which revert to default every time you close mimic and reopen. I found on many occasions I had made settings to process data export with IO's and when I accidentily or otherwise reopen Mimic these have all reverted to defaults, so I have to go through and find all these settings and change them again. It was a bit of a pain and things were easily overlooked. Examples of settings include the tick box option to includeIO's which is kind of hidden away in an "advanced" tab. Same with the alternative template file selection and even the name and location of the emily file to save. Basically I would expect that everything I have just set should stay there. I realise it could get complicated when you have defaults and deciding at which point they are restored. Maybe then you could just have a button "restore defaults" for that, and otherwise let everything stick the way the user changes it?"
I wonder if we create another setting in the main prefs for “store user settings on close” or something. I have to think about how to do that practically in Maya, I’m not sure how to create an “on window close” event, but I’m sure it’s possible (edit: the window object has a closeCommand flag where we can assign a callback when the window is closed)
hsouders
commented
3 years ago @evanatherton Do you have any concerns about moving all config to a single location? I think the cleanest way to do this is to keep mimic_config and eliminate postproc_config and postproc_options. It doesn't seem like there are enough preferences to merit maintaining all three locations, and I don't see a scenario where the postproc module would be included without mimic?
evanatherton
commented
3 years ago @hsouders I don't have a problem with moving them to a single location. You're right that the thought process at the time was "the post-processor should be self-contained", but I'm not worried about it at this point. If we ever want/need to extract it that'd be a pretty easy thing to revert.
hsouders
commented
3 years ago Sounds good. I'll probably start developing it with all user config in one place, and then we can take a look and refactor if it makes sense.
hsouders
commented
3 years ago @evanatherton I've been thinking about this, and I propose we implement 3 levels of preferences:
Each preference level would supersede the previous level(s). Thoughts?
evanatherton
commented
3 years ago @hsouders By "file", do you mean a Maya file that has a Mimic rig? So if you were to open a Maya file, that file could have Mimic preferences associated with it (i.e. if you had a project with a KUKA/ready2_animate you'd want the entertainTech post, but if you had a project with an ABB, you might want a RAPID post setup). I hadn't actually considered that, but that sounds really nice if that's what you were going for
Side note: it might be nice if we automatically picked a compatible post-processor for the type of robot if there are no user preferences set. I hate dropping in a KUKA and the ABB post is the first one up haha
hsouders
commented
3 years ago Yes - file preferences would be saved on the Maya file... So if I were to make file with a robot and a particular postproc setup, those postproc preferences would be saved with the maya file. This would help with file portability because if I make a file and gave it to you, you should be able to open the file and see all the settings I used instead of trying to re-create/match my unknown configuration.
Agreed - it would be nice to have the correct postprocessor automatically selected. I kinda think that a lot of the code that handles postproc options should be rolled into a class to help simplify it?
evanatherton
commented
3 years ago ok cool, that sounds great.
Where do you actually plan on storing the preferences on the file? Maybe a scriptNode?
The other option I can think of would be a null object like a locator with custom attributes that match the preferences. That's probably more transparent than a scriptNode as long as the prefs stay fairly discrete (i.e. I don't think we can store something like a dictionary or tuple on a Maya transform attribute).
Agreed on creating a class to handle the postproc options. definitely open to anything you want to try there
hsouders
commented
3 years ago Regarding storing prefs on the file: I looked at a scriptNode, but that seemed a little wonky. It seems like other people commandeer networkNodes and add metadata that way. I read somewhere that a potential drawback to this solution is that it's possible the node will be removed when saving an optimized file. I honestly have no idea how likely this is or even how to save an optimized file in Maya!
Currently, I have an mvp saving everything in fileInfo, but I'm open to ideas if you foresee an issue with this approach. I haven't come across any issues so far, and it's wwaayyy easier (pm.fileInfo has a dict interface) to use than the metadata approach. Let me know if you see any problems.
I have some wonky stuff happening to handle the postproc options..... maybe that'll be the next thing to tackle after this PR.
evanatherton
commented
3 years ago ah cool - hadn't come across fileInfo before, but that seems perfect!
(btw - to create an optimized file you go to file > Optimize Scene Size. If you open the settings for that there are a ton of things you can clean up, all together or individual, like deleting cached data, empty transforms, etc)
hsouders
commented
3 years ago Some questions:
evanatherton
commented
3 years ago 🔥 🔥 🔥
Should "Hotkeys" under the Mimic "Prefs" tab be moved to the new Preferences window? I think so? Would we want to change the UI to set the hotkey when a user saves all preferences? We also run into the possibility that someone sets a hotkey and tries to load their preferences on a different machine but the key is already taken - a pretty minor issue? It's not a perfect solution, but I think this would get us 90% of the way.
I think those can move. In general I think people who actually have custom hotkeys set are really particular about their setup - but I don't think we have a ton of Mimic users who are in that group. We also check if the hotkey is already taken before assigning it, so there's not really a risk of overwriting someone's hotkey. What's tricky is you can't edit maya's default hotkeys, which most people stay in; so if you actually want to use that feature we require you to create a new hotkey profile. I feel like I'd want that to be a deliberate choice, but I don't feel that strongly about it. I do wonder how many Mimic users actually use that feature haha.
Should "Shader range" under the Mimic "Prefs" tab be duplicated and appear in both the new Preferences window (as a default value) as well as the standard Mimic window? We could set this value on rigs as they are added into the scene. Additionally, should we move the shader pref to somewhere like Setup Tab -> General Tab -> Somewhere to eliminate confusion? It seems odd to have a "prefs" tab in addition to Preferences window. Or should we just rename that tab? Also - do I need to enable something to see the shader work? It doesn't display on my machine for some reason.
I agree that this has value in the main window because it's actually a tool that can be used to set a specific rig's shader range. Because of that, I do think you're right that being in a "prefs" window in the main UI doesn't make much sense and I wouldn't want to have another tab for a single option. I think another frame in the Setup Tab -> General Tab is perfect - I'd probably put it between the "Tool Setup" and "Axis Limits" and maybe call it "UI Setup". Love the idea of still having it in the prefs window to set the default value, and set the value on the rigs as they're imported.
To show the limit shader (where it turns red when you're close to the axis limit), you need to have the "Textured" mode enable, which is the circle icon with the checkered pattern in the viewport toolbar
Should we display all postproc options (even if they aren't allowed for the selected posptroc?) I think it might be nice to display all preferences but gray out the disallowed options. I think that would be relatively clear-ish? Thoughts?
I actually love that idea. I think it'd make it a little more clear what each post is capable of compared to others. And what options could be enabled if a user wanted to customize a post.
What could be a little tricky here is that the way we have it set up currently, setting the default for each option works globally for all of the posts. So if every post has the option "Include external axes" and you set that preference to "True", it'll be checked for every post. I can envision a scenario where you want your default post-processor to be Kuka entertainTech and you want to include external axes, but maybe you have an ABB with no track; so when you switch to the ABB Rapid post you want that option to be deselected automatically.
So with that in mind, were you thinking that you could set the default options for each post, and set a default post?
Any thoughts an UI? I'm not sure how this should all get arranged. I'm definitely open to some constructive criticism.
I think what you've done already is exactly what I would've done to maintain consistency with how the options are presented in the main UI. At first glance, the only thing I'd probably do is move the default robot out of the postproc settings and up to the top. It always feels weird to have a whole section with a single option, but that feels like the most general setting. I'd make a "General Settings" above "Program Settings" and put it there.
Should anything else be moved/added to the Preferences window??
Aside from the hotkey discussion I can't think of anything at this point, but I'll let you know if anything pops up
p.s. this is looking great, can't thank you enough for taking this on!
hsouders
commented
3 years ago Hotkeys: We could add another tab to the Preferences window for hotkeys? That way they are still in the preferences window but we can keep the functionality the same?
Postproc options: I guess we could save the cartesian product of all the options so each postproc has it's own. I'll take a look at this. It may make more sense to do the easy solution now (a single set of options for all postprocs) and then do the more complex thing later. I'm not sure how much of the postproc code I want to wrap my head around and modify? 😄
evanatherton
commented
3 years ago I think Hotkeys in another tab, but same behavior as before is perfect.
Re: prostproc - agreed that the easiest to start with would be the single set of options for all. I think the only place those come into play are in mimic/scripts/postproc/postproc_options.py in the line:
DEFAULT_USER_OPTIONS = configure_user_options( use_nonlinear_motion=True, include_axes=True )
Think if we just made that something like:
DEFAULT_USER_OPTIONS = configure_user_options(USER_PREFS.DEFAULT_POSTPROC_OPTIONS) that'd get us most of the way there
Setting up which options are actually supported in a postprocessor is handled in that postprocessor itself, so it's safe to have option in DEFAULT_USER_OPTIONS that aren't supported by a particular post. What I can't remember is if that gets called when Mimic is first loaded, or when a post-processor is selected - I'll look into that though
hsouders
commented
3 years ago Copy hotkeys.
I think I have the postproc stuff figured out as well, so no need to investigate!
andy3336
commented
3 years ago @hsouders By "file", do you mean a Maya file that has a Mimic rig? So if you were to open a Maya file, that file could have Mimic preferences associated with it (i.e. if you had a project with a KUKA/ready2_animate you'd want the entertainTech post, but if you had a project with an ABB, you might want a RAPID post setup). I hadn't actually considered that, but that sounds really nice if that's what you were going for
Side note: it might be nice if we automatically picked a compatible post-processor for the type of robot if there are no user preferences set. I hate dropping in a KUKA and the ABB post is the first one up haha
how do make the same time for ABB with Mimic?
hsouders
commented
3 years ago Hi @andy3336 - I'm not sure I understand the question. Can you provide a little more detail?
andy3336
commented
3 years ago sorry, I export a RAPID and run it on ABB The speed result is different from the simulation result from Mimic What's wrong?
hsouders
commented
3 years ago @evanatherton Do you think "Key Tool Controller" should be a preference?
evanatherton
commented
3 years ago @hsouders That one is used so infrequently, and for a very specific purpose, so I don't think it should be a preference.
Profiles. It would be nice to be able to load Mimic profiles or even just be able to change defaults. I've filled in the same info on the program settings hundreds of times from when I've re-opened a project or accidentally closed mimic and had to re-open it.