This adds the ability to keyframe more than one value per input (e.g. a vec2,
vec3, etc.) so that you can animate, for example, an X axis separately from a
Y axis.
To allow keyframing of each axis of a vector 2/3/4, without simply separating
the inputs for each axis, the NodeInputs need to support more than one keyframe
track with the ability to merge them into a single value when necessary.
Widget now supports creating keyframe and standard values, supports dragging
from sliders (not creating an undo command for each drag), and everything is
undoable.
Previously the non-keyframed value was stored as a static keyframe but this
introduced issues when an input was in a state of keyframes being enabled but
0 keyframes existing. Having a standard value makes much more sense.
Since all NodeInputs will generally only need their data type and default
value set once, we place it all into the constructor for cleaner and easier
to manage code.
While the copied graph doesn't pick up InvalidateCache signals, some node
processing relies on NodeInput update signals to update their internals
correctly.
If the nodes are now stateless, there's nothing stopping the renderer from
rendering multiple frames at once. Earlier since the nodes held some of their
input/output data (and that data could change per frame), it was not possible
to render multiple frames at once without conflicts. Now that the node state is
held in render threads, they can do whatever they want at any time.
If Nodes only have the one output, we don't need to do so much differentiation
between them. Previous iteration used outputs as like a distinct function
within a Node (e.g. length output would return one result, buffer output would
produce a different result - each run different code to produce their results).
Now in this iteration, it's more accurate to say a Node is just one function
(which seems more appropriate for a node system anyway).
Old code assumes that a NodeParam's parent will always be a Node. The function
has been separated off and tweaked in the event that this is not the case.
A signal emitted and received in the same thread will call other functions
before returning to the one that emitted the signal. If these other functions
try to lock a mutex while a mutex is already locked by the emitting function,
we get stuck in a deadlock. These changes ensure that a signal is never emitted
by any function until all the nodes locked by it are unlocked.
Sometimes we'll be copying nodes without wanting to copy their connections,
since we'll want to connect them to equivalent copies rather than connecting
them to the same nodes the originals were connected to. We now have an extra
parameter to distinguish such operations.
The new rendering pipeline strives to simplify the nodes themselves as much
as possible and move much of the logic to an external rendering engine. This
change removes all of the responsibilities that no longer belong to the
nodes themselves and will soon be folded into the renderer.
Nodes were previously written to be "strongly typed" in that a parameter's
"type" enforced whether it could be connected to another. All code related
to that has now been removed since not only is it hard to maintain and
likely unnecessary, it's possible the nodes will work differently later on
anyway.
itsmattkc