Files
test/source/blender/editors/space_node/node_select.cc

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

1416 lines
40 KiB
C++
Raw Normal View History

/* SPDX-FileCopyrightText: 2008 Blender Authors
*
* SPDX-License-Identifier: GPL-2.0-or-later */
/** \file
* \ingroup spnode
2011-02-27 20:29:51 +00:00
*/
#include <array>
#include <cstdlib>
#include <fmt/format.h>
#include "DNA_node_types.h"
#include "DNA_windowmanager_types.h"
#include "BLI_lasso_2d.hh"
#include "BLI_listbase.h"
#include "BLI_math_vector.h"
#include "BLI_rect.h"
#include "BLI_string.h"
#include "BLI_string_utf8.h"
#include "BLI_utildefines.h"
#include "BKE_context.hh"
#include "BKE_main.hh"
#include "BKE_main_invariants.hh"
#include "BKE_node.hh"
#include "BKE_node_legacy_types.hh"
#include "BKE_node_runtime.hh"
#include "BKE_node_tree_update.hh"
#include "BKE_viewer_path.hh"
2024-04-12 17:03:18 -04:00
#include "BKE_workspace.hh"
#include "ED_node.hh" /* own include */
#include "ED_screen.hh"
#include "ED_select_utils.hh"
#include "ED_view3d.hh"
Geometry Nodes: viewport preview This adds support for showing geometry passed to the Viewer in the 3d viewport (instead of just in the spreadsheet). The "viewer geometry" bypasses the group output. So it is not necessary to change the final output of the node group to be able to see the intermediate geometry. **Activation and deactivation of a viewer node** * A viewer node is activated by clicking on it. * Ctrl+shift+click on any node/socket connects it to the viewer and makes it active. * Ctrl+shift+click in empty space deactivates the active viewer. * When the active viewer is not visible anymore (e.g. another object is selected, or the current node group is exit), it is deactivated. * Clicking on the icon in the header of the Viewer node toggles whether its active or not. **Pinning** * The spreadsheet still allows pinning the active viewer as before. When pinned, the spreadsheet still references the viewer node even when it becomes inactive. * The viewport does not support pinning at the moment. It always shows the active viewer. **Attribute** * When a field is linked to the second input of the viewer node it is displayed as an overlay in the viewport. * When possible the correct domain for the attribute is determined automatically. This does not work in all cases. It falls back to the face corner domain on meshes and the point domain on curves. When necessary, the domain can be picked manually. * The spreadsheet now only shows the "Viewer" column for the domain that is selected in the Viewer node. * Instance attributes are visualized as a constant color per instance. **Viewport Options** * The attribute overlay opacity can be controlled with the "Viewer Node" setting in the overlays popover. * A viewport can be configured not to show intermediate viewer-geometry by disabling the "Viewer Node" option in the "View" menu. **Implementation Details** * The "spreadsheet context path" was generalized to a "viewer path" that is used in more places now. * The viewer node itself determines the attribute domain, evaluates the field and stores the result in a `.viewer` attribute. * A new "viewer attribute' overlay displays the data from the `.viewer` attribute. * The ground truth for the active viewer node is stored in the workspace now. Node editors, spreadsheets and viewports retrieve the active viewer from there unless they are pinned. * The depsgraph object iterator has a new "viewer path" setting. When set, the viewed geometry of the corresponding object is part of the iterator instead of the final evaluated geometry. * To support the instance attribute overlay `DupliObject` was extended to contain the information necessary for drawing the overlay. * The ctrl+shift+click operator has been refactored so that it can make existing links to viewers active again. * The auto-domain-detection in the Viewer node works by checking the "preferred domain" for every field input. If there is not exactly one preferred domain, the fallback is used. Known limitations: * Loose edges of meshes don't have the attribute overlay. This could be added separately if necessary. * Some attributes are hard to visualize as a color directly. For example, the values might have to be normalized or some should be drawn as arrays. For now, we encourage users to build node groups that generate appropriate viewer-geometry. We might include some of that functionality in future versions. Support for displaying attribute values as text in the viewport is planned as well. * There seems to be an issue with the attribute overlay for pointclouds on nvidia gpus, to be investigated. Differential Revision: https://developer.blender.org/D15954
2022-09-28 17:54:59 +02:00
#include "ED_viewer_path.hh"
#include "RNA_access.hh"
#include "RNA_define.hh"
#include "WM_api.hh"
#include "WM_types.hh"
#include "UI_interface.hh"
#include "UI_resources.hh"
UI: show recently selected items at the top of searches The goal is to make the search faster to use by dynamically adapting to the user. This can be achieved using the simple but common approach of showing recently selected items at the top. Note, that the "matching score" between the query and each search item still has precedence when determining the order. So the last used item is only at the top, if there is no other search item that matches the query better. Besides making the search generally faster to use, my hope is that this can also reduce the need for manually weighting search items in some places. This is because while the ordering might not be perfect the first time, it will always be once the user selected the element that should be at the top once. This patch includes: * Support for taking recent searches into account in string searching. * Keep track of a global list of recent searches. * Store recent searches on disk similar to recently opened files. * A new setting in the user preferences that allows disabling the functionality. This can be used if deterministic key strokes are required, e.g. for automated tests. In the future this could be improved in different ways: * Add some kind of separator in the search list to indicate which elements are at the top because they have been used recently. * Store the recent search items per search, instead of in a global list. This way it could adapt to the user even better. Pull Request: https://projects.blender.org/blender/blender/pulls/110828
2023-09-25 10:56:12 +02:00
#include "UI_string_search.hh"
#include "UI_view2d.hh"
#include "DEG_depsgraph.hh"
#include "node_intern.hh" /* own include */
namespace blender::ed::space_node {
static bool is_event_over_node_or_socket(const bContext &C, const wmEvent &event);
/**
* Function to detect if there is a visible view3d that uses workbench in texture mode.
* This function is for fixing #76970 for Blender 2.83. The actual fix should add a mechanism in
* the depsgraph that can be used by the draw engines to check if they need to be redrawn.
*
* We don't want to add these risky changes this close before releasing 2.83 without good testing
* hence this workaround. There are still cases were too many updates happen. For example when you
* have both a Cycles and workbench with textures viewport.
*/
static bool has_workbench_in_texture_color(const wmWindowManager *wm,
const Scene *scene,
const Object *ob)
{
LISTBASE_FOREACH (wmWindow *, win, &wm->windows) {
if (win->scene != scene) {
continue;
}
const bScreen *screen = BKE_workspace_active_screen_get(win->workspace_hook);
LISTBASE_FOREACH (ScrArea *, area, &screen->areabase) {
if (area->spacetype == SPACE_VIEW3D) {
const View3D *v3d = (const View3D *)area->spacedata.first;
if (ED_view3d_has_workbench_in_texture_color(scene, ob, v3d)) {
return true;
}
}
}
}
return false;
}
/* -------------------------------------------------------------------- */
/** \name Public Node Selection API
* \{ */
rctf node_frame_rect_inside(const SpaceNode &snode, const bNode &node)
{
const float margin = 4.0f * NODE_RESIZE_MARGIN * math::max(snode.runtime->aspect, 1.0f);
rctf frame_inside = {
node.runtime->draw_bounds.xmin,
node.runtime->draw_bounds.xmax,
node.runtime->draw_bounds.ymin,
node.runtime->draw_bounds.ymax,
};
BLI_rctf_pad(&frame_inside, -margin, -margin);
return frame_inside;
}
bool node_or_socket_isect_event(const bContext &C, const wmEvent &event)
{
return is_event_over_node_or_socket(C, event);
}
static bool node_frame_select_isect_mouse(const SpaceNode &snode,
const bNode &node,
const float2 &mouse)
{
/* Frame nodes are selectable by their borders (including their whole rect - as for other nodes -
* would prevent e.g. box selection of nodes inside that frame). */
const rctf frame_inside = node_frame_rect_inside(snode, node);
if (BLI_rctf_isect_pt(&node.runtime->draw_bounds, mouse.x, mouse.y) &&
!BLI_rctf_isect_pt(&frame_inside, mouse.x, mouse.y))
{
return true;
}
return false;
}
static bNode *node_under_mouse_select(const SpaceNode &snode, const float2 mouse)
{
for (bNode *node : tree_draw_order_calc_nodes_reversed(*snode.edittree)) {
switch (node->type_legacy) {
case NODE_FRAME: {
if (node_frame_select_isect_mouse(snode, *node, mouse)) {
return node;
}
break;
}
default: {
if (BLI_rctf_isect_pt(&node->runtime->draw_bounds, int(mouse.x), int(mouse.y))) {
return node;
}
break;
}
}
}
return nullptr;
}
static bool is_position_over_node_or_socket(SpaceNode &snode, ARegion &region, const float2 &mouse)
{
if (node_under_mouse_select(snode, mouse)) {
return true;
}
if (node_find_indicated_socket(snode, region, mouse, SOCK_IN | SOCK_OUT)) {
return true;
}
return false;
}
static bool is_event_over_node_or_socket(const bContext &C, const wmEvent &event)
{
SpaceNode &snode = *CTX_wm_space_node(&C);
ARegion &region = *CTX_wm_region(&C);
int2 mval;
WM_event_drag_start_mval(&event, &region, mval);
float2 mouse;
UI_view2d_region_to_view(&region.v2d, mval.x, mval.y, &mouse.x, &mouse.y);
return is_position_over_node_or_socket(snode, region, mouse);
}
void node_socket_select(bNode *node, bNodeSocket &sock)
{
sock.flag |= SELECT;
/* select node too */
if (node) {
node->flag |= SELECT;
}
}
void node_socket_deselect(bNode *node, bNodeSocket &sock, const bool deselect_node)
{
sock.flag &= ~SELECT;
if (node && deselect_node) {
bool sel = false;
/* if no selected sockets remain, also deselect the node */
LISTBASE_FOREACH (bNodeSocket *, input, &node->inputs) {
if (input->flag & SELECT) {
sel = true;
break;
}
}
LISTBASE_FOREACH (bNodeSocket *, output, &node->outputs) {
if (output->flag & SELECT) {
sel = true;
break;
}
}
if (!sel) {
node->flag &= ~SELECT;
}
}
}
static void node_socket_toggle(bNode *node, bNodeSocket &sock, bool deselect_node)
{
if (sock.flag & SELECT) {
node_socket_deselect(node, sock, deselect_node);
}
else {
node_socket_select(node, sock);
}
}
bool node_deselect_all(bNodeTree &node_tree)
{
bool changed = false;
for (bNode *node : node_tree.all_nodes()) {
changed |= bke::node_set_selected(*node, false);
}
return changed;
}
void node_deselect_all_input_sockets(bNodeTree &node_tree, const bool deselect_nodes)
{
/* XXX not calling node_socket_deselect here each time, because this does iteration
* over all node sockets internally to check if the node stays selected.
* We can do that more efficiently here.
*/
for (bNode *node : node_tree.all_nodes()) {
2021-12-03 16:33:14 -05:00
bool sel = false;
2021-12-03 16:33:14 -05:00
LISTBASE_FOREACH (bNodeSocket *, socket, &node->inputs) {
socket->flag &= ~SELECT;
}
/* If no selected sockets remain, also deselect the node. */
if (deselect_nodes) {
2021-12-03 16:33:14 -05:00
LISTBASE_FOREACH (bNodeSocket *, socket, &node->outputs) {
if (socket->flag & SELECT) {
sel = true;
break;
}
}
if (!sel) {
node->flag &= ~SELECT;
}
}
}
}
void node_deselect_all_output_sockets(bNodeTree &node_tree, const bool deselect_nodes)
{
/* XXX not calling node_socket_deselect here each time, because this does iteration
* over all node sockets internally to check if the node stays selected.
* We can do that more efficiently here.
*/
for (bNode *node : node_tree.all_nodes()) {
2014-02-03 18:55:59 +11:00
bool sel = false;
2021-12-03 16:33:14 -05:00
LISTBASE_FOREACH (bNodeSocket *, socket, &node->outputs) {
socket->flag &= ~SELECT;
}
/* if no selected sockets remain, also deselect the node */
if (deselect_nodes) {
2021-12-03 16:33:14 -05:00
LISTBASE_FOREACH (bNodeSocket *, socket, &node->inputs) {
if (socket->flag & SELECT) {
sel = true;
break;
}
}
if (!sel) {
node->flag &= ~SELECT;
}
}
}
}
Geometry Nodes: add simulation support This adds support for building simulations with geometry nodes. A new `Simulation Input` and `Simulation Output` node allow maintaining a simulation state across multiple frames. Together these two nodes form a `simulation zone` which contains all the nodes that update the simulation state from one frame to the next. A new simulation zone can be added via the menu (`Simulation > Simulation Zone`) or with the node add search. The simulation state contains a geometry by default. However, it is possible to add multiple geometry sockets as well as other socket types. Currently, field inputs are evaluated and stored for the preceding geometry socket in the order that the sockets are shown. Simulation state items can be added by linking one of the empty sockets to something else. In the sidebar, there is a new panel that allows adding, removing and reordering these sockets. The simulation nodes behave as follows: * On the first frame, the inputs of the `Simulation Input` node are evaluated to initialize the simulation state. In later frames these sockets are not evaluated anymore. The `Delta Time` at the first frame is zero, but the simulation zone is still evaluated. * On every next frame, the `Simulation Input` node outputs the simulation state of the previous frame. Nodes in the simulation zone can edit that data in arbitrary ways, also taking into account the `Delta Time`. The new simulation state has to be passed to the `Simulation Output` node where it is cached and forwarded. * On a frame that is already cached or baked, the nodes in the simulation zone are not evaluated, because the `Simulation Output` node can return the previously cached data directly. It is not allowed to connect sockets from inside the simulation zone to the outside without going through the `Simulation Output` node. This is a necessary restriction to make caching and sub-frame interpolation work. Links can go into the simulation zone without problems though. Anonymous attributes are not propagated by the simulation nodes unless they are explicitly stored in the simulation state. This is unfortunate, but currently there is no practical and reliable alternative. The core problem is detecting which anonymous attributes will be required for the simulation and afterwards. While we can detect this for the current evaluation, we can't look into the future in time to see what data will be necessary. We intend to make it easier to explicitly pass data through a simulation in the future, even if the simulation is in a nested node group. There is a new `Simulation Nodes` panel in the physics tab in the properties editor. It allows baking all simulation zones on the selected objects. The baking options are intentially kept at a minimum for this MVP. More features for simulation baking as well as baking in general can be expected to be added separately. All baked data is stored on disk in a folder next to the .blend file. #106937 describes how baking is implemented in more detail. Volumes can not be baked yet and materials are lost during baking for now. Packing the baked data into the .blend file is not yet supported. The timeline indicates which frames are currently cached, baked or cached but invalidated by user-changes. Simulation input and output nodes are internally linked together by their `bNode.identifier` which stays the same even if the node name changes. They are generally added and removed together. However, there are still cases where "dangling" simulation nodes can be created currently. Those generally don't cause harm, but would be nice to avoid this in more cases in the future. Co-authored-by: Hans Goudey <h.goudey@me.com> Co-authored-by: Lukas Tönne <lukas@blender.org> Pull Request: https://projects.blender.org/blender/blender/pulls/104924
2023-05-03 13:18:51 +02:00
void node_select_paired(bNodeTree &node_tree)
{
node_tree.ensure_topology_cache();
for (const bke::bNodeZoneType *zone_type : bke::all_zone_types()) {
for (bNode *input_node : node_tree.nodes_by_type(zone_type->input_idname)) {
if (bNode *output_node = zone_type->get_corresponding_output(node_tree, *input_node)) {
if (input_node->flag & NODE_SELECT) {
output_node->flag |= NODE_SELECT;
}
if (output_node->flag & NODE_SELECT) {
input_node->flag |= NODE_SELECT;
}
Geometry Nodes: new Repeat Zone This adds support for running a set of nodes repeatedly. The number of iterations can be controlled dynamically as an input of the repeat zone. The repeat zone can be added in via the search or from the Add > Utilities menu. The main use case is to replace long repetitive node chains with a more flexible alternative. Technically, repeat zones can also be used for many other use cases. However, due to their serial nature, performance is very sub-optimal when they are used to solve problems that could be processed in parallel. Better solutions for such use cases will be worked on separately. Repeat zones are similar to simulation zones. The major difference is that they have no concept of time and are always evaluated entirely in the current frame, while in simulations only a single iteration is evaluated per frame. Stopping the repetition early using a dynamic condition is not yet supported. "Break" functionality can be implemented manually using Switch nodes in the loop for now. It's likely that this functionality will be built into the repeat zone in the future. For now, things are kept more simple. Remaining Todos after this first version: * Improve socket inspection and viewer node support. Currently, only the first iteration is taken into account for socket inspection and the viewer. * Make loop evaluation more lazy. Currently, the evaluation is eager, meaning that it evaluates some nodes even though their output may not be required. Pull Request: https://projects.blender.org/blender/blender/pulls/109164
2023-07-11 22:36:10 +02:00
}
}
}
Geometry Nodes: add simulation support This adds support for building simulations with geometry nodes. A new `Simulation Input` and `Simulation Output` node allow maintaining a simulation state across multiple frames. Together these two nodes form a `simulation zone` which contains all the nodes that update the simulation state from one frame to the next. A new simulation zone can be added via the menu (`Simulation > Simulation Zone`) or with the node add search. The simulation state contains a geometry by default. However, it is possible to add multiple geometry sockets as well as other socket types. Currently, field inputs are evaluated and stored for the preceding geometry socket in the order that the sockets are shown. Simulation state items can be added by linking one of the empty sockets to something else. In the sidebar, there is a new panel that allows adding, removing and reordering these sockets. The simulation nodes behave as follows: * On the first frame, the inputs of the `Simulation Input` node are evaluated to initialize the simulation state. In later frames these sockets are not evaluated anymore. The `Delta Time` at the first frame is zero, but the simulation zone is still evaluated. * On every next frame, the `Simulation Input` node outputs the simulation state of the previous frame. Nodes in the simulation zone can edit that data in arbitrary ways, also taking into account the `Delta Time`. The new simulation state has to be passed to the `Simulation Output` node where it is cached and forwarded. * On a frame that is already cached or baked, the nodes in the simulation zone are not evaluated, because the `Simulation Output` node can return the previously cached data directly. It is not allowed to connect sockets from inside the simulation zone to the outside without going through the `Simulation Output` node. This is a necessary restriction to make caching and sub-frame interpolation work. Links can go into the simulation zone without problems though. Anonymous attributes are not propagated by the simulation nodes unless they are explicitly stored in the simulation state. This is unfortunate, but currently there is no practical and reliable alternative. The core problem is detecting which anonymous attributes will be required for the simulation and afterwards. While we can detect this for the current evaluation, we can't look into the future in time to see what data will be necessary. We intend to make it easier to explicitly pass data through a simulation in the future, even if the simulation is in a nested node group. There is a new `Simulation Nodes` panel in the physics tab in the properties editor. It allows baking all simulation zones on the selected objects. The baking options are intentially kept at a minimum for this MVP. More features for simulation baking as well as baking in general can be expected to be added separately. All baked data is stored on disk in a folder next to the .blend file. #106937 describes how baking is implemented in more detail. Volumes can not be baked yet and materials are lost during baking for now. Packing the baked data into the .blend file is not yet supported. The timeline indicates which frames are currently cached, baked or cached but invalidated by user-changes. Simulation input and output nodes are internally linked together by their `bNode.identifier` which stays the same even if the node name changes. They are generally added and removed together. However, there are still cases where "dangling" simulation nodes can be created currently. Those generally don't cause harm, but would be nice to avoid this in more cases in the future. Co-authored-by: Hans Goudey <h.goudey@me.com> Co-authored-by: Lukas Tönne <lukas@blender.org> Pull Request: https://projects.blender.org/blender/blender/pulls/104924
2023-05-03 13:18:51 +02:00
}
VectorSet<bNode *> get_selected_nodes(bNodeTree &node_tree)
{
VectorSet<bNode *> selected_nodes;
for (bNode *node : node_tree.all_nodes()) {
if (node->flag & NODE_SELECT) {
selected_nodes.add(node);
}
}
return selected_nodes;
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Select Grouped Operator
* \{ */
/* Return true if we need redraw, otherwise false. */
static bool node_select_grouped_type(bNodeTree &node_tree, bNode &node_act)
{
bool changed = false;
for (bNode *node : node_tree.all_nodes()) {
if ((node->flag & SELECT) == 0) {
if (node->type_legacy == node_act.type_legacy) {
bke::node_set_selected(*node, true);
changed = true;
}
}
}
return changed;
}
static bool node_select_grouped_color(bNodeTree &node_tree, bNode &node_act)
{
bool changed = false;
for (bNode *node : node_tree.all_nodes()) {
if ((node->flag & SELECT) == 0) {
if (compare_v3v3(node->color, node_act.color, 0.005f)) {
bke::node_set_selected(*node, true);
changed = true;
}
}
}
return changed;
}
static bool node_select_grouped_name(bNodeTree &node_tree, bNode &node_act, const bool from_right)
{
bool changed = false;
const uint delims[] = {'.', '-', '_', '\0'};
size_t pref_len_act, pref_len_curr;
const char *sep, *suf_act, *suf_curr;
pref_len_act = BLI_str_partition_ex_utf8(
node_act.name, nullptr, delims, &sep, &suf_act, from_right);
/* NOTE: in case we are searching for suffix, and found none, use whole name as suffix. */
if (from_right && !(sep && suf_act)) {
pref_len_act = 0;
suf_act = node_act.name;
}
for (bNode *node : node_tree.all_nodes()) {
if (node->flag & SELECT) {
continue;
}
pref_len_curr = BLI_str_partition_ex_utf8(
node->name, nullptr, delims, &sep, &suf_curr, from_right);
/* Same as with active node name! */
if (from_right && !(sep && suf_curr)) {
pref_len_curr = 0;
suf_curr = node->name;
}
if ((from_right && STREQ(suf_act, suf_curr)) ||
(!from_right && (pref_len_act == pref_len_curr) &&
STREQLEN(node_act.name, node->name, pref_len_act)))
{
bke::node_set_selected(*node, true);
changed = true;
}
}
return changed;
}
enum {
NODE_SELECT_GROUPED_TYPE = 0,
NODE_SELECT_GROUPED_COLOR = 1,
NODE_SELECT_GROUPED_PREFIX = 2,
NODE_SELECT_GROUPED_SUFIX = 3,
};
static wmOperatorStatus node_select_grouped_exec(bContext *C, wmOperator *op)
{
SpaceNode &snode = *CTX_wm_space_node(C);
bNodeTree &node_tree = *snode.edittree;
bNode *node_act = bke::node_get_active(*snode.edittree);
if (node_act == nullptr) {
return OPERATOR_CANCELLED;
}
bool changed = false;
const bool extend = RNA_boolean_get(op->ptr, "extend");
const int type = RNA_enum_get(op->ptr, "type");
if (!extend) {
node_deselect_all(node_tree);
}
bke::node_set_selected(*node_act, true);
switch (type) {
case NODE_SELECT_GROUPED_TYPE:
changed = node_select_grouped_type(node_tree, *node_act);
break;
case NODE_SELECT_GROUPED_COLOR:
changed = node_select_grouped_color(node_tree, *node_act);
break;
case NODE_SELECT_GROUPED_PREFIX:
changed = node_select_grouped_name(node_tree, *node_act, false);
break;
case NODE_SELECT_GROUPED_SUFIX:
changed = node_select_grouped_name(node_tree, *node_act, true);
break;
default:
break;
}
if (changed) {
tree_draw_order_update(node_tree);
WM_event_add_notifier(C, NC_NODE | NA_SELECTED, nullptr);
return OPERATOR_FINISHED;
}
return OPERATOR_CANCELLED;
}
void NODE_OT_select_grouped(wmOperatorType *ot)
{
PropertyRNA *prop;
static const EnumPropertyItem prop_select_grouped_types[] = {
{NODE_SELECT_GROUPED_TYPE, "TYPE", 0, "Type", ""},
{NODE_SELECT_GROUPED_COLOR, "COLOR", 0, "Color", ""},
{NODE_SELECT_GROUPED_PREFIX, "PREFIX", 0, "Prefix", ""},
{NODE_SELECT_GROUPED_SUFIX, "SUFFIX", 0, "Suffix", ""},
{0, nullptr, 0, nullptr, nullptr},
};
/* identifiers */
ot->name = "Select Grouped";
ot->description = "Select nodes with similar properties";
ot->idname = "NODE_OT_select_grouped";
/* API callbacks. */
ot->invoke = WM_menu_invoke;
ot->exec = node_select_grouped_exec;
ot->poll = ED_operator_node_active;
/* flags */
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
/* properties */
prop = RNA_def_boolean(ot->srna,
"extend",
false,
"Extend",
"Extend selection instead of deselecting everything first");
RNA_def_property_flag(prop, PROP_SKIP_SAVE);
ot->prop = RNA_def_enum(ot->srna, "type", prop_select_grouped_types, 0, "Type", "");
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Select (Cursor Pick) Operator
* \{ */
void node_select_single(bContext &C, bNode &node)
{
Main *bmain = CTX_data_main(&C);
SpaceNode &snode = *CTX_wm_space_node(&C);
bNodeTree &node_tree = *snode.edittree;
const Object *ob = CTX_data_active_object(&C);
const Scene *scene = CTX_data_scene(&C);
const wmWindowManager *wm = CTX_wm_manager(&C);
bool active_texture_changed = false;
for (bNode *node_iter : node_tree.all_nodes()) {
if (node_iter != &node) {
bke::node_set_selected(*node_iter, false);
}
}
bke::node_set_selected(node, true);
ED_node_set_active(bmain, &snode, &node_tree, &node, &active_texture_changed);
ED_node_set_active_viewer_key(&snode);
tree_draw_order_update(node_tree);
if (active_texture_changed && has_workbench_in_texture_color(wm, scene, ob)) {
DEG_id_tag_update(&node_tree.id, ID_RECALC_SYNC_TO_EVAL);
}
WM_event_add_notifier(&C, NC_NODE | NA_SELECTED, nullptr);
}
Fix T96520 Node editor: Tweak fails with unselected nodes Use the same method for node selection and dragging that is used in the 3D viewport and UV editor. Instead of relying on a modal operator - use the keymap to handle click/drag events. Details: Failure to transform unselected nodes was caused by [0] & [1] however detecting drag relied on specific behavior which I don't think we should be depending on. This error happened when selection was defined both in the key-map for the tool and for the node-editor. - The left mouse button would activate selection in both the tool and "Node Editor" keymap. - The first selection would return `FINISHED | PASS_THROUGH` when selecting a previously unselected node. - The same PRESS would trigger a second selection would return `RUNNING_MODAL | PASS_THROUGH`, (starting a NODE_OT_select as a modal operator). - In 3.1 (with tweak events) the modal operator would then exit and fall-back to the tweak event which would transform the selected nodes. - In 3.2 (as of [0]) the PRESS that starts the modal operator is considered "handled" and prevents drag event from being detected. The correct behavior in this case isn't obvious: If a modal operator starts on pressing a button, using that same the release to generate drag/click events is disputable. Even in the case or 3.1 it was inconsistent as tweak events were generated but click events weren't. Note: after investigating this bug it turns out a similar issue already existed in 2.91 and all releases afterwards. While the bug is more obscure, it's also caused by the tweak event being interrupted as described here, this commit resolves T81824 as well. [0]: 4d0f846b936c9101ecb76a6db962aac2d74a460a [1]: 4986f718482b061082936f1f6aa13929741093a2 Reviewed By: Severin Ref D14499
2022-05-10 22:57:00 +10:00
static bool node_mouse_select(bContext *C,
wmOperator *op,
const int2 mval,
const SelectPick_Params &params)
{
Main &bmain = *CTX_data_main(C);
SpaceNode &snode = *CTX_wm_space_node(C);
bNodeTree &node_tree = *snode.edittree;
ARegion &region = *CTX_wm_region(C);
const Object *ob = CTX_data_active_object(C);
const Scene *scene = CTX_data_scene(C);
const wmWindowManager *wm = CTX_wm_manager(C);
bNode *node = nullptr;
bNodeSocket *sock = nullptr;
/* Always do socket_select when extending selection. */
const bool socket_select = (params.sel_op == SEL_OP_XOR) ||
Fix T96520 Node editor: Tweak fails with unselected nodes Use the same method for node selection and dragging that is used in the 3D viewport and UV editor. Instead of relying on a modal operator - use the keymap to handle click/drag events. Details: Failure to transform unselected nodes was caused by [0] & [1] however detecting drag relied on specific behavior which I don't think we should be depending on. This error happened when selection was defined both in the key-map for the tool and for the node-editor. - The left mouse button would activate selection in both the tool and "Node Editor" keymap. - The first selection would return `FINISHED | PASS_THROUGH` when selecting a previously unselected node. - The same PRESS would trigger a second selection would return `RUNNING_MODAL | PASS_THROUGH`, (starting a NODE_OT_select as a modal operator). - In 3.1 (with tweak events) the modal operator would then exit and fall-back to the tweak event which would transform the selected nodes. - In 3.2 (as of [0]) the PRESS that starts the modal operator is considered "handled" and prevents drag event from being detected. The correct behavior in this case isn't obvious: If a modal operator starts on pressing a button, using that same the release to generate drag/click events is disputable. Even in the case or 3.1 it was inconsistent as tweak events were generated but click events weren't. Note: after investigating this bug it turns out a similar issue already existed in 2.91 and all releases afterwards. While the bug is more obscure, it's also caused by the tweak event being interrupted as described here, this commit resolves T81824 as well. [0]: 4d0f846b936c9101ecb76a6db962aac2d74a460a [1]: 4986f718482b061082936f1f6aa13929741093a2 Reviewed By: Severin Ref D14499
2022-05-10 22:57:00 +10:00
RNA_boolean_get(op->ptr, "socket_select");
bool changed = false;
bool found = false;
bool node_was_selected = false;
/* Get mouse coordinates in view2d space. */
float2 cursor;
UI_view2d_region_to_view(&region.v2d, mval.x, mval.y, &cursor.x, &cursor.y);
/* First do socket selection, these generally overlap with nodes. */
if (socket_select) {
Fix T96520 Node editor: Tweak fails with unselected nodes Use the same method for node selection and dragging that is used in the 3D viewport and UV editor. Instead of relying on a modal operator - use the keymap to handle click/drag events. Details: Failure to transform unselected nodes was caused by [0] & [1] however detecting drag relied on specific behavior which I don't think we should be depending on. This error happened when selection was defined both in the key-map for the tool and for the node-editor. - The left mouse button would activate selection in both the tool and "Node Editor" keymap. - The first selection would return `FINISHED | PASS_THROUGH` when selecting a previously unselected node. - The same PRESS would trigger a second selection would return `RUNNING_MODAL | PASS_THROUGH`, (starting a NODE_OT_select as a modal operator). - In 3.1 (with tweak events) the modal operator would then exit and fall-back to the tweak event which would transform the selected nodes. - In 3.2 (as of [0]) the PRESS that starts the modal operator is considered "handled" and prevents drag event from being detected. The correct behavior in this case isn't obvious: If a modal operator starts on pressing a button, using that same the release to generate drag/click events is disputable. Even in the case or 3.1 it was inconsistent as tweak events were generated but click events weren't. Note: after investigating this bug it turns out a similar issue already existed in 2.91 and all releases afterwards. While the bug is more obscure, it's also caused by the tweak event being interrupted as described here, this commit resolves T81824 as well. [0]: 4d0f846b936c9101ecb76a6db962aac2d74a460a [1]: 4986f718482b061082936f1f6aa13929741093a2 Reviewed By: Severin Ref D14499
2022-05-10 22:57:00 +10:00
/* NOTE: unlike nodes #SelectPick_Params isn't fully supported. */
const bool extend = (params.sel_op == SEL_OP_XOR);
sock = node_find_indicated_socket(snode, region, cursor, SOCK_IN);
if (sock) {
node = &sock->owner_node();
Fix T96520 Node editor: Tweak fails with unselected nodes Use the same method for node selection and dragging that is used in the 3D viewport and UV editor. Instead of relying on a modal operator - use the keymap to handle click/drag events. Details: Failure to transform unselected nodes was caused by [0] & [1] however detecting drag relied on specific behavior which I don't think we should be depending on. This error happened when selection was defined both in the key-map for the tool and for the node-editor. - The left mouse button would activate selection in both the tool and "Node Editor" keymap. - The first selection would return `FINISHED | PASS_THROUGH` when selecting a previously unselected node. - The same PRESS would trigger a second selection would return `RUNNING_MODAL | PASS_THROUGH`, (starting a NODE_OT_select as a modal operator). - In 3.1 (with tweak events) the modal operator would then exit and fall-back to the tweak event which would transform the selected nodes. - In 3.2 (as of [0]) the PRESS that starts the modal operator is considered "handled" and prevents drag event from being detected. The correct behavior in this case isn't obvious: If a modal operator starts on pressing a button, using that same the release to generate drag/click events is disputable. Even in the case or 3.1 it was inconsistent as tweak events were generated but click events weren't. Note: after investigating this bug it turns out a similar issue already existed in 2.91 and all releases afterwards. While the bug is more obscure, it's also caused by the tweak event being interrupted as described here, this commit resolves T81824 as well. [0]: 4d0f846b936c9101ecb76a6db962aac2d74a460a [1]: 4986f718482b061082936f1f6aa13929741093a2 Reviewed By: Severin Ref D14499
2022-05-10 22:57:00 +10:00
found = true;
node_was_selected = node->flag & SELECT;
/* NOTE: SOCK_IN does not take into account the extend case...
* This feature is not really used anyway currently? */
node_socket_toggle(node, *sock, true);
Fix T96520 Node editor: Tweak fails with unselected nodes Use the same method for node selection and dragging that is used in the 3D viewport and UV editor. Instead of relying on a modal operator - use the keymap to handle click/drag events. Details: Failure to transform unselected nodes was caused by [0] & [1] however detecting drag relied on specific behavior which I don't think we should be depending on. This error happened when selection was defined both in the key-map for the tool and for the node-editor. - The left mouse button would activate selection in both the tool and "Node Editor" keymap. - The first selection would return `FINISHED | PASS_THROUGH` when selecting a previously unselected node. - The same PRESS would trigger a second selection would return `RUNNING_MODAL | PASS_THROUGH`, (starting a NODE_OT_select as a modal operator). - In 3.1 (with tweak events) the modal operator would then exit and fall-back to the tweak event which would transform the selected nodes. - In 3.2 (as of [0]) the PRESS that starts the modal operator is considered "handled" and prevents drag event from being detected. The correct behavior in this case isn't obvious: If a modal operator starts on pressing a button, using that same the release to generate drag/click events is disputable. Even in the case or 3.1 it was inconsistent as tweak events were generated but click events weren't. Note: after investigating this bug it turns out a similar issue already existed in 2.91 and all releases afterwards. While the bug is more obscure, it's also caused by the tweak event being interrupted as described here, this commit resolves T81824 as well. [0]: 4d0f846b936c9101ecb76a6db962aac2d74a460a [1]: 4986f718482b061082936f1f6aa13929741093a2 Reviewed By: Severin Ref D14499
2022-05-10 22:57:00 +10:00
changed = true;
}
if (!changed) {
sock = node_find_indicated_socket(snode, region, cursor, SOCK_OUT);
if (sock) {
node = &sock->owner_node();
found = true;
node_was_selected = node->flag & SELECT;
if (sock->flag & SELECT) {
if (extend) {
node_socket_deselect(node, *sock, true);
changed = true;
}
}
else {
/* Only allow one selected output per node, for sensible linking.
* Allow selecting outputs from different nodes though, if extend is true. */
for (bNodeSocket *tsock : node->output_sockets()) {
if (tsock == sock) {
continue;
}
node_socket_deselect(node, *tsock, true);
Fix T96520 Node editor: Tweak fails with unselected nodes Use the same method for node selection and dragging that is used in the 3D viewport and UV editor. Instead of relying on a modal operator - use the keymap to handle click/drag events. Details: Failure to transform unselected nodes was caused by [0] & [1] however detecting drag relied on specific behavior which I don't think we should be depending on. This error happened when selection was defined both in the key-map for the tool and for the node-editor. - The left mouse button would activate selection in both the tool and "Node Editor" keymap. - The first selection would return `FINISHED | PASS_THROUGH` when selecting a previously unselected node. - The same PRESS would trigger a second selection would return `RUNNING_MODAL | PASS_THROUGH`, (starting a NODE_OT_select as a modal operator). - In 3.1 (with tweak events) the modal operator would then exit and fall-back to the tweak event which would transform the selected nodes. - In 3.2 (as of [0]) the PRESS that starts the modal operator is considered "handled" and prevents drag event from being detected. The correct behavior in this case isn't obvious: If a modal operator starts on pressing a button, using that same the release to generate drag/click events is disputable. Even in the case or 3.1 it was inconsistent as tweak events were generated but click events weren't. Note: after investigating this bug it turns out a similar issue already existed in 2.91 and all releases afterwards. While the bug is more obscure, it's also caused by the tweak event being interrupted as described here, this commit resolves T81824 as well. [0]: 4d0f846b936c9101ecb76a6db962aac2d74a460a [1]: 4986f718482b061082936f1f6aa13929741093a2 Reviewed By: Severin Ref D14499
2022-05-10 22:57:00 +10:00
changed = true;
}
if (!extend) {
for (bNode *tnode : node_tree.all_nodes()) {
if (tnode == node) {
continue;
}
for (bNodeSocket *tsock : tnode->output_sockets()) {
node_socket_deselect(tnode, *tsock, true);
changed = true;
}
}
}
node_socket_select(node, *sock);
changed = true;
}
}
}
}
if (!sock) {
Fix T96520 Node editor: Tweak fails with unselected nodes Use the same method for node selection and dragging that is used in the 3D viewport and UV editor. Instead of relying on a modal operator - use the keymap to handle click/drag events. Details: Failure to transform unselected nodes was caused by [0] & [1] however detecting drag relied on specific behavior which I don't think we should be depending on. This error happened when selection was defined both in the key-map for the tool and for the node-editor. - The left mouse button would activate selection in both the tool and "Node Editor" keymap. - The first selection would return `FINISHED | PASS_THROUGH` when selecting a previously unselected node. - The same PRESS would trigger a second selection would return `RUNNING_MODAL | PASS_THROUGH`, (starting a NODE_OT_select as a modal operator). - In 3.1 (with tweak events) the modal operator would then exit and fall-back to the tweak event which would transform the selected nodes. - In 3.2 (as of [0]) the PRESS that starts the modal operator is considered "handled" and prevents drag event from being detected. The correct behavior in this case isn't obvious: If a modal operator starts on pressing a button, using that same the release to generate drag/click events is disputable. Even in the case or 3.1 it was inconsistent as tweak events were generated but click events weren't. Note: after investigating this bug it turns out a similar issue already existed in 2.91 and all releases afterwards. While the bug is more obscure, it's also caused by the tweak event being interrupted as described here, this commit resolves T81824 as well. [0]: 4d0f846b936c9101ecb76a6db962aac2d74a460a [1]: 4986f718482b061082936f1f6aa13929741093a2 Reviewed By: Severin Ref D14499
2022-05-10 22:57:00 +10:00
/* Find the closest visible node. */
node = node_under_mouse_select(snode, cursor);
Fix T96520 Node editor: Tweak fails with unselected nodes Use the same method for node selection and dragging that is used in the 3D viewport and UV editor. Instead of relying on a modal operator - use the keymap to handle click/drag events. Details: Failure to transform unselected nodes was caused by [0] & [1] however detecting drag relied on specific behavior which I don't think we should be depending on. This error happened when selection was defined both in the key-map for the tool and for the node-editor. - The left mouse button would activate selection in both the tool and "Node Editor" keymap. - The first selection would return `FINISHED | PASS_THROUGH` when selecting a previously unselected node. - The same PRESS would trigger a second selection would return `RUNNING_MODAL | PASS_THROUGH`, (starting a NODE_OT_select as a modal operator). - In 3.1 (with tweak events) the modal operator would then exit and fall-back to the tweak event which would transform the selected nodes. - In 3.2 (as of [0]) the PRESS that starts the modal operator is considered "handled" and prevents drag event from being detected. The correct behavior in this case isn't obvious: If a modal operator starts on pressing a button, using that same the release to generate drag/click events is disputable. Even in the case or 3.1 it was inconsistent as tweak events were generated but click events weren't. Note: after investigating this bug it turns out a similar issue already existed in 2.91 and all releases afterwards. While the bug is more obscure, it's also caused by the tweak event being interrupted as described here, this commit resolves T81824 as well. [0]: 4d0f846b936c9101ecb76a6db962aac2d74a460a [1]: 4986f718482b061082936f1f6aa13929741093a2 Reviewed By: Severin Ref D14499
2022-05-10 22:57:00 +10:00
found = (node != nullptr);
node_was_selected = node && (node->flag & SELECT);
if (params.sel_op == SEL_OP_SET) {
if ((found && params.select_passthrough) && (node->flag & SELECT)) {
Fix T96520 Node editor: Tweak fails with unselected nodes Use the same method for node selection and dragging that is used in the 3D viewport and UV editor. Instead of relying on a modal operator - use the keymap to handle click/drag events. Details: Failure to transform unselected nodes was caused by [0] & [1] however detecting drag relied on specific behavior which I don't think we should be depending on. This error happened when selection was defined both in the key-map for the tool and for the node-editor. - The left mouse button would activate selection in both the tool and "Node Editor" keymap. - The first selection would return `FINISHED | PASS_THROUGH` when selecting a previously unselected node. - The same PRESS would trigger a second selection would return `RUNNING_MODAL | PASS_THROUGH`, (starting a NODE_OT_select as a modal operator). - In 3.1 (with tweak events) the modal operator would then exit and fall-back to the tweak event which would transform the selected nodes. - In 3.2 (as of [0]) the PRESS that starts the modal operator is considered "handled" and prevents drag event from being detected. The correct behavior in this case isn't obvious: If a modal operator starts on pressing a button, using that same the release to generate drag/click events is disputable. Even in the case or 3.1 it was inconsistent as tweak events were generated but click events weren't. Note: after investigating this bug it turns out a similar issue already existed in 2.91 and all releases afterwards. While the bug is more obscure, it's also caused by the tweak event being interrupted as described here, this commit resolves T81824 as well. [0]: 4d0f846b936c9101ecb76a6db962aac2d74a460a [1]: 4986f718482b061082936f1f6aa13929741093a2 Reviewed By: Severin Ref D14499
2022-05-10 22:57:00 +10:00
found = false;
}
else if (found || params.deselect_all) {
Fix T96520 Node editor: Tweak fails with unselected nodes Use the same method for node selection and dragging that is used in the 3D viewport and UV editor. Instead of relying on a modal operator - use the keymap to handle click/drag events. Details: Failure to transform unselected nodes was caused by [0] & [1] however detecting drag relied on specific behavior which I don't think we should be depending on. This error happened when selection was defined both in the key-map for the tool and for the node-editor. - The left mouse button would activate selection in both the tool and "Node Editor" keymap. - The first selection would return `FINISHED | PASS_THROUGH` when selecting a previously unselected node. - The same PRESS would trigger a second selection would return `RUNNING_MODAL | PASS_THROUGH`, (starting a NODE_OT_select as a modal operator). - In 3.1 (with tweak events) the modal operator would then exit and fall-back to the tweak event which would transform the selected nodes. - In 3.2 (as of [0]) the PRESS that starts the modal operator is considered "handled" and prevents drag event from being detected. The correct behavior in this case isn't obvious: If a modal operator starts on pressing a button, using that same the release to generate drag/click events is disputable. Even in the case or 3.1 it was inconsistent as tweak events were generated but click events weren't. Note: after investigating this bug it turns out a similar issue already existed in 2.91 and all releases afterwards. While the bug is more obscure, it's also caused by the tweak event being interrupted as described here, this commit resolves T81824 as well. [0]: 4d0f846b936c9101ecb76a6db962aac2d74a460a [1]: 4986f718482b061082936f1f6aa13929741093a2 Reviewed By: Severin Ref D14499
2022-05-10 22:57:00 +10:00
/* Deselect everything. */
changed = node_deselect_all(node_tree);
}
}
Fix T96520 Node editor: Tweak fails with unselected nodes Use the same method for node selection and dragging that is used in the 3D viewport and UV editor. Instead of relying on a modal operator - use the keymap to handle click/drag events. Details: Failure to transform unselected nodes was caused by [0] & [1] however detecting drag relied on specific behavior which I don't think we should be depending on. This error happened when selection was defined both in the key-map for the tool and for the node-editor. - The left mouse button would activate selection in both the tool and "Node Editor" keymap. - The first selection would return `FINISHED | PASS_THROUGH` when selecting a previously unselected node. - The same PRESS would trigger a second selection would return `RUNNING_MODAL | PASS_THROUGH`, (starting a NODE_OT_select as a modal operator). - In 3.1 (with tweak events) the modal operator would then exit and fall-back to the tweak event which would transform the selected nodes. - In 3.2 (as of [0]) the PRESS that starts the modal operator is considered "handled" and prevents drag event from being detected. The correct behavior in this case isn't obvious: If a modal operator starts on pressing a button, using that same the release to generate drag/click events is disputable. Even in the case or 3.1 it was inconsistent as tweak events were generated but click events weren't. Note: after investigating this bug it turns out a similar issue already existed in 2.91 and all releases afterwards. While the bug is more obscure, it's also caused by the tweak event being interrupted as described here, this commit resolves T81824 as well. [0]: 4d0f846b936c9101ecb76a6db962aac2d74a460a [1]: 4986f718482b061082936f1f6aa13929741093a2 Reviewed By: Severin Ref D14499
2022-05-10 22:57:00 +10:00
if (found) {
switch (params.sel_op) {
case SEL_OP_ADD:
bke::node_set_selected(*node, true);
Fix T96520 Node editor: Tweak fails with unselected nodes Use the same method for node selection and dragging that is used in the 3D viewport and UV editor. Instead of relying on a modal operator - use the keymap to handle click/drag events. Details: Failure to transform unselected nodes was caused by [0] & [1] however detecting drag relied on specific behavior which I don't think we should be depending on. This error happened when selection was defined both in the key-map for the tool and for the node-editor. - The left mouse button would activate selection in both the tool and "Node Editor" keymap. - The first selection would return `FINISHED | PASS_THROUGH` when selecting a previously unselected node. - The same PRESS would trigger a second selection would return `RUNNING_MODAL | PASS_THROUGH`, (starting a NODE_OT_select as a modal operator). - In 3.1 (with tweak events) the modal operator would then exit and fall-back to the tweak event which would transform the selected nodes. - In 3.2 (as of [0]) the PRESS that starts the modal operator is considered "handled" and prevents drag event from being detected. The correct behavior in this case isn't obvious: If a modal operator starts on pressing a button, using that same the release to generate drag/click events is disputable. Even in the case or 3.1 it was inconsistent as tweak events were generated but click events weren't. Note: after investigating this bug it turns out a similar issue already existed in 2.91 and all releases afterwards. While the bug is more obscure, it's also caused by the tweak event being interrupted as described here, this commit resolves T81824 as well. [0]: 4d0f846b936c9101ecb76a6db962aac2d74a460a [1]: 4986f718482b061082936f1f6aa13929741093a2 Reviewed By: Severin Ref D14499
2022-05-10 22:57:00 +10:00
break;
case SEL_OP_SUB:
bke::node_set_selected(*node, false);
Fix T96520 Node editor: Tweak fails with unselected nodes Use the same method for node selection and dragging that is used in the 3D viewport and UV editor. Instead of relying on a modal operator - use the keymap to handle click/drag events. Details: Failure to transform unselected nodes was caused by [0] & [1] however detecting drag relied on specific behavior which I don't think we should be depending on. This error happened when selection was defined both in the key-map for the tool and for the node-editor. - The left mouse button would activate selection in both the tool and "Node Editor" keymap. - The first selection would return `FINISHED | PASS_THROUGH` when selecting a previously unselected node. - The same PRESS would trigger a second selection would return `RUNNING_MODAL | PASS_THROUGH`, (starting a NODE_OT_select as a modal operator). - In 3.1 (with tweak events) the modal operator would then exit and fall-back to the tweak event which would transform the selected nodes. - In 3.2 (as of [0]) the PRESS that starts the modal operator is considered "handled" and prevents drag event from being detected. The correct behavior in this case isn't obvious: If a modal operator starts on pressing a button, using that same the release to generate drag/click events is disputable. Even in the case or 3.1 it was inconsistent as tweak events were generated but click events weren't. Note: after investigating this bug it turns out a similar issue already existed in 2.91 and all releases afterwards. While the bug is more obscure, it's also caused by the tweak event being interrupted as described here, this commit resolves T81824 as well. [0]: 4d0f846b936c9101ecb76a6db962aac2d74a460a [1]: 4986f718482b061082936f1f6aa13929741093a2 Reviewed By: Severin Ref D14499
2022-05-10 22:57:00 +10:00
break;
case SEL_OP_XOR: {
/* Check active so clicking on an inactive node activates it. */
bool is_selected = (node->flag & NODE_SELECT) && (node->flag & NODE_ACTIVE);
bke::node_set_selected(*node, !is_selected);
Fix T96520 Node editor: Tweak fails with unselected nodes Use the same method for node selection and dragging that is used in the 3D viewport and UV editor. Instead of relying on a modal operator - use the keymap to handle click/drag events. Details: Failure to transform unselected nodes was caused by [0] & [1] however detecting drag relied on specific behavior which I don't think we should be depending on. This error happened when selection was defined both in the key-map for the tool and for the node-editor. - The left mouse button would activate selection in both the tool and "Node Editor" keymap. - The first selection would return `FINISHED | PASS_THROUGH` when selecting a previously unselected node. - The same PRESS would trigger a second selection would return `RUNNING_MODAL | PASS_THROUGH`, (starting a NODE_OT_select as a modal operator). - In 3.1 (with tweak events) the modal operator would then exit and fall-back to the tweak event which would transform the selected nodes. - In 3.2 (as of [0]) the PRESS that starts the modal operator is considered "handled" and prevents drag event from being detected. The correct behavior in this case isn't obvious: If a modal operator starts on pressing a button, using that same the release to generate drag/click events is disputable. Even in the case or 3.1 it was inconsistent as tweak events were generated but click events weren't. Note: after investigating this bug it turns out a similar issue already existed in 2.91 and all releases afterwards. While the bug is more obscure, it's also caused by the tweak event being interrupted as described here, this commit resolves T81824 as well. [0]: 4d0f846b936c9101ecb76a6db962aac2d74a460a [1]: 4986f718482b061082936f1f6aa13929741093a2 Reviewed By: Severin Ref D14499
2022-05-10 22:57:00 +10:00
break;
}
case SEL_OP_SET:
bke::node_set_selected(*node, true);
Fix T96520 Node editor: Tweak fails with unselected nodes Use the same method for node selection and dragging that is used in the 3D viewport and UV editor. Instead of relying on a modal operator - use the keymap to handle click/drag events. Details: Failure to transform unselected nodes was caused by [0] & [1] however detecting drag relied on specific behavior which I don't think we should be depending on. This error happened when selection was defined both in the key-map for the tool and for the node-editor. - The left mouse button would activate selection in both the tool and "Node Editor" keymap. - The first selection would return `FINISHED | PASS_THROUGH` when selecting a previously unselected node. - The same PRESS would trigger a second selection would return `RUNNING_MODAL | PASS_THROUGH`, (starting a NODE_OT_select as a modal operator). - In 3.1 (with tweak events) the modal operator would then exit and fall-back to the tweak event which would transform the selected nodes. - In 3.2 (as of [0]) the PRESS that starts the modal operator is considered "handled" and prevents drag event from being detected. The correct behavior in this case isn't obvious: If a modal operator starts on pressing a button, using that same the release to generate drag/click events is disputable. Even in the case or 3.1 it was inconsistent as tweak events were generated but click events weren't. Note: after investigating this bug it turns out a similar issue already existed in 2.91 and all releases afterwards. While the bug is more obscure, it's also caused by the tweak event being interrupted as described here, this commit resolves T81824 as well. [0]: 4d0f846b936c9101ecb76a6db962aac2d74a460a [1]: 4986f718482b061082936f1f6aa13929741093a2 Reviewed By: Severin Ref D14499
2022-05-10 22:57:00 +10:00
break;
case SEL_OP_AND:
/* Doesn't make sense for picking. */
BLI_assert_unreachable();
Fix T96520 Node editor: Tweak fails with unselected nodes Use the same method for node selection and dragging that is used in the 3D viewport and UV editor. Instead of relying on a modal operator - use the keymap to handle click/drag events. Details: Failure to transform unselected nodes was caused by [0] & [1] however detecting drag relied on specific behavior which I don't think we should be depending on. This error happened when selection was defined both in the key-map for the tool and for the node-editor. - The left mouse button would activate selection in both the tool and "Node Editor" keymap. - The first selection would return `FINISHED | PASS_THROUGH` when selecting a previously unselected node. - The same PRESS would trigger a second selection would return `RUNNING_MODAL | PASS_THROUGH`, (starting a NODE_OT_select as a modal operator). - In 3.1 (with tweak events) the modal operator would then exit and fall-back to the tweak event which would transform the selected nodes. - In 3.2 (as of [0]) the PRESS that starts the modal operator is considered "handled" and prevents drag event from being detected. The correct behavior in this case isn't obvious: If a modal operator starts on pressing a button, using that same the release to generate drag/click events is disputable. Even in the case or 3.1 it was inconsistent as tweak events were generated but click events weren't. Note: after investigating this bug it turns out a similar issue already existed in 2.91 and all releases afterwards. While the bug is more obscure, it's also caused by the tweak event being interrupted as described here, this commit resolves T81824 as well. [0]: 4d0f846b936c9101ecb76a6db962aac2d74a460a [1]: 4986f718482b061082936f1f6aa13929741093a2 Reviewed By: Severin Ref D14499
2022-05-10 22:57:00 +10:00
break;
2013-03-18 18:25:05 +00:00
}
Fix T96520 Node editor: Tweak fails with unselected nodes Use the same method for node selection and dragging that is used in the 3D viewport and UV editor. Instead of relying on a modal operator - use the keymap to handle click/drag events. Details: Failure to transform unselected nodes was caused by [0] & [1] however detecting drag relied on specific behavior which I don't think we should be depending on. This error happened when selection was defined both in the key-map for the tool and for the node-editor. - The left mouse button would activate selection in both the tool and "Node Editor" keymap. - The first selection would return `FINISHED | PASS_THROUGH` when selecting a previously unselected node. - The same PRESS would trigger a second selection would return `RUNNING_MODAL | PASS_THROUGH`, (starting a NODE_OT_select as a modal operator). - In 3.1 (with tweak events) the modal operator would then exit and fall-back to the tweak event which would transform the selected nodes. - In 3.2 (as of [0]) the PRESS that starts the modal operator is considered "handled" and prevents drag event from being detected. The correct behavior in this case isn't obvious: If a modal operator starts on pressing a button, using that same the release to generate drag/click events is disputable. Even in the case or 3.1 it was inconsistent as tweak events were generated but click events weren't. Note: after investigating this bug it turns out a similar issue already existed in 2.91 and all releases afterwards. While the bug is more obscure, it's also caused by the tweak event being interrupted as described here, this commit resolves T81824 as well. [0]: 4d0f846b936c9101ecb76a6db962aac2d74a460a [1]: 4986f718482b061082936f1f6aa13929741093a2 Reviewed By: Severin Ref D14499
2022-05-10 22:57:00 +10:00
changed = true;
}
}
Geometry Nodes: viewport preview This adds support for showing geometry passed to the Viewer in the 3d viewport (instead of just in the spreadsheet). The "viewer geometry" bypasses the group output. So it is not necessary to change the final output of the node group to be able to see the intermediate geometry. **Activation and deactivation of a viewer node** * A viewer node is activated by clicking on it. * Ctrl+shift+click on any node/socket connects it to the viewer and makes it active. * Ctrl+shift+click in empty space deactivates the active viewer. * When the active viewer is not visible anymore (e.g. another object is selected, or the current node group is exit), it is deactivated. * Clicking on the icon in the header of the Viewer node toggles whether its active or not. **Pinning** * The spreadsheet still allows pinning the active viewer as before. When pinned, the spreadsheet still references the viewer node even when it becomes inactive. * The viewport does not support pinning at the moment. It always shows the active viewer. **Attribute** * When a field is linked to the second input of the viewer node it is displayed as an overlay in the viewport. * When possible the correct domain for the attribute is determined automatically. This does not work in all cases. It falls back to the face corner domain on meshes and the point domain on curves. When necessary, the domain can be picked manually. * The spreadsheet now only shows the "Viewer" column for the domain that is selected in the Viewer node. * Instance attributes are visualized as a constant color per instance. **Viewport Options** * The attribute overlay opacity can be controlled with the "Viewer Node" setting in the overlays popover. * A viewport can be configured not to show intermediate viewer-geometry by disabling the "Viewer Node" option in the "View" menu. **Implementation Details** * The "spreadsheet context path" was generalized to a "viewer path" that is used in more places now. * The viewer node itself determines the attribute domain, evaluates the field and stores the result in a `.viewer` attribute. * A new "viewer attribute' overlay displays the data from the `.viewer` attribute. * The ground truth for the active viewer node is stored in the workspace now. Node editors, spreadsheets and viewports retrieve the active viewer from there unless they are pinned. * The depsgraph object iterator has a new "viewer path" setting. When set, the viewed geometry of the corresponding object is part of the iterator instead of the final evaluated geometry. * To support the instance attribute overlay `DupliObject` was extended to contain the information necessary for drawing the overlay. * The ctrl+shift+click operator has been refactored so that it can make existing links to viewers active again. * The auto-domain-detection in the Viewer node works by checking the "preferred domain" for every field input. If there is not exactly one preferred domain, the fallback is used. Known limitations: * Loose edges of meshes don't have the attribute overlay. This could be added separately if necessary. * Some attributes are hard to visualize as a color directly. For example, the values might have to be normalized or some should be drawn as arrays. For now, we encourage users to build node groups that generate appropriate viewer-geometry. We might include some of that functionality in future versions. Support for displaying attribute values as text in the viewport is planned as well. * There seems to be an issue with the attribute overlay for pointclouds on nvidia gpus, to be investigated. Differential Revision: https://developer.blender.org/D15954
2022-09-28 17:54:59 +02:00
if (RNA_boolean_get(op->ptr, "clear_viewer")) {
if (node == nullptr) {
/* Disable existing active viewer. */
WorkSpace *workspace = CTX_wm_workspace(C);
BKE_viewer_path_clear(&workspace->viewer_path);
WM_event_add_notifier(C, NC_VIEWER_PATH, nullptr);
}
}
if (!(changed || found)) {
return false;
}
bool active_texture_changed = false;
bool viewer_node_changed = false;
if ((node != nullptr) && (node_was_selected == false || params.select_passthrough == false)) {
viewer_node_changed = (node->flag & NODE_DO_OUTPUT) == 0 &&
node->type_legacy == GEO_NODE_VIEWER;
ED_node_set_active(&bmain, &snode, snode.edittree, node, &active_texture_changed);
}
else if (node != nullptr && node->type_legacy == GEO_NODE_VIEWER) {
Geometry Nodes: viewport preview This adds support for showing geometry passed to the Viewer in the 3d viewport (instead of just in the spreadsheet). The "viewer geometry" bypasses the group output. So it is not necessary to change the final output of the node group to be able to see the intermediate geometry. **Activation and deactivation of a viewer node** * A viewer node is activated by clicking on it. * Ctrl+shift+click on any node/socket connects it to the viewer and makes it active. * Ctrl+shift+click in empty space deactivates the active viewer. * When the active viewer is not visible anymore (e.g. another object is selected, or the current node group is exit), it is deactivated. * Clicking on the icon in the header of the Viewer node toggles whether its active or not. **Pinning** * The spreadsheet still allows pinning the active viewer as before. When pinned, the spreadsheet still references the viewer node even when it becomes inactive. * The viewport does not support pinning at the moment. It always shows the active viewer. **Attribute** * When a field is linked to the second input of the viewer node it is displayed as an overlay in the viewport. * When possible the correct domain for the attribute is determined automatically. This does not work in all cases. It falls back to the face corner domain on meshes and the point domain on curves. When necessary, the domain can be picked manually. * The spreadsheet now only shows the "Viewer" column for the domain that is selected in the Viewer node. * Instance attributes are visualized as a constant color per instance. **Viewport Options** * The attribute overlay opacity can be controlled with the "Viewer Node" setting in the overlays popover. * A viewport can be configured not to show intermediate viewer-geometry by disabling the "Viewer Node" option in the "View" menu. **Implementation Details** * The "spreadsheet context path" was generalized to a "viewer path" that is used in more places now. * The viewer node itself determines the attribute domain, evaluates the field and stores the result in a `.viewer` attribute. * A new "viewer attribute' overlay displays the data from the `.viewer` attribute. * The ground truth for the active viewer node is stored in the workspace now. Node editors, spreadsheets and viewports retrieve the active viewer from there unless they are pinned. * The depsgraph object iterator has a new "viewer path" setting. When set, the viewed geometry of the corresponding object is part of the iterator instead of the final evaluated geometry. * To support the instance attribute overlay `DupliObject` was extended to contain the information necessary for drawing the overlay. * The ctrl+shift+click operator has been refactored so that it can make existing links to viewers active again. * The auto-domain-detection in the Viewer node works by checking the "preferred domain" for every field input. If there is not exactly one preferred domain, the fallback is used. Known limitations: * Loose edges of meshes don't have the attribute overlay. This could be added separately if necessary. * Some attributes are hard to visualize as a color directly. For example, the values might have to be normalized or some should be drawn as arrays. For now, we encourage users to build node groups that generate appropriate viewer-geometry. We might include some of that functionality in future versions. Support for displaying attribute values as text in the viewport is planned as well. * There seems to be an issue with the attribute overlay for pointclouds on nvidia gpus, to be investigated. Differential Revision: https://developer.blender.org/D15954
2022-09-28 17:54:59 +02:00
viewer_path::activate_geometry_node(bmain, snode, *node);
2022-09-06 12:13:15 -05:00
}
ED_node_set_active_viewer_key(&snode);
tree_draw_order_update(node_tree);
if ((active_texture_changed && has_workbench_in_texture_color(wm, scene, ob)) ||
viewer_node_changed)
{
DEG_id_tag_update(&snode.edittree->id, ID_RECALC_SYNC_TO_EVAL);
}
WM_event_add_notifier(C, NC_NODE | NA_SELECTED, nullptr);
Geometry Nodes: support attaching gizmos to input values This adds support for attaching gizmos for input values. The goal is to make it easier for users to set input values intuitively in the 3D viewport. We went through multiple different possible designs until we settled on the one implemented here. We picked it for it's flexibility and ease of use when using geometry node assets. The core principle in the design is that **gizmos are attached to existing input values instead of being the input value themselves**. This actually fits the existing concept of gizmos in Blender well, but may be a bit unintutitive in a node setup at first. The attachment is done using links in the node editor. The most basic usage of the node is to link a Value node to the new Linear Gizmo node. This attaches the gizmo to the input value and allows you to change it from the 3D view. The attachment is indicated by the gizmo icon in the sockets which are controlled by a gizmo as well as the back-link (notice the double link) when the gizmo is active. The core principle makes it straight forward to control the same node setup from the 3D view with gizmos, or by manually changing input values, or by driving the input values procedurally. If the input value is controlled indirectly by other inputs, it's often possible to **automatically propagate** the gizmo to the actual input. Backpropagation does not work for all nodes, although more nodes can be supported over time. This patch adds the first three gizmo nodes which cover common use cases: * **Linear Gizmo**: Creates a gizmo that controls a float or integer value using a linear movement of e.g. an arrow in the 3D viewport. * **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be rotated to change the attached angle input. * **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale. In the future, more built-in gizmos and potentially the ability for custom gizmos could be added. All gizmo nodes have a **Transform** geometry output. Using it is optional but it is recommended when the gizmo is used to control inputs that affect a geometry. When it is used, Blender will automatically transform the gizmos together with the geometry that they control. To achieve this, the output should be merged with the generated geometry using the *Join Geometry* node. The data contained in *Transform* output is not visible geometry, but just internal information that helps Blender to give a better user experience when using gizmos. The gizmo nodes have a multi-input socket. This allows **controlling multiple values** with the same gizmo. Only a small set of **gizmo shapes** is supported initially. It might be extended in the future but one goal is to give the gizmos used by different node group assets a familiar look and feel. A similar constraint exists for **colors**. Currently, one can choose from a fixed set of colors which can be modified in the theme settings. The set of **visible gizmos** is determined by a multiple factors because it's not really feasible to show all possible gizmos at all times. To see any of the geometry nodes gizmos, the "Active Modifier" option has to be enabled in the "Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of the following is true: * The gizmo controls an input of the active modifier of the active object. * The gizmo controls a value in a selected node in an open node editor. * The gizmo controls a pinned value in an open node editor. Pinning works by clicking the gizmo icon next to the value. Pull Request: https://projects.blender.org/blender/blender/pulls/112677
2024-07-10 16:18:47 +02:00
WM_event_add_notifier(C, NC_NODE | ND_NODE_GIZMO, nullptr);
2022-09-06 12:13:15 -05:00
BKE_main_ensure_invariants(bmain, node_tree.id);
return true;
}
static wmOperatorStatus node_select_exec(bContext *C, wmOperator *op)
{
/* Get settings from RNA properties for operator. */
int2 mval;
Fix T96520 Node editor: Tweak fails with unselected nodes Use the same method for node selection and dragging that is used in the 3D viewport and UV editor. Instead of relying on a modal operator - use the keymap to handle click/drag events. Details: Failure to transform unselected nodes was caused by [0] & [1] however detecting drag relied on specific behavior which I don't think we should be depending on. This error happened when selection was defined both in the key-map for the tool and for the node-editor. - The left mouse button would activate selection in both the tool and "Node Editor" keymap. - The first selection would return `FINISHED | PASS_THROUGH` when selecting a previously unselected node. - The same PRESS would trigger a second selection would return `RUNNING_MODAL | PASS_THROUGH`, (starting a NODE_OT_select as a modal operator). - In 3.1 (with tweak events) the modal operator would then exit and fall-back to the tweak event which would transform the selected nodes. - In 3.2 (as of [0]) the PRESS that starts the modal operator is considered "handled" and prevents drag event from being detected. The correct behavior in this case isn't obvious: If a modal operator starts on pressing a button, using that same the release to generate drag/click events is disputable. Even in the case or 3.1 it was inconsistent as tweak events were generated but click events weren't. Note: after investigating this bug it turns out a similar issue already existed in 2.91 and all releases afterwards. While the bug is more obscure, it's also caused by the tweak event being interrupted as described here, this commit resolves T81824 as well. [0]: 4d0f846b936c9101ecb76a6db962aac2d74a460a [1]: 4986f718482b061082936f1f6aa13929741093a2 Reviewed By: Severin Ref D14499
2022-05-10 22:57:00 +10:00
RNA_int_get_array(op->ptr, "location", mval);
const SelectPick_Params params = ED_select_pick_params_from_operator(op->ptr);
/* Perform the selection. */
const bool changed = node_mouse_select(C, op, mval, params);
Fix T96520 Node editor: Tweak fails with unselected nodes Use the same method for node selection and dragging that is used in the 3D viewport and UV editor. Instead of relying on a modal operator - use the keymap to handle click/drag events. Details: Failure to transform unselected nodes was caused by [0] & [1] however detecting drag relied on specific behavior which I don't think we should be depending on. This error happened when selection was defined both in the key-map for the tool and for the node-editor. - The left mouse button would activate selection in both the tool and "Node Editor" keymap. - The first selection would return `FINISHED | PASS_THROUGH` when selecting a previously unselected node. - The same PRESS would trigger a second selection would return `RUNNING_MODAL | PASS_THROUGH`, (starting a NODE_OT_select as a modal operator). - In 3.1 (with tweak events) the modal operator would then exit and fall-back to the tweak event which would transform the selected nodes. - In 3.2 (as of [0]) the PRESS that starts the modal operator is considered "handled" and prevents drag event from being detected. The correct behavior in this case isn't obvious: If a modal operator starts on pressing a button, using that same the release to generate drag/click events is disputable. Even in the case or 3.1 it was inconsistent as tweak events were generated but click events weren't. Note: after investigating this bug it turns out a similar issue already existed in 2.91 and all releases afterwards. While the bug is more obscure, it's also caused by the tweak event being interrupted as described here, this commit resolves T81824 as well. [0]: 4d0f846b936c9101ecb76a6db962aac2d74a460a [1]: 4986f718482b061082936f1f6aa13929741093a2 Reviewed By: Severin Ref D14499
2022-05-10 22:57:00 +10:00
if (changed) {
return OPERATOR_PASS_THROUGH | OPERATOR_FINISHED;
}
/* Nothing selected, just pass through. */
Fix T96520 Node editor: Tweak fails with unselected nodes Use the same method for node selection and dragging that is used in the 3D viewport and UV editor. Instead of relying on a modal operator - use the keymap to handle click/drag events. Details: Failure to transform unselected nodes was caused by [0] & [1] however detecting drag relied on specific behavior which I don't think we should be depending on. This error happened when selection was defined both in the key-map for the tool and for the node-editor. - The left mouse button would activate selection in both the tool and "Node Editor" keymap. - The first selection would return `FINISHED | PASS_THROUGH` when selecting a previously unselected node. - The same PRESS would trigger a second selection would return `RUNNING_MODAL | PASS_THROUGH`, (starting a NODE_OT_select as a modal operator). - In 3.1 (with tweak events) the modal operator would then exit and fall-back to the tweak event which would transform the selected nodes. - In 3.2 (as of [0]) the PRESS that starts the modal operator is considered "handled" and prevents drag event from being detected. The correct behavior in this case isn't obvious: If a modal operator starts on pressing a button, using that same the release to generate drag/click events is disputable. Even in the case or 3.1 it was inconsistent as tweak events were generated but click events weren't. Note: after investigating this bug it turns out a similar issue already existed in 2.91 and all releases afterwards. While the bug is more obscure, it's also caused by the tweak event being interrupted as described here, this commit resolves T81824 as well. [0]: 4d0f846b936c9101ecb76a6db962aac2d74a460a [1]: 4986f718482b061082936f1f6aa13929741093a2 Reviewed By: Severin Ref D14499
2022-05-10 22:57:00 +10:00
return OPERATOR_PASS_THROUGH | OPERATOR_CANCELLED;
}
static wmOperatorStatus node_select_invoke(bContext *C, wmOperator *op, const wmEvent *event)
Fix T96520 Node editor: Tweak fails with unselected nodes Use the same method for node selection and dragging that is used in the 3D viewport and UV editor. Instead of relying on a modal operator - use the keymap to handle click/drag events. Details: Failure to transform unselected nodes was caused by [0] & [1] however detecting drag relied on specific behavior which I don't think we should be depending on. This error happened when selection was defined both in the key-map for the tool and for the node-editor. - The left mouse button would activate selection in both the tool and "Node Editor" keymap. - The first selection would return `FINISHED | PASS_THROUGH` when selecting a previously unselected node. - The same PRESS would trigger a second selection would return `RUNNING_MODAL | PASS_THROUGH`, (starting a NODE_OT_select as a modal operator). - In 3.1 (with tweak events) the modal operator would then exit and fall-back to the tweak event which would transform the selected nodes. - In 3.2 (as of [0]) the PRESS that starts the modal operator is considered "handled" and prevents drag event from being detected. The correct behavior in this case isn't obvious: If a modal operator starts on pressing a button, using that same the release to generate drag/click events is disputable. Even in the case or 3.1 it was inconsistent as tweak events were generated but click events weren't. Note: after investigating this bug it turns out a similar issue already existed in 2.91 and all releases afterwards. While the bug is more obscure, it's also caused by the tweak event being interrupted as described here, this commit resolves T81824 as well. [0]: 4d0f846b936c9101ecb76a6db962aac2d74a460a [1]: 4986f718482b061082936f1f6aa13929741093a2 Reviewed By: Severin Ref D14499
2022-05-10 22:57:00 +10:00
{
RNA_int_set_array(op->ptr, "location", event->mval);
const wmOperatorStatus retval = node_select_exec(C, op);
Fix T96520 Node editor: Tweak fails with unselected nodes Use the same method for node selection and dragging that is used in the 3D viewport and UV editor. Instead of relying on a modal operator - use the keymap to handle click/drag events. Details: Failure to transform unselected nodes was caused by [0] & [1] however detecting drag relied on specific behavior which I don't think we should be depending on. This error happened when selection was defined both in the key-map for the tool and for the node-editor. - The left mouse button would activate selection in both the tool and "Node Editor" keymap. - The first selection would return `FINISHED | PASS_THROUGH` when selecting a previously unselected node. - The same PRESS would trigger a second selection would return `RUNNING_MODAL | PASS_THROUGH`, (starting a NODE_OT_select as a modal operator). - In 3.1 (with tweak events) the modal operator would then exit and fall-back to the tweak event which would transform the selected nodes. - In 3.2 (as of [0]) the PRESS that starts the modal operator is considered "handled" and prevents drag event from being detected. The correct behavior in this case isn't obvious: If a modal operator starts on pressing a button, using that same the release to generate drag/click events is disputable. Even in the case or 3.1 it was inconsistent as tweak events were generated but click events weren't. Note: after investigating this bug it turns out a similar issue already existed in 2.91 and all releases afterwards. While the bug is more obscure, it's also caused by the tweak event being interrupted as described here, this commit resolves T81824 as well. [0]: 4d0f846b936c9101ecb76a6db962aac2d74a460a [1]: 4986f718482b061082936f1f6aa13929741093a2 Reviewed By: Severin Ref D14499
2022-05-10 22:57:00 +10:00
return WM_operator_flag_only_pass_through_on_press(retval, event);
}
void NODE_OT_select(wmOperatorType *ot)
{
PropertyRNA *prop;
/* identifiers */
ot->name = "Select";
ot->idname = "NODE_OT_select";
ot->description = "Select the node under the cursor";
/* API callbacks. */
ot->exec = node_select_exec;
Fix T96520 Node editor: Tweak fails with unselected nodes Use the same method for node selection and dragging that is used in the 3D viewport and UV editor. Instead of relying on a modal operator - use the keymap to handle click/drag events. Details: Failure to transform unselected nodes was caused by [0] & [1] however detecting drag relied on specific behavior which I don't think we should be depending on. This error happened when selection was defined both in the key-map for the tool and for the node-editor. - The left mouse button would activate selection in both the tool and "Node Editor" keymap. - The first selection would return `FINISHED | PASS_THROUGH` when selecting a previously unselected node. - The same PRESS would trigger a second selection would return `RUNNING_MODAL | PASS_THROUGH`, (starting a NODE_OT_select as a modal operator). - In 3.1 (with tweak events) the modal operator would then exit and fall-back to the tweak event which would transform the selected nodes. - In 3.2 (as of [0]) the PRESS that starts the modal operator is considered "handled" and prevents drag event from being detected. The correct behavior in this case isn't obvious: If a modal operator starts on pressing a button, using that same the release to generate drag/click events is disputable. Even in the case or 3.1 it was inconsistent as tweak events were generated but click events weren't. Note: after investigating this bug it turns out a similar issue already existed in 2.91 and all releases afterwards. While the bug is more obscure, it's also caused by the tweak event being interrupted as described here, this commit resolves T81824 as well. [0]: 4d0f846b936c9101ecb76a6db962aac2d74a460a [1]: 4986f718482b061082936f1f6aa13929741093a2 Reviewed By: Severin Ref D14499
2022-05-10 22:57:00 +10:00
ot->invoke = node_select_invoke;
ot->poll = ED_operator_node_active;
ot->get_name = ED_select_pick_get_name;
/* flags */
2012-08-04 12:54:27 +00:00
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
/* properties */
Fix T96520 Node editor: Tweak fails with unselected nodes Use the same method for node selection and dragging that is used in the 3D viewport and UV editor. Instead of relying on a modal operator - use the keymap to handle click/drag events. Details: Failure to transform unselected nodes was caused by [0] & [1] however detecting drag relied on specific behavior which I don't think we should be depending on. This error happened when selection was defined both in the key-map for the tool and for the node-editor. - The left mouse button would activate selection in both the tool and "Node Editor" keymap. - The first selection would return `FINISHED | PASS_THROUGH` when selecting a previously unselected node. - The same PRESS would trigger a second selection would return `RUNNING_MODAL | PASS_THROUGH`, (starting a NODE_OT_select as a modal operator). - In 3.1 (with tweak events) the modal operator would then exit and fall-back to the tweak event which would transform the selected nodes. - In 3.2 (as of [0]) the PRESS that starts the modal operator is considered "handled" and prevents drag event from being detected. The correct behavior in this case isn't obvious: If a modal operator starts on pressing a button, using that same the release to generate drag/click events is disputable. Even in the case or 3.1 it was inconsistent as tweak events were generated but click events weren't. Note: after investigating this bug it turns out a similar issue already existed in 2.91 and all releases afterwards. While the bug is more obscure, it's also caused by the tweak event being interrupted as described here, this commit resolves T81824 as well. [0]: 4d0f846b936c9101ecb76a6db962aac2d74a460a [1]: 4986f718482b061082936f1f6aa13929741093a2 Reviewed By: Severin Ref D14499
2022-05-10 22:57:00 +10:00
WM_operator_properties_mouse_select(ot);
prop = RNA_def_int_vector(ot->srna,
"location",
2,
2022-05-15 19:04:07 +02:00
nullptr,
Fix T96520 Node editor: Tweak fails with unselected nodes Use the same method for node selection and dragging that is used in the 3D viewport and UV editor. Instead of relying on a modal operator - use the keymap to handle click/drag events. Details: Failure to transform unselected nodes was caused by [0] & [1] however detecting drag relied on specific behavior which I don't think we should be depending on. This error happened when selection was defined both in the key-map for the tool and for the node-editor. - The left mouse button would activate selection in both the tool and "Node Editor" keymap. - The first selection would return `FINISHED | PASS_THROUGH` when selecting a previously unselected node. - The same PRESS would trigger a second selection would return `RUNNING_MODAL | PASS_THROUGH`, (starting a NODE_OT_select as a modal operator). - In 3.1 (with tweak events) the modal operator would then exit and fall-back to the tweak event which would transform the selected nodes. - In 3.2 (as of [0]) the PRESS that starts the modal operator is considered "handled" and prevents drag event from being detected. The correct behavior in this case isn't obvious: If a modal operator starts on pressing a button, using that same the release to generate drag/click events is disputable. Even in the case or 3.1 it was inconsistent as tweak events were generated but click events weren't. Note: after investigating this bug it turns out a similar issue already existed in 2.91 and all releases afterwards. While the bug is more obscure, it's also caused by the tweak event being interrupted as described here, this commit resolves T81824 as well. [0]: 4d0f846b936c9101ecb76a6db962aac2d74a460a [1]: 4986f718482b061082936f1f6aa13929741093a2 Reviewed By: Severin Ref D14499
2022-05-10 22:57:00 +10:00
INT_MIN,
INT_MAX,
"Location",
"Mouse location",
INT_MIN,
INT_MAX);
RNA_def_property_flag(prop, PROP_HIDDEN);
RNA_def_boolean(ot->srna, "socket_select", false, "Socket Select", "");
Geometry Nodes: viewport preview This adds support for showing geometry passed to the Viewer in the 3d viewport (instead of just in the spreadsheet). The "viewer geometry" bypasses the group output. So it is not necessary to change the final output of the node group to be able to see the intermediate geometry. **Activation and deactivation of a viewer node** * A viewer node is activated by clicking on it. * Ctrl+shift+click on any node/socket connects it to the viewer and makes it active. * Ctrl+shift+click in empty space deactivates the active viewer. * When the active viewer is not visible anymore (e.g. another object is selected, or the current node group is exit), it is deactivated. * Clicking on the icon in the header of the Viewer node toggles whether its active or not. **Pinning** * The spreadsheet still allows pinning the active viewer as before. When pinned, the spreadsheet still references the viewer node even when it becomes inactive. * The viewport does not support pinning at the moment. It always shows the active viewer. **Attribute** * When a field is linked to the second input of the viewer node it is displayed as an overlay in the viewport. * When possible the correct domain for the attribute is determined automatically. This does not work in all cases. It falls back to the face corner domain on meshes and the point domain on curves. When necessary, the domain can be picked manually. * The spreadsheet now only shows the "Viewer" column for the domain that is selected in the Viewer node. * Instance attributes are visualized as a constant color per instance. **Viewport Options** * The attribute overlay opacity can be controlled with the "Viewer Node" setting in the overlays popover. * A viewport can be configured not to show intermediate viewer-geometry by disabling the "Viewer Node" option in the "View" menu. **Implementation Details** * The "spreadsheet context path" was generalized to a "viewer path" that is used in more places now. * The viewer node itself determines the attribute domain, evaluates the field and stores the result in a `.viewer` attribute. * A new "viewer attribute' overlay displays the data from the `.viewer` attribute. * The ground truth for the active viewer node is stored in the workspace now. Node editors, spreadsheets and viewports retrieve the active viewer from there unless they are pinned. * The depsgraph object iterator has a new "viewer path" setting. When set, the viewed geometry of the corresponding object is part of the iterator instead of the final evaluated geometry. * To support the instance attribute overlay `DupliObject` was extended to contain the information necessary for drawing the overlay. * The ctrl+shift+click operator has been refactored so that it can make existing links to viewers active again. * The auto-domain-detection in the Viewer node works by checking the "preferred domain" for every field input. If there is not exactly one preferred domain, the fallback is used. Known limitations: * Loose edges of meshes don't have the attribute overlay. This could be added separately if necessary. * Some attributes are hard to visualize as a color directly. For example, the values might have to be normalized or some should be drawn as arrays. For now, we encourage users to build node groups that generate appropriate viewer-geometry. We might include some of that functionality in future versions. Support for displaying attribute values as text in the viewport is planned as well. * There seems to be an issue with the attribute overlay for pointclouds on nvidia gpus, to be investigated. Differential Revision: https://developer.blender.org/D15954
2022-09-28 17:54:59 +02:00
RNA_def_boolean(ot->srna,
"clear_viewer",
false,
"Clear Viewer",
"Deactivate geometry nodes viewer when clicking in empty space");
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Box Select Operator
* \{ */
static wmOperatorStatus node_box_select_exec(bContext *C, wmOperator *op)
{
SpaceNode &snode = *CTX_wm_space_node(C);
bNodeTree &node_tree = *snode.edittree;
const ARegion &region = *CTX_wm_region(C);
rctf rectf;
WM_operator_properties_border_to_rctf(op, &rectf);
UI_view2d_region_to_view_rctf(&region.v2d, &rectf, &rectf);
const eSelectOp sel_op = (eSelectOp)RNA_enum_get(op->ptr, "mode");
const bool select = (sel_op != SEL_OP_SUB);
if (SEL_OP_USE_PRE_DESELECT(sel_op)) {
node_deselect_all(node_tree);
}
for (bNode *node : node_tree.all_nodes()) {
bool is_inside = false;
switch (node->type_legacy) {
case NODE_FRAME: {
/* Frame nodes are selectable by their borders (including their whole rect - as for other
* nodes - would prevent selection of other nodes inside that frame. */
const rctf frame_inside = node_frame_rect_inside(snode, *node);
if (BLI_rctf_isect(&rectf, &node->runtime->draw_bounds, nullptr) &&
!BLI_rctf_inside_rctf(&frame_inside, &rectf))
{
bke::node_set_selected(*node, select);
is_inside = true;
}
break;
}
default: {
is_inside = BLI_rctf_isect(&rectf, &node->runtime->draw_bounds, nullptr);
break;
}
}
if (is_inside) {
bke::node_set_selected(*node, select);
}
}
tree_draw_order_update(node_tree);
WM_event_add_notifier(C, NC_NODE | NA_SELECTED, nullptr);
return OPERATOR_FINISHED;
}
static wmOperatorStatus node_box_select_invoke(bContext *C, wmOperator *op, const wmEvent *event)
{
2014-02-03 18:55:59 +11:00
const bool tweak = RNA_boolean_get(op->ptr, "tweak");
if (tweak && is_event_over_node_or_socket(*C, *event)) {
return OPERATOR_CANCELLED | OPERATOR_PASS_THROUGH;
}
return WM_gesture_box_invoke(C, op, event);
}
void NODE_OT_select_box(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Box Select";
ot->idname = "NODE_OT_select_box";
ot->description = "Use box selection to select nodes";
/* API callbacks. */
ot->invoke = node_box_select_invoke;
ot->exec = node_box_select_exec;
ot->modal = WM_gesture_box_modal;
ot->cancel = WM_gesture_box_cancel;
ot->poll = ED_operator_node_active;
/* flags */
2012-08-04 12:54:27 +00:00
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
/* properties */
RNA_def_boolean(ot->srna,
"tweak",
false,
"Tweak",
"Only activate when mouse is not over a node (useful for tweak gesture)");
WM_operator_properties_gesture_box(ot);
WM_operator_properties_select_operation_simple(ot);
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Circle Select Operator
* \{ */
static wmOperatorStatus node_circleselect_exec(bContext *C, wmOperator *op)
{
SpaceNode *snode = CTX_wm_space_node(C);
ARegion *region = CTX_wm_region(C);
bNodeTree &node_tree = *snode->edittree;
int x, y, radius;
float2 offset;
float zoom = float(BLI_rcti_size_x(&region->winrct)) / BLI_rctf_size_x(&region->v2d.cur);
const eSelectOp sel_op = ED_select_op_modal(
(eSelectOp)RNA_enum_get(op->ptr, "mode"),
WM_gesture_is_modal_first((const wmGesture *)op->customdata));
const bool select = (sel_op != SEL_OP_SUB);
if (SEL_OP_USE_PRE_DESELECT(sel_op)) {
node_deselect_all(node_tree);
}
/* get operator properties */
x = RNA_int_get(op->ptr, "x");
y = RNA_int_get(op->ptr, "y");
radius = RNA_int_get(op->ptr, "radius");
UI_view2d_region_to_view(&region->v2d, x, y, &offset.x, &offset.y);
for (bNode *node : node_tree.all_nodes()) {
switch (node->type_legacy) {
case NODE_FRAME: {
/* Frame nodes are selectable by their borders (including their whole rect - as for other
* nodes - would prevent selection of _only_ other nodes inside that frame. */
rctf frame_inside = node_frame_rect_inside(*snode, *node);
const float radius_adjusted = float(radius) / zoom;
BLI_rctf_pad(&frame_inside, -2.0f * radius_adjusted, -2.0f * radius_adjusted);
if (BLI_rctf_isect_circle(&node->runtime->draw_bounds, offset, radius_adjusted) &&
!BLI_rctf_isect_circle(&frame_inside, offset, radius_adjusted))
{
bke::node_set_selected(*node, select);
}
break;
}
default: {
if (BLI_rctf_isect_circle(&node->runtime->draw_bounds, offset, radius / zoom)) {
bke::node_set_selected(*node, select);
}
break;
}
}
}
WM_event_add_notifier(C, NC_NODE | NA_SELECTED, nullptr);
return OPERATOR_FINISHED;
}
void NODE_OT_select_circle(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Circle Select";
ot->idname = "NODE_OT_select_circle";
ot->description = "Use circle selection to select nodes";
/* API callbacks. */
ot->invoke = WM_gesture_circle_invoke;
ot->exec = node_circleselect_exec;
ot->modal = WM_gesture_circle_modal;
ot->poll = ED_operator_node_active;
ot->get_name = ED_select_circle_get_name;
/* flags */
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
/* properties */
WM_operator_properties_gesture_circle(ot);
WM_operator_properties_select_operation_simple(ot);
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Lasso Select Operator
* \{ */
static wmOperatorStatus node_lasso_select_invoke(bContext *C, wmOperator *op, const wmEvent *event)
{
const bool tweak = RNA_boolean_get(op->ptr, "tweak");
if (tweak && is_event_over_node_or_socket(*C, *event)) {
return OPERATOR_CANCELLED | OPERATOR_PASS_THROUGH;
}
return WM_gesture_lasso_invoke(C, op, event);
}
static bool do_lasso_select_node(bContext *C, const Span<int2> mcoords, eSelectOp sel_op)
{
SpaceNode *snode = CTX_wm_space_node(C);
bNodeTree &node_tree = *snode->edittree;
ARegion *region = CTX_wm_region(C);
rcti rect;
bool changed = false;
const bool select = (sel_op != SEL_OP_SUB);
if (SEL_OP_USE_PRE_DESELECT(sel_op)) {
node_deselect_all(node_tree);
changed = true;
}
/* Get rectangle from operator. */
BLI_lasso_boundbox(&rect, mcoords);
for (bNode *node : node_tree.all_nodes()) {
if (select && (node->flag & NODE_SELECT)) {
continue;
}
switch (node->type_legacy) {
case NODE_FRAME: {
/* Frame nodes are selectable by their borders (including their whole rect - as for other
* nodes - would prevent selection of other nodes inside that frame. */
rctf rectf;
BLI_rctf_rcti_copy(&rectf, &rect);
UI_view2d_region_to_view_rctf(&region->v2d, &rectf, &rectf);
const rctf frame_inside = node_frame_rect_inside(*snode, *node);
if (BLI_rctf_isect(&rectf, &node->runtime->draw_bounds, nullptr) &&
!BLI_rctf_inside_rctf(&frame_inside, &rectf))
{
bke::node_set_selected(*node, select);
changed = true;
}
break;
}
default: {
int2 screen_co;
const float2 center = {BLI_rctf_cent_x(&node->runtime->draw_bounds),
BLI_rctf_cent_y(&node->runtime->draw_bounds)};
/* marker in screen coords */
if (UI_view2d_view_to_region_clip(
&region->v2d, center.x, center.y, &screen_co.x, &screen_co.y) &&
BLI_rcti_isect_pt(&rect, screen_co.x, screen_co.y) &&
BLI_lasso_is_point_inside(mcoords, screen_co.x, screen_co.y, INT_MAX))
{
bke::node_set_selected(*node, select);
changed = true;
}
break;
}
}
}
if (changed) {
WM_event_add_notifier(C, NC_NODE | NA_SELECTED, nullptr);
}
return changed;
}
static wmOperatorStatus node_lasso_select_exec(bContext *C, wmOperator *op)
{
const Array<int2> mcoords = WM_gesture_lasso_path_to_array(C, op);
if (mcoords.is_empty()) {
return OPERATOR_PASS_THROUGH;
}
const eSelectOp sel_op = (eSelectOp)RNA_enum_get(op->ptr, "mode");
do_lasso_select_node(C, mcoords, sel_op);
return OPERATOR_FINISHED;
}
void NODE_OT_select_lasso(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Lasso Select";
ot->description = "Select nodes using lasso selection";
ot->idname = "NODE_OT_select_lasso";
/* API callbacks. */
ot->invoke = node_lasso_select_invoke;
ot->modal = WM_gesture_lasso_modal;
ot->exec = node_lasso_select_exec;
ot->poll = ED_operator_node_active;
ot->cancel = WM_gesture_lasso_cancel;
/* flags */
ot->flag = OPTYPE_UNDO | OPTYPE_DEPENDS_ON_CURSOR;
/* properties */
RNA_def_boolean(ot->srna,
"tweak",
false,
"Tweak",
"Only activate when mouse is not over a node (useful for tweak gesture)");
WM_operator_properties_gesture_lasso(ot);
WM_operator_properties_select_operation_simple(ot);
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name (De)select All Operator
* \{ */
static bool any_node_selected(const bNodeTree &node_tree)
{
for (const bNode *node : node_tree.all_nodes()) {
if (node->flag & NODE_SELECT) {
return true;
}
}
return false;
}
static wmOperatorStatus node_select_all_exec(bContext *C, wmOperator *op)
{
SpaceNode &snode = *CTX_wm_space_node(C);
bNodeTree &node_tree = *snode.edittree;
node_tree.ensure_topology_cache();
int action = RNA_enum_get(op->ptr, "action");
if (action == SEL_TOGGLE) {
if (any_node_selected(node_tree)) {
action = SEL_DESELECT;
}
else {
action = SEL_SELECT;
}
}
switch (action) {
case SEL_SELECT:
for (bNode *node : node_tree.all_nodes()) {
bke::node_set_selected(*node, true);
}
break;
case SEL_DESELECT:
node_deselect_all(node_tree);
break;
case SEL_INVERT:
for (bNode *node : node_tree.all_nodes()) {
bke::node_set_selected(*node, !(node->flag & SELECT));
}
break;
}
tree_draw_order_update(node_tree);
WM_event_add_notifier(C, NC_NODE | NA_SELECTED, nullptr);
Geometry Nodes: support attaching gizmos to input values This adds support for attaching gizmos for input values. The goal is to make it easier for users to set input values intuitively in the 3D viewport. We went through multiple different possible designs until we settled on the one implemented here. We picked it for it's flexibility and ease of use when using geometry node assets. The core principle in the design is that **gizmos are attached to existing input values instead of being the input value themselves**. This actually fits the existing concept of gizmos in Blender well, but may be a bit unintutitive in a node setup at first. The attachment is done using links in the node editor. The most basic usage of the node is to link a Value node to the new Linear Gizmo node. This attaches the gizmo to the input value and allows you to change it from the 3D view. The attachment is indicated by the gizmo icon in the sockets which are controlled by a gizmo as well as the back-link (notice the double link) when the gizmo is active. The core principle makes it straight forward to control the same node setup from the 3D view with gizmos, or by manually changing input values, or by driving the input values procedurally. If the input value is controlled indirectly by other inputs, it's often possible to **automatically propagate** the gizmo to the actual input. Backpropagation does not work for all nodes, although more nodes can be supported over time. This patch adds the first three gizmo nodes which cover common use cases: * **Linear Gizmo**: Creates a gizmo that controls a float or integer value using a linear movement of e.g. an arrow in the 3D viewport. * **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be rotated to change the attached angle input. * **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale. In the future, more built-in gizmos and potentially the ability for custom gizmos could be added. All gizmo nodes have a **Transform** geometry output. Using it is optional but it is recommended when the gizmo is used to control inputs that affect a geometry. When it is used, Blender will automatically transform the gizmos together with the geometry that they control. To achieve this, the output should be merged with the generated geometry using the *Join Geometry* node. The data contained in *Transform* output is not visible geometry, but just internal information that helps Blender to give a better user experience when using gizmos. The gizmo nodes have a multi-input socket. This allows **controlling multiple values** with the same gizmo. Only a small set of **gizmo shapes** is supported initially. It might be extended in the future but one goal is to give the gizmos used by different node group assets a familiar look and feel. A similar constraint exists for **colors**. Currently, one can choose from a fixed set of colors which can be modified in the theme settings. The set of **visible gizmos** is determined by a multiple factors because it's not really feasible to show all possible gizmos at all times. To see any of the geometry nodes gizmos, the "Active Modifier" option has to be enabled in the "Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of the following is true: * The gizmo controls an input of the active modifier of the active object. * The gizmo controls a value in a selected node in an open node editor. * The gizmo controls a pinned value in an open node editor. Pinning works by clicking the gizmo icon next to the value. Pull Request: https://projects.blender.org/blender/blender/pulls/112677
2024-07-10 16:18:47 +02:00
WM_event_add_notifier(C, NC_NODE | ND_NODE_GIZMO, nullptr);
return OPERATOR_FINISHED;
}
void NODE_OT_select_all(wmOperatorType *ot)
{
/* identifiers */
ot->name = "(De)select All";
ot->description = "(De)select all nodes";
ot->idname = "NODE_OT_select_all";
/* API callbacks. */
ot->exec = node_select_all_exec;
ot->poll = ED_operator_node_active;
/* flags */
2012-08-04 12:54:27 +00:00
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
WM_operator_properties_select_all(ot);
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Select Linked To Operator
* \{ */
static wmOperatorStatus node_select_linked_to_exec(bContext *C, wmOperator * /*op*/)
{
SpaceNode &snode = *CTX_wm_space_node(C);
bNodeTree &node_tree = *snode.edittree;
node_tree.ensure_topology_cache();
VectorSet<bNode *> initial_selection = get_selected_nodes(node_tree);
for (bNode *node : initial_selection) {
for (bNodeSocket *output_socket : node->output_sockets()) {
if (!output_socket->is_available()) {
continue;
}
for (bNodeSocket *input_socket : output_socket->directly_linked_sockets()) {
if (!input_socket->is_available()) {
continue;
}
bke::node_set_selected(input_socket->owner_node(), true);
}
}
}
tree_draw_order_update(node_tree);
WM_event_add_notifier(C, NC_NODE | NA_SELECTED, nullptr);
return OPERATOR_FINISHED;
}
void NODE_OT_select_linked_to(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Select Linked To";
ot->description = "Select nodes linked to the selected ones";
ot->idname = "NODE_OT_select_linked_to";
/* API callbacks. */
ot->exec = node_select_linked_to_exec;
ot->poll = ED_operator_node_active;
/* flags */
2012-08-04 12:54:27 +00:00
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Select Linked From Operator
* \{ */
static wmOperatorStatus node_select_linked_from_exec(bContext *C, wmOperator * /*op*/)
{
SpaceNode &snode = *CTX_wm_space_node(C);
bNodeTree &node_tree = *snode.edittree;
node_tree.ensure_topology_cache();
VectorSet<bNode *> initial_selection = get_selected_nodes(node_tree);
for (bNode *node : initial_selection) {
for (bNodeSocket *input_socket : node->input_sockets()) {
if (!input_socket->is_available()) {
continue;
}
for (bNodeSocket *output_socket : input_socket->directly_linked_sockets()) {
if (!output_socket->is_available()) {
continue;
}
bke::node_set_selected(output_socket->owner_node(), true);
}
}
}
tree_draw_order_update(node_tree);
WM_event_add_notifier(C, NC_NODE | NA_SELECTED, nullptr);
return OPERATOR_FINISHED;
}
void NODE_OT_select_linked_from(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Select Linked From";
ot->description = "Select nodes linked from the selected ones";
ot->idname = "NODE_OT_select_linked_from";
/* API callbacks. */
ot->exec = node_select_linked_from_exec;
ot->poll = ED_operator_node_active;
/* flags */
2012-08-04 12:54:27 +00:00
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Select Same Type Step Operator
* \{ */
static bool nodes_are_same_type_for_select(const bNode &a, const bNode &b)
{
return a.type_legacy == b.type_legacy;
}
static wmOperatorStatus node_select_same_type_step_exec(bContext *C, wmOperator *op)
{
SpaceNode *snode = CTX_wm_space_node(C);
ARegion *region = CTX_wm_region(C);
const bool prev = RNA_boolean_get(op->ptr, "prev");
bNode *active_node = bke::node_get_active(*snode->edittree);
if (active_node == nullptr) {
return OPERATOR_CANCELLED;
}
bNodeTree &node_tree = *snode->edittree;
node_tree.ensure_topology_cache();
if (node_tree.all_nodes().size() == 1) {
return OPERATOR_CANCELLED;
}
const Span<const bNode *> toposort = node_tree.toposort_left_to_right();
const int index = toposort.first_index(active_node);
int new_index = index;
while (true) {
new_index += (prev ? -1 : 1);
if (!toposort.index_range().contains(new_index)) {
return OPERATOR_CANCELLED;
}
if (nodes_are_same_type_for_select(*toposort[new_index], *active_node)) {
break;
}
}
bNode *new_active_node = node_tree.all_nodes()[toposort[new_index]->index()];
if (new_active_node == active_node) {
return OPERATOR_CANCELLED;
}
node_select_single(*C, *new_active_node);
if (!BLI_rctf_inside_rctf(&region->v2d.cur, &new_active_node->runtime->draw_bounds)) {
const int smooth_viewtx = WM_operator_smooth_viewtx_get(op);
space_node_view_flag(*C, *snode, *region, NODE_SELECT, smooth_viewtx);
}
return OPERATOR_FINISHED;
}
void NODE_OT_select_same_type_step(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Activate Same Type Next/Prev";
ot->description = "Activate and view same node type, step by step";
ot->idname = "NODE_OT_select_same_type_step";
/* API callbacks. */
ot->exec = node_select_same_type_step_exec;
ot->poll = ED_operator_node_active;
/* flags */
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
RNA_def_boolean(ot->srna, "prev", false, "Previous", "");
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Find Node by Name Operator
* \{ */
static std::string node_find_create_label(const bNodeTree &ntree, const bNode &node)
{
std::string label = bke::node_label(ntree, node);
if (label == node.name) {
return label;
}
return fmt::format("{} ({})", label, node.name);
}
/* Generic search invoke. */
static void node_find_update_fn(const bContext *C,
void * /*arg*/,
const char *str,
uiSearchItems *items,
const bool /*is_first*/)
{
SpaceNode *snode = CTX_wm_space_node(C);
UI: show recently selected items at the top of searches The goal is to make the search faster to use by dynamically adapting to the user. This can be achieved using the simple but common approach of showing recently selected items at the top. Note, that the "matching score" between the query and each search item still has precedence when determining the order. So the last used item is only at the top, if there is no other search item that matches the query better. Besides making the search generally faster to use, my hope is that this can also reduce the need for manually weighting search items in some places. This is because while the ordering might not be perfect the first time, it will always be once the user selected the element that should be at the top once. This patch includes: * Support for taking recent searches into account in string searching. * Keep track of a global list of recent searches. * Store recent searches on disk similar to recently opened files. * A new setting in the user preferences that allows disabling the functionality. This can be used if deterministic key strokes are required, e.g. for automated tests. In the future this could be improved in different ways: * Add some kind of separator in the search list to indicate which elements are at the top because they have been used recently. * Store the recent search items per search, instead of in a global list. This way it could adapt to the user even better. Pull Request: https://projects.blender.org/blender/blender/pulls/110828
2023-09-25 10:56:12 +02:00
ui::string_search::StringSearch<bNode> search;
const bNodeTree &ntree = *snode->edittree;
for (bNode *node : snode->edittree->all_nodes()) {
const std::string name = node_find_create_label(ntree, *node);
search.add(name, node);
}
const Vector<bNode *> filtered_nodes = search.query(str);
for (bNode *node : filtered_nodes) {
const std::string name = node_find_create_label(ntree, *node);
if (!UI_search_item_add(items, name, node, ICON_NONE, 0, 0)) {
break;
}
}
}
static void node_find_exec_fn(bContext *C, void * /*arg1*/, void *arg2)
{
SpaceNode *snode = CTX_wm_space_node(C);
bNode *active = (bNode *)arg2;
if (active) {
ARegion *region = CTX_wm_region(C);
node_select_single(*C, *active);
if (!BLI_rctf_inside_rctf(&region->v2d.cur, &active->runtime->draw_bounds)) {
space_node_view_flag(*C, *snode, *region, NODE_SELECT, U.smooth_viewtx);
}
}
}
static uiBlock *node_find_menu(bContext *C, ARegion *region, void *arg_optype)
{
static char search[256] = "";
uiBlock *block;
uiBut *but;
wmOperatorType *optype = (wmOperatorType *)arg_optype;
block = UI_block_begin(C, region, "_popup", blender::ui::EmbossType::Emboss);
UI_block_flag_enable(block, UI_BLOCK_LOOP | UI_BLOCK_MOVEMOUSE_QUIT | UI_BLOCK_SEARCH_MENU);
UI_block_theme_style_set(block, UI_BLOCK_THEME_STYLE_POPUP);
const int box_width = UI_searchbox_size_x_guess(C, node_find_update_fn);
but = uiDefSearchBut(
block, search, 0, ICON_VIEWZOOM, sizeof(search), 0, 0, box_width, UI_UNIT_Y, "");
UI_but_func_search_set(
but, nullptr, node_find_update_fn, optype, false, nullptr, node_find_exec_fn, nullptr);
UI_but_flag_enable(but, UI_BUT_ACTIVATE_ON_INIT);
/* Fake button holds space for search items. */
const int height = UI_searchbox_size_y() - UI_SEARCHBOX_BOUNDS;
uiDefBut(
block, UI_BTYPE_LABEL, 0, "", 0, -height, box_width, height, nullptr, 0, 0, std::nullopt);
/* Move it downwards, mouse over button. */
std::array<int, 2> bounds_offset = {0, -UI_UNIT_Y};
UI_block_bounds_set_popup(block, UI_SEARCHBOX_BOUNDS, bounds_offset.data());
return block;
}
static wmOperatorStatus node_find_node_invoke(bContext *C,
wmOperator *op,
const wmEvent * /*event*/)
{
UI_popup_block_invoke(C, node_find_menu, op->type, nullptr);
return OPERATOR_CANCELLED;
}
void NODE_OT_find_node(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Find Node";
ot->description = "Search for a node by name and focus and select it";
ot->idname = "NODE_OT_find_node";
/* API callbacks. */
ot->invoke = node_find_node_invoke;
ot->poll = ED_operator_node_active;
/* flags */
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
}
/** \} */
2022-01-24 21:15:25 +11:00
} // namespace blender::ed::space_node