Files
test2/source/blender/editors/space_node/node_edit.cc

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

2660 lines
76 KiB
C++
Raw Normal View History

/* SPDX-FileCopyrightText: 2005 Blender Authors
*
* SPDX-License-Identifier: GPL-2.0-or-later */
/** \file
* \ingroup spnode
2011-02-27 20:29:51 +00:00
*/
#include <algorithm>
#include <optional>
#include "MEM_guardedalloc.h"
#include "DNA_material_types.h"
#include "DNA_node_types.h"
#include "DNA_text_types.h"
#include "DNA_world_types.h"
#include "BKE_callbacks.hh"
#include "BKE_context.hh"
#include "BKE_global.hh"
#include "BKE_image.hh"
2024-01-15 12:44:04 -05:00
#include "BKE_lib_id.hh"
#include "BKE_main.hh"
Core: add concept of invariants in original DNA data This patch adds a new `BKE_main_ensure_invariants` function. For now it only ensures node-tree related invariants, but more may be added over time. The already existing `ED_node_tree_propagate_change` now internally calls `BKE_main_ensure_invariants`. We can probably remove this indirection at some point and call the new function directly, but for now it is kept to keep this patch small. This is based on a recent discussion in the Core module meeting: https://devtalk.blender.org/t/2024-12-12-core-meeting/38074 ```cpp /** * Makes sure that invariants in original DNA data are maintained after changes. * * This function has to be idempotent, i.e. after calling it once, additional calls should not * modify DNA data further. If it would, it would imply that this function does more than * maintaining invariants. * * This has to be called after any kind of change to original DNA data that may be involved in some * of the maintained invariants. It's possible to do multiple changes in a row and then fixing all * invariants with a single call in the end. Obviously, the invariants are not maintained in the * meantime then and functions relying on them might not work. * * If nothing is changed, this function does nothing and it should not be slower than checking a * flag on every data-block in the given bmain. * * Sometimes, it is known that only a single or very few data-blocks have been changed (e.g. when a * node has been inserted in a node tree). Passing in #modified_ids can speed up the function * because it may avoid the need to iterate over all data-blocks to find modified data-blocks. * * Examples of maintained invariants: * - Group nodes need to have the correct sockets based on the referenced node group. * - The geometry nodes modifier needs to have the correct inputs based on the referenced group. */ void BKE_main_ensure_invariants(Main &bmain, std::optional<blender::Span<ID *>> modified_ids = std::nullopt); ``` This also adds `windowmanager` as a dependency of `blenkernel` to be able to send notifiers. Pull Request: https://projects.blender.org/blender/blender/pulls/132023
2025-01-13 15:03:24 +01:00
#include "BKE_main_invariants.hh"
#include "BKE_material.hh"
#include "BKE_node.hh"
#include "BKE_node_legacy_types.hh"
#include "BKE_node_runtime.hh"
#include "BKE_node_tree_update.hh"
#include "BKE_report.hh"
#include "BKE_scene.hh"
#include "BKE_scene_runtime.hh"
#include "BLI_listbase.h"
#include "BLI_math_vector.h"
#include "BLI_math_vector.hh"
#include "BLI_string.h"
#include "BLI_string_utf8.h"
#include "BLT_translation.hh"
#include "DEG_depsgraph.hh"
#include "DEG_depsgraph_build.hh"
#include "DEG_depsgraph_debug.hh"
#include "DEG_depsgraph_query.hh"
#include "RE_engine.h"
#include "RE_pipeline.h"
#include "ED_image.hh"
#include "ED_node.hh" /* own include */
#include "ED_render.hh"
#include "ED_screen.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 "RNA_prototypes.hh"
#include "WM_api.hh"
#include "WM_types.hh"
#include "UI_view2d.hh"
#include "GPU_capabilities.hh"
2024-02-01 10:40:24 -05:00
#include "GPU_material.hh"
2024-01-18 22:50:23 +02:00
#include "IMB_imbuf_types.hh"
#include "NOD_composite.hh"
#include "NOD_geometry.hh"
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
#include "NOD_shader.h"
#include "NOD_socket.hh"
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
#include "NOD_texture.h"
#include "node_intern.hh" /* own include */
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
#include "COM_compositor.hh"
#include "COM_context.hh"
#include "COM_profiler.hh"
namespace blender::ed::space_node {
2012-08-15 11:31:04 +00:00
#define USE_ESC_COMPO
/* -------------------------------------------------------------------- */
/** \name Composite Job Manager
* \{ */
enum {
COM_RECALC_COMPOSITE = 1,
COM_RECALC_VIEWER = 2,
};
struct CompoJob {
/* Input parameters. */
Main *bmain;
Scene *scene;
ViewLayer *view_layer;
bNodeTree *ntree;
int recalc_flags;
/* Evaluated state/ */
Depsgraph *compositor_depsgraph;
bNodeTree *localtree;
/* Render instance. */
Render *re;
/* Job system integration. */
const bool *stop;
bool *do_update;
float *progress;
bool cancelled;
compositor::Profiler profiler;
compositor::OutputTypes needed_outputs;
};
float node_socket_calculate_height(const bNodeSocket &socket)
{
float sock_height = NODE_SOCKSIZE;
if (socket.flag & SOCK_MULTI_INPUT) {
sock_height += max_ii(NODE_MULTI_INPUT_LINK_GAP * 0.5f * socket.runtime->total_inputs,
NODE_SOCKSIZE);
}
return sock_height;
}
float2 node_link_calculate_multi_input_position(const float2 &socket_position,
const int index,
const int total_inputs)
{
const float offset = (total_inputs * NODE_MULTI_INPUT_LINK_GAP - NODE_MULTI_INPUT_LINK_GAP) *
0.5f;
return {socket_position.x, socket_position.y - offset + index * NODE_MULTI_INPUT_LINK_GAP};
}
static void compo_tag_output_nodes(bNodeTree *nodetree, int recalc_flags)
{
for (bNode *node : nodetree->all_nodes()) {
if (node->type_legacy == CMP_NODE_COMPOSITE) {
if (recalc_flags & COM_RECALC_COMPOSITE) {
node->flag |= NODE_DO_OUTPUT_RECALC;
}
}
else if (node->type_legacy == CMP_NODE_VIEWER) {
if (recalc_flags & COM_RECALC_VIEWER) {
node->flag |= NODE_DO_OUTPUT_RECALC;
}
}
else if (node->type_legacy == NODE_GROUP) {
if (node->id) {
compo_tag_output_nodes((bNodeTree *)node->id, recalc_flags);
}
}
}
}
static int compo_get_recalc_flags(const bContext *C)
{
wmWindowManager *wm = CTX_wm_manager(C);
int recalc_flags = 0;
LISTBASE_FOREACH (wmWindow *, win, &wm->windows) {
const bScreen *screen = WM_window_get_active_screen(win);
LISTBASE_FOREACH (ScrArea *, area, &screen->areabase) {
if (area->spacetype == SPACE_IMAGE) {
SpaceImage *sima = (SpaceImage *)area->spacedata.first;
if (sima->image) {
if (sima->image->type == IMA_TYPE_R_RESULT) {
recalc_flags |= COM_RECALC_COMPOSITE;
}
else if (sima->image->type == IMA_TYPE_COMPOSITE) {
recalc_flags |= COM_RECALC_VIEWER;
}
}
}
else if (area->spacetype == SPACE_NODE) {
SpaceNode *snode = (SpaceNode *)area->spacedata.first;
if (snode->flag & SNODE_BACKDRAW) {
recalc_flags |= COM_RECALC_VIEWER;
}
}
}
}
return recalc_flags;
}
/* Called by compositor, only to check job 'stop' value. */
static bool compo_breakjob(void *cjv)
{
CompoJob *cj = (CompoJob *)cjv;
/* Without G.is_break 'ESC' won't quit - which annoys users. */
2012-08-15 11:31:04 +00:00
return (*(cj->stop)
#ifdef USE_ESC_COMPO
|| G.is_break
#endif
);
}
/* Called by compositor, #wmJob sends notifier. */
static void compo_statsdrawjob(void *cjv, const char * /*str*/)
{
CompoJob *cj = (CompoJob *)cjv;
*(cj->do_update) = true;
}
/* Called by compositor, wmJob sends notifier. */
static void compo_redrawjob(void *cjv)
{
CompoJob *cj = (CompoJob *)cjv;
*(cj->do_update) = true;
}
static void compo_freejob(void *cjv)
{
CompoJob *cj = (CompoJob *)cjv;
if (cj->localtree) {
/* Merge back node previews, only for completed jobs. */
if (!cj->cancelled) {
bke::node_tree_local_merge(cj->bmain, cj->localtree, cj->ntree);
}
bke::node_tree_free_tree(cj->localtree);
MEM_freeN(cj->localtree);
}
MEM_delete(cj);
}
/* Only now we copy the nodetree, so adding many jobs while
* sliding buttons doesn't frustrate. */
static void compo_initjob(void *cjv)
{
CompoJob *cj = (CompoJob *)cjv;
Main *bmain = cj->bmain;
Scene *scene = cj->scene;
ViewLayer *view_layer = cj->view_layer;
bke::CompositorRuntime &compositor_runtime = scene->runtime->compositor;
if (!compositor_runtime.preview_depsgraph) {
compositor_runtime.preview_depsgraph = DEG_graph_new(
bmain, scene, view_layer, DAG_EVAL_RENDER);
DEG_debug_name_set(compositor_runtime.preview_depsgraph, "COMPOSITOR");
}
/* Update the viewer layer of the compositor since it changed since the depsgraph was created. */
if (DEG_get_input_view_layer(compositor_runtime.preview_depsgraph) != view_layer) {
DEG_graph_replace_owners(compositor_runtime.preview_depsgraph, bmain, scene, view_layer);
DEG_graph_tag_relations_update(compositor_runtime.preview_depsgraph);
}
cj->compositor_depsgraph = compositor_runtime.preview_depsgraph;
DEG_graph_build_for_compositor_preview(cj->compositor_depsgraph, cj->ntree);
/* NOTE: Don't update animation to preserve unkeyed changes, this means can not use
* evaluate_on_framechange. */
DEG_evaluate_on_refresh(cj->compositor_depsgraph);
bNodeTree *ntree_eval = (bNodeTree *)DEG_get_evaluated_id(cj->compositor_depsgraph,
&cj->ntree->id);
cj->localtree = bke::node_tree_localize(ntree_eval, nullptr);
if (cj->recalc_flags) {
compo_tag_output_nodes(cj->localtree, cj->recalc_flags);
}
cj->re = RE_NewInteractiveCompositorRender(scene);
if (scene->r.compositor_device == SCE_COMPOSITOR_DEVICE_GPU) {
RE_system_gpu_context_ensure(cj->re);
}
}
/* Called before redraw notifiers, it moves finished previews over. */
static void compo_updatejob(void * /*cjv*/)
{
WM_main_add_notifier(NC_SCENE | ND_COMPO_RESULT, nullptr);
}
static void compo_progressjob(void *cjv, float progress)
{
CompoJob *cj = (CompoJob *)cjv;
*(cj->progress) = progress;
}
/* Only this runs inside thread. */
static void compo_startjob(void *cjv, wmJobWorkerStatus *worker_status)
{
CompoJob *cj = (CompoJob *)cjv;
2012-06-21 13:19:19 +00:00
bNodeTree *ntree = cj->localtree;
Scene *scene = DEG_get_evaluated_scene(cj->compositor_depsgraph);
if (scene->use_nodes == false) {
return;
}
cj->stop = &worker_status->stop;
cj->do_update = &worker_status->do_update;
cj->progress = &worker_status->progress;
ntree->runtime->test_break = compo_breakjob;
ntree->runtime->tbh = cj;
ntree->runtime->stats_draw = compo_statsdrawjob;
ntree->runtime->sdh = cj;
ntree->runtime->progress = compo_progressjob;
ntree->runtime->prh = cj;
ntree->runtime->update_draw = compo_redrawjob;
ntree->runtime->udh = cj;
BKE_callback_exec_id(cj->bmain, &cj->scene->id, BKE_CB_EVT_COMPOSITE_PRE);
if ((scene->r.scemode & R_MULTIVIEW) == 0) {
COM_execute(cj->re, &scene->r, scene, ntree, "", nullptr, &cj->profiler, cj->needed_outputs);
}
else {
LISTBASE_FOREACH (SceneRenderView *, srv, &scene->r.views) {
if (BKE_scene_multiview_is_render_view_active(&scene->r, srv) == false) {
continue;
}
COM_execute(
cj->re, &scene->r, scene, ntree, srv->name, nullptr, &cj->profiler, cj->needed_outputs);
Multi-View and Stereo 3D Official Documentation: http://www.blender.org/manual/render/workflows/multiview.html Implemented Features ==================== Builtin Stereo Camera * Convergence Mode * Interocular Distance * Convergence Distance * Pivot Mode Viewport * Cameras * Plane * Volume Compositor * View Switch Node * Image Node Multi-View OpenEXR support Sequencer * Image/Movie Strips 'Use Multiview' UV/Image Editor * Option to see Multi-View images in Stereo-3D or its individual images * Save/Open Multi-View (OpenEXR, Stereo3D, individual views) images I/O * Save/Open Multi-View (OpenEXR, Stereo3D, individual views) images Scene Render Views * Ability to have an arbitrary number of views in the scene Missing Bits ============ First rule of Multi-View bug report: If something is not working as it should *when Views is off* this is a severe bug, do mention this in the report. Second rule is, if something works *when Views is off* but doesn't (or crashes) when *Views is on*, this is a important bug. Do mention this in the report. Everything else is likely small todos, and may wait until we are sure none of the above is happening. Apart from that there are those known issues: * Compositor Image Node poorly working for Multi-View OpenEXR (this was working prefectly before the 'Use Multi-View' functionality) * Selecting camera from Multi-View when looking from camera is problematic * Animation Playback (ctrl+F11) doesn't support stereo formats * Wrong filepath when trying to play back animated scene * Viewport Rendering doesn't support Multi-View * Overscan Rendering * Fullscreen display modes need to warn the user * Object copy should be aware of views suffix Acknowledgments =============== * Francesco Siddi for the help with the original feature specs and design * Brecht Van Lommel for the original review of the code and design early on * Blender Foundation for the Development Fund to support the project wrap up Final patch reviewers: * Antony Riakiotakis (psy-fi) * Campbell Barton (ideasman42) * Julian Eisel (Severin) * Sergey Sharybin (nazgul) * Thomas Dinged (dingto) Code contributors of the original branch in github: * Alexey Akishin * Gabriel Caraballo
2015-04-06 10:40:12 -03:00
}
}
ntree->runtime->test_break = nullptr;
ntree->runtime->stats_draw = nullptr;
ntree->runtime->progress = nullptr;
}
static void compo_canceljob(void *cjv)
{
CompoJob *cj = (CompoJob *)cjv;
Main *bmain = cj->bmain;
Scene *scene = cj->scene;
BKE_callback_exec_id(bmain, &scene->id, BKE_CB_EVT_COMPOSITE_CANCEL);
cj->cancelled = true;
scene->runtime->compositor.per_node_execution_time = cj->profiler.get_nodes_evaluation_times();
}
static void compo_completejob(void *cjv)
{
CompoJob *cj = (CompoJob *)cjv;
Main *bmain = cj->bmain;
Scene *scene = cj->scene;
BKE_callback_exec_id(bmain, &scene->id, BKE_CB_EVT_COMPOSITE_POST);
scene->runtime->compositor.per_node_execution_time = cj->profiler.get_nodes_evaluation_times();
}
/** \} */
} // namespace blender::ed::space_node
/* -------------------------------------------------------------------- */
/** \name Composite Job C API
* \{ */
/* Identify if the compositor can run. Currently, this only checks if the compositor is set to GPU
* and the render size exceeds what can be allocated as a texture in it. */
static bool is_compositing_possible(const bContext *C)
{
Scene *scene = CTX_data_scene(C);
/* CPU compositor can always run. */
if (scene->r.compositor_device != SCE_COMPOSITOR_DEVICE_GPU) {
return true;
}
int width, height;
BKE_render_resolution(&scene->r, false, &width, &height);
const int max_texture_size = GPU_max_texture_size();
/* There is no way to know if the render size is too large except if we actually allocate a test
* texture, which we want to avoid due its cost. So we employ a heuristic that so far has worked
* with all known GPU drivers. */
if (size_t(width) * height > (size_t(max_texture_size) * max_texture_size) / 4) {
WM_report(RPT_ERROR, "Render size too large for GPU, use CPU compositor instead");
return false;
}
return true;
}
/* Returns the compositor outputs that need to be computed because their result is visible to the
* user. */
static blender::compositor::OutputTypes get_compositor_needed_outputs(const bContext *C)
{
blender::compositor::OutputTypes needed_outputs = blender::compositor::OutputTypes::None;
wmWindowManager *window_manager = CTX_wm_manager(C);
LISTBASE_FOREACH (wmWindow *, window, &window_manager->windows) {
bScreen *screen = WM_window_get_active_screen(window);
LISTBASE_FOREACH (ScrArea *, area, &screen->areabase) {
SpaceLink *space_link = static_cast<SpaceLink *>(area->spacedata.first);
if (!space_link || !ELEM(space_link->spacetype, SPACE_NODE, SPACE_IMAGE)) {
continue;
}
if (space_link->spacetype == SPACE_NODE) {
const SpaceNode *space_node = reinterpret_cast<const SpaceNode *>(space_link);
if (space_node->flag & SNODE_BACKDRAW) {
needed_outputs |= blender::compositor::OutputTypes::Viewer;
}
if (space_node->overlay.flag & SN_OVERLAY_SHOW_PREVIEWS) {
needed_outputs |= blender::compositor::OutputTypes::Previews;
}
}
else if (space_link->spacetype == SPACE_IMAGE) {
const SpaceImage *space_image = reinterpret_cast<const SpaceImage *>(space_link);
Image *image = ED_space_image(space_image);
if (!image || image->source != IMA_SRC_VIEWER) {
continue;
}
if (image->type == IMA_TYPE_R_RESULT) {
needed_outputs |= blender::compositor::OutputTypes::Composite;
}
else if (image->type == IMA_TYPE_COMPOSITE) {
needed_outputs |= blender::compositor::OutputTypes::Viewer;
}
}
/* All outputs are already needed, return early. */
if (needed_outputs ==
(blender::compositor::OutputTypes::Composite | blender::compositor::OutputTypes::Viewer |
blender::compositor::OutputTypes::Previews))
{
return needed_outputs;
}
}
}
return needed_outputs;
}
void ED_node_composite_job(const bContext *C, bNodeTree *nodetree, Scene *scene_owner)
{
blender::compositor::OutputTypes needed_outputs = get_compositor_needed_outputs(C);
if (needed_outputs == blender::compositor::OutputTypes::None) {
return;
}
using namespace blender::ed::space_node;
Main *bmain = CTX_data_main(C);
Scene *scene = CTX_data_scene(C);
ViewLayer *view_layer = CTX_data_view_layer(C);
Render & Compositing Thread Fixes * Rendering twice or more could crash layer/pass buttons. * Compositing would crash while drawing the image. * Rendering animations could also crash drawing the image. * Compositing could crash * Starting to rendering while preview render / compo was still running could crash. * Exiting while rendering an animation would not abort the renderer properly, making Blender seemingly freeze. * Fixes theoretically possible issue with setting malloc lock with nested threads. * Drawing previews inside nodes could crash when those nodes were being rendered at the same time. There's more crashes, manipulating the scene data or undo can still crash, this commit only focuses on making sure the image buffer and render result access is thread safe. Implementation: * Rather than assuming the render result does not get freed during render, which seems to be quite difficult to do given that e.g. the compositor is allowed to change the size of the buffer or output different passes, the render result is now protected with a read/write mutex. * The read/write mutex allows multiple readers (and pixel writers) at the same time, but only allows one writer to manipulate the data structure. * Added BKE_image_acquire_ibuf/BKE_image_release_ibuf to access images being rendered, cases where this is not needed (most code) can still use BKE_image_get_ibuf. * The job manager now allows only one rendering job at the same time, rather than the G.rendering check which was not reliable.
2009-09-30 18:18:32 +00:00
if (!is_compositing_possible(C)) {
return;
}
/* See #32272. */
if (G.is_rendering) {
return;
}
2012-08-15 11:31:04 +00:00
#ifdef USE_ESC_COMPO
G.is_break = false;
2012-08-15 11:31:04 +00:00
#endif
BKE_image_backup_render(
scene, BKE_image_ensure_viewer(bmain, IMA_TYPE_R_RESULT, "Render Result"), false);
wmJob *wm_job = WM_jobs_get(CTX_wm_manager(C),
CTX_wm_window(C),
scene_owner,
"Compositing",
WM_JOB_EXCL_RENDER | WM_JOB_PROGRESS,
WM_JOB_TYPE_COMPOSITE);
CompoJob *cj = MEM_new<CompoJob>("compo job");
/* Custom data for preview thread. */
cj->bmain = bmain;
cj->scene = scene;
cj->view_layer = view_layer;
cj->ntree = nodetree;
cj->recalc_flags = compo_get_recalc_flags(C);
cj->needed_outputs = needed_outputs;
/* Set up job. */
WM_jobs_customdata_set(wm_job, cj, compo_freejob);
WM_jobs_timer(wm_job, 0.1, NC_SCENE | ND_COMPO_RESULT, NC_SCENE | ND_COMPO_RESULT);
WM_jobs_callbacks_ex(wm_job,
compo_startjob,
compo_initjob,
compo_updatejob,
nullptr,
compo_completejob,
compo_canceljob);
WM_jobs_start(CTX_wm_manager(C), wm_job);
}
/** \} */
namespace blender::ed::space_node {
/* -------------------------------------------------------------------- */
/** \name Composite Poll & Utility Functions
* \{ */
2018-07-02 11:47:00 +02:00
bool composite_node_active(bContext *C)
{
2012-06-21 13:19:19 +00:00
if (ED_operator_node_active(C)) {
SpaceNode *snode = CTX_wm_space_node(C);
if (ED_node_is_compositor(snode)) {
return true;
}
}
return false;
}
2018-07-02 11:47:00 +02:00
bool composite_node_editable(bContext *C)
{
if (ED_operator_node_editable(C)) {
SpaceNode *snode = CTX_wm_space_node(C);
if (ED_node_is_compositor(snode)) {
return true;
}
}
return false;
}
/** \} */
} // namespace blender::ed::space_node
/* -------------------------------------------------------------------- */
/** \name Node Editor Public API Functions
* \{ */
void ED_node_set_tree_type(SpaceNode *snode, blender::bke::bNodeTreeType *typeinfo)
{
if (typeinfo) {
STRNCPY(snode->tree_idname, typeinfo->idname.c_str());
}
else {
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
snode->tree_idname[0] = '\0';
}
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
}
Fix #121480: Cryptomatte shows some objects as black The issue originates to the change in default view transform from Filmic to AgX, which does slightly different clipping, and clips color to black if there is any negative values. This change implements an idea of skipping view transform for viewer node when it is connected to the Pick output of the cryptomatte node. It actually goes a bit deeper than this and any operation can tag its result as a non-color data, and the viewer node will respect that. It is achieved by passing some extra meta-data along the evaluation pipeline. For the CPU compositor it is done via MetaData, and for the GPU compositor it is done as part of Result. Connecting any other node in-between of viewer and Cryptomatte's Pick will treat the result as color values, and apply color management. Connecting Pick to the Composite output will also consider it as color, since there is no concept of non-color-managed render result. An alternative approaches were tested, including: - Doing negative value clamping at the viewer node. It does not work for legacy cryptomatte node, as it needs to have access to original non-modified Pick result. - Change the order of components, and store ID in another channel. Using one of other of Green or Blue channels might work for some view transforms, but it does not work for AgX. Using Alpha channel seemingly works better, but it is has different issues caused by the fact that display transform de-associates alpha, leading to over-exposed regions which are hard to see in the file from the report. And might lead to the similar issues as the initial report with other objects or view transforms. - Use positive values in the Pick channel. It does make things visible, but they are all white due to the nature of how AgX works, making it not so useful as a result. Pull Request: https://projects.blender.org/blender/blender/pulls/122177
2024-05-24 17:25:57 +02:00
bool ED_node_is_compositor(const SpaceNode *snode)
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
{
return snode->tree_idname == ntreeType_Composite->idname;
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
}
bool ED_node_is_shader(SpaceNode *snode)
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
{
return snode->tree_idname == ntreeType_Shader->idname;
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
}
bool ED_node_is_texture(SpaceNode *snode)
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
{
return snode->tree_idname == ntreeType_Texture->idname;
}
bool ED_node_is_geometry(SpaceNode *snode)
{
return snode->tree_idname == ntreeType_Geometry->idname;
}
bool ED_node_supports_preview(SpaceNode *snode)
{
Nodes: experimental node previews in the shader editor First implementation of node previews in the shader node editor. Using the same user interface as compositor node previews, most shader nodes can now be previewed (except group in/output and material output). This is currently still an experimental feature, as polishing of the user experience and performance improvements are planned. These will be easier to do as incremental changes on this implementation. See #110353 for details on the work that remains to be done and known limitations. Implementation notes: We take advantage of the `RenderResult` available as `ImBuf` images to store a `Render` for every viewed nested node tree present in a `SpaceNode`. The computation is initiated at the moment of drawing nodes overlays. One render is started for the current nodetree, having a `ViewLayer` associated with each previewed node. We separate the previewed nodes in two categories: the shader ones and the non-shader ones. - For non-shader nodes, we use AOVs which highly speed up the rendering process by rendering every non-shader nodes at the same time. They are rendered in the first `ViewLayer`. - For shader nodes, we render them each in a different `ViewLayer`, by rerouting the node to the output of the material in the preview scene. The preview scene takes the same aspect as the Material preview scene, and the same preview object is used. At the moment of drawing the node overlay, we take the `Render` of the viewed node tree and extract the `ImBuf` of the wanted viewlayer/pass for each previewed node. Pull Request: https://projects.blender.org/blender/blender/pulls/110065
2023-08-08 17:36:06 +02:00
return ED_node_is_compositor(snode) ||
(USER_EXPERIMENTAL_TEST(&U, use_shader_node_previews) && ED_node_is_shader(snode));
}
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
void ED_node_shader_default(const bContext *C, ID *id)
{
Main *bmain = CTX_data_main(C);
if (GS(id->name) == ID_MA) {
/* Materials */
Object *ob = CTX_data_active_object(C);
Material *ma = (Material *)id;
Material *ma_default;
if (ob && ob->type == OB_VOLUME) {
ma_default = BKE_material_default_volume();
}
else {
ma_default = BKE_material_default_surface();
}
ma->nodetree = blender::bke::node_tree_copy_tree(bmain, ma_default->nodetree);
ma->nodetree->owner_id = &ma->id;
for (bNode *node_iter : ma->nodetree->all_nodes()) {
STRNCPY_UTF8(node_iter->name, DATA_(node_iter->name));
blender::bke::node_unique_name(ma->nodetree, node_iter);
}
BKE_ntree_update_after_single_tree_change(*bmain, *ma->nodetree);
}
else if (ELEM(GS(id->name), ID_WO, ID_LA)) {
/* Emission */
bNodeTree *ntree = blender::bke::node_tree_add_tree_embedded(
nullptr, id, "Shader Nodetree", ntreeType_Shader->idname);
bNode *shader, *output;
if (GS(id->name) == ID_WO) {
World *world = (World *)id;
shader = blender::bke::node_add_static_node(nullptr, ntree, SH_NODE_BACKGROUND);
output = blender::bke::node_add_static_node(nullptr, ntree, SH_NODE_OUTPUT_WORLD);
blender::bke::node_add_link(ntree,
shader,
blender::bke::node_find_socket(shader, SOCK_OUT, "Background"),
output,
blender::bke::node_find_socket(output, SOCK_IN, "Surface"));
bNodeSocket *color_sock = blender::bke::node_find_socket(shader, SOCK_IN, "Color");
copy_v3_v3(((bNodeSocketValueRGBA *)color_sock->default_value)->value, &world->horr);
}
else {
shader = blender::bke::node_add_static_node(nullptr, ntree, SH_NODE_EMISSION);
output = blender::bke::node_add_static_node(nullptr, ntree, SH_NODE_OUTPUT_LIGHT);
blender::bke::node_add_link(ntree,
shader,
blender::bke::node_find_socket(shader, SOCK_OUT, "Emission"),
output,
blender::bke::node_find_socket(output, SOCK_IN, "Surface"));
}
shader->location[0] = 10.0f;
shader->location[1] = 300.0f;
output->location[0] = 300.0f;
output->location[1] = 300.0f;
blender::bke::node_set_active(ntree, output);
BKE_ntree_update_after_single_tree_change(*bmain, *ntree);
}
else {
printf("ED_node_shader_default called on wrong ID type.\n");
return;
}
}
void ED_node_composit_default(const bContext *C, Scene *sce)
{
/* but lets check it anyway */
if (sce->nodetree) {
if (G.debug & G_DEBUG) {
printf("error in composite initialize\n");
}
return;
}
sce->nodetree = blender::bke::node_tree_add_tree_embedded(
nullptr, &sce->id, "Compositing Nodetree", ntreeType_Composite->idname);
bNode *out = blender::bke::node_add_static_node(C, sce->nodetree, CMP_NODE_COMPOSITE);
out->location[0] = 200.0f;
out->location[1] = 200.0f;
bNode *in = blender::bke::node_add_static_node(C, sce->nodetree, CMP_NODE_R_LAYERS);
in->location[0] = -200.0f;
in->location[1] = 200.0f;
blender::bke::node_set_active(sce->nodetree, in);
/* Links from color to color. */
bNodeSocket *fromsock = (bNodeSocket *)in->outputs.first;
bNodeSocket *tosock = (bNodeSocket *)out->inputs.first;
blender::bke::node_add_link(sce->nodetree, in, fromsock, out, tosock);
BKE_ntree_update_after_single_tree_change(*CTX_data_main(C), *sce->nodetree);
}
void ED_node_texture_default(const bContext *C, Tex *tex)
{
if (tex->nodetree) {
if (G.debug & G_DEBUG) {
printf("error in texture initialize\n");
}
return;
}
tex->nodetree = blender::bke::node_tree_add_tree_embedded(
nullptr, &tex->id, "Texture Nodetree", ntreeType_Texture->idname);
bNode *out = blender::bke::node_add_static_node(C, tex->nodetree, TEX_NODE_OUTPUT);
out->location[0] = 300.0f;
out->location[1] = 300.0f;
bNode *in = blender::bke::node_add_static_node(C, tex->nodetree, TEX_NODE_CHECKER);
in->location[0] = 10.0f;
in->location[1] = 300.0f;
blender::bke::node_set_active(tex->nodetree, in);
bNodeSocket *fromsock = (bNodeSocket *)in->outputs.first;
bNodeSocket *tosock = (bNodeSocket *)out->inputs.first;
blender::bke::node_add_link(tex->nodetree, in, fromsock, out, tosock);
BKE_ntree_update_after_single_tree_change(*CTX_data_main(C), *tex->nodetree);
}
namespace blender::ed::space_node {
void snode_set_context(const bContext &C)
{
/* NOTE: Here we set the active tree(s), even called for each redraw now, so keep it fast :). */
SpaceNode *snode = CTX_wm_space_node(&C);
bke::bNodeTreeType *treetype = bke::node_tree_type_find(snode->tree_idname);
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
bNodeTree *ntree = snode->nodetree;
ID *id = snode->id, *from = snode->from;
/* Check the tree type. */
if (!treetype || (treetype->poll && !treetype->poll(&C, treetype))) {
/* Invalid tree type, skip.
* NOTE: not resetting the node path here, invalid #bNodeTreeType
* may still be registered at a later point. */
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
return;
}
if (snode->nodetree && !STREQ(snode->nodetree->idname, snode->tree_idname)) {
/* Current tree does not match selected type, clear tree path. */
ntree = nullptr;
id = nullptr;
from = nullptr;
}
if (!(snode->flag & SNODE_PIN) || ntree == nullptr) {
if (treetype->get_from_context) {
/* Reset and update from context. */
ntree = nullptr;
id = nullptr;
from = nullptr;
treetype->get_from_context(&C, treetype, &ntree, &id, &from);
}
}
if (snode->nodetree != ntree || snode->id != id || snode->from != from ||
(snode->treepath.last == nullptr && ntree))
{
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
ED_node_tree_start(snode, ntree, id, from);
2013-03-18 18:25:05 +00:00
}
}
} // namespace blender::ed::space_node
void ED_node_set_active(
Main *bmain, SpaceNode *snode, bNodeTree *ntree, bNode *node, bool *r_active_texture_changed)
{
if (r_active_texture_changed) {
*r_active_texture_changed = false;
}
blender::bke::node_set_active(ntree, node);
if (node->type_legacy == NODE_GROUP) {
return;
}
const bool was_output = (node->flag & NODE_DO_OUTPUT) != 0;
bool do_update = false;
/* Generic node group output: set node as active output. */
if (node->is_group_output()) {
for (bNode *node_iter : ntree->all_nodes()) {
if (node_iter->is_group_output()) {
node_iter->flag &= ~NODE_DO_OUTPUT;
}
}
node->flag |= NODE_DO_OUTPUT;
if (!was_output) {
do_update = true;
BKE_ntree_update_tag_active_output_changed(ntree);
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
}
}
/* Tree specific activate calls. */
if (ntree->type == NTREE_SHADER) {
if (ELEM(node->type_legacy,
SH_NODE_OUTPUT_MATERIAL,
SH_NODE_OUTPUT_WORLD,
SH_NODE_OUTPUT_LIGHT,
SH_NODE_OUTPUT_LINESTYLE))
{
for (bNode *node_iter : ntree->all_nodes()) {
if (node_iter->type_legacy == node->type_legacy) {
node_iter->flag &= ~NODE_DO_OUTPUT;
}
}
node->flag |= NODE_DO_OUTPUT;
BKE_ntree_update_tag_active_output_changed(ntree);
}
Nodes: refactor node tree update handling Goals of this refactor: * More unified approach to updating everything that needs to be updated after a change in a node tree. * The updates should happen in the correct order and quadratic or worse algorithms should be avoided. * Improve detection of changes to the output to avoid tagging the depsgraph when it's not necessary. * Move towards a more declarative style of defining nodes by having a more centralized update procedure. The refactor consists of two main parts: * Node tree tagging and update refactor. * Generally, when changes are done to a node tree, it is tagged dirty until a global update function is called that updates everything in the correct order. * The tagging is more fine-grained compared to before, to allow for more precise depsgraph update tagging. * Depsgraph changes. * The shading specific depsgraph node for node trees as been removed. * Instead, there is a new `NTREE_OUTPUT` depsgrap node, which is only tagged when the output of the node tree changed (e.g. the Group Output or Material Output node). * The copy-on-write relation from node trees to the data block they are embedded in is now non-flushing. This avoids e.g. triggering a material update after the shader node tree changed in unrelated ways. Instead the material has a flushing relation to the new `NTREE_OUTPUT` node now. * The depsgraph no longer reports data block changes through to cycles through `Depsgraph.updates` when only the node tree changed in ways that do not affect the output. Avoiding unnecessary updates seems to work well for geometry nodes and cycles. The situation is a bit worse when there are drivers on the node tree, but that could potentially be improved separately in the future. Avoiding updates in eevee and the compositor is more tricky, but also less urgent. * Eevee updates are triggered by calling `DRW_notify_view_update` in `ED_render_view3d_update` indirectly from `DEG_editors_update`. * Compositor updates are triggered by `ED_node_composite_job` in `node_area_refresh`. This is triggered by calling `ED_area_tag_refresh` in `node_area_listener`. Removing updates always has the risk of breaking some dependency that no one was aware of. It's not unlikely that this will happen here as well. Adding back missing updates should be quite a bit easier than getting rid of unnecessary updates though. Differential Revision: https://developer.blender.org/D13246
2021-12-21 15:18:56 +01:00
BKE_main_ensure_invariants(*bmain, ntree->id);
if (node->flag & NODE_ACTIVE_TEXTURE) {
2023-08-21 10:05:45 +10:00
/* If active texture changed, free GLSL materials. */
LISTBASE_FOREACH (Material *, ma, &bmain->materials) {
if (ma->nodetree && ma->use_nodes &&
blender::bke::node_tree_contains_tree(ma->nodetree, ntree))
{
GPU_material_free(&ma->gpumaterial);
/* Sync to active texpaint slot, otherwise we can end up painting on a different slot
* than we are looking at. */
if (ma->texpaintslot) {
if (node->id != nullptr && GS(node->id->name) == ID_IM) {
Image *image = (Image *)node->id;
for (int i = 0; i < ma->tot_slots; i++) {
if (ma->texpaintslot[i].ima == image) {
ma->paint_active_slot = i;
}
}
}
}
}
}
LISTBASE_FOREACH (World *, wo, &bmain->worlds) {
if (wo->nodetree && wo->use_nodes &&
blender::bke::node_tree_contains_tree(wo->nodetree, ntree))
{
GPU_material_free(&wo->gpumaterial);
}
}
/* Sync to Image Editor under the following conditions:
* - current image is not pinned
* - current image is not a Render Result or ViewerNode (want to keep looking at these) */
if (node->id != nullptr && GS(node->id->name) == ID_IM) {
Image *image = (Image *)node->id;
ED_space_image_sync(bmain, image, true);
}
if (r_active_texture_changed) {
*r_active_texture_changed = true;
}
BKE_main_ensure_invariants(*bmain, ntree->id);
WM_main_add_notifier(NC_IMAGE, nullptr);
}
WM_main_add_notifier(NC_MATERIAL | ND_NODES, node->id);
}
else if (ntree->type == NTREE_COMPOSIT) {
/* Make active viewer, currently only one is supported. */
if (node->type_legacy == CMP_NODE_VIEWER) {
for (bNode *node_iter : ntree->all_nodes()) {
if (node_iter->type_legacy == CMP_NODE_VIEWER) {
node_iter->flag &= ~NODE_DO_OUTPUT;
}
}
node->flag |= NODE_DO_OUTPUT;
if (was_output == 0) {
BKE_ntree_update_tag_active_output_changed(ntree);
BKE_main_ensure_invariants(*bmain, ntree->id);
}
/* Adding a node doesn't link this yet. */
node->id = (ID *)BKE_image_ensure_viewer(bmain, IMA_TYPE_COMPOSITE, "Viewer Node");
}
else if (node->type_legacy == CMP_NODE_COMPOSITE) {
if (was_output == 0) {
for (bNode *node_iter : ntree->all_nodes()) {
if (node_iter->type_legacy == CMP_NODE_COMPOSITE) {
node_iter->flag &= ~NODE_DO_OUTPUT;
}
}
node->flag |= NODE_DO_OUTPUT;
BKE_ntree_update_tag_active_output_changed(ntree);
BKE_main_ensure_invariants(*bmain, ntree->id);
}
}
else if (do_update) {
BKE_main_ensure_invariants(*bmain, ntree->id);
}
}
else if (ntree->type == NTREE_GEOMETRY) {
if (node->type_legacy == GEO_NODE_VIEWER) {
if ((node->flag & NODE_DO_OUTPUT) == 0) {
for (bNode *node_iter : ntree->all_nodes()) {
if (node_iter->type_legacy == GEO_NODE_VIEWER) {
node_iter->flag &= ~NODE_DO_OUTPUT;
}
}
node->flag |= NODE_DO_OUTPUT;
}
blender::ed::viewer_path::activate_geometry_node(*bmain, *snode, *node);
}
}
}
void ED_node_post_apply_transform(bContext * /*C*/, bNodeTree * /*ntree*/)
{
/* XXX This does not work due to layout functions relying on node->block,
* which only exists during actual drawing. Can we rely on valid draw_bounds rects?
*/
/* make sure nodes have correct bounding boxes after transform */
2021-02-05 16:23:34 +11:00
// node_update_nodetree(C, ntree, 0.0f, 0.0f);
}
/** \} */
namespace blender::ed::space_node {
/* -------------------------------------------------------------------- */
/** \name Node Generic
* \{ */
static bool socket_is_occluded(const float2 &location,
const bNode &node_the_socket_belongs_to,
const Span<bNode *> sorted_nodes)
{
for (bNode *node : sorted_nodes) {
if (node == &node_the_socket_belongs_to) {
/* Nodes after this one are underneath and can't occlude the socket. */
return false;
}
rctf socket_hitbox;
const float socket_hitbox_radius = NODE_SOCKSIZE - 0.1f * U.widget_unit;
BLI_rctf_init_pt_radius(&socket_hitbox, location, socket_hitbox_radius);
if (BLI_rctf_inside_rctf(&node->runtime->draw_bounds, &socket_hitbox)) {
return true;
}
}
return false;
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Node Size Widget Operator
* \{ */
struct NodeSizeWidget {
float mxstart, mystart;
float oldlocx, oldlocy;
float oldwidth, oldheight;
int directions;
bool precision, snap_to_grid;
};
static void node_resize_init(
bContext *C, wmOperator *op, const float2 &cursor, const bNode *node, NodeResizeDirection dir)
{
Scene *scene = CTX_data_scene(C);
NodeSizeWidget *nsw = MEM_cnew<NodeSizeWidget>(__func__);
op->customdata = nsw;
nsw->mxstart = cursor.x;
nsw->mystart = cursor.y;
/* store old */
nsw->oldlocx = node->location[0];
nsw->oldlocy = node->location[1];
nsw->oldwidth = node->width;
nsw->oldheight = node->height;
nsw->directions = dir;
nsw->snap_to_grid = scene->toolsettings->snap_flag_node;
WM_cursor_modal_set(CTX_wm_window(C), node_get_resize_cursor(dir));
/* add modal handler */
WM_event_add_modal_handler(C, op);
}
static void node_resize_exit(bContext *C, wmOperator *op, bool cancel)
{
WM_cursor_modal_restore(CTX_wm_window(C));
/* Restore old data on cancel. */
if (cancel) {
SpaceNode *snode = CTX_wm_space_node(C);
bNode *node = bke::node_get_active(snode->edittree);
NodeSizeWidget *nsw = (NodeSizeWidget *)op->customdata;
node->location[0] = nsw->oldlocx;
node->location[1] = nsw->oldlocy;
node->width = nsw->oldwidth;
node->height = nsw->oldheight;
}
MEM_freeN(op->customdata);
op->customdata = nullptr;
}
enum class NodeResizeAction : int {
Begin = 0,
Cancel = 1,
SnapInvertOn = 2,
SnapInvertOff = 3,
};
wmKeyMap *node_resize_modal_keymap(wmKeyConfig *keyconf)
{
static const EnumPropertyItem modal_items[] = {
{int(NodeResizeAction::Begin), "BEGIN", 0, "Resize Node", ""},
{int(NodeResizeAction::Cancel), "CANCEL", 0, "Cancel", ""},
{int(NodeResizeAction::SnapInvertOn), "SNAP_INVERT_ON", 0, "Snap Invert", ""},
{int(NodeResizeAction::SnapInvertOff), "SNAP_INVERT_OFF", 0, "Snap Invert", ""},
{0, nullptr, 0, nullptr, nullptr},
};
wmKeyMap *keymap = WM_modalkeymap_find(keyconf, "Node Resize Modal Map");
if (keymap && keymap->modal_items) {
return nullptr;
}
keymap = WM_modalkeymap_ensure(keyconf, "Node Resize Modal Map", modal_items);
WM_modalkeymap_assign(keymap, "NODE_OT_resize");
return keymap;
}
/* Compute the nearest 1D coordinate corresponding to the nearest grid in node editors. */
static float nearest_node_grid_coord(float co)
{
/* Size and location of nodes are independent of UI scale, so grid size should be independent of
* UI scale as well. */
float grid_size = grid_size_get() / UI_SCALE_FAC;
float rest = fmod(co, grid_size);
float offset = rest - grid_size / 2 >= 0 ? grid_size : 0;
return co - rest + offset;
}
static int node_resize_modal(bContext *C, wmOperator *op, const wmEvent *event)
{
2012-06-21 13:19:19 +00:00
SpaceNode *snode = CTX_wm_space_node(C);
ARegion *region = CTX_wm_region(C);
bNode *node = bke::node_get_active(snode->edittree);
NodeSizeWidget *nsw = (NodeSizeWidget *)op->customdata;
if (event->type == EVT_MODAL_MAP) {
switch (NodeResizeAction(event->val)) {
case NodeResizeAction::Begin: {
return OPERATOR_RUNNING_MODAL;
}
case NodeResizeAction::Cancel: {
node_resize_exit(C, op, true);
ED_region_tag_redraw(region);
return OPERATOR_CANCELLED;
}
case NodeResizeAction::SnapInvertOn:
case NodeResizeAction::SnapInvertOff: {
nsw->snap_to_grid = !nsw->snap_to_grid;
return OPERATOR_RUNNING_MODAL;
}
}
}
switch (event->type) {
case MOUSEMOVE: {
int2 mval;
WM_event_drag_start_mval(event, region, mval);
float mx, my;
UI_view2d_region_to_view(&region->v2d, mval.x, mval.y, &mx, &my);
float dx = (mx - nsw->mxstart) / UI_SCALE_FAC;
const float dy = (my - nsw->mystart) / UI_SCALE_FAC;
if (node) {
float *pwidth = &node->width;
float oldwidth = nsw->oldwidth;
float widthmin = node->typeinfo->minwidth;
float widthmax = node->typeinfo->maxwidth;
{
if (nsw->directions & NODE_RESIZE_RIGHT) {
*pwidth = oldwidth + dx;
if (nsw->snap_to_grid) {
*pwidth = nearest_node_grid_coord(*pwidth);
}
CLAMP(*pwidth, widthmin, widthmax);
}
if (nsw->directions & NODE_RESIZE_LEFT) {
float locmax = nsw->oldlocx + oldwidth;
if (nsw->snap_to_grid) {
dx = nearest_node_grid_coord(dx);
}
node->location[0] = nsw->oldlocx + dx;
CLAMP(node->location[0], locmax - widthmax, locmax - widthmin);
*pwidth = locmax - node->location[0];
}
}
/* Height works the other way round. */
{
float heightmin = UI_SCALE_FAC * node->typeinfo->minheight;
float heightmax = UI_SCALE_FAC * node->typeinfo->maxheight;
if (nsw->directions & NODE_RESIZE_TOP) {
float locmin = nsw->oldlocy - nsw->oldheight;
node->location[1] = nsw->oldlocy + dy;
CLAMP(node->location[1], locmin + heightmin, locmin + heightmax);
node->height = node->location[1] - locmin;
}
if (nsw->directions & NODE_RESIZE_BOTTOM) {
node->height = nsw->oldheight - dy;
CLAMP(node->height, heightmin, heightmax);
}
}
}
ED_region_tag_redraw(region);
break;
}
case LEFTMOUSE:
case MIDDLEMOUSE:
case RIGHTMOUSE: {
if (event->val == KM_RELEASE) {
node_resize_exit(C, op, false);
ED_node_post_apply_transform(C, snode->edittree);
return OPERATOR_FINISHED;
}
break;
}
}
return OPERATOR_RUNNING_MODAL;
}
static int node_resize_invoke(bContext *C, wmOperator *op, const wmEvent *event)
{
2012-06-21 13:19:19 +00:00
SpaceNode *snode = CTX_wm_space_node(C);
ARegion *region = CTX_wm_region(C);
const bNode *node = bke::node_get_active(snode->edittree);
if (node == nullptr) {
return OPERATOR_CANCELLED | OPERATOR_PASS_THROUGH;
}
/* Convert mouse coordinates to `v2d` space. */
float2 cursor;
int2 mval;
WM_event_drag_start_mval(event, region, mval);
UI_view2d_region_to_view(&region->v2d, mval.x, mval.y, &cursor.x, &cursor.y);
const NodeResizeDirection dir = node_get_resize_direction(*snode, node, cursor.x, cursor.y);
if (dir == NODE_RESIZE_NONE) {
return OPERATOR_CANCELLED | OPERATOR_PASS_THROUGH;
}
node_resize_init(C, op, cursor, node, dir);
return OPERATOR_RUNNING_MODAL;
}
static void node_resize_cancel(bContext *C, wmOperator *op)
{
node_resize_exit(C, op, true);
}
void NODE_OT_resize(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Resize Node";
ot->idname = "NODE_OT_resize";
ot->description = "Resize a node";
/* api callbacks */
ot->invoke = node_resize_invoke;
ot->modal = node_resize_modal;
ot->poll = ED_operator_node_active;
ot->cancel = node_resize_cancel;
/* flags */
ot->flag = OPTYPE_BLOCKING;
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Node Hidden Sockets
* \{ */
bool node_has_hidden_sockets(bNode *node)
{
LISTBASE_FOREACH (bNodeSocket *, sock, &node->inputs) {
if (sock->flag & SOCK_HIDDEN) {
return true;
}
}
LISTBASE_FOREACH (bNodeSocket *, sock, &node->outputs) {
if (sock->flag & SOCK_HIDDEN) {
return true;
}
}
return false;
}
2023-06-04 14:55:20 +10:00
void node_set_hidden_sockets(bNode *node, int set)
{
/* The Reroute node is the socket itself, do not hide this. */
if (node->is_reroute()) {
return;
}
if (set == 0) {
LISTBASE_FOREACH (bNodeSocket *, sock, &node->inputs) {
sock->flag &= ~SOCK_HIDDEN;
}
LISTBASE_FOREACH (bNodeSocket *, sock, &node->outputs) {
sock->flag &= ~SOCK_HIDDEN;
}
}
else {
/* Hide unused sockets. */
LISTBASE_FOREACH (bNodeSocket *, sock, &node->inputs) {
if (sock->link == nullptr) {
sock->flag |= SOCK_HIDDEN;
}
}
LISTBASE_FOREACH (bNodeSocket *, sock, &node->outputs) {
if ((sock->flag & SOCK_IS_LINKED) == 0) {
sock->flag |= SOCK_HIDDEN;
}
}
}
}
bool node_is_previewable(const SpaceNode &snode, const bNodeTree &ntree, const bNode &node)
Nodes: experimental node previews in the shader editor First implementation of node previews in the shader node editor. Using the same user interface as compositor node previews, most shader nodes can now be previewed (except group in/output and material output). This is currently still an experimental feature, as polishing of the user experience and performance improvements are planned. These will be easier to do as incremental changes on this implementation. See #110353 for details on the work that remains to be done and known limitations. Implementation notes: We take advantage of the `RenderResult` available as `ImBuf` images to store a `Render` for every viewed nested node tree present in a `SpaceNode`. The computation is initiated at the moment of drawing nodes overlays. One render is started for the current nodetree, having a `ViewLayer` associated with each previewed node. We separate the previewed nodes in two categories: the shader ones and the non-shader ones. - For non-shader nodes, we use AOVs which highly speed up the rendering process by rendering every non-shader nodes at the same time. They are rendered in the first `ViewLayer`. - For shader nodes, we render them each in a different `ViewLayer`, by rerouting the node to the output of the material in the preview scene. The preview scene takes the same aspect as the Material preview scene, and the same preview object is used. At the moment of drawing the node overlay, we take the `Render` of the viewed node tree and extract the `ImBuf` of the wanted viewlayer/pass for each previewed node. Pull Request: https://projects.blender.org/blender/blender/pulls/110065
2023-08-08 17:36:06 +02:00
{
if (!(snode.overlay.flag & SN_OVERLAY_SHOW_OVERLAYS) ||
!(snode.overlay.flag & SN_OVERLAY_SHOW_PREVIEWS))
{
return false;
}
Nodes: experimental node previews in the shader editor First implementation of node previews in the shader node editor. Using the same user interface as compositor node previews, most shader nodes can now be previewed (except group in/output and material output). This is currently still an experimental feature, as polishing of the user experience and performance improvements are planned. These will be easier to do as incremental changes on this implementation. See #110353 for details on the work that remains to be done and known limitations. Implementation notes: We take advantage of the `RenderResult` available as `ImBuf` images to store a `Render` for every viewed nested node tree present in a `SpaceNode`. The computation is initiated at the moment of drawing nodes overlays. One render is started for the current nodetree, having a `ViewLayer` associated with each previewed node. We separate the previewed nodes in two categories: the shader ones and the non-shader ones. - For non-shader nodes, we use AOVs which highly speed up the rendering process by rendering every non-shader nodes at the same time. They are rendered in the first `ViewLayer`. - For shader nodes, we render them each in a different `ViewLayer`, by rerouting the node to the output of the material in the preview scene. The preview scene takes the same aspect as the Material preview scene, and the same preview object is used. At the moment of drawing the node overlay, we take the `Render` of the viewed node tree and extract the `ImBuf` of the wanted viewlayer/pass for each previewed node. Pull Request: https://projects.blender.org/blender/blender/pulls/110065
2023-08-08 17:36:06 +02:00
if (ntree.type == NTREE_SHADER) {
return USER_EXPERIMENTAL_TEST(&U, use_shader_node_previews) && !node.is_frame();
Nodes: experimental node previews in the shader editor First implementation of node previews in the shader node editor. Using the same user interface as compositor node previews, most shader nodes can now be previewed (except group in/output and material output). This is currently still an experimental feature, as polishing of the user experience and performance improvements are planned. These will be easier to do as incremental changes on this implementation. See #110353 for details on the work that remains to be done and known limitations. Implementation notes: We take advantage of the `RenderResult` available as `ImBuf` images to store a `Render` for every viewed nested node tree present in a `SpaceNode`. The computation is initiated at the moment of drawing nodes overlays. One render is started for the current nodetree, having a `ViewLayer` associated with each previewed node. We separate the previewed nodes in two categories: the shader ones and the non-shader ones. - For non-shader nodes, we use AOVs which highly speed up the rendering process by rendering every non-shader nodes at the same time. They are rendered in the first `ViewLayer`. - For shader nodes, we render them each in a different `ViewLayer`, by rerouting the node to the output of the material in the preview scene. The preview scene takes the same aspect as the Material preview scene, and the same preview object is used. At the moment of drawing the node overlay, we take the `Render` of the viewed node tree and extract the `ImBuf` of the wanted viewlayer/pass for each previewed node. Pull Request: https://projects.blender.org/blender/blender/pulls/110065
2023-08-08 17:36:06 +02:00
}
return node.typeinfo->flag & NODE_PREVIEW;
}
static bool cursor_isect_multi_input_socket(const float2 &cursor, const bNodeSocket &socket)
{
const float node_socket_height = node_socket_calculate_height(socket);
const float2 location = socket.runtime->location;
/* `.xmax = socket->location[0] + NODE_SOCKSIZE * 5.5f`
* would be the same behavior as for regular sockets.
* But keep it smaller because for multi-input socket you
* sometimes want to drag the link to the other side, if you may
* accidentally pick the wrong link otherwise. */
rctf multi_socket_rect;
BLI_rctf_init(&multi_socket_rect,
location.x - NODE_SOCKSIZE * 4.0f,
location.x + NODE_SOCKSIZE * 2.0f,
location.y - node_socket_height,
location.y + node_socket_height);
if (BLI_rctf_isect_pt(&multi_socket_rect, cursor.x, cursor.y)) {
return true;
}
return false;
}
bNodeSocket *node_find_indicated_socket(SpaceNode &snode,
ARegion &region,
const float2 &cursor,
const eNodeSocketInOut in_out)
{
const float view2d_scale = UI_view2d_scale_get_x(&region.v2d);
const float max_distance = NODE_SOCKSIZE + std::clamp(20.0f / view2d_scale, 5.0f, 30.0f);
const float padded_socket_size = NODE_SOCKSIZE + 4;
bNodeTree &tree = *snode.edittree;
tree.ensure_topology_cache();
const Array<bNode *> sorted_nodes = tree_draw_order_calc_nodes_reversed(tree);
if (sorted_nodes.is_empty()) {
return nullptr;
}
float best_distance = FLT_MAX;
bNodeSocket *best_socket = nullptr;
auto update_best_socket = [&](bNodeSocket *socket, const float distance) {
if (socket_is_occluded(socket->runtime->location, socket->owner_node(), sorted_nodes)) {
return;
}
if (distance < best_distance) {
best_distance = distance;
best_socket = socket;
}
};
for (bNode *node : sorted_nodes) {
const bool node_hidden = node->flag & NODE_HIDDEN;
2024-12-13 11:15:15 -05:00
if (!node->is_reroute() && !node_hidden &&
node->runtime->draw_bounds.ymax - cursor.y < NODE_DY)
{
/* Don't pick socket when cursor is over node header. This allows the user to always resize
* by dragging on the left and right side of the header. */
continue;
}
if (in_out & SOCK_IN) {
for (bNodeSocket *sock : node->input_sockets()) {
if (!node->is_socket_icon_drawn(*sock)) {
continue;
}
const float2 location = sock->runtime->location;
const float distance = math::distance(location, cursor);
if (sock->flag & SOCK_MULTI_INPUT && !node_hidden) {
if (cursor_isect_multi_input_socket(cursor, *sock)) {
update_best_socket(sock, distance);
continue;
}
}
if (distance < max_distance) {
update_best_socket(sock, distance);
}
}
}
if (in_out & SOCK_OUT) {
for (bNodeSocket *sock : node->output_sockets()) {
if (!node->is_socket_icon_drawn(*sock)) {
continue;
}
const float2 location = sock->runtime->location;
const float distance = math::distance(location, cursor);
if (distance < max_distance) {
if (node_hidden) {
if (location.x - cursor.x > padded_socket_size) {
/* Needed to be able to resize collapsed nodes. */
continue;
}
}
update_best_socket(sock, distance);
}
}
}
}
return best_socket;
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Node Link Dimming
* \{ */
float node_link_dim_factor(const View2D &v2d, const bNodeLink &link)
{
if (link.fromsock == nullptr || link.tosock == nullptr) {
return 1.0f;
}
if (link.flag & NODE_LINK_INSERT_TARGET_INVALID) {
return 0.2f;
}
const float2 from = link.fromsock->runtime->location;
const float2 to = link.tosock->runtime->location;
const float min_endpoint_distance = std::min(
std::max(BLI_rctf_length_x(&v2d.cur, from.x), BLI_rctf_length_y(&v2d.cur, from.y)),
std::max(BLI_rctf_length_x(&v2d.cur, to.x), BLI_rctf_length_y(&v2d.cur, to.y)));
if (min_endpoint_distance == 0.0f) {
return 1.0f;
}
const float viewport_width = BLI_rctf_size_x(&v2d.cur);
return std::clamp(1.0f - min_endpoint_distance / viewport_width * 10.0f, 0.05f, 1.0f);
}
bool node_link_is_hidden_or_dimmed(const View2D &v2d, const bNodeLink &link)
{
return bke::node_link_is_hidden(&link) || node_link_dim_factor(v2d, link) < 0.5f;
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Node Duplicate Operator
* \{ */
static void node_duplicate_reparent_recursive(bNodeTree *ntree,
const Map<bNode *, bNode *> &node_map,
bNode *node)
{
bNode *parent;
node->flag |= NODE_TEST;
/* Find first selected parent. */
for (parent = node->parent; parent; parent = parent->parent) {
if (parent->flag & SELECT) {
if (!(parent->flag & NODE_TEST)) {
node_duplicate_reparent_recursive(ntree, node_map, parent);
}
break;
}
}
/* Reparent node copy to parent copy. */
if (parent) {
bke::node_detach_node(ntree, node_map.lookup(node));
bke::node_attach_node(ntree, node_map.lookup(node), node_map.lookup(parent));
}
}
void remap_node_pairing(bNodeTree &dst_tree, const Map<const bNode *, bNode *> &node_map)
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
{
/* We don't have the old tree for looking up output nodes by ID,
* so we have to build a map first to find copied output nodes in the new tree. */
Map<int32_t, bNode *> dst_output_node_map;
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
for (const auto &item : node_map.items()) {
if (bke::all_zone_output_node_types().contains(item.key->type_legacy)) {
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
dst_output_node_map.add_new(item.key->identifier, item.value);
}
}
for (bNode *dst_node : node_map.values()) {
if (bke::all_zone_input_node_types().contains(dst_node->type_legacy)) {
const bke::bNodeZoneType &zone_type = *bke::zone_type_by_node_type(dst_node->type_legacy);
int &output_node_id = zone_type.get_corresponding_output_id(*dst_node);
if (const bNode *output_node = dst_output_node_map.lookup_default(output_node_id, nullptr)) {
output_node_id = output_node->identifier;
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
}
else {
output_node_id = 0;
blender::nodes::update_node_declaration_and_sockets(dst_tree, *dst_node);
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
}
}
}
}
static int node_duplicate_exec(bContext *C, wmOperator *op)
Implements a new operator for detaching nodes. In the process i overhauled the node muting system as well. There are a number of features that use a kind of "internal linking" in nodes: 1. muting 2. delete + reconnect (restore link to/from node after delete) 3. the new detach operator (same as 2, but don't delete the node) The desired behavior in all cases is the same: find a sensible mapping of inputs-to-outputs of a node. In the case of muting these links are displayed in red on the node itself. For the other operators they are used to relink connections, such that one gets the best possible ongoing link between previous up- and downstream nodes. Muting previously used a complicated callback system to ensure consistent behavior in the editor as well as execution in compositor, shader cpu/gpu and texture nodes. This has been greatly simplified by moving the muting step into the node tree localization functions. Any muted node is now bypassed using the generalized nodeInternalRelink function and then removed from the local tree. This way the internal execution system doesn't have to deal with muted nodes at all, as if they are non-existent. The same function is also used by the delete_reconnect and the new links_detach operators (which work directly in the editor node tree). Detaching nodes is currently keymapped as a translation variant (macro operator): pressing ALTKEY + moving node first detaches and then continues with regular transform operator. The default key is ALT+DKEY though, instead ALT+GKEY, since the latter is already used for the ungroup operator.
2012-02-27 17:38:16 +00:00
{
2018-06-09 15:16:44 +02:00
Main *bmain = CTX_data_main(C);
2012-06-21 13:19:19 +00:00
SpaceNode *snode = CTX_wm_space_node(C);
bNodeTree *ntree = snode->edittree;
2014-02-03 18:55:59 +11:00
const bool keep_inputs = RNA_boolean_get(op->ptr, "keep_inputs");
bool linked = RNA_boolean_get(op->ptr, "linked") || ((U.dupflag & USER_DUP_NTREE) == 0);
const bool dupli_node_tree = !linked;
2018-06-09 15:16:44 +02:00
ED_preview_kill_jobs(CTX_wm_manager(C), bmain);
Map<bNode *, bNode *> node_map;
Map<const bNodeSocket *, bNodeSocket *> socket_map;
Map<const ID *, ID *> duplicated_node_groups;
node_select_paired(*ntree);
for (bNode *node : get_selected_nodes(*ntree)) {
bNode *new_node = bke::node_copy_with_mapping(
ntree, *node, LIB_ID_COPY_DEFAULT, true, socket_map);
node_map.add_new(node, new_node);
if (node->id && dupli_node_tree) {
ID *new_group = duplicated_node_groups.lookup_or_add_cb(node->id, [&]() {
ID *new_group = BKE_id_copy(bmain, node->id);
/* Remove user added by copying. */
id_us_min(new_group);
return new_group;
});
id_us_plus(new_group);
id_us_min(new_node->id);
new_node->id = new_group;
}
}
if (node_map.is_empty()) {
return OPERATOR_CANCELLED;
}
/* Copy links between selected nodes. */
bNodeLink *lastlink = (bNodeLink *)ntree->links.last;
LISTBASE_FOREACH (bNodeLink *, link, &ntree->links) {
/* This creates new links between copied nodes. If keep_inputs is set, also copies input links
* from unselected (when fromnode is null)! */
if (link->tonode && (link->tonode->flag & NODE_SELECT) &&
(keep_inputs || (link->fromnode && (link->fromnode->flag & NODE_SELECT))))
{
bNodeLink *newlink = MEM_cnew<bNodeLink>("bNodeLink");
newlink->flag = link->flag;
newlink->tonode = node_map.lookup(link->tonode);
newlink->tosock = socket_map.lookup(link->tosock);
if (link->tosock->flag & SOCK_MULTI_INPUT) {
newlink->multi_input_sort_id = link->multi_input_sort_id;
}
if (link->fromnode && (link->fromnode->flag & NODE_SELECT)) {
newlink->fromnode = node_map.lookup(link->fromnode);
newlink->fromsock = socket_map.lookup(link->fromsock);
}
else {
/* Input node not copied, this keeps the original input linked. */
newlink->fromnode = link->fromnode;
newlink->fromsock = link->fromsock;
}
BLI_addtail(&ntree->links, newlink);
}
/* Make sure we don't copy new links again. */
if (link == lastlink) {
break;
}
}
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
for (bNode *node : node_map.values()) {
blender::bke::node_declaration_ensure(ntree, node);
}
ntree->ensure_topology_cache();
for (bNode *node : node_map.values()) {
update_multi_input_indices_for_removed_links(*node);
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
}
/* Clear flags for recursive depth-first iteration. */
for (bNode *node : ntree->all_nodes()) {
node->flag &= ~NODE_TEST;
}
/* Reparent copied nodes. */
for (bNode *node : node_map.keys()) {
if (!(node->flag & NODE_TEST)) {
node_duplicate_reparent_recursive(ntree, node_map, node);
}
}
{
/* Use temporary map that has const key, because that's what the function below expects. */
Map<const bNode *, bNode *> const_node_map;
for (const auto item : node_map.items()) {
const_node_map.add(item.key, item.value);
}
remap_node_pairing(*ntree, const_node_map);
}
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
/* Deselect old nodes, select the copies instead. */
for (const auto item : node_map.items()) {
bNode *src_node = item.key;
bNode *dst_node = item.value;
bke::node_set_selected(src_node, false);
src_node->flag &= ~(NODE_ACTIVE | NODE_ACTIVE_TEXTURE);
bke::node_set_selected(dst_node, true);
}
tree_draw_order_update(*snode->edittree);
BKE_main_ensure_invariants(*bmain, snode->edittree->id);
return OPERATOR_FINISHED;
}
void NODE_OT_duplicate(wmOperatorType *ot)
{
PropertyRNA *prop;
/* identifiers */
ot->name = "Duplicate Nodes";
ot->description = "Duplicate selected nodes";
ot->idname = "NODE_OT_duplicate";
/* api callbacks */
ot->exec = node_duplicate_exec;
ot->poll = ED_operator_node_editable;
/* flags */
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
RNA_def_boolean(
ot->srna, "keep_inputs", false, "Keep Inputs", "Keep the input links to duplicated nodes");
prop = RNA_def_boolean(ot->srna,
"linked",
true,
"Linked",
"Duplicate node but not node trees, linking to the original data");
RNA_def_property_flag(prop, PROP_SKIP_SAVE);
}
/* Goes over all scenes, reads render layers. */
static int node_read_viewlayers_exec(bContext *C, wmOperator * /*op*/)
{
2012-06-21 13:19:19 +00:00
Main *bmain = CTX_data_main(C);
SpaceNode *snode = CTX_wm_space_node(C);
Scene *curscene = CTX_data_scene(C);
bNodeTree &edit_tree = *snode->edittree;
ED_preview_kill_jobs(CTX_wm_manager(C), bmain);
/* first tag scenes unread */
LISTBASE_FOREACH (Scene *, scene, &bmain->scenes) {
scene->id.tag |= ID_TAG_DOIT;
}
for (bNode *node : edit_tree.all_nodes()) {
if ((node->type_legacy == CMP_NODE_R_LAYERS) ||
(node->type_legacy == CMP_NODE_CRYPTOMATTE &&
node->custom1 == CMP_NODE_CRYPTOMATTE_SOURCE_RENDER))
Compositor: Redesign Cryptomatte node for better usability In the current implementation, cryptomatte passes are connected to the node and elements are picked by using the eyedropper tool on a special pick channel. This design has two disadvantages - both connecting all passes individually and always having to switch to the picker channel are tedious. With the new design, the user selects the RenderLayer or Image from which the Cryptomatte layers are directly loaded (the type of pass is determined by an enum). This allows the node to automatically detect all relevant passes. Then, when using the eyedropper tool, the operator looks up the selected coordinates from the picked Image, Node backdrop or Clip and reads the picked object directly from the Renderlayer/Image, therefore allowing to pick in any context (e.g. by clicking on the Combined pass in the Image Viewer). The sampled color is looked up in the metadata and the actual name is stored in the cryptomatte node. This also allows to remove a hash by just removing the name from the matte id. Technically there is some loss of flexibility because the Cryptomatte pass inputs can no longer be connected to other nodes, but since any compositing done on them is likely to break the Cryptomatte system anyways, this isn't really a concern in practise. In the future, this would also allow to automatically translate values to names by looking up the value in the associated metadata of the input, or to get a better visualization of overlapping areas in the Pick output since we could blend colors now that the output doesn't have to contain the exact value. Idea + Original patch: Lucas Stockner Reviewed By: Brecht van Lommel Differential Revision: https://developer.blender.org/D3959
2021-03-16 07:37:30 +01:00
{
2012-06-21 13:19:19 +00:00
ID *id = node->id;
if (id == nullptr) {
Compositor: Redesign Cryptomatte node for better usability In the current implementation, cryptomatte passes are connected to the node and elements are picked by using the eyedropper tool on a special pick channel. This design has two disadvantages - both connecting all passes individually and always having to switch to the picker channel are tedious. With the new design, the user selects the RenderLayer or Image from which the Cryptomatte layers are directly loaded (the type of pass is determined by an enum). This allows the node to automatically detect all relevant passes. Then, when using the eyedropper tool, the operator looks up the selected coordinates from the picked Image, Node backdrop or Clip and reads the picked object directly from the Renderlayer/Image, therefore allowing to pick in any context (e.g. by clicking on the Combined pass in the Image Viewer). The sampled color is looked up in the metadata and the actual name is stored in the cryptomatte node. This also allows to remove a hash by just removing the name from the matte id. Technically there is some loss of flexibility because the Cryptomatte pass inputs can no longer be connected to other nodes, but since any compositing done on them is likely to break the Cryptomatte system anyways, this isn't really a concern in practise. In the future, this would also allow to automatically translate values to names by looking up the value in the associated metadata of the input, or to get a better visualization of overlapping areas in the Pick output since we could blend colors now that the output doesn't have to contain the exact value. Idea + Original patch: Lucas Stockner Reviewed By: Brecht van Lommel Differential Revision: https://developer.blender.org/D3959
2021-03-16 07:37:30 +01:00
continue;
}
if (id->tag & ID_TAG_DOIT) {
RE_ReadRenderResult(curscene, (Scene *)id);
ntreeCompositTagRender((Scene *)id);
id->tag &= ~ID_TAG_DOIT;
}
}
}
BKE_main_ensure_invariants(*bmain, edit_tree.id);
return OPERATOR_FINISHED;
}
void NODE_OT_read_viewlayers(wmOperatorType *ot)
{
ot->name = "Read View Layers";
ot->idname = "NODE_OT_read_viewlayers";
ot->description = "Read all render layers of all used scenes";
ot->exec = node_read_viewlayers_exec;
ot->poll = composite_node_active;
}
int node_render_changed_exec(bContext *C, wmOperator * /*op*/)
{
2012-06-21 13:19:19 +00:00
Scene *sce = CTX_data_scene(C);
/* This is actually a test whether scene is used by the compositor or not.
* All the nodes are using same render result, so there is no need to do
* anything smart about check how exactly scene is used. */
bNode *node = nullptr;
for (bNode *node_iter : sce->nodetree->all_nodes()) {
if (node_iter->id == (ID *)sce) {
node = node_iter;
break;
}
}
if (node) {
ViewLayer *view_layer = (ViewLayer *)BLI_findlink(&sce->view_layers, node->custom1);
if (view_layer) {
PointerRNA op_ptr;
WM_operator_properties_create(&op_ptr, "RENDER_OT_render");
RNA_string_set(&op_ptr, "layer", view_layer->name);
2012-06-21 13:19:19 +00:00
RNA_string_set(&op_ptr, "scene", sce->id.name + 2);
/* To keep keyframe positions. */
sce->r.scemode |= R_NO_FRAME_UPDATE;
WM_operator_name_call(C, "RENDER_OT_render", WM_OP_INVOKE_DEFAULT, &op_ptr, nullptr);
WM_operator_properties_free(&op_ptr);
return OPERATOR_FINISHED;
}
}
return OPERATOR_CANCELLED;
}
void NODE_OT_render_changed(wmOperatorType *ot)
{
ot->name = "Render Changed Layer";
ot->idname = "NODE_OT_render_changed";
ot->description = "Render current scene, when input node's layer has been changed";
ot->exec = node_render_changed_exec;
ot->poll = composite_node_active;
/* flags */
ot->flag = 0;
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Node Hide Operator
* \{ */
/**
* Toggles the flag on all selected nodes. If the flag is set on all nodes it is unset.
* If the flag is not set on all nodes, it is set.
*/
static void node_flag_toggle_exec(SpaceNode *snode, int toggle_flag)
{
2012-06-21 13:19:19 +00:00
int tot_eq = 0, tot_neq = 0;
for (bNode *node : snode->edittree->all_nodes()) {
if (node->flag & SELECT) {
if (toggle_flag == NODE_PREVIEW && !node_is_previewable(*snode, *snode->edittree, *node)) {
continue;
}
if (toggle_flag == NODE_OPTIONS &&
!(node->typeinfo->draw_buttons || node->typeinfo->draw_buttons_ex))
{
continue;
}
if (node->flag & toggle_flag) {
tot_eq++;
}
else {
tot_neq++;
}
}
}
for (bNode *node : snode->edittree->all_nodes()) {
if (node->flag & SELECT) {
if (toggle_flag == NODE_PREVIEW && !node_is_previewable(*snode, *snode->edittree, *node)) {
continue;
}
if (toggle_flag == NODE_OPTIONS &&
!(node->typeinfo->draw_buttons || node->typeinfo->draw_buttons_ex))
{
continue;
}
if ((tot_eq && tot_neq) || tot_eq == 0) {
node->flag |= toggle_flag;
}
else {
node->flag &= ~toggle_flag;
}
}
}
}
static int node_hide_toggle_exec(bContext *C, wmOperator * /*op*/)
{
2012-06-21 13:19:19 +00:00
SpaceNode *snode = CTX_wm_space_node(C);
/* Sanity checking (poll callback checks this already). */
if ((snode == nullptr) || (snode->edittree == nullptr)) {
return OPERATOR_CANCELLED;
}
node_flag_toggle_exec(snode, NODE_HIDDEN);
WM_event_add_notifier(C, NC_NODE | ND_DISPLAY, nullptr);
return OPERATOR_FINISHED;
}
void NODE_OT_hide_toggle(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Hide";
ot->description = "Toggle hiding of selected nodes";
ot->idname = "NODE_OT_hide_toggle";
/* callbacks */
ot->exec = node_hide_toggle_exec;
ot->poll = ED_operator_node_active;
/* flags */
2012-06-21 13:19:19 +00:00
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
}
static int node_preview_toggle_exec(bContext *C, wmOperator * /*op*/)
{
2012-06-21 13:19:19 +00:00
SpaceNode *snode = CTX_wm_space_node(C);
/* Sanity checking (poll callback checks this already). */
if ((snode == nullptr) || (snode->edittree == nullptr)) {
return OPERATOR_CANCELLED;
}
node_flag_toggle_exec(snode, NODE_PREVIEW);
BKE_main_ensure_invariants(*CTX_data_main(C), snode->edittree->id);
return OPERATOR_FINISHED;
}
Nodes: experimental node previews in the shader editor First implementation of node previews in the shader node editor. Using the same user interface as compositor node previews, most shader nodes can now be previewed (except group in/output and material output). This is currently still an experimental feature, as polishing of the user experience and performance improvements are planned. These will be easier to do as incremental changes on this implementation. See #110353 for details on the work that remains to be done and known limitations. Implementation notes: We take advantage of the `RenderResult` available as `ImBuf` images to store a `Render` for every viewed nested node tree present in a `SpaceNode`. The computation is initiated at the moment of drawing nodes overlays. One render is started for the current nodetree, having a `ViewLayer` associated with each previewed node. We separate the previewed nodes in two categories: the shader ones and the non-shader ones. - For non-shader nodes, we use AOVs which highly speed up the rendering process by rendering every non-shader nodes at the same time. They are rendered in the first `ViewLayer`. - For shader nodes, we render them each in a different `ViewLayer`, by rerouting the node to the output of the material in the preview scene. The preview scene takes the same aspect as the Material preview scene, and the same preview object is used. At the moment of drawing the node overlay, we take the `Render` of the viewed node tree and extract the `ImBuf` of the wanted viewlayer/pass for each previewed node. Pull Request: https://projects.blender.org/blender/blender/pulls/110065
2023-08-08 17:36:06 +02:00
static bool node_previewable(bContext *C)
{
if (ED_operator_node_active(C)) {
SpaceNode *snode = CTX_wm_space_node(C);
if (ED_node_supports_preview(snode)) {
return true;
}
}
return false;
}
void NODE_OT_preview_toggle(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Toggle Node Preview";
ot->description = "Toggle preview display for selected nodes";
ot->idname = "NODE_OT_preview_toggle";
/* callbacks */
ot->exec = node_preview_toggle_exec;
Nodes: experimental node previews in the shader editor First implementation of node previews in the shader node editor. Using the same user interface as compositor node previews, most shader nodes can now be previewed (except group in/output and material output). This is currently still an experimental feature, as polishing of the user experience and performance improvements are planned. These will be easier to do as incremental changes on this implementation. See #110353 for details on the work that remains to be done and known limitations. Implementation notes: We take advantage of the `RenderResult` available as `ImBuf` images to store a `Render` for every viewed nested node tree present in a `SpaceNode`. The computation is initiated at the moment of drawing nodes overlays. One render is started for the current nodetree, having a `ViewLayer` associated with each previewed node. We separate the previewed nodes in two categories: the shader ones and the non-shader ones. - For non-shader nodes, we use AOVs which highly speed up the rendering process by rendering every non-shader nodes at the same time. They are rendered in the first `ViewLayer`. - For shader nodes, we render them each in a different `ViewLayer`, by rerouting the node to the output of the material in the preview scene. The preview scene takes the same aspect as the Material preview scene, and the same preview object is used. At the moment of drawing the node overlay, we take the `Render` of the viewed node tree and extract the `ImBuf` of the wanted viewlayer/pass for each previewed node. Pull Request: https://projects.blender.org/blender/blender/pulls/110065
2023-08-08 17:36:06 +02:00
ot->poll = node_previewable;
/* flags */
2012-06-21 13:19:19 +00:00
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
}
static int node_deactivate_viewer_exec(bContext *C, wmOperator * /*op*/)
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
{
SpaceNode &snode = *CTX_wm_space_node(C);
WorkSpace &workspace = *CTX_wm_workspace(C);
bNode *active_viewer = viewer_path::find_geometry_nodes_viewer(workspace.viewer_path, snode);
for (bNode *node : snode.edittree->all_nodes()) {
if (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
continue;
}
if (!(node->flag & SELECT)) {
continue;
}
if (node == active_viewer) {
node->flag &= ~NODE_DO_OUTPUT;
BKE_ntree_update_tag_node_property(snode.edittree, node);
}
}
BKE_main_ensure_invariants(*CTX_data_main(C), snode.edittree->id);
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
return OPERATOR_FINISHED;
}
void NODE_OT_deactivate_viewer(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Deactivate Viewer Node";
ot->description = "Deactivate selected viewer node in geometry nodes";
ot->idname = __func__;
/* callbacks */
ot->exec = node_deactivate_viewer_exec;
ot->poll = ED_operator_node_active;
/* flags */
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
}
static int node_options_toggle_exec(bContext *C, wmOperator * /*op*/)
{
2012-06-21 13:19:19 +00:00
SpaceNode *snode = CTX_wm_space_node(C);
/* Sanity checking (poll callback checks this already). */
if ((snode == nullptr) || (snode->edittree == nullptr)) {
return OPERATOR_CANCELLED;
}
node_flag_toggle_exec(snode, NODE_OPTIONS);
WM_event_add_notifier(C, NC_NODE | ND_DISPLAY, nullptr);
return OPERATOR_FINISHED;
}
void NODE_OT_options_toggle(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Toggle Node Options";
ot->description = "Toggle option buttons display for selected nodes";
ot->idname = "NODE_OT_options_toggle";
/* callbacks */
ot->exec = node_options_toggle_exec;
ot->poll = ED_operator_node_active;
/* flags */
2012-06-21 13:19:19 +00:00
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
}
static int node_socket_toggle_exec(bContext *C, wmOperator * /*op*/)
{
2012-06-21 13:19:19 +00:00
SpaceNode *snode = CTX_wm_space_node(C);
/* Sanity checking (poll callback checks this already). */
if ((snode == nullptr) || (snode->edittree == nullptr)) {
return OPERATOR_CANCELLED;
}
ED_preview_kill_jobs(CTX_wm_manager(C), CTX_data_main(C));
/* Toggle for all selected nodes */
bool hidden = false;
for (bNode *node : snode->edittree->all_nodes()) {
if (node->flag & SELECT) {
if (node_has_hidden_sockets(node)) {
hidden = true;
break;
}
}
}
for (bNode *node : snode->edittree->all_nodes()) {
if (node->flag & SELECT) {
2023-06-04 14:55:20 +10:00
node_set_hidden_sockets(node, !hidden);
}
}
BKE_main_ensure_invariants(*CTX_data_main(C), snode->edittree->id);
WM_event_add_notifier(C, NC_NODE | ND_DISPLAY, nullptr);
/* Hack to force update of the button state after drawing, see #112462. */
WM_event_add_mousemove(CTX_wm_window(C));
return OPERATOR_FINISHED;
}
void NODE_OT_hide_socket_toggle(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Toggle Hidden Node Sockets";
ot->description = "Toggle unused node socket display";
ot->idname = "NODE_OT_hide_socket_toggle";
/* callbacks */
ot->exec = node_socket_toggle_exec;
ot->poll = ED_operator_node_active;
/* flags */
2012-06-21 13:19:19 +00:00
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Node Mute Operator
* \{ */
static int node_mute_exec(bContext *C, wmOperator * /*op*/)
{
2018-06-09 15:16:44 +02:00
Main *bmain = CTX_data_main(C);
2012-06-21 13:19:19 +00:00
SpaceNode *snode = CTX_wm_space_node(C);
2018-06-09 15:16:44 +02:00
ED_preview_kill_jobs(CTX_wm_manager(C), bmain);
for (bNode *node : snode->edittree->all_nodes()) {
if ((node->flag & SELECT) && !node->typeinfo->no_muting) {
Implements a new operator for detaching nodes. In the process i overhauled the node muting system as well. There are a number of features that use a kind of "internal linking" in nodes: 1. muting 2. delete + reconnect (restore link to/from node after delete) 3. the new detach operator (same as 2, but don't delete the node) The desired behavior in all cases is the same: find a sensible mapping of inputs-to-outputs of a node. In the case of muting these links are displayed in red on the node itself. For the other operators they are used to relink connections, such that one gets the best possible ongoing link between previous up- and downstream nodes. Muting previously used a complicated callback system to ensure consistent behavior in the editor as well as execution in compositor, shader cpu/gpu and texture nodes. This has been greatly simplified by moving the muting step into the node tree localization functions. Any muted node is now bypassed using the generalized nodeInternalRelink function and then removed from the local tree. This way the internal execution system doesn't have to deal with muted nodes at all, as if they are non-existent. The same function is also used by the delete_reconnect and the new links_detach operators (which work directly in the editor node tree). Detaching nodes is currently keymapped as a translation variant (macro operator): pressing ALTKEY + moving node first detaches and then continues with regular transform operator. The default key is ALT+DKEY though, instead ALT+GKEY, since the latter is already used for the ungroup operator.
2012-02-27 17:38:16 +00:00
node->flag ^= NODE_MUTED;
BKE_ntree_update_tag_node_mute(snode->edittree, node);
}
}
BKE_main_ensure_invariants(*bmain, snode->edittree->id);
return OPERATOR_FINISHED;
}
void NODE_OT_mute_toggle(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Toggle Node Mute";
ot->description = "Toggle muting of selected nodes";
ot->idname = "NODE_OT_mute_toggle";
/* callbacks */
ot->exec = node_mute_exec;
ot->poll = ED_operator_node_editable;
/* flags */
2012-06-21 13:19:19 +00:00
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Node Delete Operator
* \{ */
static int node_delete_exec(bContext *C, wmOperator * /*op*/)
{
2018-06-09 15:16:44 +02:00
Main *bmain = CTX_data_main(C);
2012-06-21 13:19:19 +00:00
SpaceNode *snode = CTX_wm_space_node(C);
2018-06-09 15:16:44 +02:00
ED_preview_kill_jobs(CTX_wm_manager(C), bmain);
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
/* Delete paired nodes as well. */
node_select_paired(*snode->edittree);
LISTBASE_FOREACH_MUTABLE (bNode *, node, &snode->edittree->nodes) {
if (node->flag & SELECT) {
bke::node_remove_node(bmain, snode->edittree, node, true);
}
}
BKE_main_ensure_invariants(*bmain, snode->edittree->id);
return OPERATOR_FINISHED;
}
void NODE_OT_delete(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Delete";
ot->description = "Remove selected nodes";
ot->idname = "NODE_OT_delete";
/* api callbacks */
ot->exec = node_delete_exec;
ot->poll = ED_operator_node_editable;
/* flags */
2012-06-21 13:19:19 +00:00
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Node Delete with Reconnect Operator
* \{ */
static int node_delete_reconnect_exec(bContext *C, wmOperator * /*op*/)
{
Main *bmain = CTX_data_main(C);
SpaceNode *snode = CTX_wm_space_node(C);
ED_preview_kill_jobs(CTX_wm_manager(C), CTX_data_main(C));
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
/* Delete paired nodes as well. */
node_select_paired(*snode->edittree);
LISTBASE_FOREACH_MUTABLE (bNode *, node, &snode->edittree->nodes) {
if (node->flag & SELECT) {
blender::bke::node_internal_relink(snode->edittree, node);
bke::node_remove_node(bmain, snode->edittree, node, true);
/* Since this node might have been animated, and that animation data been
* deleted, a notifier call is necessary to redraw any animation editor. */
WM_event_add_notifier(C, NC_ANIMATION | ND_ANIMCHAN, nullptr);
}
}
BKE_main_ensure_invariants(*bmain, snode->edittree->id);
return OPERATOR_FINISHED;
}
void NODE_OT_delete_reconnect(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Delete with Reconnect";
ot->description = "Remove nodes and reconnect nodes as if deletion was muted";
ot->idname = "NODE_OT_delete_reconnect";
/* api callbacks */
ot->exec = node_delete_reconnect_exec;
ot->poll = ED_operator_node_editable;
/* flags */
2012-06-21 13:19:19 +00:00
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
}
Adds a new node type for saving multiple image files from a single node. Unlike the existing file output node this node has an arbitrary number of possible input slots. It has a base path string that can be set to a general base folder. Every input socket then uses its name as an extension of the base path for file organization. This can include further subfolders on top of the base path. Example: Base path: '/home/user/myproject' Input 1: 'Compo' Input 2: 'Diffuse/' Input 3: 'details/Normals' would create output files in /home/user/myproject: Compo0001.png, Compo0002.png, ... in /home/user/myproject/Diffuse: 0001.png, 0002.png, ... (no filename base given) in /home/user/myproject/details: Normals0001.png, Normals0002.png, ... Most settings for the node can be found in the sidebar (NKEY). New input sockets can be added with the "Add Input" button. There is a list of input sockets and below that the details for each socket can be changed, including the sub-path and filename. Sockets can be removed here as well. By default each socket uses the render settings file output format, but each can use its own format if necessary. To my knowledge this is the first node making use of such dynamic sockets in trunk. So this is also a design test, other nodes might use this in the future. Adding operator buttons on top of a node is a bit unwieldy atm, because all node operators generally work on selected and/or active node(s). The operator button would therefore either have to make sure the node is activated before the operator is called (block callback maybe?) OR it has to store the node name (risky, weak reference). For now it is only used in the sidebar, where only the active node's buttons are displayed. Also adds a new struct_type value to bNodeSocket, in order to distinguish different socket types with the same data type (file inputs are SOCK_RGBA color sockets). Would be nicer to use data type only for actual data evaluation, but used in too many places, this works ok for now.
2012-02-22 12:24:04 +00:00
/** \} */
/* -------------------------------------------------------------------- */
/** \name Node File Output Add Socket Operator
* \{ */
Adds a new node type for saving multiple image files from a single node. Unlike the existing file output node this node has an arbitrary number of possible input slots. It has a base path string that can be set to a general base folder. Every input socket then uses its name as an extension of the base path for file organization. This can include further subfolders on top of the base path. Example: Base path: '/home/user/myproject' Input 1: 'Compo' Input 2: 'Diffuse/' Input 3: 'details/Normals' would create output files in /home/user/myproject: Compo0001.png, Compo0002.png, ... in /home/user/myproject/Diffuse: 0001.png, 0002.png, ... (no filename base given) in /home/user/myproject/details: Normals0001.png, Normals0002.png, ... Most settings for the node can be found in the sidebar (NKEY). New input sockets can be added with the "Add Input" button. There is a list of input sockets and below that the details for each socket can be changed, including the sub-path and filename. Sockets can be removed here as well. By default each socket uses the render settings file output format, but each can use its own format if necessary. To my knowledge this is the first node making use of such dynamic sockets in trunk. So this is also a design test, other nodes might use this in the future. Adding operator buttons on top of a node is a bit unwieldy atm, because all node operators generally work on selected and/or active node(s). The operator button would therefore either have to make sure the node is activated before the operator is called (block callback maybe?) OR it has to store the node name (risky, weak reference). For now it is only used in the sidebar, where only the active node's buttons are displayed. Also adds a new struct_type value to bNodeSocket, in order to distinguish different socket types with the same data type (file inputs are SOCK_RGBA color sockets). Would be nicer to use data type only for actual data evaluation, but used in too many places, this works ok for now.
2012-02-22 12:24:04 +00:00
static int node_output_file_add_socket_exec(bContext *C, wmOperator *op)
Adds a new node type for saving multiple image files from a single node. Unlike the existing file output node this node has an arbitrary number of possible input slots. It has a base path string that can be set to a general base folder. Every input socket then uses its name as an extension of the base path for file organization. This can include further subfolders on top of the base path. Example: Base path: '/home/user/myproject' Input 1: 'Compo' Input 2: 'Diffuse/' Input 3: 'details/Normals' would create output files in /home/user/myproject: Compo0001.png, Compo0002.png, ... in /home/user/myproject/Diffuse: 0001.png, 0002.png, ... (no filename base given) in /home/user/myproject/details: Normals0001.png, Normals0002.png, ... Most settings for the node can be found in the sidebar (NKEY). New input sockets can be added with the "Add Input" button. There is a list of input sockets and below that the details for each socket can be changed, including the sub-path and filename. Sockets can be removed here as well. By default each socket uses the render settings file output format, but each can use its own format if necessary. To my knowledge this is the first node making use of such dynamic sockets in trunk. So this is also a design test, other nodes might use this in the future. Adding operator buttons on top of a node is a bit unwieldy atm, because all node operators generally work on selected and/or active node(s). The operator button would therefore either have to make sure the node is activated before the operator is called (block callback maybe?) OR it has to store the node name (risky, weak reference). For now it is only used in the sidebar, where only the active node's buttons are displayed. Also adds a new struct_type value to bNodeSocket, in order to distinguish different socket types with the same data type (file inputs are SOCK_RGBA color sockets). Would be nicer to use data type only for actual data evaluation, but used in too many places, this works ok for now.
2012-02-22 12:24:04 +00:00
{
2012-06-21 13:19:19 +00:00
Scene *scene = CTX_data_scene(C);
SpaceNode *snode = CTX_wm_space_node(C);
PointerRNA ptr = CTX_data_pointer_get(C, "node");
bNodeTree *ntree = nullptr;
bNode *node = nullptr;
char file_path[MAX_NAME];
if (ptr.data) {
node = (bNode *)ptr.data;
ntree = (bNodeTree *)ptr.owner_id;
}
else if (snode && snode->edittree) {
ntree = snode->edittree;
node = bke::node_get_active(snode->edittree);
}
if (!node || node->type_legacy != CMP_NODE_OUTPUT_FILE) {
Adds a new node type for saving multiple image files from a single node. Unlike the existing file output node this node has an arbitrary number of possible input slots. It has a base path string that can be set to a general base folder. Every input socket then uses its name as an extension of the base path for file organization. This can include further subfolders on top of the base path. Example: Base path: '/home/user/myproject' Input 1: 'Compo' Input 2: 'Diffuse/' Input 3: 'details/Normals' would create output files in /home/user/myproject: Compo0001.png, Compo0002.png, ... in /home/user/myproject/Diffuse: 0001.png, 0002.png, ... (no filename base given) in /home/user/myproject/details: Normals0001.png, Normals0002.png, ... Most settings for the node can be found in the sidebar (NKEY). New input sockets can be added with the "Add Input" button. There is a list of input sockets and below that the details for each socket can be changed, including the sub-path and filename. Sockets can be removed here as well. By default each socket uses the render settings file output format, but each can use its own format if necessary. To my knowledge this is the first node making use of such dynamic sockets in trunk. So this is also a design test, other nodes might use this in the future. Adding operator buttons on top of a node is a bit unwieldy atm, because all node operators generally work on selected and/or active node(s). The operator button would therefore either have to make sure the node is activated before the operator is called (block callback maybe?) OR it has to store the node name (risky, weak reference). For now it is only used in the sidebar, where only the active node's buttons are displayed. Also adds a new struct_type value to bNodeSocket, in order to distinguish different socket types with the same data type (file inputs are SOCK_RGBA color sockets). Would be nicer to use data type only for actual data evaluation, but used in too many places, this works ok for now.
2012-02-22 12:24:04 +00:00
return OPERATOR_CANCELLED;
}
RNA_string_get(op->ptr, "file_path", file_path);
ntreeCompositOutputFileAddSocket(ntree, node, file_path, &scene->r.im_format);
BKE_main_ensure_invariants(*CTX_data_main(C), snode->edittree->id);
Adds a new node type for saving multiple image files from a single node. Unlike the existing file output node this node has an arbitrary number of possible input slots. It has a base path string that can be set to a general base folder. Every input socket then uses its name as an extension of the base path for file organization. This can include further subfolders on top of the base path. Example: Base path: '/home/user/myproject' Input 1: 'Compo' Input 2: 'Diffuse/' Input 3: 'details/Normals' would create output files in /home/user/myproject: Compo0001.png, Compo0002.png, ... in /home/user/myproject/Diffuse: 0001.png, 0002.png, ... (no filename base given) in /home/user/myproject/details: Normals0001.png, Normals0002.png, ... Most settings for the node can be found in the sidebar (NKEY). New input sockets can be added with the "Add Input" button. There is a list of input sockets and below that the details for each socket can be changed, including the sub-path and filename. Sockets can be removed here as well. By default each socket uses the render settings file output format, but each can use its own format if necessary. To my knowledge this is the first node making use of such dynamic sockets in trunk. So this is also a design test, other nodes might use this in the future. Adding operator buttons on top of a node is a bit unwieldy atm, because all node operators generally work on selected and/or active node(s). The operator button would therefore either have to make sure the node is activated before the operator is called (block callback maybe?) OR it has to store the node name (risky, weak reference). For now it is only used in the sidebar, where only the active node's buttons are displayed. Also adds a new struct_type value to bNodeSocket, in order to distinguish different socket types with the same data type (file inputs are SOCK_RGBA color sockets). Would be nicer to use data type only for actual data evaluation, but used in too many places, this works ok for now.
2012-02-22 12:24:04 +00:00
return OPERATOR_FINISHED;
}
void NODE_OT_output_file_add_socket(wmOperatorType *ot)
Adds a new node type for saving multiple image files from a single node. Unlike the existing file output node this node has an arbitrary number of possible input slots. It has a base path string that can be set to a general base folder. Every input socket then uses its name as an extension of the base path for file organization. This can include further subfolders on top of the base path. Example: Base path: '/home/user/myproject' Input 1: 'Compo' Input 2: 'Diffuse/' Input 3: 'details/Normals' would create output files in /home/user/myproject: Compo0001.png, Compo0002.png, ... in /home/user/myproject/Diffuse: 0001.png, 0002.png, ... (no filename base given) in /home/user/myproject/details: Normals0001.png, Normals0002.png, ... Most settings for the node can be found in the sidebar (NKEY). New input sockets can be added with the "Add Input" button. There is a list of input sockets and below that the details for each socket can be changed, including the sub-path and filename. Sockets can be removed here as well. By default each socket uses the render settings file output format, but each can use its own format if necessary. To my knowledge this is the first node making use of such dynamic sockets in trunk. So this is also a design test, other nodes might use this in the future. Adding operator buttons on top of a node is a bit unwieldy atm, because all node operators generally work on selected and/or active node(s). The operator button would therefore either have to make sure the node is activated before the operator is called (block callback maybe?) OR it has to store the node name (risky, weak reference). For now it is only used in the sidebar, where only the active node's buttons are displayed. Also adds a new struct_type value to bNodeSocket, in order to distinguish different socket types with the same data type (file inputs are SOCK_RGBA color sockets). Would be nicer to use data type only for actual data evaluation, but used in too many places, this works ok for now.
2012-02-22 12:24:04 +00:00
{
/* identifiers */
ot->name = "Add File Node Socket";
ot->description = "Add a new input to a file output node";
ot->idname = "NODE_OT_output_file_add_socket";
Adds a new node type for saving multiple image files from a single node. Unlike the existing file output node this node has an arbitrary number of possible input slots. It has a base path string that can be set to a general base folder. Every input socket then uses its name as an extension of the base path for file organization. This can include further subfolders on top of the base path. Example: Base path: '/home/user/myproject' Input 1: 'Compo' Input 2: 'Diffuse/' Input 3: 'details/Normals' would create output files in /home/user/myproject: Compo0001.png, Compo0002.png, ... in /home/user/myproject/Diffuse: 0001.png, 0002.png, ... (no filename base given) in /home/user/myproject/details: Normals0001.png, Normals0002.png, ... Most settings for the node can be found in the sidebar (NKEY). New input sockets can be added with the "Add Input" button. There is a list of input sockets and below that the details for each socket can be changed, including the sub-path and filename. Sockets can be removed here as well. By default each socket uses the render settings file output format, but each can use its own format if necessary. To my knowledge this is the first node making use of such dynamic sockets in trunk. So this is also a design test, other nodes might use this in the future. Adding operator buttons on top of a node is a bit unwieldy atm, because all node operators generally work on selected and/or active node(s). The operator button would therefore either have to make sure the node is activated before the operator is called (block callback maybe?) OR it has to store the node name (risky, weak reference). For now it is only used in the sidebar, where only the active node's buttons are displayed. Also adds a new struct_type value to bNodeSocket, in order to distinguish different socket types with the same data type (file inputs are SOCK_RGBA color sockets). Would be nicer to use data type only for actual data evaluation, but used in too many places, this works ok for now.
2012-02-22 12:24:04 +00:00
/* callbacks */
ot->exec = node_output_file_add_socket_exec;
ot->poll = composite_node_editable;
Adds a new node type for saving multiple image files from a single node. Unlike the existing file output node this node has an arbitrary number of possible input slots. It has a base path string that can be set to a general base folder. Every input socket then uses its name as an extension of the base path for file organization. This can include further subfolders on top of the base path. Example: Base path: '/home/user/myproject' Input 1: 'Compo' Input 2: 'Diffuse/' Input 3: 'details/Normals' would create output files in /home/user/myproject: Compo0001.png, Compo0002.png, ... in /home/user/myproject/Diffuse: 0001.png, 0002.png, ... (no filename base given) in /home/user/myproject/details: Normals0001.png, Normals0002.png, ... Most settings for the node can be found in the sidebar (NKEY). New input sockets can be added with the "Add Input" button. There is a list of input sockets and below that the details for each socket can be changed, including the sub-path and filename. Sockets can be removed here as well. By default each socket uses the render settings file output format, but each can use its own format if necessary. To my knowledge this is the first node making use of such dynamic sockets in trunk. So this is also a design test, other nodes might use this in the future. Adding operator buttons on top of a node is a bit unwieldy atm, because all node operators generally work on selected and/or active node(s). The operator button would therefore either have to make sure the node is activated before the operator is called (block callback maybe?) OR it has to store the node name (risky, weak reference). For now it is only used in the sidebar, where only the active node's buttons are displayed. Also adds a new struct_type value to bNodeSocket, in order to distinguish different socket types with the same data type (file inputs are SOCK_RGBA color sockets). Would be nicer to use data type only for actual data evaluation, but used in too many places, this works ok for now.
2012-02-22 12:24:04 +00:00
/* flags */
2012-06-21 13:19:19 +00:00
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
RNA_def_string(
ot->srna, "file_path", "Image", MAX_NAME, "File Path", "Subpath of the output file");
Adds a new node type for saving multiple image files from a single node. Unlike the existing file output node this node has an arbitrary number of possible input slots. It has a base path string that can be set to a general base folder. Every input socket then uses its name as an extension of the base path for file organization. This can include further subfolders on top of the base path. Example: Base path: '/home/user/myproject' Input 1: 'Compo' Input 2: 'Diffuse/' Input 3: 'details/Normals' would create output files in /home/user/myproject: Compo0001.png, Compo0002.png, ... in /home/user/myproject/Diffuse: 0001.png, 0002.png, ... (no filename base given) in /home/user/myproject/details: Normals0001.png, Normals0002.png, ... Most settings for the node can be found in the sidebar (NKEY). New input sockets can be added with the "Add Input" button. There is a list of input sockets and below that the details for each socket can be changed, including the sub-path and filename. Sockets can be removed here as well. By default each socket uses the render settings file output format, but each can use its own format if necessary. To my knowledge this is the first node making use of such dynamic sockets in trunk. So this is also a design test, other nodes might use this in the future. Adding operator buttons on top of a node is a bit unwieldy atm, because all node operators generally work on selected and/or active node(s). The operator button would therefore either have to make sure the node is activated before the operator is called (block callback maybe?) OR it has to store the node name (risky, weak reference). For now it is only used in the sidebar, where only the active node's buttons are displayed. Also adds a new struct_type value to bNodeSocket, in order to distinguish different socket types with the same data type (file inputs are SOCK_RGBA color sockets). Would be nicer to use data type only for actual data evaluation, but used in too many places, this works ok for now.
2012-02-22 12:24:04 +00:00
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Node Multi File Output Remove Socket Operator
* \{ */
Adds a new node type for saving multiple image files from a single node. Unlike the existing file output node this node has an arbitrary number of possible input slots. It has a base path string that can be set to a general base folder. Every input socket then uses its name as an extension of the base path for file organization. This can include further subfolders on top of the base path. Example: Base path: '/home/user/myproject' Input 1: 'Compo' Input 2: 'Diffuse/' Input 3: 'details/Normals' would create output files in /home/user/myproject: Compo0001.png, Compo0002.png, ... in /home/user/myproject/Diffuse: 0001.png, 0002.png, ... (no filename base given) in /home/user/myproject/details: Normals0001.png, Normals0002.png, ... Most settings for the node can be found in the sidebar (NKEY). New input sockets can be added with the "Add Input" button. There is a list of input sockets and below that the details for each socket can be changed, including the sub-path and filename. Sockets can be removed here as well. By default each socket uses the render settings file output format, but each can use its own format if necessary. To my knowledge this is the first node making use of such dynamic sockets in trunk. So this is also a design test, other nodes might use this in the future. Adding operator buttons on top of a node is a bit unwieldy atm, because all node operators generally work on selected and/or active node(s). The operator button would therefore either have to make sure the node is activated before the operator is called (block callback maybe?) OR it has to store the node name (risky, weak reference). For now it is only used in the sidebar, where only the active node's buttons are displayed. Also adds a new struct_type value to bNodeSocket, in order to distinguish different socket types with the same data type (file inputs are SOCK_RGBA color sockets). Would be nicer to use data type only for actual data evaluation, but used in too many places, this works ok for now.
2012-02-22 12:24:04 +00:00
static int node_output_file_remove_active_socket_exec(bContext *C, wmOperator * /*op*/)
Adds a new node type for saving multiple image files from a single node. Unlike the existing file output node this node has an arbitrary number of possible input slots. It has a base path string that can be set to a general base folder. Every input socket then uses its name as an extension of the base path for file organization. This can include further subfolders on top of the base path. Example: Base path: '/home/user/myproject' Input 1: 'Compo' Input 2: 'Diffuse/' Input 3: 'details/Normals' would create output files in /home/user/myproject: Compo0001.png, Compo0002.png, ... in /home/user/myproject/Diffuse: 0001.png, 0002.png, ... (no filename base given) in /home/user/myproject/details: Normals0001.png, Normals0002.png, ... Most settings for the node can be found in the sidebar (NKEY). New input sockets can be added with the "Add Input" button. There is a list of input sockets and below that the details for each socket can be changed, including the sub-path and filename. Sockets can be removed here as well. By default each socket uses the render settings file output format, but each can use its own format if necessary. To my knowledge this is the first node making use of such dynamic sockets in trunk. So this is also a design test, other nodes might use this in the future. Adding operator buttons on top of a node is a bit unwieldy atm, because all node operators generally work on selected and/or active node(s). The operator button would therefore either have to make sure the node is activated before the operator is called (block callback maybe?) OR it has to store the node name (risky, weak reference). For now it is only used in the sidebar, where only the active node's buttons are displayed. Also adds a new struct_type value to bNodeSocket, in order to distinguish different socket types with the same data type (file inputs are SOCK_RGBA color sockets). Would be nicer to use data type only for actual data evaluation, but used in too many places, this works ok for now.
2012-02-22 12:24:04 +00:00
{
2012-06-21 13:19:19 +00:00
SpaceNode *snode = CTX_wm_space_node(C);
A number of changes to node RNA and the file output node, to simplify socket types and make node code more robust for future nodes with extra socket data. * Removed the struct_type identifier from sockets completely. Any specialization of socket types can be done by using separate collections in RNA and customized socket draw callbacks in node type. Sockets themselves are pure data inputs/outputs now. Possibly the sock->storage data could also be removed, but this will change anyway with id properties in custom nodes. * Replaced the direct socket button draw calls by extra callbacks in node types. This allows nodes to draw sockets in specialized ways without referring to the additional struct_type identifier. Default is simply drawing the socket default_value button, only file output node overrides this atm. * File output node slots now use a separate file sub-path in their storage data, instead of using the socket name. That way the path is an actual PROP_FILEPATH property and it works better with the UI list template (name property is local to the data struct). * Node draw contexts for options on the node itself and detail buttons in the sidebar now have an extra context pointer "node" (uiLayoutSetContextPointer). This can be used to bind operator buttons to a specific node, instead of having to rely on the active/selected node(s) or making weak links via node name. Compare to modifiers and logic bricks, they use the same feature. * Added another operator for reordering custom input slots in the file output node.
2012-05-02 07:18:51 +00:00
PointerRNA ptr = CTX_data_pointer_get(C, "node");
bNodeTree *ntree = nullptr;
bNode *node = nullptr;
if (ptr.data) {
node = (bNode *)ptr.data;
ntree = (bNodeTree *)ptr.owner_id;
}
else if (snode && snode->edittree) {
ntree = snode->edittree;
node = bke::node_get_active(snode->edittree);
}
if (!node || node->type_legacy != CMP_NODE_OUTPUT_FILE) {
Adds a new node type for saving multiple image files from a single node. Unlike the existing file output node this node has an arbitrary number of possible input slots. It has a base path string that can be set to a general base folder. Every input socket then uses its name as an extension of the base path for file organization. This can include further subfolders on top of the base path. Example: Base path: '/home/user/myproject' Input 1: 'Compo' Input 2: 'Diffuse/' Input 3: 'details/Normals' would create output files in /home/user/myproject: Compo0001.png, Compo0002.png, ... in /home/user/myproject/Diffuse: 0001.png, 0002.png, ... (no filename base given) in /home/user/myproject/details: Normals0001.png, Normals0002.png, ... Most settings for the node can be found in the sidebar (NKEY). New input sockets can be added with the "Add Input" button. There is a list of input sockets and below that the details for each socket can be changed, including the sub-path and filename. Sockets can be removed here as well. By default each socket uses the render settings file output format, but each can use its own format if necessary. To my knowledge this is the first node making use of such dynamic sockets in trunk. So this is also a design test, other nodes might use this in the future. Adding operator buttons on top of a node is a bit unwieldy atm, because all node operators generally work on selected and/or active node(s). The operator button would therefore either have to make sure the node is activated before the operator is called (block callback maybe?) OR it has to store the node name (risky, weak reference). For now it is only used in the sidebar, where only the active node's buttons are displayed. Also adds a new struct_type value to bNodeSocket, in order to distinguish different socket types with the same data type (file inputs are SOCK_RGBA color sockets). Would be nicer to use data type only for actual data evaluation, but used in too many places, this works ok for now.
2012-02-22 12:24:04 +00:00
return OPERATOR_CANCELLED;
}
if (!ntreeCompositOutputFileRemoveActiveSocket(ntree, node)) {
Adds a new node type for saving multiple image files from a single node. Unlike the existing file output node this node has an arbitrary number of possible input slots. It has a base path string that can be set to a general base folder. Every input socket then uses its name as an extension of the base path for file organization. This can include further subfolders on top of the base path. Example: Base path: '/home/user/myproject' Input 1: 'Compo' Input 2: 'Diffuse/' Input 3: 'details/Normals' would create output files in /home/user/myproject: Compo0001.png, Compo0002.png, ... in /home/user/myproject/Diffuse: 0001.png, 0002.png, ... (no filename base given) in /home/user/myproject/details: Normals0001.png, Normals0002.png, ... Most settings for the node can be found in the sidebar (NKEY). New input sockets can be added with the "Add Input" button. There is a list of input sockets and below that the details for each socket can be changed, including the sub-path and filename. Sockets can be removed here as well. By default each socket uses the render settings file output format, but each can use its own format if necessary. To my knowledge this is the first node making use of such dynamic sockets in trunk. So this is also a design test, other nodes might use this in the future. Adding operator buttons on top of a node is a bit unwieldy atm, because all node operators generally work on selected and/or active node(s). The operator button would therefore either have to make sure the node is activated before the operator is called (block callback maybe?) OR it has to store the node name (risky, weak reference). For now it is only used in the sidebar, where only the active node's buttons are displayed. Also adds a new struct_type value to bNodeSocket, in order to distinguish different socket types with the same data type (file inputs are SOCK_RGBA color sockets). Would be nicer to use data type only for actual data evaluation, but used in too many places, this works ok for now.
2012-02-22 12:24:04 +00:00
return OPERATOR_CANCELLED;
}
BKE_main_ensure_invariants(*CTX_data_main(C), ntree->id);
Adds a new node type for saving multiple image files from a single node. Unlike the existing file output node this node has an arbitrary number of possible input slots. It has a base path string that can be set to a general base folder. Every input socket then uses its name as an extension of the base path for file organization. This can include further subfolders on top of the base path. Example: Base path: '/home/user/myproject' Input 1: 'Compo' Input 2: 'Diffuse/' Input 3: 'details/Normals' would create output files in /home/user/myproject: Compo0001.png, Compo0002.png, ... in /home/user/myproject/Diffuse: 0001.png, 0002.png, ... (no filename base given) in /home/user/myproject/details: Normals0001.png, Normals0002.png, ... Most settings for the node can be found in the sidebar (NKEY). New input sockets can be added with the "Add Input" button. There is a list of input sockets and below that the details for each socket can be changed, including the sub-path and filename. Sockets can be removed here as well. By default each socket uses the render settings file output format, but each can use its own format if necessary. To my knowledge this is the first node making use of such dynamic sockets in trunk. So this is also a design test, other nodes might use this in the future. Adding operator buttons on top of a node is a bit unwieldy atm, because all node operators generally work on selected and/or active node(s). The operator button would therefore either have to make sure the node is activated before the operator is called (block callback maybe?) OR it has to store the node name (risky, weak reference). For now it is only used in the sidebar, where only the active node's buttons are displayed. Also adds a new struct_type value to bNodeSocket, in order to distinguish different socket types with the same data type (file inputs are SOCK_RGBA color sockets). Would be nicer to use data type only for actual data evaluation, but used in too many places, this works ok for now.
2012-02-22 12:24:04 +00:00
return OPERATOR_FINISHED;
}
void NODE_OT_output_file_remove_active_socket(wmOperatorType *ot)
Adds a new node type for saving multiple image files from a single node. Unlike the existing file output node this node has an arbitrary number of possible input slots. It has a base path string that can be set to a general base folder. Every input socket then uses its name as an extension of the base path for file organization. This can include further subfolders on top of the base path. Example: Base path: '/home/user/myproject' Input 1: 'Compo' Input 2: 'Diffuse/' Input 3: 'details/Normals' would create output files in /home/user/myproject: Compo0001.png, Compo0002.png, ... in /home/user/myproject/Diffuse: 0001.png, 0002.png, ... (no filename base given) in /home/user/myproject/details: Normals0001.png, Normals0002.png, ... Most settings for the node can be found in the sidebar (NKEY). New input sockets can be added with the "Add Input" button. There is a list of input sockets and below that the details for each socket can be changed, including the sub-path and filename. Sockets can be removed here as well. By default each socket uses the render settings file output format, but each can use its own format if necessary. To my knowledge this is the first node making use of such dynamic sockets in trunk. So this is also a design test, other nodes might use this in the future. Adding operator buttons on top of a node is a bit unwieldy atm, because all node operators generally work on selected and/or active node(s). The operator button would therefore either have to make sure the node is activated before the operator is called (block callback maybe?) OR it has to store the node name (risky, weak reference). For now it is only used in the sidebar, where only the active node's buttons are displayed. Also adds a new struct_type value to bNodeSocket, in order to distinguish different socket types with the same data type (file inputs are SOCK_RGBA color sockets). Would be nicer to use data type only for actual data evaluation, but used in too many places, this works ok for now.
2012-02-22 12:24:04 +00:00
{
/* identifiers */
ot->name = "Remove File Node Socket";
ot->description = "Remove the active input from a file output node";
ot->idname = "NODE_OT_output_file_remove_active_socket";
Adds a new node type for saving multiple image files from a single node. Unlike the existing file output node this node has an arbitrary number of possible input slots. It has a base path string that can be set to a general base folder. Every input socket then uses its name as an extension of the base path for file organization. This can include further subfolders on top of the base path. Example: Base path: '/home/user/myproject' Input 1: 'Compo' Input 2: 'Diffuse/' Input 3: 'details/Normals' would create output files in /home/user/myproject: Compo0001.png, Compo0002.png, ... in /home/user/myproject/Diffuse: 0001.png, 0002.png, ... (no filename base given) in /home/user/myproject/details: Normals0001.png, Normals0002.png, ... Most settings for the node can be found in the sidebar (NKEY). New input sockets can be added with the "Add Input" button. There is a list of input sockets and below that the details for each socket can be changed, including the sub-path and filename. Sockets can be removed here as well. By default each socket uses the render settings file output format, but each can use its own format if necessary. To my knowledge this is the first node making use of such dynamic sockets in trunk. So this is also a design test, other nodes might use this in the future. Adding operator buttons on top of a node is a bit unwieldy atm, because all node operators generally work on selected and/or active node(s). The operator button would therefore either have to make sure the node is activated before the operator is called (block callback maybe?) OR it has to store the node name (risky, weak reference). For now it is only used in the sidebar, where only the active node's buttons are displayed. Also adds a new struct_type value to bNodeSocket, in order to distinguish different socket types with the same data type (file inputs are SOCK_RGBA color sockets). Would be nicer to use data type only for actual data evaluation, but used in too many places, this works ok for now.
2012-02-22 12:24:04 +00:00
/* callbacks */
ot->exec = node_output_file_remove_active_socket_exec;
ot->poll = composite_node_editable;
Adds a new node type for saving multiple image files from a single node. Unlike the existing file output node this node has an arbitrary number of possible input slots. It has a base path string that can be set to a general base folder. Every input socket then uses its name as an extension of the base path for file organization. This can include further subfolders on top of the base path. Example: Base path: '/home/user/myproject' Input 1: 'Compo' Input 2: 'Diffuse/' Input 3: 'details/Normals' would create output files in /home/user/myproject: Compo0001.png, Compo0002.png, ... in /home/user/myproject/Diffuse: 0001.png, 0002.png, ... (no filename base given) in /home/user/myproject/details: Normals0001.png, Normals0002.png, ... Most settings for the node can be found in the sidebar (NKEY). New input sockets can be added with the "Add Input" button. There is a list of input sockets and below that the details for each socket can be changed, including the sub-path and filename. Sockets can be removed here as well. By default each socket uses the render settings file output format, but each can use its own format if necessary. To my knowledge this is the first node making use of such dynamic sockets in trunk. So this is also a design test, other nodes might use this in the future. Adding operator buttons on top of a node is a bit unwieldy atm, because all node operators generally work on selected and/or active node(s). The operator button would therefore either have to make sure the node is activated before the operator is called (block callback maybe?) OR it has to store the node name (risky, weak reference). For now it is only used in the sidebar, where only the active node's buttons are displayed. Also adds a new struct_type value to bNodeSocket, in order to distinguish different socket types with the same data type (file inputs are SOCK_RGBA color sockets). Would be nicer to use data type only for actual data evaluation, but used in too many places, this works ok for now.
2012-02-22 12:24:04 +00:00
/* flags */
2012-06-21 13:19:19 +00:00
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
Adds a new node type for saving multiple image files from a single node. Unlike the existing file output node this node has an arbitrary number of possible input slots. It has a base path string that can be set to a general base folder. Every input socket then uses its name as an extension of the base path for file organization. This can include further subfolders on top of the base path. Example: Base path: '/home/user/myproject' Input 1: 'Compo' Input 2: 'Diffuse/' Input 3: 'details/Normals' would create output files in /home/user/myproject: Compo0001.png, Compo0002.png, ... in /home/user/myproject/Diffuse: 0001.png, 0002.png, ... (no filename base given) in /home/user/myproject/details: Normals0001.png, Normals0002.png, ... Most settings for the node can be found in the sidebar (NKEY). New input sockets can be added with the "Add Input" button. There is a list of input sockets and below that the details for each socket can be changed, including the sub-path and filename. Sockets can be removed here as well. By default each socket uses the render settings file output format, but each can use its own format if necessary. To my knowledge this is the first node making use of such dynamic sockets in trunk. So this is also a design test, other nodes might use this in the future. Adding operator buttons on top of a node is a bit unwieldy atm, because all node operators generally work on selected and/or active node(s). The operator button would therefore either have to make sure the node is activated before the operator is called (block callback maybe?) OR it has to store the node name (risky, weak reference). For now it is only used in the sidebar, where only the active node's buttons are displayed. Also adds a new struct_type value to bNodeSocket, in order to distinguish different socket types with the same data type (file inputs are SOCK_RGBA color sockets). Would be nicer to use data type only for actual data evaluation, but used in too many places, this works ok for now.
2012-02-22 12:24:04 +00:00
}
A number of changes to node RNA and the file output node, to simplify socket types and make node code more robust for future nodes with extra socket data. * Removed the struct_type identifier from sockets completely. Any specialization of socket types can be done by using separate collections in RNA and customized socket draw callbacks in node type. Sockets themselves are pure data inputs/outputs now. Possibly the sock->storage data could also be removed, but this will change anyway with id properties in custom nodes. * Replaced the direct socket button draw calls by extra callbacks in node types. This allows nodes to draw sockets in specialized ways without referring to the additional struct_type identifier. Default is simply drawing the socket default_value button, only file output node overrides this atm. * File output node slots now use a separate file sub-path in their storage data, instead of using the socket name. That way the path is an actual PROP_FILEPATH property and it works better with the UI list template (name property is local to the data struct). * Node draw contexts for options on the node itself and detail buttons in the sidebar now have an extra context pointer "node" (uiLayoutSetContextPointer). This can be used to bind operator buttons to a specific node, instead of having to rely on the active/selected node(s) or making weak links via node name. Compare to modifiers and logic bricks, they use the same feature. * Added another operator for reordering custom input slots in the file output node.
2012-05-02 07:18:51 +00:00
/** \} */
/* -------------------------------------------------------------------- */
/** \name Node Multi File Output Move Socket Node
* \{ */
A number of changes to node RNA and the file output node, to simplify socket types and make node code more robust for future nodes with extra socket data. * Removed the struct_type identifier from sockets completely. Any specialization of socket types can be done by using separate collections in RNA and customized socket draw callbacks in node type. Sockets themselves are pure data inputs/outputs now. Possibly the sock->storage data could also be removed, but this will change anyway with id properties in custom nodes. * Replaced the direct socket button draw calls by extra callbacks in node types. This allows nodes to draw sockets in specialized ways without referring to the additional struct_type identifier. Default is simply drawing the socket default_value button, only file output node overrides this atm. * File output node slots now use a separate file sub-path in their storage data, instead of using the socket name. That way the path is an actual PROP_FILEPATH property and it works better with the UI list template (name property is local to the data struct). * Node draw contexts for options on the node itself and detail buttons in the sidebar now have an extra context pointer "node" (uiLayoutSetContextPointer). This can be used to bind operator buttons to a specific node, instead of having to rely on the active/selected node(s) or making weak links via node name. Compare to modifiers and logic bricks, they use the same feature. * Added another operator for reordering custom input slots in the file output node.
2012-05-02 07:18:51 +00:00
static int node_output_file_move_active_socket_exec(bContext *C, wmOperator *op)
{
2012-06-21 13:19:19 +00:00
SpaceNode *snode = CTX_wm_space_node(C);
A number of changes to node RNA and the file output node, to simplify socket types and make node code more robust for future nodes with extra socket data. * Removed the struct_type identifier from sockets completely. Any specialization of socket types can be done by using separate collections in RNA and customized socket draw callbacks in node type. Sockets themselves are pure data inputs/outputs now. Possibly the sock->storage data could also be removed, but this will change anyway with id properties in custom nodes. * Replaced the direct socket button draw calls by extra callbacks in node types. This allows nodes to draw sockets in specialized ways without referring to the additional struct_type identifier. Default is simply drawing the socket default_value button, only file output node overrides this atm. * File output node slots now use a separate file sub-path in their storage data, instead of using the socket name. That way the path is an actual PROP_FILEPATH property and it works better with the UI list template (name property is local to the data struct). * Node draw contexts for options on the node itself and detail buttons in the sidebar now have an extra context pointer "node" (uiLayoutSetContextPointer). This can be used to bind operator buttons to a specific node, instead of having to rely on the active/selected node(s) or making weak links via node name. Compare to modifiers and logic bricks, they use the same feature. * Added another operator for reordering custom input slots in the file output node.
2012-05-02 07:18:51 +00:00
PointerRNA ptr = CTX_data_pointer_get(C, "node");
bNode *node = nullptr;
if (ptr.data) {
node = (bNode *)ptr.data;
}
else if (snode && snode->edittree) {
node = bke::node_get_active(snode->edittree);
}
if (!node || node->type_legacy != CMP_NODE_OUTPUT_FILE) {
A number of changes to node RNA and the file output node, to simplify socket types and make node code more robust for future nodes with extra socket data. * Removed the struct_type identifier from sockets completely. Any specialization of socket types can be done by using separate collections in RNA and customized socket draw callbacks in node type. Sockets themselves are pure data inputs/outputs now. Possibly the sock->storage data could also be removed, but this will change anyway with id properties in custom nodes. * Replaced the direct socket button draw calls by extra callbacks in node types. This allows nodes to draw sockets in specialized ways without referring to the additional struct_type identifier. Default is simply drawing the socket default_value button, only file output node overrides this atm. * File output node slots now use a separate file sub-path in their storage data, instead of using the socket name. That way the path is an actual PROP_FILEPATH property and it works better with the UI list template (name property is local to the data struct). * Node draw contexts for options on the node itself and detail buttons in the sidebar now have an extra context pointer "node" (uiLayoutSetContextPointer). This can be used to bind operator buttons to a specific node, instead of having to rely on the active/selected node(s) or making weak links via node name. Compare to modifiers and logic bricks, they use the same feature. * Added another operator for reordering custom input slots in the file output node.
2012-05-02 07:18:51 +00:00
return OPERATOR_CANCELLED;
}
NodeImageMultiFile *nimf = (NodeImageMultiFile *)node->storage;
bNodeSocket *sock = (bNodeSocket *)BLI_findlink(&node->inputs, nimf->active_input);
if (!sock) {
A number of changes to node RNA and the file output node, to simplify socket types and make node code more robust for future nodes with extra socket data. * Removed the struct_type identifier from sockets completely. Any specialization of socket types can be done by using separate collections in RNA and customized socket draw callbacks in node type. Sockets themselves are pure data inputs/outputs now. Possibly the sock->storage data could also be removed, but this will change anyway with id properties in custom nodes. * Replaced the direct socket button draw calls by extra callbacks in node types. This allows nodes to draw sockets in specialized ways without referring to the additional struct_type identifier. Default is simply drawing the socket default_value button, only file output node overrides this atm. * File output node slots now use a separate file sub-path in their storage data, instead of using the socket name. That way the path is an actual PROP_FILEPATH property and it works better with the UI list template (name property is local to the data struct). * Node draw contexts for options on the node itself and detail buttons in the sidebar now have an extra context pointer "node" (uiLayoutSetContextPointer). This can be used to bind operator buttons to a specific node, instead of having to rely on the active/selected node(s) or making weak links via node name. Compare to modifiers and logic bricks, they use the same feature. * Added another operator for reordering custom input slots in the file output node.
2012-05-02 07:18:51 +00:00
return OPERATOR_CANCELLED;
}
int direction = RNA_enum_get(op->ptr, "direction");
2012-06-21 13:19:19 +00:00
if (direction == 1) {
A number of changes to node RNA and the file output node, to simplify socket types and make node code more robust for future nodes with extra socket data. * Removed the struct_type identifier from sockets completely. Any specialization of socket types can be done by using separate collections in RNA and customized socket draw callbacks in node type. Sockets themselves are pure data inputs/outputs now. Possibly the sock->storage data could also be removed, but this will change anyway with id properties in custom nodes. * Replaced the direct socket button draw calls by extra callbacks in node types. This allows nodes to draw sockets in specialized ways without referring to the additional struct_type identifier. Default is simply drawing the socket default_value button, only file output node overrides this atm. * File output node slots now use a separate file sub-path in their storage data, instead of using the socket name. That way the path is an actual PROP_FILEPATH property and it works better with the UI list template (name property is local to the data struct). * Node draw contexts for options on the node itself and detail buttons in the sidebar now have an extra context pointer "node" (uiLayoutSetContextPointer). This can be used to bind operator buttons to a specific node, instead of having to rely on the active/selected node(s) or making weak links via node name. Compare to modifiers and logic bricks, they use the same feature. * Added another operator for reordering custom input slots in the file output node.
2012-05-02 07:18:51 +00:00
bNodeSocket *before = sock->prev;
if (!before) {
A number of changes to node RNA and the file output node, to simplify socket types and make node code more robust for future nodes with extra socket data. * Removed the struct_type identifier from sockets completely. Any specialization of socket types can be done by using separate collections in RNA and customized socket draw callbacks in node type. Sockets themselves are pure data inputs/outputs now. Possibly the sock->storage data could also be removed, but this will change anyway with id properties in custom nodes. * Replaced the direct socket button draw calls by extra callbacks in node types. This allows nodes to draw sockets in specialized ways without referring to the additional struct_type identifier. Default is simply drawing the socket default_value button, only file output node overrides this atm. * File output node slots now use a separate file sub-path in their storage data, instead of using the socket name. That way the path is an actual PROP_FILEPATH property and it works better with the UI list template (name property is local to the data struct). * Node draw contexts for options on the node itself and detail buttons in the sidebar now have an extra context pointer "node" (uiLayoutSetContextPointer). This can be used to bind operator buttons to a specific node, instead of having to rely on the active/selected node(s) or making weak links via node name. Compare to modifiers and logic bricks, they use the same feature. * Added another operator for reordering custom input slots in the file output node.
2012-05-02 07:18:51 +00:00
return OPERATOR_CANCELLED;
}
A number of changes to node RNA and the file output node, to simplify socket types and make node code more robust for future nodes with extra socket data. * Removed the struct_type identifier from sockets completely. Any specialization of socket types can be done by using separate collections in RNA and customized socket draw callbacks in node type. Sockets themselves are pure data inputs/outputs now. Possibly the sock->storage data could also be removed, but this will change anyway with id properties in custom nodes. * Replaced the direct socket button draw calls by extra callbacks in node types. This allows nodes to draw sockets in specialized ways without referring to the additional struct_type identifier. Default is simply drawing the socket default_value button, only file output node overrides this atm. * File output node slots now use a separate file sub-path in their storage data, instead of using the socket name. That way the path is an actual PROP_FILEPATH property and it works better with the UI list template (name property is local to the data struct). * Node draw contexts for options on the node itself and detail buttons in the sidebar now have an extra context pointer "node" (uiLayoutSetContextPointer). This can be used to bind operator buttons to a specific node, instead of having to rely on the active/selected node(s) or making weak links via node name. Compare to modifiers and logic bricks, they use the same feature. * Added another operator for reordering custom input slots in the file output node.
2012-05-02 07:18:51 +00:00
BLI_remlink(&node->inputs, sock);
BLI_insertlinkbefore(&node->inputs, before, sock);
2012-08-22 16:44:32 +00:00
nimf->active_input--;
A number of changes to node RNA and the file output node, to simplify socket types and make node code more robust for future nodes with extra socket data. * Removed the struct_type identifier from sockets completely. Any specialization of socket types can be done by using separate collections in RNA and customized socket draw callbacks in node type. Sockets themselves are pure data inputs/outputs now. Possibly the sock->storage data could also be removed, but this will change anyway with id properties in custom nodes. * Replaced the direct socket button draw calls by extra callbacks in node types. This allows nodes to draw sockets in specialized ways without referring to the additional struct_type identifier. Default is simply drawing the socket default_value button, only file output node overrides this atm. * File output node slots now use a separate file sub-path in their storage data, instead of using the socket name. That way the path is an actual PROP_FILEPATH property and it works better with the UI list template (name property is local to the data struct). * Node draw contexts for options on the node itself and detail buttons in the sidebar now have an extra context pointer "node" (uiLayoutSetContextPointer). This can be used to bind operator buttons to a specific node, instead of having to rely on the active/selected node(s) or making weak links via node name. Compare to modifiers and logic bricks, they use the same feature. * Added another operator for reordering custom input slots in the file output node.
2012-05-02 07:18:51 +00:00
}
else {
bNodeSocket *after = sock->next;
if (!after) {
A number of changes to node RNA and the file output node, to simplify socket types and make node code more robust for future nodes with extra socket data. * Removed the struct_type identifier from sockets completely. Any specialization of socket types can be done by using separate collections in RNA and customized socket draw callbacks in node type. Sockets themselves are pure data inputs/outputs now. Possibly the sock->storage data could also be removed, but this will change anyway with id properties in custom nodes. * Replaced the direct socket button draw calls by extra callbacks in node types. This allows nodes to draw sockets in specialized ways without referring to the additional struct_type identifier. Default is simply drawing the socket default_value button, only file output node overrides this atm. * File output node slots now use a separate file sub-path in their storage data, instead of using the socket name. That way the path is an actual PROP_FILEPATH property and it works better with the UI list template (name property is local to the data struct). * Node draw contexts for options on the node itself and detail buttons in the sidebar now have an extra context pointer "node" (uiLayoutSetContextPointer). This can be used to bind operator buttons to a specific node, instead of having to rely on the active/selected node(s) or making weak links via node name. Compare to modifiers and logic bricks, they use the same feature. * Added another operator for reordering custom input slots in the file output node.
2012-05-02 07:18:51 +00:00
return OPERATOR_CANCELLED;
}
A number of changes to node RNA and the file output node, to simplify socket types and make node code more robust for future nodes with extra socket data. * Removed the struct_type identifier from sockets completely. Any specialization of socket types can be done by using separate collections in RNA and customized socket draw callbacks in node type. Sockets themselves are pure data inputs/outputs now. Possibly the sock->storage data could also be removed, but this will change anyway with id properties in custom nodes. * Replaced the direct socket button draw calls by extra callbacks in node types. This allows nodes to draw sockets in specialized ways without referring to the additional struct_type identifier. Default is simply drawing the socket default_value button, only file output node overrides this atm. * File output node slots now use a separate file sub-path in their storage data, instead of using the socket name. That way the path is an actual PROP_FILEPATH property and it works better with the UI list template (name property is local to the data struct). * Node draw contexts for options on the node itself and detail buttons in the sidebar now have an extra context pointer "node" (uiLayoutSetContextPointer). This can be used to bind operator buttons to a specific node, instead of having to rely on the active/selected node(s) or making weak links via node name. Compare to modifiers and logic bricks, they use the same feature. * Added another operator for reordering custom input slots in the file output node.
2012-05-02 07:18:51 +00:00
BLI_remlink(&node->inputs, sock);
BLI_insertlinkafter(&node->inputs, after, sock);
2012-08-22 16:44:32 +00:00
nimf->active_input++;
A number of changes to node RNA and the file output node, to simplify socket types and make node code more robust for future nodes with extra socket data. * Removed the struct_type identifier from sockets completely. Any specialization of socket types can be done by using separate collections in RNA and customized socket draw callbacks in node type. Sockets themselves are pure data inputs/outputs now. Possibly the sock->storage data could also be removed, but this will change anyway with id properties in custom nodes. * Replaced the direct socket button draw calls by extra callbacks in node types. This allows nodes to draw sockets in specialized ways without referring to the additional struct_type identifier. Default is simply drawing the socket default_value button, only file output node overrides this atm. * File output node slots now use a separate file sub-path in their storage data, instead of using the socket name. That way the path is an actual PROP_FILEPATH property and it works better with the UI list template (name property is local to the data struct). * Node draw contexts for options on the node itself and detail buttons in the sidebar now have an extra context pointer "node" (uiLayoutSetContextPointer). This can be used to bind operator buttons to a specific node, instead of having to rely on the active/selected node(s) or making weak links via node name. Compare to modifiers and logic bricks, they use the same feature. * Added another operator for reordering custom input slots in the file output node.
2012-05-02 07:18:51 +00:00
}
BKE_ntree_update_tag_node_property(snode->edittree, node);
BKE_main_ensure_invariants(*CTX_data_main(C), snode->edittree->id);
A number of changes to node RNA and the file output node, to simplify socket types and make node code more robust for future nodes with extra socket data. * Removed the struct_type identifier from sockets completely. Any specialization of socket types can be done by using separate collections in RNA and customized socket draw callbacks in node type. Sockets themselves are pure data inputs/outputs now. Possibly the sock->storage data could also be removed, but this will change anyway with id properties in custom nodes. * Replaced the direct socket button draw calls by extra callbacks in node types. This allows nodes to draw sockets in specialized ways without referring to the additional struct_type identifier. Default is simply drawing the socket default_value button, only file output node overrides this atm. * File output node slots now use a separate file sub-path in their storage data, instead of using the socket name. That way the path is an actual PROP_FILEPATH property and it works better with the UI list template (name property is local to the data struct). * Node draw contexts for options on the node itself and detail buttons in the sidebar now have an extra context pointer "node" (uiLayoutSetContextPointer). This can be used to bind operator buttons to a specific node, instead of having to rely on the active/selected node(s) or making weak links via node name. Compare to modifiers and logic bricks, they use the same feature. * Added another operator for reordering custom input slots in the file output node.
2012-05-02 07:18:51 +00:00
return OPERATOR_FINISHED;
}
void NODE_OT_output_file_move_active_socket(wmOperatorType *ot)
{
static const EnumPropertyItem direction_items[] = {
{1, "UP", 0, "Up", ""}, {2, "DOWN", 0, "Down", ""}, {0, nullptr, 0, nullptr, nullptr}};
A number of changes to node RNA and the file output node, to simplify socket types and make node code more robust for future nodes with extra socket data. * Removed the struct_type identifier from sockets completely. Any specialization of socket types can be done by using separate collections in RNA and customized socket draw callbacks in node type. Sockets themselves are pure data inputs/outputs now. Possibly the sock->storage data could also be removed, but this will change anyway with id properties in custom nodes. * Replaced the direct socket button draw calls by extra callbacks in node types. This allows nodes to draw sockets in specialized ways without referring to the additional struct_type identifier. Default is simply drawing the socket default_value button, only file output node overrides this atm. * File output node slots now use a separate file sub-path in their storage data, instead of using the socket name. That way the path is an actual PROP_FILEPATH property and it works better with the UI list template (name property is local to the data struct). * Node draw contexts for options on the node itself and detail buttons in the sidebar now have an extra context pointer "node" (uiLayoutSetContextPointer). This can be used to bind operator buttons to a specific node, instead of having to rely on the active/selected node(s) or making weak links via node name. Compare to modifiers and logic bricks, they use the same feature. * Added another operator for reordering custom input slots in the file output node.
2012-05-02 07:18:51 +00:00
/* identifiers */
ot->name = "Move File Node Socket";
ot->description = "Move the active input of a file output node up or down the list";
ot->idname = "NODE_OT_output_file_move_active_socket";
A number of changes to node RNA and the file output node, to simplify socket types and make node code more robust for future nodes with extra socket data. * Removed the struct_type identifier from sockets completely. Any specialization of socket types can be done by using separate collections in RNA and customized socket draw callbacks in node type. Sockets themselves are pure data inputs/outputs now. Possibly the sock->storage data could also be removed, but this will change anyway with id properties in custom nodes. * Replaced the direct socket button draw calls by extra callbacks in node types. This allows nodes to draw sockets in specialized ways without referring to the additional struct_type identifier. Default is simply drawing the socket default_value button, only file output node overrides this atm. * File output node slots now use a separate file sub-path in their storage data, instead of using the socket name. That way the path is an actual PROP_FILEPATH property and it works better with the UI list template (name property is local to the data struct). * Node draw contexts for options on the node itself and detail buttons in the sidebar now have an extra context pointer "node" (uiLayoutSetContextPointer). This can be used to bind operator buttons to a specific node, instead of having to rely on the active/selected node(s) or making weak links via node name. Compare to modifiers and logic bricks, they use the same feature. * Added another operator for reordering custom input slots in the file output node.
2012-05-02 07:18:51 +00:00
/* callbacks */
ot->exec = node_output_file_move_active_socket_exec;
ot->poll = composite_node_editable;
A number of changes to node RNA and the file output node, to simplify socket types and make node code more robust for future nodes with extra socket data. * Removed the struct_type identifier from sockets completely. Any specialization of socket types can be done by using separate collections in RNA and customized socket draw callbacks in node type. Sockets themselves are pure data inputs/outputs now. Possibly the sock->storage data could also be removed, but this will change anyway with id properties in custom nodes. * Replaced the direct socket button draw calls by extra callbacks in node types. This allows nodes to draw sockets in specialized ways without referring to the additional struct_type identifier. Default is simply drawing the socket default_value button, only file output node overrides this atm. * File output node slots now use a separate file sub-path in their storage data, instead of using the socket name. That way the path is an actual PROP_FILEPATH property and it works better with the UI list template (name property is local to the data struct). * Node draw contexts for options on the node itself and detail buttons in the sidebar now have an extra context pointer "node" (uiLayoutSetContextPointer). This can be used to bind operator buttons to a specific node, instead of having to rely on the active/selected node(s) or making weak links via node name. Compare to modifiers and logic bricks, they use the same feature. * Added another operator for reordering custom input slots in the file output node.
2012-05-02 07:18:51 +00:00
/* flags */
2012-06-21 13:19:19 +00:00
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
A number of changes to node RNA and the file output node, to simplify socket types and make node code more robust for future nodes with extra socket data. * Removed the struct_type identifier from sockets completely. Any specialization of socket types can be done by using separate collections in RNA and customized socket draw callbacks in node type. Sockets themselves are pure data inputs/outputs now. Possibly the sock->storage data could also be removed, but this will change anyway with id properties in custom nodes. * Replaced the direct socket button draw calls by extra callbacks in node types. This allows nodes to draw sockets in specialized ways without referring to the additional struct_type identifier. Default is simply drawing the socket default_value button, only file output node overrides this atm. * File output node slots now use a separate file sub-path in their storage data, instead of using the socket name. That way the path is an actual PROP_FILEPATH property and it works better with the UI list template (name property is local to the data struct). * Node draw contexts for options on the node itself and detail buttons in the sidebar now have an extra context pointer "node" (uiLayoutSetContextPointer). This can be used to bind operator buttons to a specific node, instead of having to rely on the active/selected node(s) or making weak links via node name. Compare to modifiers and logic bricks, they use the same feature. * Added another operator for reordering custom input slots in the file output node.
2012-05-02 07:18:51 +00:00
RNA_def_enum(ot->srna, "direction", direction_items, 2, "Direction", "");
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Node Copy Node Color Operator
* \{ */
static int node_copy_color_exec(bContext *C, wmOperator * /*op*/)
{
SpaceNode &snode = *CTX_wm_space_node(C);
bNodeTree &ntree = *snode.edittree;
bNode *active_node = bke::node_get_active(&ntree);
if (!active_node) {
return OPERATOR_CANCELLED;
}
for (bNode *node : ntree.all_nodes()) {
if (node->flag & NODE_SELECT && node != active_node) {
if (active_node->flag & NODE_CUSTOM_COLOR) {
node->flag |= NODE_CUSTOM_COLOR;
copy_v3_v3(node->color, active_node->color);
}
else {
node->flag &= ~NODE_CUSTOM_COLOR;
}
}
}
WM_event_add_notifier(C, NC_NODE | ND_DISPLAY, nullptr);
return OPERATOR_FINISHED;
}
void NODE_OT_node_copy_color(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Copy Color";
ot->description = "Copy color to all selected nodes";
ot->idname = "NODE_OT_node_copy_color";
/* api callbacks */
ot->exec = node_copy_color_exec;
ot->poll = ED_operator_node_editable;
/* flags */
2012-06-21 13:19:19 +00:00
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Node Shader Script Update
* \{ */
2018-07-02 11:47:00 +02:00
static bool node_shader_script_update_poll(bContext *C)
{
Scene *scene = CTX_data_scene(C);
const RenderEngineType *type = RE_engines_find(scene->r.engine);
SpaceNode *snode = CTX_wm_space_node(C);
/* Test if we have a render engine that supports shaders scripts. */
if (!(type && type->update_script_node)) {
return false;
}
/* See if we have a shader script node in context. */
bNode *node = (bNode *)CTX_data_pointer_get_type(C, "node", &RNA_ShaderNodeScript).data;
if (!node && snode && snode->edittree) {
node = bke::node_get_active(snode->edittree);
}
if (node && node->type_legacy == SH_NODE_SCRIPT) {
NodeShaderScript *nss = (NodeShaderScript *)node->storage;
2012-11-03 15:35:03 +00:00
if (node->id || nss->filepath[0]) {
return ED_operator_node_editable(C);
2012-11-03 15:35:03 +00:00
}
}
/* See if we have a text datablock in context. */
Text *text = (Text *)CTX_data_pointer_get_type(C, "edit_text", &RNA_Text).data;
if (text) {
return true;
}
/* We don't check if text datablock is actually in use, too slow for poll. */
return false;
}
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
/* recursively check for script nodes in groups using this text and update */
2014-04-11 11:25:41 +10:00
static bool node_shader_script_update_text_recursive(RenderEngine *engine,
RenderEngineType *type,
bNodeTree *ntree,
Text *text,
VectorSet<bNodeTree *> &done_trees)
{
2014-04-11 11:25:41 +10:00
bool found = false;
done_trees.add_new(ntree);
/* Update each script that is using this text datablock. */
for (bNode *node : ntree->all_nodes()) {
if (node->type_legacy == NODE_GROUP) {
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
bNodeTree *ngroup = (bNodeTree *)node->id;
if (ngroup && !done_trees.contains(ngroup)) {
found |= node_shader_script_update_text_recursive(engine, type, ngroup, text, done_trees);
}
}
else if (node->type_legacy == SH_NODE_SCRIPT && node->id == &text->id) {
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
type->update_script_node(engine, ntree, node);
found = true;
}
}
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
return found;
}
static int node_shader_script_update_exec(bContext *C, wmOperator *op)
{
Main *bmain = CTX_data_main(C);
Scene *scene = CTX_data_scene(C);
SpaceNode *snode = CTX_wm_space_node(C);
PointerRNA nodeptr = CTX_data_pointer_get_type(C, "node", &RNA_ShaderNodeScript);
2014-04-11 11:25:41 +10:00
bool found = false;
/* setup render engine */
RenderEngineType *type = RE_engines_find(scene->r.engine);
RenderEngine *engine = RE_engine_create(type);
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
engine->reports = op->reports;
bNodeTree *ntree_base = nullptr;
bNode *node = nullptr;
if (nodeptr.data) {
ntree_base = (bNodeTree *)nodeptr.owner_id;
node = (bNode *)nodeptr.data;
}
else if (snode && snode->edittree) {
2015-11-23 15:44:15 +11:00
ntree_base = snode->edittree;
node = bke::node_get_active(snode->edittree);
}
if (node) {
/* Update single node. */
2015-11-23 15:44:15 +11:00
type->update_script_node(engine, ntree_base, node);
found = true;
}
else {
/* Update all nodes using text datablock. */
Text *text = (Text *)CTX_data_pointer_get_type(C, "edit_text", &RNA_Text).data;
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
if (text) {
VectorSet<bNodeTree *> done_trees;
FOREACH_NODETREE_BEGIN (bmain, ntree, id) {
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
if (ntree->type == NTREE_SHADER) {
if (!done_trees.contains(ntree)) {
found |= node_shader_script_update_text_recursive(
engine, type, ntree, text, done_trees);
}
}
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
}
FOREACH_NODETREE_END;
if (!found) {
2012-11-07 14:56:53 +00:00
BKE_report(op->reports, RPT_INFO, "Text not used by any node, no update done");
}
}
}
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
RE_engine_free(engine);
2013-03-31 03:28:46 +00:00
return (found) ? OPERATOR_FINISHED : OPERATOR_CANCELLED;
}
void NODE_OT_shader_script_update(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Script Node Update";
ot->description = "Update shader script node with new sockets and options from the script";
ot->idname = "NODE_OT_shader_script_update";
/* api callbacks */
ot->exec = node_shader_script_update_exec;
ot->poll = node_shader_script_update_poll;
/* flags */
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Node Viewer Border
* \{ */
static void viewer_border_corner_to_backdrop(SpaceNode *snode,
ARegion *region,
int x,
int y,
int backdrop_width,
int backdrop_height,
float *fx,
float *fy)
{
float bufx = backdrop_width * snode->zoom;
float bufy = backdrop_height * snode->zoom;
*fx = (bufx > 0.0f ? (float(x) - 0.5f * region->winx - snode->xof) / bufx + 0.5f : 0.0f);
*fy = (bufy > 0.0f ? (float(y) - 0.5f * region->winy - snode->yof) / bufy + 0.5f : 0.0f);
}
static int viewer_border_exec(bContext *C, wmOperator *op)
{
Main *bmain = CTX_data_main(C);
void *lock;
ED_preview_kill_jobs(CTX_wm_manager(C), bmain);
Image *ima = BKE_image_ensure_viewer(bmain, IMA_TYPE_COMPOSITE, "Viewer Node");
ImBuf *ibuf = BKE_image_acquire_ibuf(ima, nullptr, &lock);
if (ibuf) {
ARegion *region = CTX_wm_region(C);
SpaceNode *snode = CTX_wm_space_node(C);
bNodeTree *btree = snode->nodetree;
rcti rect;
rctf rectf;
/* Get border from operator. */
WM_operator_properties_border_to_rcti(op, &rect);
/* Convert border to unified space within backdrop image. */
viewer_border_corner_to_backdrop(
snode, region, rect.xmin, rect.ymin, ibuf->x, ibuf->y, &rectf.xmin, &rectf.ymin);
viewer_border_corner_to_backdrop(
snode, region, rect.xmax, rect.ymax, ibuf->x, ibuf->y, &rectf.xmax, &rectf.ymax);
/* Clamp coordinates. */
rectf.xmin = max_ff(rectf.xmin, 0.0f);
rectf.ymin = max_ff(rectf.ymin, 0.0f);
rectf.xmax = min_ff(rectf.xmax, 1.0f);
rectf.ymax = min_ff(rectf.ymax, 1.0f);
if (rectf.xmin < rectf.xmax && rectf.ymin < rectf.ymax) {
btree->viewer_border = rectf;
if (rectf.xmin == 0.0f && rectf.ymin == 0.0f && rectf.xmax == 1.0f && rectf.ymax == 1.0f) {
btree->flag &= ~NTREE_VIEWER_BORDER;
}
else {
btree->flag |= NTREE_VIEWER_BORDER;
}
BKE_main_ensure_invariants(*bmain, btree->id);
WM_event_add_notifier(C, NC_NODE | ND_DISPLAY, nullptr);
}
else {
btree->flag &= ~NTREE_VIEWER_BORDER;
}
}
BKE_image_release_ibuf(ima, ibuf, lock);
return OPERATOR_FINISHED;
}
void NODE_OT_viewer_border(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Viewer Region";
ot->description = "Set the boundaries for viewer operations";
ot->idname = "NODE_OT_viewer_border";
/* api callbacks */
ot->invoke = WM_gesture_box_invoke;
ot->exec = viewer_border_exec;
ot->modal = WM_gesture_box_modal;
ot->cancel = WM_gesture_box_cancel;
ot->poll = composite_node_active;
/* flags */
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
/* properties */
WM_operator_properties_gesture_box(ot);
}
static int clear_viewer_border_exec(bContext *C, wmOperator * /*op*/)
{
SpaceNode *snode = CTX_wm_space_node(C);
bNodeTree *btree = snode->nodetree;
btree->flag &= ~NTREE_VIEWER_BORDER;
BKE_main_ensure_invariants(*CTX_data_main(C), btree->id);
WM_event_add_notifier(C, NC_NODE | ND_DISPLAY, nullptr);
return OPERATOR_FINISHED;
}
void NODE_OT_clear_viewer_border(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Clear Viewer Region";
ot->description = "Clear the boundaries for viewer operations";
ot->idname = "NODE_OT_clear_viewer_border";
/* api callbacks */
ot->exec = clear_viewer_border_exec;
ot->poll = composite_node_active;
/* flags */
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Cryptomatte Add Socket
* \{ */
static int node_cryptomatte_add_socket_exec(bContext *C, wmOperator * /*op*/)
{
SpaceNode *snode = CTX_wm_space_node(C);
PointerRNA ptr = CTX_data_pointer_get(C, "node");
bNodeTree *ntree = nullptr;
bNode *node = nullptr;
if (ptr.data) {
node = (bNode *)ptr.data;
ntree = (bNodeTree *)ptr.owner_id;
}
else if (snode && snode->edittree) {
ntree = snode->edittree;
node = bke::node_get_active(snode->edittree);
}
if (!node || node->type_legacy != CMP_NODE_CRYPTOMATTE_LEGACY) {
return OPERATOR_CANCELLED;
}
ntreeCompositCryptomatteAddSocket(ntree, node);
BKE_main_ensure_invariants(*CTX_data_main(C), ntree->id);
return OPERATOR_FINISHED;
}
void NODE_OT_cryptomatte_layer_add(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Add Cryptomatte Socket";
ot->description = "Add a new input layer to a Cryptomatte node";
ot->idname = "NODE_OT_cryptomatte_layer_add";
/* callbacks */
ot->exec = node_cryptomatte_add_socket_exec;
ot->poll = composite_node_editable;
/* flags */
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Cryptomatte Remove Socket
* \{ */
static int node_cryptomatte_remove_socket_exec(bContext *C, wmOperator * /*op*/)
{
SpaceNode *snode = CTX_wm_space_node(C);
PointerRNA ptr = CTX_data_pointer_get(C, "node");
bNodeTree *ntree = nullptr;
bNode *node = nullptr;
if (ptr.data) {
node = (bNode *)ptr.data;
ntree = (bNodeTree *)ptr.owner_id;
}
else if (snode && snode->edittree) {
ntree = snode->edittree;
node = bke::node_get_active(snode->edittree);
}
if (!node || node->type_legacy != CMP_NODE_CRYPTOMATTE_LEGACY) {
return OPERATOR_CANCELLED;
}
if (!ntreeCompositCryptomatteRemoveSocket(ntree, node)) {
return OPERATOR_CANCELLED;
}
BKE_main_ensure_invariants(*CTX_data_main(C), ntree->id);
return OPERATOR_FINISHED;
}
void NODE_OT_cryptomatte_layer_remove(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Remove Cryptomatte Socket";
ot->description = "Remove layer from a Cryptomatte node";
ot->idname = "NODE_OT_cryptomatte_layer_remove";
/* callbacks */
ot->exec = node_cryptomatte_remove_socket_exec;
ot->poll = composite_node_editable;
/* flags */
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
}
/** \} */
} // namespace blender::ed::space_node