[Bf-compositor] Extending some node functions to VSE

Diego Gangl dnicolas at gmail.com
Thu May 22 15:26:53 CEST 2014


I think it makes sense to have both input and output nodes. The node
system doesn't have to end on a single output necessarily (eg, using
file output nodes). This way you can feed from channels and into
channels, share nodes and data, and do the entire video in one
nodetree. The only problem to avoid would be circular dependencies but
the compositor can prevent them already.

Anyways, let's wait for a dev :)


2014-05-22 7:08 GMT-03:00 Francesco Paglia <f.paglia.80 at gmail.com>:
> I think we have to wait for some developer to add their voice on this since
> I don't really know how it should work from a code point of view.
>
> However from my point of view a nodal system should drive everything and 3D
> scene as well as 2D node tree (I don't want to limit this tool to the
> compositor) or VSE should be just node of this structure... Well I'm going
> too far actually :)
>
>
> 2014-05-22 11:46 GMT+02:00 David McSween <3pointedit at gmail.com>:
>
>> The VSE is at the end of the Blender work flow chain. So it cannot send-to
>> anywhere else in Blender.
>> Would this be an alternate 'Head end' to the compositor, or a different
>> VSE mode?
>> If its a mode switch perhaps it could be a second meta-strip type? Where
>> you arrange shots and collapse them into a container. Then you could step in
>> and edit it's contents.
>> Stepping out would simply show its comp result.
>>
>> David
>>
>> On 22 May 2014 19:25, "Francesco Paglia" <f.paglia.80 at gmail.com> wrote:
>>>
>>> My answers are inlined
>>>
>>>
>>> 2014-05-22 11:11 GMT+02:00 David McSween <3pointedit at gmail.com>:
>>>>
>>>> What I meant by limitations of using nodes in single strips is... you
>>>> could not easily send source image through a node tree to affect other
>>>> strips.
>>>>
>>>> But I see that you are suggesting a sort of meta-node strip(?), that
>>>> uses VSE channels as sources.
>>>
>>>
>>> Right
>>>
>>>>
>>>> Is a channel considered an input node or an individual strip?
>>>
>>> The whole channel is used as input
>>>
>>>>
>>>> Does a channel only become active when a strip occupies it?
>>>>
>>> As soon as a strip even  1 frm long is added to a channel it becomes
>>> eligible as an input source
>>>
>>>>
>>>> The timeline metaphor is much easier to grasp for time-related changes
>>>> to media, relative to each other. I really wish there was an efficient way
>>>> to send these decisions to the compositor...
>>>>
>>> It would be a big improvement for me too! :)
>>>
>>>>
>>>>
>>>> On Thu, May 22, 2014 at 6:16 PM, Francesco Paglia
>>>> <f.paglia.80 at gmail.com> wrote:
>>>>>
>>>>> IMHO a strip contain a node tree where you can use as input other
>>>>> strips embedded in the timeline as well as extra elements imported or
>>>>> generated directly in the node tree (like a renderlayer of a scene or an
>>>>> image or a text)
>>>>>
>>>>> To give you some reference you can take a look at the compositing
>>>>> system of the "ancient" AVID DS or latest version of Lightworks...
>>>>> As you can see there strips are added in the compositor node tree and
>>>>> treated as inputs.
>>>>>
>>>>> The DS approach differ from the lightworks one and both are efficient
>>>>> in their own way:
>>>>> DS define a subtimeline with all the strips embedded
>>>>> Lightworks reads directly the original timeline
>>>>>
>>>>> In both cases you get an input node for each layer (doesn't matter how
>>>>> many clips are involved per track) that I find really useful
>>>>> I do prefer the subtimeline solution of DS because it locks all the
>>>>> strips to the local timeline and if you change your edit you wont loose the
>>>>> link between them.
>>>>>
>>>>> I don't understand completely what you mean with the constrains and
>>>>> limitation of the single strip because in any way you get strips with alpha
>>>>> and opacity and you can blend them with all the method allowed by the
>>>>> software
>>>>>
>>>>>
>>>>>
>>>>> 2014-05-22 10:00 GMT+02:00 David McSween <3pointedit at gmail.com>:
>>>>>
>>>>>> Could you explain the concept of - converting strips to "compositing
>>>>>> containters"
>>>>>>
>>>>>> Does this mean that:
>>>>>> 1. a proxy of the strip appears in the compositor (and it's
>>>>>> result/output in the VSE)
>>>>>> or that
>>>>>> 2. the VSE strip contains a mini node tree in the VSE.
>>>>>>
>>>>>> The first idea allows for multiple strip interaction, where the strips
>>>>>> are concurrent in the timeline. for example chromakeying action over
>>>>>> background.
>>>>>> The second idea seems to constrain node effects to a single strip?
>>>>>>
>>>>>> Thanks for the interest.
>>>>>> David
>>>>>>
>>>>>>
>>>>>> On Thu, May 22, 2014 at 5:37 PM, Francesco Paglia
>>>>>> <f.paglia.80 at gmail.com> wrote:
>>>>>>>
>>>>>>> +1
>>>>>>> As I see some node functionalities have been imported in the VSE but
>>>>>>> the design (as is now) shows a lack of possibilities and doesn't look very
>>>>>>> efficient.
>>>>>>> Probably we have to wait until compositor becomes unlinked from the
>>>>>>> renderlayer  system.
>>>>>>> But imagine the power we gain in this way simply converting strips to
>>>>>>> "compositing containters"...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2014-05-22 7:08 GMT+02:00 David McSween <3pointedit at gmail.com>:
>>>>>>>>
>>>>>>>> This is slightly off topic, but I wonder if it is possible to extend
>>>>>>>> the function of VSE strip modifiers to use compositor nodes?
>>>>>>>>
>>>>>>>> That is allow re-using simple 'node code' like blur, to alter strip
>>>>>>>> frames in the VSE.
>>>>>>>>
>>>>>>>> We already have Curves and Color Corrector as well as Masks.
>>>>>>>>
>>>>>>>> I propose simply adding 'discreet task' modifiers but also wonder if
>>>>>>>> you can realistically port a compositor node tree into a VSE strip as a
>>>>>>>> frame modifier?
>>>>>>>>
>>>>>>>> One of the most annoying deficiencies in the VSE currently is the
>>>>>>>> lack of Blur filters.
>>>>>>>>
>>>>>>>> Thanks for your consideration.
>>>>>>>> David McSween
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Bf-compositor mailing list
>>>>>>>> Bf-compositor at blender.org
>>>>>>>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Francesco Paglia
>>>>>>> Vfx and Production Supervisor
>>>>>>>
>>>>>>> mobile  +39 347.82.12.473
>>>>>>> e-mail   f.paglia.80 at gmail.com
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Bf-compositor mailing list
>>>>>>> Bf-compositor at blender.org
>>>>>>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Bf-compositor mailing list
>>>>>> Bf-compositor at blender.org
>>>>>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Francesco Paglia
>>>>> Vfx and Production Supervisor
>>>>>
>>>>> mobile  +39 347.82.12.473
>>>>> e-mail   f.paglia.80 at gmail.com
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Bf-compositor mailing list
>>>>> Bf-compositor at blender.org
>>>>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Bf-compositor mailing list
>>>> Bf-compositor at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>>>
>>>
>>>
>>>
>>> --
>>> Francesco Paglia
>>> Vfx and Production Supervisor
>>>
>>> mobile  +39 347.82.12.473
>>> e-mail   f.paglia.80 at gmail.com
>>>
>>>
>>> _______________________________________________
>>> Bf-compositor mailing list
>>> Bf-compositor at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>>
>>
>> _______________________________________________
>> Bf-compositor mailing list
>> Bf-compositor at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>
>
>
>
> --
> Francesco Paglia
> Vfx and Production Supervisor
>
> mobile  +39 347.82.12.473
> e-mail   f.paglia.80 at gmail.com
>
>
> _______________________________________________
> Bf-compositor mailing list
> Bf-compositor at blender.org
> http://lists.blender.org/mailman/listinfo/bf-compositor
>


More information about the Bf-compositor mailing list