[Bf-committers] Composite Nodes vs Sequencer

Reuben Martin reuben.m at gmail.com
Tue Apr 29 04:03:13 CEST 2008

Back on Monday 28 April 2008, Rui Campos was like:
> This is just my opinion on what I saw lately with Node(s) in the patch
> tracker not being added to the Compositor due to some idea that they
> belong to the sequencer instead, even though the code was good enough for
> inclusion.
> I don't really know what is the major idea behind the Compositor and its
> interaction with the Sequencer, but I do use the Compositor more often
> than the Sequencer and with live footage, rather then with fancy 3D stuff.

I've been thinking about this model myself and have run into some annoying 
problems doing some VFX over the last few weeks that have led me to conclude 
that the following changes need to be made over time:

1) Compositor should have sequencer input and sequencer output nodes.

2) We need to be able to have any arbitrary number of sequencer timelines and 
compositor networks (correct term?) as desired. **Grouped by scene!!**

3) Timelines need to be able to have the output from another timeline as an 
input. Same with compositor networks.

4) The data of the timelines / networks need to be abstracted similar to how 
we abstract objects and object data.

5) Get rid of the compositor / sequencer rendering options. Both are on by 
default. If you don't need any compositing of sequencing done, you don't 
create any compositor node networks or sequencer timelines.

6) This is a must: All FX, compositor nodes, etc MUST work better with the 
Key-Mode rendering option. Too many of them mix the output as pre-mulitplied. 
This is really bad when in Key-mode, because parts of the output generated 
will be keyed and other parts pre-multiplied. Now how do you import THAT into 
a 3rd party app?

7) There's probably more I've forgotten.

And while I'm at it, totally OT, we need a Halo option that renders the Halo 
on edges (or curves) instead of verticies.


More information about the Bf-committers mailing list