Configurability of captures in an interface #53
Description
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)
- Add background color settings #34 Add background color settings
- Add additional viewport options #35 Add additional viewport settings
- Support "tokens" in the save output path #17 Support "tokens" in save output path
- Enable custom lighting in playblast #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.