Page MenuHome

Optional parameters for play_rendered_anim operator
Needs ReviewPublic

Authored by Christian Brinkmann (poor) on Mar 6 2018, 2:46 PM.

Details

Reviewers
None
Group Reviewers
User Interface
Summary

This patch basically adds all required parameters to play_rendered_anim() operator, allowing scripters playing back any rendered sequence or movie (according to the user preferences). Based on that work, I thought we can also provide a simple UI, which can be quite useful to review/playback the rendering without changing the current scene settings:

Personally, I never understood what the operator is doing under the hood and for that reason I always manually started an external player, I'm familiar with. However, I recently discovered the operator and I think it's actually a pretty nice feature if the user interaction would be better, so in addition to the popup I added some extra warnings and error messages as well, which should help users figuring out what's happening or what's might be wrong with the settings.

I'd appreciate any feedback.

Cheers,
Christian

Note: Successfully tested with all players except Framecycler (seems there is no standalone version anymore).

Diff Detail

Event Timeline

I'd be interested to know if other animators would find this handy.
Since the references to an old djv and blender2.4x are still in this file, I wonder if many people are using animation-players besides Blender.

Will this UI pop-up every an artist want's to play back an animation? If not, when will they see this UI?


Concerns aside, checking on code.

Main issue with this patch is too much logic is in the operator now.

Would rather have the operator get the values from the UI or initialize from Blender, then call a function which handles the details (this is common practice in C & Py code).

It could be a single function in bpy_extras.anim_utils (or get it's own module playback_utils) which doesn't know about the UI, Blender's scenes or user preferences. It just takes args and runs the animation playback.

This way the operator code can be kept small, the playback code a single function with explicit args making it more straightforward & useful from Python too.

I removed BF Blender as project reviewers, no need to notify everyone in the project of changes here.

For the UI, there should not be a popup by default when pressing Ctrl + F11. The purpose of this operator is to quickly play back the animation, which could have been a playblast render for example. Ideally this could work like other operators in Blender, where you can change the properties afterwards and get live feedback on the changes, but adding a UI to the blender animation player is more complicated. If animators want these properties before playing the animation I'm guessing it would be as a separate menu entry.

This patch seems to be doing a bunch of extra things, detecting image vs. movie formats, EXR preview playback, put # for frame numbers in the path, DPI. The patch description should at least mention why they were done, and perhaps would be better as a separate patch depending if they are required for the new properties to work.

exr preview support removed

I removed BF Blender as project reviewers, no need to notify everyone in the project of changes here.

Thanks @Brecht Van Lommel (brecht), wasn't sure about the reviewers.

For the UI, there should not be a popup by default when pressing Ctrl + F11. The purpose of this operator is to quickly play back the animation, which could have been a playblast render for example. Ideally this could work like other operators in Blender, where you can change the properties afterwards and get live feedback on the changes, but adding a UI to the blender animation player is more complicated. If animators want these properties before playing the animation I'm guessing it would be as a separate menu entry.

Problem is that we can only change the settings of blender's player by changing the scene properties at the moment and it feels bad to change any render setting for an image sequence preview. Live feedback seems complicated, because there is no panel or UI element where the properties can live so the UI provided in the patch is just a simple way (partial solution) to solve that issue. However, you are right, from a user point of view I think the best solution would be adjusting the settings within the player itself afterwards, which also solves the issue of restarting it over and over again, right? Out of curiosity: what's so bad on confirmation dialogs?

This patch seems to be doing a bunch of extra things, detecting image vs. movie formats, EXR preview playback, put # for frame numbers in the path, DPI. The patch description should at least mention why they were done, and perhaps would be better as a separate patch depending if they are required for the new properties to work.

I removed exr preview support for now. All other things you've mentioned are actually required to either pass the first frame, movie or sequence name (../seq_###.exr) depending on the player.

Anyway, thanks for your feedback!

However, you are right, from a user point of view I think the best solution would be adjusting the settings within the player itself afterwards, which also solves the issue of restarting it over and over again, right?

Right, it's difficult to guess the appropriate frame numbers if you want to play only some specific part, scrubbing in the player would be easier.

Out of curiosity: what's so bad on confirmation dialogs?

Adding extra steps to slows down the user. For example some animators will do an OpenGL playblast render and then play it, if the scene is too heavy for realtime playback, and they might do that very often. Some feedback from users would be good, but my guess is that users wanting to play back a animation with a specific frame range or frame rate that is different than the original is relatively rare. So I'm not sure it's worth slowing down the more common use case, and it may be better as a separate menu entry.

I'd be interested to know if other animators would find this handy.

Thanks for your feedback @Campbell Barton (campbellbarton). It's just an extension of the old one and even the current implementation comes in handy (if you know what you are doing), because you don't need to start the player manually and load up the sequence.

Since the references to an old djv and blender2.4x are still in this file, I wonder if many people are using animation-players besides Blender.

No, I tried to remove deprecated code. Since DJV Viewer is still a valid option for individuals or smaller studios I think it's nice to support it:

Will this UI pop-up every an artist want's to play back an animation? If not, when will they see this UI?

Yes, but only in case the option is set to "INTERNAL". There is no other player supporting all the properties so I thought it isn't worth it displaying an UI with a maximum of 2 sliders for each player. Also for all other players you can pass the formatted path to the sequence ../seq_####.jpg via command line and adjust the settings afterwards, for the blender player I thought that's helpful because we could avoid that users change their scene properties for an image preview.

Main issue with this patch is too much logic is in the operator now.
Would rather have the operator get the values from the UI or initialize from Blender, then call a function which handles the details (this is common practice in C & Py code).
It could be a single function in bpy_extras.anim_utils (or get it's own module playback_utils) which doesn't know about the UI, Blender's scenes or user preferences. It just takes args and runs the animation playback.
This way the operator code can be kept small, the playback code a single function with explicit args making it more straightforward & useful from Python too.

Great idea. We can split the code, no problem at all.

I don't think having this popup each time is acceptable, as Brecht says, we can simply have a second menu item what allows options to be given.

As for splitting this up, suggest a function for checking compatibility, another to play bpy_extras.playback_utils.player_compatible_check(...) & player_launch(...)

Adding extra steps to slows down the user. For example some animators will do an OpenGL playblast render and then play it, if the scene is too heavy for realtime playback, and they might do that very often. Some feedback from users would be good, but my guess is that users wanting to play back a animation with a specific frame range or frame rate that is different than the original is relatively rare. So I'm not sure it's worth slowing down the more common use case, and it may be better as a separate menu entry.

Ok, thanks @Brecht Van Lommel (brecht). I could imagine, getting that dialog the first time starting the playback per scene might feels good and does not slow down the user (also in case of OpenGL previews), only issue is how the get the dialog back if needed... I'd like to try that idea before adding a new menu entry. Please let me know, if you have any concerns about that.

As for splitting this up, suggest a function for checking compatibility, another to play bpy_extras.playback_utils.player_compatible_check(...) & player_launch(...)

Yeah, I'll try to implement it that way. Thanks @Campbell Barton (campbellbarton)

Ok, thanks @Brecht Van Lommel (brecht). I could imagine, getting that dialog the first time starting the playback per scene might feels good and does not slow down the user (also in case of OpenGL previews), only issue is how the get the dialog back if needed... I'd like to try that idea before adding a new menu entry. Please let me know, if you have any concerns about that.

I'm not sure what would be the purpose of showing it only the first time? If it would remember the frame range and frame rate values specified then, the user would have no way to change them the second time. If it wouldn't remember the values, why would they only be needed the first time?

Definitely No to any kind of popup when hitting Ctrl+F11. Even if it's only once, it slows down and after that we still have the issue of where to set these settings.

If the settings are only for that instance of the Blender player then they should be in the player itself. A UI for it is long due anyway (for example an overlay to show the obscure shortcuts).

I'm not sure what would be the purpose of showing it only the first time? If it would remember the frame range and frame rate values specified then, the user would have no way to change them the second time. If it wouldn't remember the values, why would they only be needed the first time?

The idea was to store the data per scene when confirmed and finding a nice way to get the properties back if needed, e.g. by using Ctrl+Shift+F11 or something. If that's not an option anyway, I'll focus on implementing the operators. No problem, was just an idea.

In D3097#73386, @venomgfx wrote:

Definitely No to any kind of popup when hitting Ctrl+F11. Even if it's only once, it slows down and after that we still have the issue of where to set these settings.
If the settings are only for that instance of the Blender player then they should be in the player itself. A UI for it is long due anyway (for example an overlay to show the obscure shortcuts).

Thanks for joining @venomgfx. Yeah, we've already discussed that adjusting the properties within the player itself (after starting the player) would probably be the best option. You are working at the blender institute, right? What players you guys are using at the institute?