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) closed this task as Resolved.
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.

Is there still a way to render the scene from it's own sequencer at all? Such as having the camera for the scene underly all sequencer material?

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.

Being global has the down-side of not supporting multiple video edits per blend file - you couldn't for example, copy the scene, to try some alternate edits.

We could make the video editor data separate from scenes though (there own data-block for example).

Is there still a way to render the scene from it's own sequencer at all? Such as having the camera for the scene underly all sequencer material?

No, you need a separate scene.

We could make the video editor data separate from scenes though (there own data-block for example).

I think that would solve many problems and lead to making the Sequencer a much more versatile and well integrated tool, however stuff like the decrease in the playback rate of scene strips(2.79>2.80) will have to be addressed too.

We could make the video editor data separate from scenes though (there own data-block for example).

I think that would solve many problems and lead to making the Sequencer a much more versatile and well integrated tool,

Not sure about this, it's not _that_ hard to use a separate scene for video editing, more a minor annoyance you might hit when starting out.

however stuff like the decrease in the playback rate of scene strips(2.79>2.80) will have to be addressed too.

Has this regression been reported?

Way back when Motion Builder was Filmbox(more than 20 years ago) is was possible to edit camera mise-en-scenes in a timeline realtime(of the current scene). Since then pretty much all 3D packages and 3D game engines have this feature added, including Unity and Unreal, but still not Blender. With gpencil and the speed of EEVEE, realtime virtual filmmaking(and previz), should be within reach in Blender, but being able to seamless edit cameras(in 3d view) integrated with the sequencer, is a most essential step in that direction. However, without the ability to use cameras of the current scene in the sequencer, this is not possible.

I've been spamming with this POC from 2.79, but here it is again, showcasing 3D View integrated(previewing) the edits in the sequencer: https://www.youtube.com/watch?v=AG52ytTa_JU It's a delightful workflow. However, this hack has the limitation that moving the scene strips in time, will not change the entry point in the 3d scene.

With the scenes separated from the sequences, that would not only solve the scene addressing the same scene problems, but also allow the sequencer to switch between scenes without switching the contents of the sequencer and much more. Some additional words on the topic: https://blender.community/c/rightclickselect/kWbbbc/

Yes, I think that regression was reported, but I can't remember the outcome. Oh, here it is: https://developer.blender.org/T62517

From the user perspective, with the current implementation, I'd like to note 2 things.

  1. Not being able to add current scene into the VSE is confusing. There is nothing to indicate it becomes a possibility by creating a whole new scene; It makes the user think he's doing something wrong or that this is a bug (Note the bug reports).
  2. It is indeed annoying, feels needlessly clunky.

Being global has the down-side of not supporting multiple video edits per blend file - you couldn't for example, copy the scene, to try some alternate edits.
We could make the video editor data separate from scenes though (there own data-block for example).

One thing I'm realizing is that I don't understand the need to tie a video editor to a scene. What purpose does this serve? (e.g. Why should the user have to create a new scene to create another edit?)

The video editor is fundamentally different from every other editor. Whereas all other editors are used in service of building the current scene, VSE isn't; It's the other way around. I'd like to suggest, ultimately, that it becomes a globally launchable editor (A toggling button that changes VSE <> Scene).

A "global" VSE I know is a bit different from the way pretty much everything is done in Blender, but I think it makes sense. I like your idea of the VSE having separate data. I'm understanding you to mean like being able to globally create new scenes, the user will be able to easily create new editor data in VSE with the push of a "+" button. That sounds fantastic and logical.


A temporary solution suggestion: Let the user know they need to create a new scene to add the current scene to a strip. Maybe in the form of grayed out "Scene". Mouse-over will have a tool tip explaining what's going on.

The video editor is fundamentally different from every other editor. Whereas all other editors are used in service of building the current scene

Except the Text Editor. The contents of the Sequencer should be independent of the Scene selection like the Text Editor's contents is.

Hey, everybody! For those of you who need a WORKAROUND SO AS TO KEEP VIDEO AND SEQUENCER AUDIO IN SYNC WHEN ANIMATING, the Lord gave me a cool idea. It's really simple: just create a shallow copy of the scene and name it Stage, then add that to the sequencer of the true scene to use for video. Changes to animations will be updated. About the only thing to port manually would be the scene length, but that shouldn't be changing very often, so...