[Bf-committers] Proposal: Blender OpenCL compositor

Matt Ebb matt at mke3.net
Fri Jan 21 00:10:08 CET 2011


On Fri, Jan 21, 2011 at 4:49 AM, Jeroen Bakker <j.bakker at atmind.nl> wrote:
> Hi Lukas,
>
> Spaghetti vs Expressions :) : I agree with your conclusion. I really see
> this as that there are to few control parameters on a node and limited
> node implementations

It doesn't have to be a matter of spaghetti vs expressions. While
Houdini uses a lot of expressions to manage multiple types of data
flowing through one wire, it's not the only way. Many modern node
based compositors handle several image planes per wire - in fusion
there is a generic 'channel booleans' node to switch them around, in
Nuke there are re-ordering nodes, even Shake had a simple text field
where you could mention what RGBA channels and ordering would be
processed and output from the input (not an expression). It would be
very easy with the right internal design to have consistent options
for each node to choose what input channels it will work on and what
it will output. I mention this in some of my replies to francois'
blog.

It seems to me that this discussion is veering towards issues that
impact workflow design, not just speed optimisation. I personally
think this is a good thing - there are several things that can and
should be modernised inside the compositor that would require
re-coding, and the question should always be 'how can this enable
users to produce work faster', rather than 'how do we integrate
library/technology X'. This also comes with a different set of
requirements though, if you're talking about changes to workflow, it
requires more research into this aspect of user interaction, eg.
understanding how other similar applications work and what can be
learned from it, looking at how professional compositors do things on
a daily basis, etc, not just coming up with ideas in isolation.

I say this not to be negative, but because there is a lot of room for
functional improvement in blender's compositor, and if it is to be
re-coded, it should be done with an eye to workflow and future
abilities, not just from a purely techno-centric perspective.

cheers

Matt


More information about the Bf-committers mailing list