Image Editor
When changing to another texture paint slot, the texture displayed in
the viewport changes accordingly (as well as the image displayed
in the Image Editor).
When changing the active texture in the Node Editor though, only the
texture displayed in the viewport changes.
This was mentioned in T88788 and I am not 100% sure this is desired in
all scenarios (or at all), it should be seen in tandem of D11497. This
change makes it so that the Image Editor changes to the image we changed
to in the Node Editor (keeping them in sync).
If this is not desired in all cases, this could be made an option.
ref T88788
ref D11496
ref D11497
Maniphest Tasks: T88788
Differential Revision: https://developer.blender.org/D11498
active paint slot
When changing to another texture paint slot, the texture displayed in
the viewport changes accordingly (as well as the image displayed
in the Image Editor).
When changing the active texture in the Node Editor though, only the
texture displayed in the viewport changes.
This _can_ be confusing because you can end up painting on a texture
that you are not looking at in the viewport (so you dont have any
feedback whatsoever). Not 100% sure this is desired in all scenarios,
but this change makes it so that the active paint slot changes to the
one that uses the texture we chaged to in the Node Editor (keeping them
in sync).
If this is not desired in all cases, this could be made an option.
ref T88788
ref D11496
Maniphest Tasks: T88788
Differential Revision: https://developer.blender.org/D11497
The code assumed that when a node group is is at the highest
level in the node editor, then it is embedded into another data
block and can't be referenced by other node groups. This is true
for shader and compositor nodes, but not for geometry nodes.
This makes node trees with long links that cross other nodes easier to work with.
Dimmed links will be ignored by various modal operators like cut and reroute insertion.
Differential Revision: https://developer.blender.org/D11813
The menu lists all socket types that are valid for the node tree.
Changing a socket type updates all instances of the group and keeps
existing links to the socket.
If changing the socket type leads to incorrect node connections the
links are flagged as invalid (red) and ignored but not removed. This is
so users don't lose information and can then fix resulting issues.
For example: Changing a Color socket to a Shader socket can cause an
invalid Shader-to-Color connection.
Implementation details:
The new `NODE_OT_tree_socket_change_type` operator uses the generic
`rna_node_socket_type_itemf` function to list all eligible socket types.
It uses the tree type's `valid_socket_type` callback to test for valid
types. In addition it also checks the subtype, because multiple RNA
types are registered for the same base type. The `valid_socket_type`
callback has been modified slightly to accept full socket types instead
of just the base type enum, so that custom (python) socket types can be
used by this operator.
The `nodeModifySocketType` function is now called when group nodes
encounter a socket type mismatch, instead of replacing the socket
entirely. This ensures that links are kept to/from group nodes as well
as group input/output nodes. The `nodeModifySocketType` function now
also takes a full `bNodeSocketType` instead of just the base and subtype
enum (a shortcut `nodeModifySocketTypeStatic` exists for when only
static types are used).
Differential Revision: https://developer.blender.org/D10912
This adds a viewer node similar to the one in the compositor.
The icon in the headers of nodes is removed because it served
the same purpose and is not necessary anymore.
Node outputs can be connected to the active viewer using
ctrl+shift+LMB, just like in the compositor. Right now this collides
with the shortcut used in the node wrangler addon, which will
be changed separately.
As of now, the viewed geometry is only visible in the spreadsheet.
Viewport visualization will be added separately.
There are a couple of benefits of using a viewer node compared
to the old approach with the icon in the node header:
* Better support for nodes that have more than one geometry output.
* It's more consistent with the compositor.
* If attributes become decoupled from geometry in the future,
the viewer can have a separate input for the attribute to visualize.
* The viewer node could potentially have visualization settings.
* Allows to keep "visualization points" around by having multiple
viewer nodes.
* Less visual clutter in node headers.
Differential Revision: https://developer.blender.org/D11470
This patch fixes many minor spelling mistakes, all in comments or
console output. Mostly contractions like can't, won't, don't, its/it's,
etc.
Differential Revision: https://developer.blender.org/D11663
Reviewed by Harley Acheson
This just moves a couple of files in `space_node` to C++ and fixes
related errors.
The goal is to be able to use C++ data structures to simplify the code.
Differential Revision: https://developer.blender.org/D11451
