No they’re not, if this happened, the VSE could pretty much use the Compositor as it is. The reason for the VSE being unable the use material from the Compositor(or 3d view) of the same scene as the sequence-edit is in, is because the Sequencer data is stored within the scene. The Movie Clip editor, the Image editor the Text editor do not do this. So this is not uncommon practise to store editor data outside the scene data.
It’s not about performance, it’s about workflow. My point is, that sequencer does not have access to some data like render layers, so it you want to composite 3D render with image sequence when doing motion tracking for example, it is best to use compositor as you have much finer control over layers.
In compositor you make a shot, in VSE you edit shots. Technically this line could be blured, but this is another design talk.
For reusing node setups this could be made easy by other means, like copy paste logic and attach appropriate inputs. or even whole tree could be copied and endpoints can be automatically substituted to fit VSE usecase. In any case there are many ways to resolve this, I don’t think it’s super important to go into details, but it has to be recognized, that there are nodes that make no sense in one or other context/workflow.
Regarding to accessing other strips - you say that these could be represented as image sequence and timing could be adjusted: In this case you don’t really need strips at all then, which is not necessarily bad. My point is, that strips do actually represent footage timing and offsets. If you use strips as inputs, these should be respected various effect factors could be keyframed of course or plugged into something like “Time Info node”. Otherwise if you decide to change transition time in timeline, you will then have to adjust node tree which will be very annoying.
Not sure if I understood this point well enough though.
Not quite sure if I understand. Do you propose, that there would be special “empty” strip type to do transitions?
Realistically speaking, you will have node trees with 1 or 2 inputs - plain effect and transition, so this could be possible to enforce by design and would solve a lot of problems, but also limit flexibility.
It can be done as 2 main types and still allowing for more image inputs if needed, but relationship between these won’t be managed in any way.
I wouldn’t say they are being phased out, just that I am not sure how they will work with channel headers. Nodes can definitely help, but this still needs a design that will work well so in meantime it’s most likely I will hack channels with effects as well as I can.
@tintwotin This proposal is about using compositor like nodes for individual strips not whole sequencer output. How strips are stored doesn’t change the fact, that it has to be designed if and how node system can work for VSE. Hacks could be done even now to use copmpositor in almost any imaginable way.
As Blender is now it is possible to roundtrip a strip in the compositor by opening the movie path as a Movie clip it becomes a data block that can be added with a movie-clip node in the compositor in an external scene. This scene can be returned to the sequencer. It is a tedious process, but it could be automated with an add-on, however, the performance is pretty bad and there is no caching of scene strips. The gain is that users actually can use this process to comp 3d elements with VSE strips, which isn’t possible in the solution ISS suggests, as I understand it.
With the upcoming realtime viewport compositor: REALTIME Viewport Compositing NOW!!! - Blender News - YouTube how do the VSE get any benefits from this? Currently, the performance of anything going through Scene strips is pretty poor, and having to reference external scenes is also tedious, which is why I keep returning to moving sequencer data out of scenes as the solution to a better integration of the Sequencer into current and future editors.
If that’s a technical limitation that can be overcome, it would be useful for 3D transitions, or other similar 3D “templates” where you want to bring a strip from the sequencer into a 3D scene.
The 3D features are probably something that might be better to discuss about in a separate proposal later though, since they’d require planning on how they should be implemented.
Okay. As long as there’s a way to reuse nodes in some way I think it makes sense to split it into another editor.
Is there a thread/design for the channel headers somewhere?
Yes, kind of. I think I didn’t explain the idea very well earlier. The image sequence nodes would work the same way they do as of now. They load the video or image sequence from the hard drive. They wouldn’t have any relation to any strip in the sequencer timeline.
The Media In node would bring in only the media of the strip the node group is applied on, the Transition In node would bring in the media of the two strips being transitioned, and the Meta Strip node would bring in the media of each channel of the meta strip as an input. (The Meta Strip thing is mostly a convenience feature that could be implemented later if there’s demand for it) These would be the only nodes that bring stuff in from the sequencer.
I think it’s best explained with images:
The transition factor would be 0 at the start of the transition strip, and 1 at the end of it. That way the transition would work with no need for modifications when adjusting the length of it.
Yes, if I understood correctly:
This meta strip feature lets you bring in each channel as a separate input. It’s convenient if you have multiple strips after each other that you want to layer and add effects to in the same way, since with nodes it’s inconvenient to add strips after each other. The different colors in the example represent different clips (this made up example doesn’t make much sense as you could do the same thing in the VSE, but it’s there just to show the basic idea).
This isn’t a must-have feature, but something that could be implemented later if there’s demand for it.
Yea, for adding effects on strips they wouldn’t be needed (except the strip it’s applied on and transition strips). Timing audio and making a sequence of the different shots would be done in the sequencer.
Yes, that’s my idea. For more advanced effects requiring more inputs, the image sequence nodes can be used.
In my proposal more media inputs can be brought in with the Group Input node. You can’t choose any strips from the sequencer for those inputs though, only image/video files.
They would be exposed like shown here (except without the channel input field):
Transitions can already be done in the compositor by converting strips to Image data blocks(but if sequencer data was moved out of the scene, you wouldn’t have to do the scene switching(unless you already had an output node in it)):
On the topic of separating strip and scene nodes again: I noticed that there already are cases where a single editor is used for multiple contexts with differing nodes.
In the shader editor, there’s a dropdown for object, world, and line style:
Each dropdown option has their own available nodes. Some are shared, some aren’t. For example for object materials the Material output node is available, which Line Style doesn’t have, but Line Style has the Line Style Output node.
Maybe the sequence/scene node separation could be done the same way, like this:
Just being able to save and switch between different node trees in the compositor just like material and geometry nodes would be awesome.
For me the best solution is:
.to have a NEW video editor (called PRINCIPAL VSE) which is a copy of VSE but independent of scene. The only editor that could add a “SCENE STRIP” because it is not link to any scene. So like that we could change the scene without changing the Principal sequencer content.
. The old VSE (can be called SCENE VSE) must be disallowed from adding a " SCENE STRIP". Nothing will be changed here. it will continue to serve for render setting or for storyboard and animation video editing. We could also select some videos in PRINCIPAL VSE and send them to SCENE VSE for regrouping or pre-composing.
At the end we will have two video editors as we have many node editors:
PRINCIPAL VSE & SCENE VSE.
SOME ADVANTAGES OF THAT NEW P-VSE:
. From That new editor PRINCIPAL VSE we could send our selected videos in NODE COMPOSITOR( for pre-composition, FX and transition needs ) , in CLIP EDITOR( for 2d/3d tracking, masking, stabilisation creation) , 3D SCENE ( as background image or 3d effects), or in Scene vse.
. STORYBOARDING FACILITY: Changing scene while the sequencer is constant.
. Could serve as RENDER QUEUE.
. It must have it own timeline or use the timeline of clip editor.
Note that with this implementation all our request will be possible. @iss please can you try this even as a proof of concept.
I already created an add-on that do most of all those stuff. The add-on is call BACHADAM VFX ADDON.
I will link it video here soon.
Second version of that add-on .
If you need to test that add-on just let me know.
The last version of that is not yet available it is for blender 3.2
That’s an incredible addon. Thanks for sharing it.
I posted a reply to your ideas here, as that thread is more relevant for it: Suggestion: Make the Sequencer contents into data-block, which can override the switched to Scene-Sequencer contents - #6 by ok-what
I think its a great add-on and I’d love to see something like this implemented in Blender.
I want to share that addon of mine here for free so you can try and see it potential and limitation. HOW TO SHARE A .PY FILE ON THIS PAGE