Provide a way to control how to handle node compatibility issues
when loading a Graph with the `strictCompatibility` parameter.
Introduce a new error type, GraphCompatibilityError, to be raised
when loading a Graph with compatibility issues with strictCompatibility enabled.
The file version is updated and support for files with an older version
is added: upon detecting that the file version is old, the old UID
keys will be detected and reformatted with new ones so the file can
be properly loaded.
The UID system based on a UID index is removed and replaced by a single
UID per node.
Attributes will be included in the UID computation if the `invalidate`
is set to `True` in their description. This replaces the `uid=[]` /
`uid=[0]` element of the description.
If the edges of a node to submit include an `InputNode` (which cannot
be computed), then that node should be excluded from the list of edges
to process as if that node had already been computed.
This allows to submit any type of graph involving `InputNode` to the farm.
The `selectedViewpoint` property will store the attribute corresponding to
the actively selected viewpoint, if it exists. Otherwise, it will be set
to None.
The behaviour regarding `ListAttributes` was different depending on
whether an edge or a node was removed:
- if an edge was removed, the `ListAttribute` that was the destination
of that edge had its corresponding element completely removed;
- if a node was removed, the `ListAttribute` that was the destination
of one of the node's edges had its corresponding element reset, but not
removed.
With this behaviour, a user had different UIDs depending on whether
a single edge or the whole node had been removed where the UID should
always be identical.
Up until this commit, compatibility nodes (which necessarily had a version
or description issue) were ignored during the evaluation of UID conflicts,
as they had no UID.
This however created a bug, where already existing compatibility nodes
with inputs from nodes that triggered UID conflicts were losing their
input connections: when the node with the UID conflict was replaced with
a new compatibility node (with a UID conflict issue), the link was broken
and could not be resolved anymore as it lost any mention of the input
node's name. This was also valid for nodes without any compatibility issue
which had UID conflicted-nodes as their inputs.
Processing all the nodes in addition to those with a UID conflict issue
prevents this from happening: edges are correctly preserved.
This also fixes an issue that occurred when opening a project file that
contained nodes whose type was not recognized. Instead of raising an
"unknown node type" compatibility issue, "attribute is already connected"
errors were raised for the unrecognized nodes.
When loading the graph, once all the nodes have been created and the
links resolved, the computed nodes' UID can be compared with those
stored in the graph.
If a mismatch is detected, the node that presents the UID conflict is
removed from the graph and replaced with a CompatibilityNode, set with
`UidConflict`.
Nodes that come from templates are ignored as no UID is stored in
templates. Similarly, nodes that are already Compatibility nodes are left
out as they do not have a UID.
This commit adds an option to the "load" method, "publishOutputs", that
determines whether "Publish" nodes in a template project file should be
ignored during the graph's creation.
If "publishOutputs=True", then the "Publish" nodes from the template will
be added to the graph. "Publish" nodes in a project file that is not
a template will not be affected by this and will always be added to the
graph, as any other node.
This allows to have templates that are compatible with meshroom_batch,
which requires a "Publish" node when the --output option is specified,
while not having unneeded nodes in the UI or unneeded operations:
when --output is specified in meshroom_batch, "publishOutputs=True",
otherwise it will be set to False so that the "Publish" nodes are not
executed needlessly.
Non-default internal attributes need to be written in the templates,
but the "internalInputs" entry in the dictionary should not be written
at all if all the internal attributes are set to their default values.
Add two internal attributes, "Comment" and "Invalid comment", in
a specific "Notes" tab, which will contain any further internal
attribute. Internal attributes exist for all nodes.
- "pyCompatibility.basestring" are replaced by standard Python3 "str"
- "Sequence" and "Iterable" from "collections" are now directly imported
with "collections.abc"
When loading a new graph while the opened one was locally computing nodes,
computations were automatically stopped to be able to load the new graph.
However, the computing chunks' status were not being updated before
the graphs were switched up. This meant that opening that previously
computing graph again would lead to a display in which nodes appeared to
be computing although there was no ongoing computations.
For every node, the only information that is kept when saving a
template are the non-default input attributes' values as well as the
node's position.
The unit test checking the templates' nodes is updated to stop taking
outputs into account.
If several nodes are described in the clipboard and are supposed to
be connected with each other, reconnect them together, but do not
attempt to reconnect them to the graph they were copied from, even if
it is the current graph.
Add a specific option to save a graph as a template ("Save As
Template") in "minimal" mode.
This mode only saves, for each node in the graph, the input and
output attributes whose values differ from the default ones. Any
attribute that is not serialized in the saved template file is
assumed to have its default value.
If a conflict is detected on a node when opening the template
file, it is logged but solved automatically.
The goal of this minimal mode is to prevent template files from
needing an update every single time a modification (may it be
minor or major) is done on a node description. Templates can
thus follow node changes and still be usable.
Add an "Import Scene" (Ctrl+Shift+I) option in the File menu
that allows to select an existing .mg file and import it in the
current graph.
The imported scene will automatically be placed below the lowest
existing node along the Y axis.
When creating a node with a "paste" operation, place the node
on the mouse's position in the graph instead of default position (0,0).
If the mouse is placed on an existing node, the pasted node will be
placed on the mouse's position plus an offset so that the pasted node
does not directly overlap with the existing node.
