Calvin Williamson wrote:
One good example is if you have an Op with inputs that are animated
parameters. This is the main case I can think of that would be
useful actually.
For example you might have a animated spline curve or some animated
scalar parameter (like frame number or time) that you want to pass
to an Op. One way to do this is to attach as input an op that
outputs your animated param.
This is pretty standard technique for things like scenegraphs
or hypergraphs (like maya) to get animation engines into
the graph, and that is why it would be good to make it
work for gegl too.
Though it is extra work, I think you have to be able to pass
other data along the graph to cover these kinds of animated
param nodes.
The purpose of a graph is to express algebraic relationships between
different data types. This is where I have trouble finding examples of
where we would best be served by generalizing data inputs. When would
you want to use this infrastructure to, say, add two scalars, or take
the dot product of two vectors. You might use some kind of object to
generate your animation parameters, but you don't need all this
algebraic stuff to do that.
If you need to set some non-image parameters, you could use the GObject
signal stuff to update the parameters every frame. This would allow
animation systems to be used with gegl, and you still get all the
massive simplifications I mentioned earlier.
--
Dan
