Disable scenes using themselves as sequence strips 2.8 Proposal #52586

New Issue

Campbell Barton · 2017-08-30T03:35:06+02:00

Campbell Barton commented

2017-08-30 03:35:06 +02:00

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: #52583 #50139 #44291 #42235 #38132 #33298 #30663... 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?

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: #52583 #50139 #44291 #42235 #38132 #33298 #30663... 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?

Campbell Barton commented

2017-08-30 03:35:06 +02:00

Changed status to: 'Open'

Campbell Barton commented

2017-08-30 03:35:06 +02:00

Added subscribers: @ideasman42, @mont29, @Sergey, @dfelinto

Dalai Felinto commented

2017-08-30 11:53:41 +02:00

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

Bastien Montagne commented

2017-08-30 15:24:55 +02:00

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 ).

Campbell Barton commented

2017-08-30 18:15:31 +02:00

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

Bastien Montagne commented

2017-08-30 20:44:38 +02:00

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?

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?

Campbell Barton commented

2017-08-31 05:39:25 +02:00

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.

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.

Alberto Mardegan commented

2017-08-31 08:56:17 +02:00

Added subscriber: @mardy

Alberto Mardegan commented

2017-08-31 08:56:17 +02:00

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.

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.

Danrae Pray self-assigned this 2017-11-09 02:02:59 +01:00

tintwotin commented

2017-12-22 22:20:28 +01:00

Added subscriber: @tintwotin

tintwotin commented

2017-12-22 22:20:28 +01:00

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.

Oh, so integrating the sequencer with the 3D Viewport like this, will no more be possible? [Previz Camera Tools](https://www.youtube.com/watch?v=b4eQrns5KpQ) 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.

ChristopherAnderssarian commented

2018-03-28 16:26:48 +02:00

Added subscriber: @ChristopherAnderssarian

Danrae Pray removed their assignment 2018-05-29 04:20:13 +02:00

Danrae Pray commented

2018-05-29 04:20:13 +02:00

Added subscriber: @spockTheGray-4

Brecht Van Lommel commented

2018-12-11 15:51:54 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2018-12-11 15:51:54 +01:00

Changed status from 'Open' to: 'Resolved'

Brecht Van Lommel closed this issue

2018-12-11 15:51:54 +01:00

Brecht Van Lommel self-assigned this 2018-12-11 15:51:54 +01:00

Brecht Van Lommel commented

2018-12-11 15:51:54 +01:00

This was implemented in 2.8.

KiJeon commented

2019-01-14 22:09:37 +01:00

Added subscriber: @0o00o0oo

KiJeon commented

2019-01-14 22:15:19 +01:00

In #52586#476128, @tintwotin wrote:
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.

> In #52586#476128, @tintwotin wrote: > Oh, so integrating the sequencer with the 3D Viewport like this, will no more be possible? [Previz Camera Tools](https://www.youtube.com/watch?v=b4eQrns5KpQ) > > 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.

Wilbur Jaywright commented

2019-08-03 03:46:06 +02:00

Added subscriber: @zargul

Wilbur Jaywright commented

2019-08-03 03:46:06 +02:00

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?

Campbell Barton commented

2019-08-03 05:23:17 +02:00

In #52586#599504, @0o00o0oo wrote:
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).

In #52586#743899, @zargul wrote:
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.

> In #52586#599504, @0o00o0oo wrote: > 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). > In #52586#743899, @zargul wrote: > 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.

tintwotin commented

2019-08-03 07:47:16 +02:00

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, however stuff like the decrease in the playback rate of scene strips(2.79>2.80) will have to be addressed too.

Campbell Barton commented

2019-08-03 07:54:48 +02:00

In #52586#744001, @tintwotin wrote:

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?

> In #52586#744001, @tintwotin wrote: >> 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?

tintwotin commented

2019-08-03 09:22:44 +02:00

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

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

KiJeon commented

2019-08-03 10:31:47 +02:00

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

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).
It is indeed annoying, feels needlessly clunky.

In #52586#743944, @ideasman42 wrote:
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.

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. > In #52586#743944, @ideasman42 wrote: > 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). ![image.png](https://archive.blender.org/developer/F7646878/image.png) 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. ![image.png](https://archive.blender.org/developer/F7646898/image.png)

tintwotin commented

2019-08-03 11:10:38 +02:00

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.

> 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.

Wilbur Jaywright commented

2019-09-11 21:51:50 +02:00

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...

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...

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Disable scenes using themselves as sequence strips 2.8 Proposal #52586