hi, trying to open the gui result this issue :

Error: AttributeError: file /Maya/scripts/capture_gui/vendor/Qt.py line 668: 'module' object has no attribute 'QStringListModel'

Problem

When the visible modelPanels currently all are legacy viewport renderers and extra objects are created (e.g. duplicating some) and then using the preview in the interface that forces it to render a Viewport 2.0 playblast the newly created objects are not present in the preview.

It seems viewport 2.0 doesn't know about these new objects until the Viewport 2.0 has been activated.

This sounds related to abstractfactory/maya-capture#60

To reproduce:

• Set viewports to legacy
• Open capture gui
• With override viewport options and HQ: Viewport 2.0 + AA options enabled create a preview
• Duplicate and move around some geometry
• Click preview image to update

The newly created objects will not be present, until you've switched to Viewport 2.0.

Problem

Saving to a file with an empty directory field specified does not raise an error yet it also doesn't explicitly define where the output is going to end up. This should become more predictable, like default to the images folder. It is currently unclear whether it already does so. We should enforce that behavior, or error out.

Proposal

Whenever a relative path is not os.path.isabs(path) is given in the directory field it should be relative to something static and artist-friendly, I'd recommend the workspace's image folder.

On maya 2017 I have the following error.

Replacing sys.maxint with maxint = 2 ** (struct.Struct('i').size * 8 - 1) - 1 works.

Problem

Maya sometimes crashes fatally when (re)running the gui.

To reproduce:

import capture_gui

app = capture_gui.main()
app.close()

Run this code, run it again, and again, and again. Most likely within the first 20 runs Maya would have already crashed. I'm unable to quickly identify the exact source of the problem, woohoo, time for some debugging?

Issue

Now and then a playblast might end up with a selection. Let's add an option that forces no selection prior to the playblast.

Or add something that always ensures the override on selectionHiliteDisplay display to False.

prevent the user from using a non-chronological time window.

Example non-chronological :

• Start frame = 52
• End frame = 30
  This should not be possible.

The start frame should never be higher than the end frame and vise versa

Problem

Currently the resulting playblast will always be opened automatically. This is the usual preference for most situations and applications though I'm willing to discuss alternative situations where one might not want this to happen automatically.

Solution

Add a checkbox to allow the artist to toggle automatic playback after capturing.

Problem

When closing the UI whilst having custom settings (not a specific preset loaded but manually changed) then upon reopening these settings aren't necessarily preserved.

To reproduce

1. Customize the show items under the viewport options,
2. close the ui and
3. reopen the ui.

The settings are not preserved.

It seems that sometimes it reverts back to a preset instead of custom *.

The user should be able to playblast a combination of small frames and frame ranges:

Example : 1-20, 25; 50; 75, 100-150
from-to, increment;

This translates to:

1. Frames 1 to 20:
2. Frames 25, 50 and 75
3. Frames 100 to 150

Problem

Currently the pan/zoom settings will always be playblasted when enabled on the camera. An animator requested allowing to ignore any pan/zoom with a setting in the capture-gui.

Implementation

Add a plug-in that allows you to switch on/off this behavior.

Problem

Maya Version: 2016.5
Platform: Windows

I encounter 'unknown workspace' error while running from Maya 2016.5 on line 197:

images_rule = mc.workspace("images", q=1, fre=True)

I put a 'try' around that statement to get around the RuntimeError

wrong post

Problem

The Use default behavior under the Save options (in IOPlugin) doesn't describe how it behaves. The question from artists is: "What is default?"

Proposal

I'd like to propose two solutions.

1. Remove the Use default option.
2. Add a tooltip message to the checkbox.

1. Remove the use default option

With the implementation of render tokens in #28 we can remove the default and maybe instead allow users to define their own "dynamic default" through render tokens. This way it's much less hardcoded and is clear to the user what it does.

2. Add a tooltip message to the checkbox

This would clarify on mouse-hover what it does. Most artists are trained to request additional information from UI items by hovering over them, though in many scenarios it's not instantly clear what the UI item does. By implementing a tooltip we can add some clarification. It's debatable on how good of a solution this is UX-design wise.

Let's discuss what solution would be the best fit. I'm currently thinking about proposal 1.

Issue

Currently there's no option that can toggle whether DOF should be included in the playblast (if enabled on the camera)

Problem

Currently making a playblast will always show a browser (even though it has a default filename) which, for Artists, sometimes felt as a continuous interruption when doing many playblasts.

Solution

Allow a "save to default location" kind of setting where it doesn't show the browser but automatically continues to save to a default location.

I'd like to put the preview at the center of attention.

Something more akin to this.

What do you think?

Proposal

Currently the feature of registering preset paths (that will list the presets it has) is undocumented. Let's add an example usage to the README just like how the callbacks are documented there.

Discussion

How configurable should a playblast be in production?

• What kind of settings would you propose to make editable in a capture gui and storable?
• As artist (or based on feedback/insights from artists) how would you like to manage their playblasts in production?
• Do you even want to control it through storable presets? Or do you always expect to playblast the current viewport state? If so, how can we ensure reliable consistent playblasts in production? Or better, do they need to be?
• Should it define Viewport 2.0 settings like anti-aliasing, ambient occlusion, etc? How about background colors (which aren't saved with the scene)? Or is all that up to the artist to configure in the scene or on the machine?

Related issues (regarding configurability)

• #34 Add background color settings
• #35 Add additional viewport settings
• #17 Support "tokens" in save output path
• #52 Enable custom lighting in playblast

@mottosso @tokejepsen @aardschok I'd be happy if you all could share some insights regarding this topic. Feel free to get others into the discussion as well.

This also adds to the question do we want to allow the user to generally take any form of playblasts through a capture GUI, so it's their go-to tool when doing any playblast. Or do we want something simple that just ensures all "this needs to go to the client or in the edit" playblasts are quick to do and consistent in any production.

Problem

Currently there's no setting that just captures (or snaps) the current frame.

Implementation

Implement a Current Frame option in the time widget.

Issue

The capture UI time settings automatically try to adjust so that the end frame is higher than the start frame, and vice versa.

As such when retyping the end frame, e.g. going 1... -> 12... -> 125 then The start frame will automatically be resetted to frame 1 since for a moment there the lowest set end frame was frame 1.

Proposal

Instead of this behavior it should only update that check on leaving the text field, on enter and/or after a delay (possibly 2 seconds or so?). So that one can at least type without interfering with the other setting.

Problem

Currently it's impossible to specify a dynamic path (relative under the current workspace) like the images or movies file rule defined in the workspace.

Solution

Implement render tokens like <Images> and <Movies> respectively to capture to the workspace's image or movies folder.

When trying to open the Preview Widget after the first time open and closing it, the hitbox moves to the right. The rest of the widgets can be expanded when clicking the title, the preview widget does not.

Problem

Currently the render tokens are supported in the filename (and I believe they also work in the directory field) but they do not show up under right-mouse-button for the directory field.

Solution

Implement RMB functionality for the directory field

Problem

Currently the ScaleWidget only returns the render settings and the actually specified settings are ignored.

Solution

Implement it. :)

When using custom frames the user should be able to use a sequential frame number in the file names (0001, 0002, 0003 etc) or the actual frame numbers (0001, 0030, 0060).

This functionality can be toggled in capture with the raw_frame_numbers argument.

Problem

Because preview refresh is currently outside of an undo queue (to avoid spamming tons of undos into the queue) it seems to behave unexpectedly on undo where it would revert to frame zero.

We'll need to find a good way to avoid having the undo queue filling up whilst leaving the scene the way it was.

Currently playblast only uses default lighting, artist should be able to playblast with custom lighting

Issue

Currently the option to display textures or not cannot be set in the Capture UI. These options should somehow become editable to ensure the playblasting is consistent.

Problem

Like #34 more viewport options are currently lacking support. There are no ways to customize them through the capture gui.

Note: whilst #31 remains unfixed this also means there's no way to playblast with custom settings. Once that's implemented one could disable "override viewport settings" and just directly use the settings from a viewport to workaround missing UI widgets for options

Solution

Implement the options for these features, like:

• Viewport lighting options
• Viewport shading options
• Viewport 2.0 ambient occlusion, motion blur, anti-aliasing settings, etc.

As a note, there are many viewport settings! ;)

Problem

When playblasting to the image codec the resulting playblast is not opened for previewing because the name is returned as e.g. playblast.####.png with the #### being the problematic argument for viewers.

Solution

Resolve the #### with the frame number (an existing file) and pass it as correct argument to image viewers.

Problem

When the GUI remains open for some time and a camera has been deleted or scene has changed and the camera list was not refreshed then it might try to playblast with an invalid camera, resulting in an error:

# Traceback (most recent call last):
#   File "P:\pipeline\dev\git\maya-capture-gui\capture_gui\app.py", line 239, in apply
#     options['filename'] = lib._capture(options)
#   File "P:\pipeline\dev\git\maya-capture-gui\capture_gui\lib.py", line 177, in _capture
#     path = capture.capture(**options)
#   File "P:\pipeline\dev\git\maya-capture\capture.py", line 116, in capture
#     raise RuntimeError("Camera does not exist: {0}".format(camera))
# RuntimeError: Camera does not exist: |persp1

Though this error is not shown visually to the artist, yet is only present in the script editor.

Solution

Highlight that something went wrong that describes to the artist what specifically is a wrong setting.

Notes

• The problem is also present for the "preview" thumbnail, which might tackle the problem nicely by briefly showing a red cross or "invalid camera" image instead of a preview.
• Maybe instead of a popup message the camera dropdown menu could be highlighted in red to showcase the setting that was wrong. This would be less interruptive to the Artist.
• It's best to check whether the camera exists when clicking on the Capture button than after browsing and setting the save location and letting the playblast command fail after that stage. Otherwise Artists will be setting filenames and losing that information, even though the tool could've checked this upfront.

Implementation

Maybe the Widgets could implement a Validation check that would return False if it was invalid and would have a highlighting feature to identify the settings in the widget that are invalid.

Hi,
When I try to open the gui on centos 7.6 / maya 2019.1, the console return this errors

RuntimeWarning: libshiboken: Overflow: Value -9223372036854775807 exceeds limits of type [signed] "i" (4bytes)., at line 102, in "/mnt/Pipeline/Maya/scripts/capture_gui/plugins/timeplugin.py" OverflowError RuntimeWarning: libshiboken: Overflow: Value 9223372036854775807 exceeds limits of type [signed] "i" (4bytes)., at line 102, in "/mnt/Pipeline/Maya/scripts/capture_gui/plugins/timeplugin.py"

on windows it's works normally

Problem

With the version from #15 saving with an empty filename (when save is True and use default is False) in the IoPlugin will result in the following error:

# Traceback (most recent call last):
#   File "D:\git_pipeline\maya-capture-gui\capture_gui\app.py", line 372, in apply
#     options["filename"] = lib.capture_scene(options)
#   File "D:\git_pipeline\maya-capture-gui\capture_gui\lib.py", line 197, in capture_scene
#     path = capture.capture(**options)
#   File "P:\pipeline\dev\git\maya-capture\capture.py", line 176, in capture
#     **playblast_kwargs)
# RuntimeError: The file  exists and overwrite flag not set. Playblast aborted.
# 

Proposal

It should be clearer to the end user what is going on. We could raise a clearer error message.

Proposal

Similar to Maya's render tokens for file name prefix in the render settings I'd like to have similar functionality to set a dynamic filename output that can be set up by the artist.

For example supplying a filename like <Scene> would result in the exact scene name without extension. And <Scene>_<Camera> would result in something like my_scene_persp.mov (Here my_scene comes from the scene name my_scene.ma and the camera is the persp camera that was playblasted)

Initial tokens I'm thinking of:

• <Scene>: The current scene name without extension.
• <Camera>: The camera used in the playblast
• <Resolution>: The resulting resolution in the playblast, e.g. "1920x1080"

Potentially a system could be implemented to register custom tokens that would just call the registered function with the supplied options for the capture, but I think that's something that would only be interesting if there's a need for it.

Problem

Whenever Override viewport settings is turned off in the ViewportOptions it currently overrides the view settings to an arbitrary "default" state with basically everything turned on. Based on comments from users the expected behavior in this case is that it would grab the settings from the active viewport, as such parsing those.

Solution

With this option disabled the options should be parsed from the active view, for this capture.parse_active_view could be used (taking only the settings that we need).

Console request:
from capture import capture
import capture_gui
capture_gui.main()

capture_gui.main()

Capture Gui : Writing JSON file: <open file '/home/user/CaptureGUI/capturegui.json', mode 'w' at 0x7f88e447bf60>

Problem

Currently the capture gui has no way to customize the viewport background mode or colors; or allowing to take them from the active viewport (as described in #31)

Solution

It should allow to set the background mode (gradient or solid) and respectively the colors (top/bottom or single solid color).

Problem

When the preview widget was previously opened (thus initialized) for the current open capture gui, then closed and then reopened the thumbnail is not automatically updated; this means the preview doesn't correspond with the current settings which might be unclear to artist.

Solutions

1. Remove the "initialized" state and always trigger a refresh when reopening the widget, this forces it to be up-to-date.
2. Maybe we should also clarify in a way that clicking the image will force an update; currently it's not clear that it won't update automatically and how the user would go about forcefully updating it. (Should this be a separate issue?)

Problem

Projects or pipelines often require predefined settings that can be applied and reused throughout a project. Allowing to save and share these options in the form of presets would be a great effort in that direction.

Implementation

The presets would apply things like "visibilities" of specific objects, or background color. To keep the general UI as minimalistic as possible (saving on screen space) I'd opt for a solution that implements the specific settings (configuring a preset) in a separate pop-up when clicking on the options (cogwheel) icon.

A quick mockup to showcase how this would look in the UI:

The preset could then also house the aspects configurations of Codec and Options and other settings that are often left alone during production. The idea is to keep only the most frequently used options in the base UI. The above could then, as example, become something like:

Example : When clicking "browse" and creating a folder called "test" and insert "TEST" as filename returns the wrong directory while the filename is correct.

• Check what the file dialog actually returns
• Refactor code based on findings

Problem

The preview widget aids the artist to give an idea of the playblast outcome, nevertheless for very large and complex scenes it's unnecessarily slow because it will try to update on each option change that results in different output. Instead it would be easier for those scenes to allow the artist to update the preview only manually.

Solution

Allow disabling the auto-updating feature of the thumbnail (and maybe even hide it to gain screen space?).

Issue

When playblasting with <Camera> in the filename the camera name will resolve with the namespace in it, for example namespace:camera which isn't a valid filename. As such the playblast will error.

Solution

Either strip the namespace or replace it with a symbol that's valid as filename, for example: name.replace(":", "_").

To ensure the user has the freedom to chose if the filenames contain a frame number or not we will need to remove the default behavior of the capture single frame. It should only write frame numbers when the user enables the Raw frame numbers checkbox

Current result : filename.####.extension
Proposed : filename.extension

We can enable a frame number token for the filename to ensure the user can specify the frame number the wanted fashion, for example: filename_.extension