This repository has been archived on 2023-10-09. You can view files and clone it, but cannot push or open issues or pull requests.
Files
blender-archive/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.

2836 lines
78 KiB
C++
Raw Normal View History

/*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
2010-02-12 13:34:04 +00:00
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*
* The Original Code is Copyright (C) 2005 Blender Foundation.
* All rights reserved.
*/
/** \file
* \ingroup spnode
2011-02-27 20:29:51 +00:00
*/
#include "MEM_guardedalloc.h"
2019-02-27 12:34:56 +11:00
#include "DNA_light_types.h"
#include "DNA_material_types.h"
#include "DNA_node_types.h"
#include "DNA_text_types.h"
#include "DNA_world_types.h"
#include "BLI_blenlib.h"
#include "BLI_math.h"
#include "BKE_context.h"
#include "BKE_global.h"
#include "BKE_image.h"
#include "BKE_lib_id.h"
#include "BKE_main.h"
#include "BKE_material.h"
#include "BKE_node.h"
#include "BKE_report.h"
#include "BKE_scene.h"
#include "BKE_workspace.h"
#include "DEG_depsgraph.h"
#include "DEG_depsgraph_build.h"
#include "DEG_depsgraph_query.h"
#include "RE_engine.h"
#include "RE_pipeline.h"
2012-08-01 20:39:14 +00:00
#include "ED_node.h" /* own include */
#include "ED_render.h"
#include "ED_screen.h"
#include "ED_select_utils.h"
#include "RNA_access.h"
#include "RNA_define.h"
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 "RNA_enum_types.h"
#include "WM_api.h"
#include "WM_types.h"
#include "UI_view2d.h"
#include "GPU_material.h"
#include "IMB_imbuf_types.h"
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_composite.h"
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
#include "NOD_geometry.h"
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_texture.h"
#include "node_intern.h" /* 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
2012-08-15 11:31:04 +00:00
#define USE_ESC_COMPO
/* ***************** 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;
/* Jon system integration. */
const short *stop;
short *do_update;
float *progress;
};
float node_socket_calculate_height(const bNodeSocket *socket)
{
float sock_height = NODE_SOCKSIZE * 2.0f;
if (socket->flag & SOCK_MULTI_INPUT) {
sock_height += max_ii(NODE_MULTI_INPUT_LINK_GAP * 0.5f * socket->total_inputs, NODE_SOCKSIZE);
}
return sock_height;
}
void node_link_calculate_multi_input_position(const float socket_x,
const float socket_y,
const int index,
const int total_inputs,
float r[2])
{
float offset = (total_inputs * NODE_MULTI_INPUT_LINK_GAP - NODE_MULTI_INPUT_LINK_GAP) * 0.5;
r[0] = socket_x - NODE_SOCKSIZE * 0.5f;
r[1] = socket_y - offset + (index * NODE_MULTI_INPUT_LINK_GAP);
}
static void compo_tag_output_nodes(bNodeTree *nodetree, int recalc_flags)
{
LISTBASE_FOREACH (bNode *, node, &nodetree->nodes) {
if (node->type == CMP_NODE_COMPOSITE) {
if (recalc_flags & COM_RECALC_COMPOSITE) {
node->flag |= NODE_DO_OUTPUT_RECALC;
}
}
2020-11-06 12:30:59 +11:00
else if (ELEM(node->type, CMP_NODE_VIEWER, CMP_NODE_SPLITVIEWER)) {
if (recalc_flags & COM_RECALC_VIEWER) {
node->flag |= NODE_DO_OUTPUT_RECALC;
}
}
else if (node->type == 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 compo, only to check job 'stop' value */
static int compo_breakjob(void *cjv)
{
CompoJob *cj = (CompoJob *)cjv;
2012-08-15 11:31:04 +00:00
/* without G.is_break 'ESC' wont quit - which annoys users */
return (*(cj->stop)
#ifdef USE_ESC_COMPO
|| G.is_break
#endif
);
}
/* called by compo, wmJob sends notifier */
2015-03-28 02:36:00 +11:00
static void compo_statsdrawjob(void *cjv, const char *UNUSED(str))
{
CompoJob *cj = (CompoJob *)cjv;
*(cj->do_update) = true;
}
/* called by compo, 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) {
ntreeLocalMerge(cj->bmain, cj->localtree, cj->ntree);
}
if (cj->compositor_depsgraph != nullptr) {
DEG_graph_free(cj->compositor_depsgraph);
}
MEM_freeN(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;
cj->compositor_depsgraph = DEG_graph_new(bmain, scene, view_layer, DAG_EVAL_RENDER);
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 = ntreeLocalize(ntree_eval);
if (cj->recalc_flags) {
compo_tag_output_nodes(cj->localtree, cj->recalc_flags);
}
}
/* called before redraw notifiers, it moves finished previews over */
static void compo_updatejob(void *UNUSED(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,
/* Cannot be const, this function implements wm_jobs_start_callback.
* NOLINTNEXTLINE: readability-non-const-parameter. */
short *stop,
short *do_update,
float *progress)
{
CompoJob *cj = (CompoJob *)cjv;
2012-06-21 13:19:19 +00:00
bNodeTree *ntree = cj->localtree;
Color Management, Stage 2: Switch color pipeline to use OpenColorIO Replace old color pipeline which was supporting linear/sRGB color spaces only with OpenColorIO-based pipeline. This introduces two configurable color spaces: - Input color space for images and movie clips. This space is used to convert images/movies from color space in which file is saved to Blender's linear space (for float images, byte images are not internally converted, only input space is stored for such images and used later). This setting could be found in image/clip data block settings. - Display color space which defines space in which particular display is working. This settings could be found in scene's Color Management panel. When render result is being displayed on the screen, apart from converting image to display space, some additional conversions could happen. This conversions are: - View, which defines tone curve applying before display transformation. These are different ways to view the image on the same display device. For example it could be used to emulate film view on sRGB display. - Exposure affects on image exposure before tone map is applied. - Gamma is post-display gamma correction, could be used to match particular display gamma. - RGB curves are user-defined curves which are applying before display transformation, could be used for different purposes. All this settings by default are only applying on render result and does not affect on other images. If some particular image needs to be affected by this transformation, "View as Render" setting of image data block should be set to truth. Movie clips are always affected by all display transformations. This commit also introduces configurable color space in which sequencer is working. This setting could be found in scene's Color Management panel and it should be used if such stuff as grading needs to be done in color space different from sRGB (i.e. when Film view on sRGB display is use, using VD16 space as sequencer's internal space would make grading working in space which is close to the space using for display). Some technical notes: - Image buffer's float buffer is now always in linear space, even if it was created from 16bit byte images. - Space of byte buffer is stored in image buffer's rect_colorspace property. - Profile of image buffer was removed since it's not longer meaningful. - OpenGL and GLSL is supposed to always work in sRGB space. It is possible to support other spaces, but it's quite large project which isn't so much important. - Legacy Color Management option disabled is emulated by using None display. It could have some regressions, but there's no clear way to avoid them. - If OpenColorIO is disabled on build time, it should make blender behaving in the same way as previous release with color management enabled. More details could be found at this page (more details would be added soon): http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management -- Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO integration and to Brecht van Lommel for some further development and code/ usecase review!
2012-09-15 10:05:07 +00:00
Scene *scene = cj->scene;
if (scene->use_nodes == false) {
return;
}
2012-06-21 13:19:19 +00:00
cj->stop = stop;
cj->do_update = do_update;
cj->progress = progress;
2012-06-21 13:19:19 +00:00
ntree->test_break = compo_breakjob;
ntree->tbh = cj;
ntree->stats_draw = compo_statsdrawjob;
2012-06-21 13:19:19 +00:00
ntree->sdh = cj;
ntree->progress = compo_progressjob;
ntree->prh = cj;
ntree->update_draw = compo_redrawjob;
ntree->udh = cj;
// XXX BIF_store_spare();
/* 1 is do_previews */
if ((cj->scene->r.scemode & R_MULTIVIEW) == 0) {
ntreeCompositExecTree(cj->scene,
ntree,
&cj->scene->r,
false,
true,
&scene->view_settings,
&scene->display_settings,
"");
}
else {
LISTBASE_FOREACH (SceneRenderView *, srv, &scene->r.views) {
if (BKE_scene_multiview_is_render_view_active(&scene->r, srv) == false) {
continue;
}
ntreeCompositExecTree(cj->scene,
ntree,
&cj->scene->r,
false,
true,
&scene->view_settings,
&scene->display_settings,
srv->name);
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->test_break = nullptr;
ntree->stats_draw = nullptr;
ntree->progress = nullptr;
}
/**
* \param scene_owner: is the owner of the job,
* we don't use it for anything else currently so could also be a void pointer,
* but for now keep it an 'Scene' for consistency.
*
* \note only call from spaces `refresh` callbacks, not direct! - use with care.
*/
void ED_node_composite_job(const bContext *C, struct bNodeTree *nodetree, Scene *scene_owner)
{
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
/* to fix bug: T32272. */
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 = (CompoJob *)MEM_callocN(sizeof(CompoJob), "compo job");
/* customdata 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);
/* setup 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(wm_job, compo_startjob, compo_initjob, compo_updatejob, nullptr);
WM_jobs_start(CTX_wm_manager(C), wm_job);
}
/* ***************************************** */
/* operator poll callback */
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;
}
/* operator poll callback */
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;
}
void snode_dag_update(bContext *C, SpaceNode *snode)
{
Main *bmain = CTX_data_main(C);
/* for groups, update all ID's using this */
2012-06-21 13:19:19 +00:00
if (snode->edittree != snode->nodetree) {
FOREACH_NODETREE_BEGIN (bmain, tntree, id) {
if (ntreeHasTree(tntree, snode->edittree)) {
DEG_id_tag_update(id, 0);
}
}
FOREACH_NODETREE_END;
}
DEG_id_tag_update(snode->id, 0);
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
DEG_id_tag_update(&snode->nodetree->id, 0);
}
void snode_notify(bContext *C, SpaceNode *snode)
{
ID *id = snode->id;
WM_event_add_notifier(C, NC_NODE | NA_EDITED, nullptr);
if (ED_node_is_shader(snode)) {
if (GS(id->name) == ID_MA) {
WM_main_add_notifier(NC_MATERIAL | ND_SHADING, id);
}
else if (GS(id->name) == ID_LA) {
WM_main_add_notifier(NC_LAMP | ND_LIGHTING, id);
}
else if (GS(id->name) == ID_WO) {
WM_main_add_notifier(NC_WORLD | ND_WORLD, id);
}
}
else if (ED_node_is_compositor(snode)) {
WM_event_add_notifier(C, NC_SCENE | ND_NODES, id);
}
else if (ED_node_is_texture(snode)) {
WM_event_add_notifier(C, NC_TEXTURE | ND_NODES, id);
}
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
else if (ED_node_is_geometry(snode)) {
WM_main_add_notifier(NC_OBJECT | ND_MODIFIER, 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
void ED_node_set_tree_type(SpaceNode *snode, bNodeTreeType *typeinfo)
{
if (typeinfo) {
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
BLI_strncpy(snode->tree_idname, typeinfo->idname, sizeof(snode->tree_idname));
}
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
}
2014-02-03 18:55:59 +11:00
bool ED_node_is_compositor(struct 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
{
2013-03-18 18:25:05 +00:00
return STREQ(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
}
2014-02-03 18:55:59 +11:00
bool ED_node_is_shader(struct 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
{
2013-03-18 18:25:05 +00:00
return STREQ(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
}
2014-02-03 18:55:59 +11:00
bool ED_node_is_texture(struct 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
{
2013-03-18 18:25:05 +00:00
return STREQ(snode->tree_idname, ntreeType_Texture->idname);
}
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
bool ED_node_is_geometry(struct SpaceNode *snode)
{
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
return STREQ(snode->tree_idname, ntreeType_Geometry->idname);
}
/* assumes nothing being done in ntree yet, sets the default in/out node */
/* called from shading buttons or header */
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 = ntreeCopyTree(bmain, ma_default->nodetree);
ntreeUpdateTree(bmain, ma->nodetree);
}
else if (ELEM(GS(id->name), ID_WO, ID_LA)) {
/* Emission */
bNodeTree *ntree = ntreeAddTree(nullptr, "Shader Nodetree", ntreeType_Shader->idname);
bNode *shader, *output;
if (GS(id->name) == ID_WO) {
World *world = (World *)id;
world->nodetree = ntree;
shader = nodeAddStaticNode(nullptr, ntree, SH_NODE_BACKGROUND);
output = nodeAddStaticNode(nullptr, ntree, SH_NODE_OUTPUT_WORLD);
nodeAddLink(ntree,
shader,
nodeFindSocket(shader, SOCK_OUT, "Background"),
output,
nodeFindSocket(output, SOCK_IN, "Surface"));
bNodeSocket *color_sock = nodeFindSocket(shader, SOCK_IN, "Color");
copy_v3_v3(((bNodeSocketValueRGBA *)color_sock->default_value)->value, &world->horr);
}
else {
Light *light = (Light *)id;
light->nodetree = ntree;
shader = nodeAddStaticNode(nullptr, ntree, SH_NODE_EMISSION);
output = nodeAddStaticNode(nullptr, ntree, SH_NODE_OUTPUT_LIGHT);
nodeAddLink(ntree,
shader,
nodeFindSocket(shader, SOCK_OUT, "Emission"),
output,
nodeFindSocket(output, SOCK_IN, "Surface"));
}
shader->locx = 10.0f;
shader->locy = 300.0f;
output->locx = 300.0f;
output->locy = 300.0f;
nodeSetActive(ntree, output);
ntreeUpdateTree(bmain, ntree);
}
else {
printf("ED_node_shader_default called on wrong ID type.\n");
return;
}
}
/* assumes nothing being done in ntree yet, sets the default in/out node */
/* called from shading buttons or header */
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_composit_default(const bContext *C, struct Scene *sce)
{
/* but lets check it anyway */
if (sce->nodetree) {
if (G.debug & G_DEBUG) {
printf("error in composite initialize\n");
}
return;
}
sce->nodetree = ntreeAddTree(nullptr, "Compositing Nodetree", ntreeType_Composite->idname);
____ `````|````` | | | ..'''' | | | |______ .'' | | | | ..' | | |_______ |___________ ....'' merge to TRUNK! * The old compositor is still available (Debug Menu: 200) This commit was brought to you by: Developers: * Monique Dewanchand * Jeroen Bakker * Dalai Felinto * Lukas Tönne Review: * Brecht van Lommel Testers: * Nate Wiebe * Wolfgang Faehnle * Carlo Andreacchio * Daniel Salazar * Artur Mag * Christian Krupa * Francesco Siddi * Dan McGrath * Bassam Kurdali But mostly by the community: Gold: Joshua Faulkner Michael Tiemann Francesco Paglia Blender Guru Blender Developers Fund Silver: Pablo Vazquez Joel Heethaar Amrein Olivier Ilias Karasavvidis Thomas Kumlehn Sebastian Koenig Hannu Hoffrén Benjamin Dansie Fred M'ule Michel Vilain Bradley Cathey Gianmichele Mariani Gottfried Hofmann Bjørnar Frøyse Valentijn Bruning Paul Holmes Clemens Rudolph Juris Graphix David Strebel Ronan Zeegers François Tarlier Felipe Andres Esquivel Reed Olaf Beckman Jesus Alberto Olmos Linares Kajimba Maria Figueiredo Alexandr Galperin Francesco Siddi Julio Iglesias Lopez Kjartan Tysdal Thomas Torfs Film Works Teruyuki Nakamura Roger Luethi Benoit Bolsee Stefan Abrahamsen Andreas Mattijat Xavier Bouchoux Blender 3D Graphics and Animation Henk Vostermans Daniel Blanco Delgado BlenderDay/2011 Bradley Cathey Matthieu Dupont de Dinechin Gianmichele Mariani Jérôme Scaillet Bronze (Ivo Grigull, Dylan Urquidi, Philippe Derungs, Phil Beauchamp, Bruce Parrott, Mathieu Quiblier, Daniel Martinez, Leandro Inocencio, Lluc Romaní Brasó, Jonathan Williamson, Michael Ehlen, Karlis Stigis, Dreamsteep, Martin Lindelöf, Filippo Saracino, Douwe van der Veen, Olli Äkräs, Bruno D'Arcangeli, Francisco Sedrez Warmling, Watchmike.ca, peter lener, Matteo Novellino, Martin Kirsch, Austars Schnore, KC Elliott, Massimiliano Puliero, Karl Stein, Wood Design Studios, Omer Khan, Jyrki Kanto, Michał Krupa, Lars Brubaker, Neil Richmond, Adam Kalisz, Robert Garlington, Ian Wilson, Carlo Andreacchio, Jeremias Boos, Robert Holcomb, Gabriel Zöller, Robert Cude, Natibel de Leon, Nathan Turnage, Nicolas Vergnes, Philipp Kleinhenz, Norman Hartig, Louis Kreusel, Christopher Taylor, Giovanni Remondini, Daniel Rentzsch, Nico Partipilo, Thomas Ventresco, Johannes Schwarz, Александр Коротеев, Brendon Harvey, Marcelo G. Malheiros, Marius Giurgi, Richard Burns, Perttu Iso-Metsälä, Steve Bazin, Radoslav Borisov, Yoshiyuki Shida, Julien Guigner, Andrew Hunter, Philipp Oeser, Daniel Thul, Thobias Johansson, Mauro Bonecchi, Georg Piorczynski, Sebastian Michailidis, L M Weedy, Gen X, Stefan Hinze, Nicolò Zubbini, Erik Pusch, Rob Scott, Florian Koch, Charles Razack, Adrian Baker, Oliver Villar Diz, David Revoy, Julio Iglesias Lopez, Coen Spoor, Carlos Folch, Joseph Christie, Victor Hernández García, David Mcsween, James Finnerty, Cory Kruckenberg, Giacomo Graziosi, Olivier Saraja, Lars Brubaker, Eric Hudson, Johannes Schwarz, David Elguea, Marcus Schulderinsky, Karel De Bruijn, Lucas van Wijngaarden, Stefano Ciarrocchi, Mehmet Eribol, Thomas Berglund, Zuofei Song, Dylan Urquidi )
2012-05-17 12:49:33 +00:00
sce->nodetree->chunksize = 256;
sce->nodetree->edit_quality = NTREE_QUALITY_HIGH;
sce->nodetree->render_quality = NTREE_QUALITY_HIGH;
bNode *out = nodeAddStaticNode(C, sce->nodetree, CMP_NODE_COMPOSITE);
2012-06-21 13:19:19 +00:00
out->locx = 300.0f;
out->locy = 400.0f;
bNode *in = nodeAddStaticNode(C, sce->nodetree, CMP_NODE_R_LAYERS);
2012-06-21 13:19:19 +00:00
in->locx = 10.0f;
in->locy = 400.0f;
nodeSetActive(sce->nodetree, in);
/* links from color to color */
bNodeSocket *fromsock = (bNodeSocket *)in->outputs.first;
bNodeSocket *tosock = (bNodeSocket *)out->inputs.first;
nodeAddLink(sce->nodetree, in, fromsock, out, tosock);
ntreeUpdateTree(CTX_data_main(C), sce->nodetree);
}
/* assumes nothing being done in ntree yet, sets the default in/out node */
/* called from shading buttons or header */
void ED_node_texture_default(const bContext *C, Tex *tex)
{
/* but lets check it anyway */
if (tex->nodetree) {
if (G.debug & G_DEBUG) {
printf("error in texture initialize\n");
}
return;
}
tex->nodetree = ntreeAddTree(nullptr, "Texture Nodetree", ntreeType_Texture->idname);
bNode *out = nodeAddStaticNode(C, tex->nodetree, TEX_NODE_OUTPUT);
2012-06-21 13:19:19 +00:00
out->locx = 300.0f;
out->locy = 300.0f;
bNode *in = nodeAddStaticNode(C, tex->nodetree, TEX_NODE_CHECKER);
2012-06-21 13:19:19 +00:00
in->locx = 10.0f;
in->locy = 300.0f;
nodeSetActive(tex->nodetree, in);
bNodeSocket *fromsock = (bNodeSocket *)in->outputs.first;
bNodeSocket *tosock = (bNodeSocket *)out->inputs.first;
nodeAddLink(tex->nodetree, in, fromsock, out, tosock);
ntreeUpdateTree(CTX_data_main(C), tex->nodetree);
}
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
/* Here we set the active tree(s), even called for each redraw now, so keep it fast :) */
void snode_set_context(const bContext *C)
{
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
SpaceNode *snode = CTX_wm_space_node(C);
bNodeTreeType *treetype = ntreeTypeFind(snode->tree_idname);
bNodeTree *ntree = snode->nodetree;
ID *id = snode->id, *from = snode->from;
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
/* check the tree type */
2013-03-18 18:25:05 +00:00
if (!treetype || (treetype->poll && !treetype->poll(C, treetype))) {
/* invalid tree type, skip
* NB: 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)) {
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
/* 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;
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
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
}
}
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 snode_update(SpaceNode *snode, bNode *node)
{
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
/* XXX this only updates nodes in the current node space tree path.
* The function supposedly should update any potential group node linking to changed tree,
* this really requires a working depsgraph ...
*/
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
/* update all edited group nodes */
bNodeTreePath *path = (bNodeTreePath *)snode->treepath.last;
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 (path) {
bNodeTree *ngroup = path->nodetree;
2013-03-18 18:25:05 +00:00
for (path = path->prev; path; path = path->prev) {
nodeUpdateID(path->nodetree, (ID *)ngroup);
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
ngroup = path->nodetree;
}
}
if (node) {
nodeUpdate(snode->edittree, node);
}
}
void ED_node_set_active(Main *bmain, bNodeTree *ntree, bNode *node, bool *r_active_texture_changed)
{
const bool was_active_texture = (node->flag & NODE_ACTIVE_TEXTURE) != 0;
if (r_active_texture_changed) {
*r_active_texture_changed = false;
}
nodeSetActive(ntree, node);
2012-06-21 13:19:19 +00:00
if (node->type != NODE_GROUP) {
const bool was_output = (node->flag & NODE_DO_OUTPUT) != 0;
bool do_update = 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
/* generic node group output: set node as active output */
if (node->type == NODE_GROUP_OUTPUT) {
LISTBASE_FOREACH (bNode *, node_iter, &ntree->nodes) {
if (node_iter->type == NODE_GROUP_OUTPUT) {
node_iter->flag &= ~NODE_DO_OUTPUT;
}
}
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
node->flag |= NODE_DO_OUTPUT;
if (!was_output) {
do_update = 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
}
/* tree specific activate calls */
2012-06-21 13:19:19 +00:00
if (ntree->type == NTREE_SHADER) {
/* when we select a material, active texture is cleared, for buttons */
if (node->id && ELEM(GS(node->id->name), ID_MA, ID_LA, ID_WO)) {
nodeClearActiveID(ntree, ID_TE);
}
Remove Blender Internal and legacy viewport from Blender 2.8. Brecht authored this commit, but he gave me the honours to actually do it. Here it goes; Blender Internal. Bye bye, you did great! * Point density, voxel data, ocean, environment map textures were removed, as these only worked within BI rendering. Note that the ocean modifier and the Cycles point density shader node continue to work. * Dynamic paint using material shading was removed, as this only worked with BI. If we ever wanted to support this again probably it should go through the baking API. * GPU shader export through the Python API was removed. This only worked for the old BI GLSL shaders, which no longer exists. Doing something similar for Eevee would be significantly more complicated because it uses a lot of multiplass rendering and logic outside the shader, it's probably impractical. * Collada material import / export code is mostly gone, as it only worked for BI materials. We need to add Cycles / Eevee material support at some point. * The mesh noise operator was removed since it only worked with BI material texture slots. A displacement modifier can be used instead. * The delete texture paint slot operator was removed since it only worked for BI material texture slots. Could be added back with node support. * Not all legacy viewport features are supported in the new viewport, but their code was removed. If we need to bring anything back we can look at older git revisions. * There is some legacy viewport code that I could not remove yet, and some that I probably missed. * Shader node execution code was left mostly intact, even though it is not used anywhere now. We may eventually use this to replace the texture nodes with Cycles / Eevee shader nodes. * The Cycles Bake panel now includes settings for baking multires normal and displacement maps. The underlying code needs to be merged properly, and we plan to add back support for multires AO baking and add support to Cycles baking for features like vertex color, displacement, and other missing baking features. * This commit removes DNA and the Python API for BI material, lamp, world and scene settings. This breaks a lot of addons. * There is more DNA that can be removed or renamed, where Cycles or Eevee are reusing some old BI properties but the names are not really correct anymore. * Texture slots for materials, lamps and world were removed. They remain for brushes, particles and freestyle linestyles. * 'BLENDER_RENDER' remains in the COMPAT_ENGINES of UI panels. Cycles and other renderers use this to find all panels to show, minus a few panels that they have their own replacement for.
2018-04-19 17:34:44 +02:00
if (ELEM(node->type,
SH_NODE_OUTPUT_MATERIAL,
SH_NODE_OUTPUT_WORLD,
SH_NODE_OUTPUT_LIGHT,
SH_NODE_OUTPUT_LINESTYLE)) {
LISTBASE_FOREACH (bNode *, node_iter, &ntree->nodes) {
if (node_iter->type == node->type) {
node_iter->flag &= ~NODE_DO_OUTPUT;
}
}
node->flag |= NODE_DO_OUTPUT;
if (was_output == 0) {
ED_node_tag_update_nodetree(bmain, ntree, node);
}
}
else if (do_update) {
ED_node_tag_update_nodetree(bmain, ntree, node);
}
/* if active texture changed, free glsl materials */
if ((node->flag & NODE_ACTIVE_TEXTURE) && !was_active_texture) {
LISTBASE_FOREACH (Material *, ma, &bmain->materials) {
if (ma->nodetree && ma->use_nodes && ntreeHasTree(ma->nodetree, ntree)) {
GPU_material_free(&ma->gpumaterial);
}
}
LISTBASE_FOREACH (World *, wo, &bmain->worlds) {
if (wo->nodetree && wo->use_nodes && ntreeHasTree(wo->nodetree, ntree)) {
GPU_material_free(&wo->gpumaterial);
}
}
if (r_active_texture_changed) {
*r_active_texture_changed = true;
}
ED_node_tag_update_nodetree(bmain, ntree, node);
WM_main_add_notifier(NC_IMAGE, nullptr);
}
2012-06-21 13:19:19 +00:00
WM_main_add_notifier(NC_MATERIAL | ND_NODES, node->id);
}
2012-06-21 13:19:19 +00:00
else if (ntree->type == NTREE_COMPOSIT) {
/* make active viewer, currently only 1 supported... */
2012-06-21 13:19:19 +00:00
if (ELEM(node->type, CMP_NODE_VIEWER, CMP_NODE_SPLITVIEWER)) {
LISTBASE_FOREACH (bNode *, node_iter, &ntree->nodes) {
if (ELEM(node_iter->type, CMP_NODE_VIEWER, CMP_NODE_SPLITVIEWER)) {
node_iter->flag &= ~NODE_DO_OUTPUT;
}
}
node->flag |= NODE_DO_OUTPUT;
if (was_output == 0) {
ED_node_tag_update_nodetree(bmain, ntree, node);
}
/* Adding a node doesn't link this yet. */
node->id = (ID *)BKE_image_ensure_viewer(bmain, IMA_TYPE_COMPOSITE, "Viewer Node");
}
2012-06-21 13:19:19 +00:00
else if (node->type == CMP_NODE_COMPOSITE) {
if (was_output == 0) {
LISTBASE_FOREACH (bNode *, node_iter, &ntree->nodes) {
if (node_iter->type == CMP_NODE_COMPOSITE) {
node_iter->flag &= ~NODE_DO_OUTPUT;
}
}
node->flag |= NODE_DO_OUTPUT;
ED_node_tag_update_nodetree(bmain, ntree, node);
}
}
else if (do_update) {
ED_node_tag_update_nodetree(bmain, ntree, node);
}
}
2012-06-21 13:19:19 +00:00
else if (ntree->type == NTREE_TEXTURE) {
/* XXX */
#if 0
if (node->id) {
BIF_preview_changed(-1);
allqueue(REDRAWBUTSSHADING, 1);
allqueue(REDRAWIPO, 0);
}
#endif
}
}
}
void ED_node_post_apply_transform(bContext *UNUSED(C), bNodeTree *UNUSED(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 totr 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);
}
/* ***************** generic operator functions for nodes ***************** */
#if 0 /* UNUSED */
2018-07-02 11:47:00 +02:00
static bool edit_node_poll(bContext *C)
{
return ED_operator_node_active(C);
}
static void edit_node_properties(wmOperatorType *ot)
{
/* XXX could node be a context pointer? */
RNA_def_string(ot->srna, "node", nullptr, MAX_NAME, "Node", "");
RNA_def_int(ot->srna, "socket", 0, 0, MAX_SOCKET, "Socket", "", 0, MAX_SOCKET);
RNA_def_enum(ot->srna, "in_out", rna_enum_node_socket_in_out_items, SOCK_IN, "Socket Side", "");
}
static int edit_node_invoke_properties(bContext *C, wmOperator *op)
{
if (!RNA_struct_property_is_set(op->ptr, "node")) {
2012-06-21 13:19:19 +00:00
bNode *node = CTX_data_pointer_get_type(C, "node", &RNA_Node).data;
if (!node) {
return 0;
}
else {
RNA_string_set(op->ptr, "node", node->name);
}
}
if (!RNA_struct_property_is_set(op->ptr, "in_out")) {
RNA_enum_set(op->ptr, "in_out", SOCK_IN);
}
if (!RNA_struct_property_is_set(op->ptr, "socket")) {
RNA_int_set(op->ptr, "socket", 0);
}
return 1;
}
static void edit_node_properties_get(
wmOperator *op, bNodeTree *ntree, bNode **r_node, bNodeSocket **r_sock, int *r_in_out)
{
bNode *node;
bNodeSocket *sock = nullptr;
char nodename[MAX_NAME];
int sockindex;
int in_out;
RNA_string_get(op->ptr, "node", nodename);
node = nodeFindNodebyName(ntree, nodename);
in_out = RNA_enum_get(op->ptr, "in_out");
sockindex = RNA_int_get(op->ptr, "socket");
switch (in_out) {
case SOCK_IN:
sock = BLI_findlink(&node->inputs, sockindex);
break;
case SOCK_OUT:
sock = BLI_findlink(&node->outputs, sockindex);
break;
}
if (r_node) {
*r_node = node;
}
if (r_sock) {
*r_sock = sock;
}
if (r_in_out) {
*r_in_out = in_out;
}
}
#endif
/* ************************** Node generic ************** */
/* is rct in visible part of node? */
static bNode *visible_node(SpaceNode *snode, const rctf *rct)
{
LISTBASE_FOREACH_BACKWARD (bNode *, node, &snode->edittree->nodes) {
if (BLI_rctf_isect(&node->totr, rct, nullptr)) {
return node;
}
}
return nullptr;
}
/* ********************** size widget operator ******************** */
struct NodeSizeWidget {
float mxstart, mystart;
float oldlocx, oldlocy;
float oldoffsetx, oldoffsety;
float oldwidth, oldheight;
int directions;
};
static void node_resize_init(
bContext *C, wmOperator *op, const wmEvent *UNUSED(event), bNode *node, int dir)
{
2012-06-21 13:19:19 +00:00
SpaceNode *snode = CTX_wm_space_node(C);
NodeSizeWidget *nsw = (NodeSizeWidget *)MEM_callocN(sizeof(NodeSizeWidget),
"size widget op data");
op->customdata = nsw;
nsw->mxstart = snode->runtime->cursor[0] * UI_DPI_FAC;
nsw->mystart = snode->runtime->cursor[1] * UI_DPI_FAC;
/* store old */
nsw->oldlocx = node->locx;
nsw->oldlocy = node->locy;
nsw->oldoffsetx = node->offsetx;
nsw->oldoffsety = node->offsety;
nsw->oldwidth = node->width;
nsw->oldheight = node->height;
nsw->directions = dir;
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 = nodeGetActive(snode->edittree);
NodeSizeWidget *nsw = (NodeSizeWidget *)op->customdata;
node->locx = nsw->oldlocx;
node->locy = nsw->oldlocy;
node->offsetx = nsw->oldoffsetx;
node->offsety = nsw->oldoffsety;
node->width = nsw->oldwidth;
node->height = nsw->oldheight;
}
MEM_freeN(op->customdata);
op->customdata = nullptr;
}
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);
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
bNode *node = nodeGetActive(snode->edittree);
NodeSizeWidget *nsw = (NodeSizeWidget *)op->customdata;
switch (event->type) {
case MOUSEMOVE: {
float mx, my;
UI_view2d_region_to_view(&region->v2d, event->mval[0], event->mval[1], &mx, &my);
float dx = (mx - nsw->mxstart) / UI_DPI_FAC;
float dy = (my - nsw->mystart) / UI_DPI_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;
CLAMP(*pwidth, widthmin, widthmax);
}
if (nsw->directions & NODE_RESIZE_LEFT) {
float locmax = nsw->oldlocx + oldwidth;
node->locx = nsw->oldlocx + dx;
CLAMP(node->locx, locmax - widthmax, locmax - widthmin);
*pwidth = locmax - node->locx;
}
}
/* height works the other way round ... */
{
float heightmin = UI_DPI_FAC * node->typeinfo->minheight;
float heightmax = UI_DPI_FAC * node->typeinfo->maxheight;
if (nsw->directions & NODE_RESIZE_TOP) {
float locmin = nsw->oldlocy - nsw->oldheight;
node->locy = nsw->oldlocy + dy;
CLAMP(node->locy, locmin + heightmin, locmin + heightmax);
node->height = node->locy - locmin;
}
if (nsw->directions & NODE_RESIZE_BOTTOM) {
node->height = nsw->oldheight - dy;
CLAMP(node->height, heightmin, heightmax);
}
}
/* XXX make callback? */
if (node->type == NODE_FRAME) {
/* keep the offset symmetric around center point */
if (nsw->directions & NODE_RESIZE_LEFT) {
node->locx = nsw->oldlocx + 0.5f * dx;
node->offsetx = nsw->oldoffsetx + 0.5f * dx;
}
if (nsw->directions & NODE_RESIZE_RIGHT) {
node->locx = nsw->oldlocx + 0.5f * dx;
node->offsetx = nsw->oldoffsetx - 0.5f * dx;
}
if (nsw->directions & NODE_RESIZE_TOP) {
node->locy = nsw->oldlocy + 0.5f * dy;
node->offsety = nsw->oldoffsety + 0.5f * dy;
}
if (nsw->directions & NODE_RESIZE_BOTTOM) {
node->locy = nsw->oldlocy + 0.5f * dy;
node->offsety = nsw->oldoffsety - 0.5f * dy;
}
}
}
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;
}
if (event->val == KM_PRESS) {
node_resize_exit(C, op, true);
ED_region_tag_redraw(region);
return OPERATOR_CANCELLED;
}
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);
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
bNode *node = nodeGetActive(snode->edittree);
int dir;
if (node) {
float cursor[2];
/* convert mouse coordinates to v2d space */
UI_view2d_region_to_view(&region->v2d, event->mval[0], event->mval[1], &cursor[0], &cursor[1]);
dir = node->typeinfo->resize_area_func(node, cursor[0], cursor[1]);
if (dir != 0) {
node_resize_init(C, op, event, node, dir);
return OPERATOR_RUNNING_MODAL;
}
}
return OPERATOR_CANCELLED | OPERATOR_PASS_THROUGH;
}
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;
}
/* ********************** 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;
}
void node_set_hidden_sockets(SpaceNode *snode, bNode *node, int set)
{
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 (nodeCountSocketLinks(snode->edittree, sock) == 0) {
sock->flag |= SOCK_HIDDEN;
}
}
}
}
/* checks snode->mouse position, and returns found node/socket */
static bool cursor_isect_multi_input_socket(const float cursor[2], const bNodeSocket *socket)
{
const float node_socket_height = node_socket_calculate_height(socket);
rctf multi_socket_rect;
/*.xmax = socket->locx + 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. */
BLI_rctf_init(&multi_socket_rect,
socket->locx - NODE_SOCKSIZE * 4.0f,
socket->locx + NODE_SOCKSIZE * 2.0f,
socket->locy - node_socket_height,
socket->locy + node_socket_height);
if (BLI_rctf_isect_pt(&multi_socket_rect, cursor[0], cursor[1])) {
return true;
}
return false;
}
/* type is SOCK_IN and/or SOCK_OUT */
int node_find_indicated_socket(
SpaceNode *snode, bNode **nodep, bNodeSocket **sockp, const float cursor[2], int in_out)
{
rctf rect;
*nodep = nullptr;
*sockp = nullptr;
/* check if we click in a socket */
LISTBASE_FOREACH (bNode *, node, &snode->edittree->nodes) {
2017-03-08 23:10:31 +11:00
BLI_rctf_init_pt_radius(&rect, cursor, NODE_SOCKSIZE + 4);
if (!(node->flag & NODE_HIDDEN)) {
/* extra padding inside and out - allow dragging on the text areas too */
if (in_out == SOCK_IN) {
rect.xmax += NODE_SOCKSIZE;
rect.xmin -= NODE_SOCKSIZE * 4;
}
else if (in_out == SOCK_OUT) {
rect.xmax += NODE_SOCKSIZE * 4;
rect.xmin -= NODE_SOCKSIZE;
}
}
if (in_out & SOCK_IN) {
LISTBASE_FOREACH (bNodeSocket *, sock, &node->inputs) {
if (!nodeSocketIsHidden(sock)) {
if (sock->flag & SOCK_MULTI_INPUT && !(node->flag & NODE_HIDDEN)) {
if (cursor_isect_multi_input_socket(cursor, sock)) {
if (node == visible_node(snode, &rect)) {
*nodep = node;
*sockp = sock;
return 1;
}
}
}
else if (BLI_rctf_isect_pt(&rect, sock->locx, sock->locy)) {
if (node == visible_node(snode, &rect)) {
*nodep = node;
*sockp = sock;
return 1;
}
}
}
}
}
if (in_out & SOCK_OUT) {
LISTBASE_FOREACH (bNodeSocket *, sock, &node->outputs) {
if (!nodeSocketIsHidden(sock)) {
if (BLI_rctf_isect_pt(&rect, sock->locx, sock->locy)) {
if (node == visible_node(snode, &rect)) {
*nodep = node;
*sockp = sock;
return 1;
}
}
}
}
}
}
return 0;
}
/* ****************** Duplicate *********************** */
static void node_duplicate_reparent_recursive(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(parent);
}
break;
}
}
/* reparent node copy to parent copy */
if (parent) {
nodeDetachNode(node->new_node);
nodeAttachNode(node->new_node, parent->new_node);
}
}
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 do_tag_update = false;
2018-06-09 15:16:44 +02:00
ED_preview_kill_jobs(CTX_wm_manager(C), bmain);
bNode *lastnode = (bNode *)ntree->nodes.last;
LISTBASE_FOREACH (bNode *, node, &ntree->nodes) {
if (node->flag & SELECT) {
BKE_node_copy_store_new_pointers(ntree, node, LIB_ID_COPY_DEFAULT);
2021-02-05 16:23:34 +11:00
/* To ensure redraws or re-renders happen. */
ED_node_tag_update_id(snode->id);
}
/* make sure we don't copy new nodes again! */
if (node == lastnode) {
break;
}
}
/* copy links between selected nodes
* NB: this depends on correct node->new_node and sock->new_sock pointers from above copy!
*/
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==nullptr)!
*/
if (link->tonode && (link->tonode->flag & NODE_SELECT) &&
(keep_inputs || (link->fromnode && (link->fromnode->flag & NODE_SELECT)))) {
bNodeLink *newlink = (bNodeLink *)MEM_callocN(sizeof(bNodeLink), "bNodeLink");
newlink->flag = link->flag;
newlink->tonode = link->tonode->new_node;
newlink->tosock = link->tosock->new_sock;
if (link->fromnode && (link->fromnode->flag & NODE_SELECT)) {
newlink->fromnode = link->fromnode->new_node;
newlink->fromsock = link->fromsock->new_sock;
}
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;
}
}
/* clear flags for recursive depth-first iteration */
LISTBASE_FOREACH (bNode *, node, &ntree->nodes) {
node->flag &= ~NODE_TEST;
}
/* reparent copied nodes */
LISTBASE_FOREACH (bNode *, node, &ntree->nodes) {
if ((node->flag & SELECT) && !(node->flag & NODE_TEST)) {
node_duplicate_reparent_recursive(node);
}
/* only has to check old nodes */
if (node == lastnode) {
break;
}
}
/* deselect old nodes, select the copies instead */
LISTBASE_FOREACH (bNode *, node, &ntree->nodes) {
if (node->flag & SELECT) {
/* has been set during copy above */
bNode *newnode = node->new_node;
nodeSetSelected(node, false);
node->flag &= ~(NODE_ACTIVE | NODE_ACTIVE_TEXTURE);
nodeSetSelected(newnode, true);
newnode->flag &= ~NODE_ACTIVE_PREVIEW;
2018-06-09 15:16:44 +02:00
do_tag_update |= (do_tag_update || node_connected_to_output(bmain, ntree, newnode));
}
/* make sure we don't copy new nodes again! */
if (node == lastnode) {
break;
}
}
ntreeUpdateTree(CTX_data_main(C), snode->edittree);
snode_notify(C, snode);
if (do_tag_update) {
snode_dag_update(C, snode);
}
return OPERATOR_FINISHED;
}
void NODE_OT_duplicate(wmOperatorType *ot)
{
/* 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");
}
bool ED_node_select_check(ListBase *lb)
{
LISTBASE_FOREACH (bNode *, node, lb) {
if (node->flag & NODE_SELECT) {
return true;
}
}
return false;
}
void ED_node_select_all(ListBase *lb, int action)
{
if (action == SEL_TOGGLE) {
if (ED_node_select_check(lb)) {
action = SEL_DESELECT;
}
else {
action = SEL_SELECT;
}
}
LISTBASE_FOREACH (bNode *, node, lb) {
switch (action) {
case SEL_SELECT:
nodeSetSelected(node, true);
break;
case SEL_DESELECT:
nodeSetSelected(node, false);
break;
case SEL_INVERT:
nodeSetSelected(node, !(node->flag & SELECT));
break;
}
}
}
/* ******************************** */
/* XXX some code needing updating to operators. */
/* goes over all scenes, reads render layers */
static int node_read_viewlayers_exec(bContext *C, wmOperator *UNUSED(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);
ED_preview_kill_jobs(CTX_wm_manager(C), bmain);
/* first tag scenes unread */
LISTBASE_FOREACH (Scene *, scene, &bmain->scenes) {
scene->id.tag |= LIB_TAG_DOIT;
}
LISTBASE_FOREACH (bNode *, node, &snode->edittree->nodes) {
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
if ((node->type == CMP_NODE_R_LAYERS) ||
(node->type == CMP_NODE_CRYPTOMATTE && node->custom1 == CMP_CRYPTOMATTE_SRC_RENDER)) {
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 & LIB_TAG_DOIT) {
RE_ReadRenderResult(curscene, (Scene *)id);
ntreeCompositTagRender((Scene *)id);
id->tag &= ~LIB_TAG_DOIT;
}
}
}
snode_notify(C, snode);
snode_dag_update(C, snode);
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;
/* flags */
ot->flag = 0;
}
int node_render_changed_exec(bContext *C, wmOperator *UNUSED(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;
LISTBASE_FOREACH (bNode *, node_iter, &sce->nodetree->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);
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;
}
/* ****************** Hide operator *********************** */
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;
/* 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.
*/
LISTBASE_FOREACH (bNode *, node, &snode->edittree->nodes) {
if (node->flag & SELECT) {
if (toggle_flag == NODE_PREVIEW && (node->typeinfo->flag & NODE_PREVIEW) == 0) {
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++;
}
}
}
LISTBASE_FOREACH (bNode *, node, &snode->edittree->nodes) {
if (node->flag & SELECT) {
if (toggle_flag == NODE_PREVIEW && (node->typeinfo->flag & NODE_PREVIEW) == 0) {
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 *UNUSED(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 *UNUSED(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));
node_flag_toggle_exec(snode, NODE_PREVIEW);
snode_notify(C, snode);
return OPERATOR_FINISHED;
}
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;
ot->poll = ED_operator_node_active;
/* flags */
2012-06-21 13:19:19 +00:00
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
}
static int node_options_toggle_exec(bContext *C, wmOperator *UNUSED(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 *UNUSED(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;
LISTBASE_FOREACH (bNode *, node, &snode->edittree->nodes) {
if (node->flag & SELECT) {
if (node_has_hidden_sockets(node)) {
hidden = true;
break;
}
}
}
LISTBASE_FOREACH (bNode *, node, &snode->edittree->nodes) {
if (node->flag & SELECT) {
node_set_hidden_sockets(snode, node, !hidden);
}
}
ntreeUpdateTree(CTX_data_main(C), snode->edittree);
WM_event_add_notifier(C, NC_NODE | ND_DISPLAY, nullptr);
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;
}
/* ****************** Mute operator *********************** */
static int node_mute_exec(bContext *C, wmOperator *UNUSED(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);
bool do_tag_update = false;
2018-06-09 15:16:44 +02:00
ED_preview_kill_jobs(CTX_wm_manager(C), bmain);
LISTBASE_FOREACH (bNode *, node, &snode->edittree->nodes) {
/* Only allow muting of nodes having a mute func! */
if ((node->flag & SELECT) && node->typeinfo->update_internal_links) {
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;
snode_update(snode, node);
2018-06-09 15:16:44 +02:00
do_tag_update |= (do_tag_update || node_connected_to_output(bmain, snode->edittree, node));
}
}
snode_notify(C, snode);
if (do_tag_update) {
snode_dag_update(C, snode);
}
return OPERATOR_FINISHED;
}
void NODE_OT_mute_toggle(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Toggle Node Mute";
ot->description = "Toggle muting of the 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;
}
/* ****************** Delete operator ******************* */
static int node_delete_exec(bContext *C, wmOperator *UNUSED(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);
bool do_tag_update = false;
2018-06-09 15:16:44 +02:00
ED_preview_kill_jobs(CTX_wm_manager(C), bmain);
LISTBASE_FOREACH_MUTABLE (bNode *, node, &snode->edittree->nodes) {
if (node->flag & SELECT) {
2018-06-09 15:16:44 +02:00
do_tag_update |= (do_tag_update || node_connected_to_output(bmain, snode->edittree, node));
nodeRemoveNode(bmain, snode->edittree, node, true);
}
}
ntreeUpdateTree(CTX_data_main(C), snode->edittree);
snode_notify(C, snode);
if (do_tag_update) {
snode_dag_update(C, snode);
}
return OPERATOR_FINISHED;
}
void NODE_OT_delete(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Delete";
ot->description = "Delete 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;
}
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
/* ****************** Switch View ******************* */
2018-07-02 11:47:00 +02:00
static bool node_switch_view_poll(bContext *C)
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
{
SpaceNode *snode = CTX_wm_space_node(C);
if (snode && snode->edittree) {
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
return true;
}
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
return false;
}
static int node_switch_view_exec(bContext *C, wmOperator *UNUSED(op))
{
SpaceNode *snode = CTX_wm_space_node(C);
LISTBASE_FOREACH_MUTABLE (bNode *, node, &snode->edittree->nodes) {
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
if (node->flag & SELECT) {
/* call the update function from the Switch View node */
node->update = NODE_UPDATE_OPERATOR;
}
}
ntreeUpdateTree(CTX_data_main(C), snode->edittree);
snode_notify(C, snode);
snode_dag_update(C, snode);
return OPERATOR_FINISHED;
}
void NODE_OT_switch_view_update(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Update Views";
ot->description = "Update views of selected node";
ot->idname = "NODE_OT_switch_view_update";
/* api callbacks */
ot->exec = node_switch_view_exec;
ot->poll = node_switch_view_poll;
/* flags */
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
}
/* ****************** Delete with reconnect ******************* */
static int node_delete_reconnect_exec(bContext *C, wmOperator *UNUSED(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));
LISTBASE_FOREACH_MUTABLE (bNode *, node, &snode->edittree->nodes) {
if (node->flag & SELECT) {
nodeInternalRelink(snode->edittree, node);
nodeRemoveNode(bmain, snode->edittree, node, true);
}
}
ntreeUpdateTree(CTX_data_main(C), snode->edittree);
snode_notify(C, snode);
snode_dag_update(C, snode);
return OPERATOR_FINISHED;
}
void NODE_OT_delete_reconnect(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Delete with Reconnect";
ot->description = "Delete nodes; will 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
/* ****************** File Output 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
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 = nodeGetActive(snode->edittree);
}
if (!node || node->type != 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);
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
snode_notify(C, snode);
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
}
/* ****************** Multi File Output Remove Socket ******************* */
static int node_output_file_remove_active_socket_exec(bContext *C, wmOperator *UNUSED(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 = nodeGetActive(snode->edittree);
}
if (!node || node->type != 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;
}
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
snode_notify(C, snode);
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 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
/* ****************** Multi File Output Move Socket ******************* */
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 = nodeGetActive(snode->edittree);
}
if (!node || node->type != 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
}
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
snode_notify(C, snode);
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", "");
}
/* ****************** Copy Node Color ******************* */
static int node_copy_color_exec(bContext *C, wmOperator *UNUSED(op))
{
SpaceNode *snode = CTX_wm_space_node(C);
bNodeTree *ntree = snode->edittree;
if (!ntree) {
return OPERATOR_CANCELLED;
}
bNode *node = nodeGetActive(ntree);
if (!node) {
return OPERATOR_CANCELLED;
}
LISTBASE_FOREACH (bNode *, node_iter, &ntree->nodes) {
if (node_iter->flag & NODE_SELECT && node_iter != node) {
if (node->flag & NODE_CUSTOM_COLOR) {
node_iter->flag |= NODE_CUSTOM_COLOR;
copy_v3_v3(node_iter->color, node->color);
}
else {
node_iter->flag &= ~NODE_CUSTOM_COLOR;
}
}
}
ED_node_sort(ntree);
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;
}
/* ****************** Copy to clipboard ******************* */
static int node_clipboard_copy_exec(bContext *C, wmOperator *UNUSED(op))
{
SpaceNode *snode = CTX_wm_space_node(C);
bNodeTree *ntree = snode->edittree;
ED_preview_kill_jobs(CTX_wm_manager(C), CTX_data_main(C));
/* clear current clipboard */
BKE_node_clipboard_clear();
BKE_node_clipboard_init(ntree);
LISTBASE_FOREACH (bNode *, node, &ntree->nodes) {
if (node->flag & SELECT) {
/* No ID refcounting, this node is virtual,
* detached from any actual Blender data currently. */
bNode *new_node = BKE_node_copy_store_new_pointers(
nullptr, node, LIB_ID_CREATE_NO_USER_REFCOUNT | LIB_ID_CREATE_NO_MAIN);
BKE_node_clipboard_add_node(new_node);
}
}
LISTBASE_FOREACH (bNode *, node, &ntree->nodes) {
if (node->flag & SELECT) {
bNode *new_node = node->new_node;
/* ensure valid pointers */
if (new_node->parent) {
/* parent pointer must be redirected to new node or detached if parent is
* not copied */
if (new_node->parent->flag & NODE_SELECT) {
new_node->parent = new_node->parent->new_node;
}
else {
nodeDetachNode(new_node);
}
}
}
}
/* copy links between selected nodes
* NB: this depends on correct node->new_node and sock->new_sock pointers from above copy!
*/
LISTBASE_FOREACH (bNodeLink *, link, &ntree->links) {
/* This creates new links between copied nodes. */
if (link->tonode && (link->tonode->flag & NODE_SELECT) && link->fromnode &&
(link->fromnode->flag & NODE_SELECT)) {
bNodeLink *newlink = (bNodeLink *)MEM_callocN(sizeof(bNodeLink), "bNodeLink");
newlink->flag = link->flag;
newlink->tonode = link->tonode->new_node;
newlink->tosock = link->tosock->new_sock;
newlink->fromnode = link->fromnode->new_node;
newlink->fromsock = link->fromsock->new_sock;
BKE_node_clipboard_add_link(newlink);
}
}
return OPERATOR_FINISHED;
}
void NODE_OT_clipboard_copy(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Copy to Clipboard";
ot->description = "Copies selected nodes to the clipboard";
ot->idname = "NODE_OT_clipboard_copy";
/* api callbacks */
ot->exec = node_clipboard_copy_exec;
ot->poll = ED_operator_node_active;
/* flags */
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
}
/* ****************** Paste from clipboard ******************* */
static int node_clipboard_paste_exec(bContext *C, wmOperator *op)
{
SpaceNode *snode = CTX_wm_space_node(C);
bNodeTree *ntree = snode->edittree;
2012-08-20 13:59:19 +00:00
/* validate pointers in the clipboard */
bool is_clipboard_valid = BKE_node_clipboard_validate();
const ListBase *clipboard_nodes_lb = BKE_node_clipboard_get_nodes();
const ListBase *clipboard_links_lb = BKE_node_clipboard_get_links();
if (BLI_listbase_is_empty(clipboard_nodes_lb)) {
2012-08-20 13:59:19 +00:00
BKE_report(op->reports, RPT_ERROR, "Clipboard is empty");
return OPERATOR_CANCELLED;
}
if (BKE_node_clipboard_get_type() != ntree->type) {
BKE_report(op->reports, RPT_ERROR, "Clipboard nodes are an incompatible type");
return OPERATOR_CANCELLED;
}
2012-08-20 13:59:19 +00:00
/* only warn */
if (is_clipboard_valid == false) {
2012-08-20 13:59:19 +00:00
BKE_report(op->reports,
RPT_WARNING,
"Some nodes references could not be restored, will be left empty");
}
/* make sure all clipboard nodes would be valid in the target tree */
bool all_nodes_valid = true;
LISTBASE_FOREACH (bNode *, node, clipboard_nodes_lb) {
const char *disabled_hint = nullptr;
if (!node->typeinfo->poll_instance ||
!node->typeinfo->poll_instance(node, ntree, &disabled_hint)) {
all_nodes_valid = false;
if (disabled_hint) {
BKE_reportf(op->reports,
RPT_ERROR,
"Cannot add node %s into node tree %s:\n %s",
node->name,
ntree->id.name + 2,
disabled_hint);
}
else {
BKE_reportf(op->reports,
RPT_ERROR,
"Cannot add node %s into node tree %s",
node->name,
ntree->id.name + 2);
}
}
}
if (!all_nodes_valid) {
return OPERATOR_CANCELLED;
}
ED_preview_kill_jobs(CTX_wm_manager(C), CTX_data_main(C));
/* deselect old nodes */
node_deselect_all(snode);
/* calculate "barycenter" for placing on mouse cursor */
float center[2] = {0.0f, 0.0f};
int num_nodes = 0;
LISTBASE_FOREACH_INDEX (bNode *, node, clipboard_nodes_lb, num_nodes) {
center[0] += BLI_rctf_cent_x(&node->totr);
center[1] += BLI_rctf_cent_y(&node->totr);
}
2012-08-20 13:59:19 +00:00
mul_v2_fl(center, 1.0 / num_nodes);
/* copy nodes from clipboard */
LISTBASE_FOREACH (bNode *, node, clipboard_nodes_lb) {
bNode *new_node = BKE_node_copy_store_new_pointers(ntree, node, LIB_ID_COPY_DEFAULT);
/* pasted nodes are selected */
nodeSetSelected(new_node, true);
}
/* reparent copied nodes */
LISTBASE_FOREACH (bNode *, node, clipboard_nodes_lb) {
bNode *new_node = node->new_node;
if (new_node->parent) {
new_node->parent = new_node->parent->new_node;
}
}
LISTBASE_FOREACH (bNodeLink *, link, clipboard_links_lb) {
nodeAddLink(ntree,
link->fromnode->new_node,
link->fromsock->new_sock,
link->tonode->new_node,
link->tosock->new_sock);
}
Main *bmain = CTX_data_main(C);
ntreeUpdateTree(bmain, snode->edittree);
snode_notify(C, snode);
snode_dag_update(C, snode);
/* Pasting nodes can create arbitrary new relations, because nodes can reference IDs. */
DEG_relations_tag_update(bmain);
return OPERATOR_FINISHED;
}
void NODE_OT_clipboard_paste(wmOperatorType *ot)
{
/* identifiers */
ot->name = "Paste from Clipboard";
ot->description = "Pastes nodes from the clipboard to the active node tree";
ot->idname = "NODE_OT_clipboard_paste";
/* api callbacks */
ot->exec = node_clipboard_paste_exec;
ot->poll = ED_operator_node_editable;
/* flags */
2012-08-04 12:54:27 +00:00
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
}
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
/********************** Add interface socket operator *********************/
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
static bNodeSocket *ntree_get_active_interface_socket(ListBase *lb)
{
LISTBASE_FOREACH (bNodeSocket *, socket, lb) {
if (socket->flag & SELECT) {
return socket;
}
}
return nullptr;
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
}
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
static int ntree_socket_add_exec(bContext *C, wmOperator *op)
{
SpaceNode *snode = CTX_wm_space_node(C);
bNodeTree *ntree = snode->edittree;
PointerRNA ntree_ptr;
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
RNA_id_pointer_create((ID *)ntree, &ntree_ptr);
const eNodeSocketInOut in_out = (eNodeSocketInOut)RNA_enum_get(op->ptr, "in_out");
ListBase *sockets = (in_out == SOCK_IN) ? &ntree->inputs : &ntree->outputs;
const char *default_name = (in_out == SOCK_IN) ? "Input" : "Output";
bNodeSocket *active_sock = ntree_get_active_interface_socket(sockets);
bNodeSocket *sock;
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 (active_sock) {
/* insert a copy of the active socket right after it */
sock = ntreeInsertSocketInterface(
ntree, in_out, active_sock->idname, active_sock->next, active_sock->name);
/* XXX this only works for actual sockets, not interface templates! */
/*nodeSocketCopyValue(sock, &ntree_ptr, active_sock, &ntree_ptr);*/
}
else {
/* XXX TODO define default socket type for a tree! */
sock = ntreeAddSocketInterface(ntree, in_out, "NodeSocketFloat", default_name);
}
/* Deactivate sockets. */
LISTBASE_FOREACH (bNodeSocket *, socket_iter, sockets) {
socket_iter->flag &= ~SELECT;
}
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
/* make the new socket active */
sock->flag |= SELECT;
ntreeUpdateTree(CTX_data_main(C), ntree);
snode_notify(C, snode);
snode_dag_update(C, snode);
WM_event_add_notifier(C, NC_NODE | ND_DISPLAY, nullptr);
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 OPERATOR_FINISHED;
}
void NODE_OT_tree_socket_add(wmOperatorType *ot)
{
/* identifiers */
2013-03-18 18:25:05 +00:00
ot->name = "Add Node Tree Interface Socket";
2013-03-18 18:43:22 +00:00
ot->description = "Add an input or output socket to the current node tree";
2013-03-18 18:25:05 +00:00
ot->idname = "NODE_OT_tree_socket_add";
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
/* api callbacks */
2013-03-18 18:25:05 +00:00
ot->exec = ntree_socket_add_exec;
ot->poll = ED_operator_node_editable;
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
/* flags */
2013-03-18 18:25:05 +00:00
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
RNA_def_enum(ot->srna, "in_out", rna_enum_node_socket_in_out_items, SOCK_IN, "Socket 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
}
/********************** Remove interface socket operator *********************/
static int ntree_socket_remove_exec(bContext *C, wmOperator *op)
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
{
SpaceNode *snode = CTX_wm_space_node(C);
bNodeTree *ntree = snode->edittree;
const eNodeSocketInOut in_out = (eNodeSocketInOut)RNA_enum_get(op->ptr, "in_out");
bNodeSocket *iosock = ntree_get_active_interface_socket(in_out == SOCK_IN ? &ntree->inputs :
&ntree->outputs);
if (iosock == nullptr) {
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 OPERATOR_CANCELLED;
}
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
/* preferably next socket becomes active, otherwise try previous socket */
bNodeSocket *active_sock = (iosock->next ? iosock->next : iosock->prev);
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
ntreeRemoveSocketInterface(ntree, iosock);
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
/* set active socket */
if (active_sock) {
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
active_sock->flag |= SELECT;
}
ntreeUpdateTree(CTX_data_main(C), ntree);
snode_notify(C, snode);
snode_dag_update(C, snode);
WM_event_add_notifier(C, NC_NODE | ND_DISPLAY, nullptr);
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 OPERATOR_FINISHED;
}
void NODE_OT_tree_socket_remove(wmOperatorType *ot)
{
/* identifiers */
2013-03-18 18:25:05 +00:00
ot->name = "Remove Node Tree Interface Socket";
2013-03-18 18:43:22 +00:00
ot->description = "Remove an input or output socket to the current node tree";
2013-03-18 18:25:05 +00:00
ot->idname = "NODE_OT_tree_socket_remove";
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
/* api callbacks */
2013-03-18 18:25:05 +00:00
ot->exec = ntree_socket_remove_exec;
ot->poll = ED_operator_node_editable;
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
/* flags */
2013-03-18 18:25:05 +00:00
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
RNA_def_enum(ot->srna, "in_out", rna_enum_node_socket_in_out_items, SOCK_IN, "Socket 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
}
/********************** Move interface socket operator *********************/
static const EnumPropertyItem move_direction_items[] = {
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
{1, "UP", 0, "Up", ""},
{2, "DOWN", 0, "Down", ""},
{0, nullptr, 0, nullptr, nullptr},
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
};
static int ntree_socket_move_exec(bContext *C, wmOperator *op)
{
SpaceNode *snode = CTX_wm_space_node(C);
bNodeTree *ntree = snode->edittree;
int direction = RNA_enum_get(op->ptr, "direction");
const eNodeSocketInOut in_out = (eNodeSocketInOut)RNA_enum_get(op->ptr, "in_out");
ListBase *sockets = in_out == SOCK_IN ? &ntree->inputs : &ntree->outputs;
bNodeSocket *iosock = ntree_get_active_interface_socket(sockets);
if (iosock == nullptr) {
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 OPERATOR_CANCELLED;
}
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
switch (direction) {
2013-07-19 10:40:43 +00:00
case 1: { /* up */
bNodeSocket *before = iosock->prev;
BLI_remlink(sockets, iosock);
if (before) {
BLI_insertlinkbefore(sockets, before, iosock);
}
else {
BLI_addhead(sockets, iosock);
}
2013-07-19 10:40:43 +00:00
break;
}
case 2: { /* down */
bNodeSocket *after = iosock->next;
BLI_remlink(sockets, iosock);
if (after) {
BLI_insertlinkafter(sockets, after, iosock);
}
else {
BLI_addtail(sockets, iosock);
}
2013-07-19 10:40:43 +00:00
break;
}
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
}
ntree->update |= NTREE_UPDATE_GROUP;
ntreeUpdateTree(CTX_data_main(C), ntree);
snode_notify(C, snode);
snode_dag_update(C, snode);
WM_event_add_notifier(C, NC_NODE | ND_DISPLAY, nullptr);
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 OPERATOR_FINISHED;
}
void NODE_OT_tree_socket_move(wmOperatorType *ot)
{
/* identifiers */
2013-03-18 18:25:05 +00:00
ot->name = "Move Node Tree Socket";
2013-03-18 18:43:22 +00:00
ot->description = "Move a socket up or down in the current node tree's sockets stack";
2013-03-18 18:25:05 +00:00
ot->idname = "NODE_OT_tree_socket_move";
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
/* api callbacks */
2013-03-18 18:25:05 +00:00
ot->exec = ntree_socket_move_exec;
ot->poll = ED_operator_node_editable;
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
/* flags */
2013-03-18 18:25:05 +00:00
ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO;
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
RNA_def_enum(ot->srna, "direction", move_direction_items, 1, "Direction", "");
RNA_def_enum(ot->srna, "in_out", rna_enum_node_socket_in_out_items, SOCK_IN, "Socket 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
}
/* ********************** 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 = nodeGetActive(snode->edittree);
}
2012-11-03 15:35:03 +00:00
if (node && node->type == 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)
{
2014-04-11 11:25:41 +10:00
bool found = false;
ntree->done = true;
/* update each script that is using this text datablock */
LISTBASE_FOREACH (bNode *, node, &ntree->nodes) {
2012-11-03 15:35:03 +00:00
if (node->type == 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 && !ngroup->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
found |= node_shader_script_update_text_recursive(engine, type, ngroup, text);
}
}
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
else if (node->type == SH_NODE_SCRIPT && node->id == &text->id) {
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;
/* get node */
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 = nodeGetActive(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) {
/* clear flags for recursion check */
FOREACH_NODETREE_BEGIN (bmain, ntree, id) {
if (ntree->type == NTREE_SHADER) {
ntree->done = false;
}
}
FOREACH_NODETREE_END;
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 (!ntree->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
found |= node_shader_script_update_text_recursive(engine, type, ntree, text);
}
}
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;
}
/* ********************** 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;
}
snode_notify(C, snode);
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 *UNUSED(op))
{
SpaceNode *snode = CTX_wm_space_node(C);
bNodeTree *btree = snode->nodetree;
btree->flag &= ~NTREE_VIEWER_BORDER;
snode_notify(C, snode);
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;
}
/* ****************** Cryptomatte Add Socket ******************* */
static int node_cryptomatte_add_socket_exec(bContext *C, wmOperator *UNUSED(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 = nodeGetActive(snode->edittree);
}
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
if (!node || node->type != CMP_NODE_CRYPTOMATTE_LEGACY) {
return OPERATOR_CANCELLED;
}
ntreeCompositCryptomatteAddSocket(ntree, node);
snode_notify(C, snode);
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;
}
/* ****************** Cryptomatte Remove Socket ******************* */
static int node_cryptomatte_remove_socket_exec(bContext *C, wmOperator *UNUSED(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 = nodeGetActive(snode->edittree);
}
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
if (!node || node->type != CMP_NODE_CRYPTOMATTE_LEGACY) {
return OPERATOR_CANCELLED;
}
if (!ntreeCompositCryptomatteRemoveSocket(ntree, node)) {
return OPERATOR_CANCELLED;
}
snode_notify(C, snode);
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;
}