The first in many NodeView improvements. Up until now, nodes have been forcibly
auto-arranged, which has worked as a reasonable stop-gap just so that all the
nodes are visible during testing/development. However this does not make a good
user experience.
We move the auto-arrange code to a manual function that can be used when the
user or program deems it necessary, and also abstract the node positions so that
the view can ultimately determine the exact amount of spacing (useful for
changing DPIs) or orientation, so users can direct the flow whichever way they
want.
A huge optimization that ensures only the parts of a node graph that have
changed get pushed to the renderer. For thread-safety, the node graph is
copied elsewhere so that users can make changes asynchronously and the graph
can update when its threads are ready. Up until now, if an input value changed,
every node's values would be re-copied, or worse, if a connection was changed,
the entire graph would be recopied. This has been negligible in testing since
we've been largely testing with small graphs, but for massive projects, it's
important that this be as optimized as possible.
As opposed to simply leaving all values in the table, nodes can now "take"
values that they use to free up memory (e.g. "taking" input buffers if they're
used to produce an output buffer).
This is a fairly large change, expect regressions.
Implemented the ability to copy/paste blocks/clips in the timeline. This did
require some large scale changes and reworking of the copy/paste system
introduced a few commits ago, but should be largely functional now.
Since the node graph can have transform cross nodes, input keyframes may occur
at a different times requiring transforming between sequence time and media
time. This commit implements such a mechanism in all UI classes that need it.
Should address any XML parsing issues and allows for simpler, more maintainable
code. Should also address a crash that could occur when pasting nodes that had
inputs that weren't copied.
When dragging a value in the UI, we use a "single frame update" because we want
to prioritize the currently visible frame to give visual feedback as soon as
possible. Previously, we generated a single frame InvalidateCache() signal
from the widgets themselves, but this had the major downside of not necessarily
emitting the time that the viewer was actually showing (due to either node time
transformations or times differing between the effects panels and the viewer
panels). Now, we send a different signal that viewers can handle themselves to
update the time that they're currently showing. This means the fast updating
will work no matter how many viewers are connected at whatever time each viewer
is set to.
Footage is a special case where the node parameters can reference objects that
exist outside of the graph. Therefore specific code is needed to
serialize/deserialize.
Since we load in a separate thread, when the QObject based objects are
instantiated, they're created with affinity to that separate thread. Now we
specifically ensure they are moved to the main thread after their creation.
Transitions are nodes but have a few parameters that are programmatic and always
required. This lets people write external code for transitions as well.
Previous iteration used some "magic code" that added clips automatically to the
timeline. This was functional but ultimately outside of the undo commands'
control meaning nodes could be infinitely added and abandoned. This makes the
add process part of the undo command which means it's all undoable as the user
would expect.
This was many changes that were largely fundamentally related. They included:
- More const modifiers to enforce read only node graphs
- Support for fragment and vertex shaders from the nodes
- Support for node code loaded externally (embedded into the binary)
- Fixed issue preventing two textures from being used in a shader
- Removed several unused functions and cleaned up code
- Fixed video media node misreading its matrix input
Since all Nodes have an output that provides all output values now, we now
never need to add an output from a Node derivative. These changes remove the
last of them and disable the ability to add more outputs from a derivative.
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).
Since the nodes won't be holding any rendering data themselves in this system,
we may as well enforce some level of non-write access by setting all the
functions to const. They were already const-friendly, they just weren't
labelled as such.
Fixes a "pure virtual method" crash. The inputs will try to send invalidate
cache signals through the node while it's being destroyed if these are left
connected. There's no purpose to sending invalidate cache signals since any
nodes affected by this one will automatically invalidate the cache from its
outputs being disconnected and the node being destroyed so this shouldn't
cause issues.
NodeParams used to be destroyed automatically through the QObject system, but
now that NodeParams perform actions that access the parent Node object in
their destructor, the NodeParam destructor needs to be called before the Node
has been fully destroyed. By destroying explicitly in the Node destructor we
accomplish this.
It seems unwise to let NodeInputs take more than one value, but at times
it makes sense to create a list or array of inputs. This class will create
sub-parameters as an easy way to provide variable inputs while also enforcing
one connection per input parameter.
This is also the primary motivation for the previous commit (disambiguating
when a NodeParam's parent is a Node vs some other type).
Useful for detecting when a graph needs recompiling, in tandem with the
"InvalidateCache()" signal when necessary, this signal ripples through the
nodes when any of the connections change which will likely need handling by
the renderer.
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.
commit
For testing the new iteration, the texture cache disk download was written
into the main thread instead of into the separate threads. Now they're back
in separate threads again.
Also I think some of these files probably should have been in the previous
commit.
Once again, conceptually this system should work, however it does not seem to
be the most efficient and it wouldn't surprise me if the multithreading was
eventually upgraded to an even more coherent system one day. However for
"core principles" this should be fairly decent.
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.
itsmattkc