Page MenuHome

Disable scenes using themselves as sequence strips 2.8 Proposal
Closed, ResolvedPublic

Description

While supported on a basic level, this ends up causing annoying problems especially relating to updating animated state and frame ranges.

Examples of this are: T52583 T50139 T44291 T42235 T38132 T33298 T30663... seems this is common annoyance,

This task is to see if its acceptable to remove this functionality in 2.8 to save headaches, users and devs wasting time on such useless and annoying behavior.

The main down-side is existing blend files that use this wont render files that contain scene strips using themselves.


Listing some options of how to handle this:

  • Warning on load or render, the scenes-in-scenes are not rendered (return pink pixels or so).
  • Allow existing files to render, just disallow the operator in to add the scene to its self, so newly created files don't suffer the problem.
  • Do-version files so a new scene is created with only sequence editor data. The tricky part of this is splitting out animation data (drivers especially). So not sure its practical.

Alternatives? or any preference for how to handle?

Details

Type
Design

Event Timeline

Campbell Barton (campbellbarton) triaged this task as Normal priority.Aug 30 2017, 5:16 AM

+1 I think this is reasonable. I've ran into this problem myself and from the user point of view it's mind-boggling.

Agree this should not be allowed, that kind of recursion is just calling for issues, and brings pretty much nothing to users (aside from not having to add another empty scene… :P ).

Added some options on how we might handle to the main task.

I’d go for “Warning on load or render, the scenes-in-scenes are not rendered (return pink pixels or so).”

Though maybe a do_version-ish solution is also possible. It should not be a big issue to make a 'linked objects' copy of orig scene (mere id_copy() in fact), remap orig scene strips to new copy, and delete content (objects etc.) in orig scene?

Am worried that do-versions will end up being a heavy operation.

Steps could be:

  • Create empty scene (with " Sequence" suffix or so)
  • Copy render settings.
  • Move editor struct scene->ed to this scene.
  • Create an empty action and move any fcurves that references the sequence into the new scene.

Issues I see with do-versions:

  • Everything except moving animation data seems reasonable. Complex files with drivers and NLA are likely to fail (do people often use complex animation setups in this case?)
  • Users who might not be video editing much and happen to have added a scene strip to the sequencer for some quick preview - are going to get an extra scene (harmless but annoying).

Since the conversion process isn't likely to be clean and we can't ensure it goes smoothly, think it may be better to have a utility to automate the update, its also a bit weak but means users wont open files to find broken do-versions which they can't recover from.

I support this change; in fact, I never use the scene itself in the VSE, because somehow I conceptually found it wrong (kind of self-recursion :-) ). I think we should try not to break existing files, so my vote goes for:

  • Allow existing files to render, just disallow the operator in to add the scene to its self, so newly created files don't suffer the problem.

Oh, so integrating the sequencer with the 3D Viewport like this, will no more be possible? Previz Camera Tools

How about allowing the Sequencer run in a "local" scene different from the "global" scene on the same screen? That way the global scene(screen setting) could be switched as the scenes changes in the sequencer(by a script), but not the contents of the sequencer(area setting). That way the annoying problem of changing the scene also changing the timeline contents of the sequencer could be avoided.

Brecht Van Lommel (brecht) claimed this task.

This was implemented in 2.8.

Oh, so integrating the sequencer with the 3D Viewport like this, will no more be possible? Previz Camera Tools

How about allowing the Sequencer run in a "local" scene different from the "global" scene on the same screen? That way the global scene(screen setting) could be switched as the scenes changes in the sequencer(by a script), but not the contents of the sequencer(area setting). That way the annoying problem of changing the scene also changing the timeline contents of the sequencer could be avoided.

This seems to be a short-term, and patchy fix to Blender not being able to handle an ideal workflow. I really hope the idea of a "global" sequencer is being looked at by the Blender Foundation.

This would be the direction to make doing quick previs/animatics a dream in Blender, which, outside of this one lacking feature, Blender is so suited for, especially now with the new render engine and Grease Pencil developments in 2.8.