1berry/blender
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
blender/release/scripts/startup/nodeitems_builtins.py

493 lines
19 KiB
Python
Raw Normal View History

Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
# ##### BEGIN GPL LICENSE BLOCK #####
#
# 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,
# Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
#
# ##### END GPL LICENSE BLOCK #####
# <pep8 compliant>
Fix for node menu: Show the group input/output nodes in the Input/Output categories respectively, so they can be added with the usual UI in case the user deletes them. These nodes are polled out for non-group trees (node trees not in the bpy.data.node_groups collection) to avoid confusion. For that purpose a new optional poll function argument has been added to NodeItem, which allows selectively polling individual items in an otherwise static list.
2013-05-28 09:45:34 +00:00
import bpy
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
import nodeitems_utils
Cleanup: imports, indentation, long lines
2017-03-25 11:07:05 +11:00
from nodeitems_utils import (
NodeCategory,
NodeItem,
NodeItemCustom,
)
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
# Subclasses for standard node types
Minor code simplification in previous commit.
2016-04-27 22:58:00 +02:00
class SortedNodeCategory(NodeCategory):
Nodes: sort builtin compositor/shader/texture nodes alphabetically in menus Reviewed By: lukastoenne, dingto, Severin, carter2422 Differential Revision: https://developer.blender.org/D1957
2016-04-27 00:58:25 +02:00
def __init__(self, identifier, name, description="", items=None):
Minor code simplification in previous commit.
2016-04-27 22:58:00 +02:00
# for builtin nodes the convention is to sort by name
if isinstance(items, list):
items = sorted(items, key=lambda item: item.label.lower())
super().__init__(identifier, name, description, items)
Nodes: sort builtin compositor/shader/texture nodes alphabetically in menus Reviewed By: lukastoenne, dingto, Severin, carter2422 Differential Revision: https://developer.blender.org/D1957
2016-04-27 00:58:25 +02:00
Cleanup: unused vars, imports, pep8
2016-08-01 11:54:02 +10:00
Minor code simplification in previous commit.
2016-04-27 22:58:00 +02:00
class CompositorNodeCategory(SortedNodeCategory):
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
@classmethod
def poll(cls, context):
pep8 cleanup
2013-06-27 03:05:19 +00:00
return (context.space_data.tree_type == 'CompositorNodeTree')
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
Minor code simplification in previous commit.
2016-04-27 22:58:00 +02:00
class ShaderNewNodeCategory(SortedNodeCategory):
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
@classmethod
def poll(cls, context):
pep8 cleanup
2013-06-27 03:05:19 +00:00
return (context.space_data.tree_type == 'ShaderNodeTree' and
context.scene.render.use_shading_nodes)
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
Minor code simplification in previous commit.
2016-04-27 22:58:00 +02:00
class ShaderOldNodeCategory(SortedNodeCategory):
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
@classmethod
def poll(cls, context):
pep8 cleanup
2013-06-27 03:05:19 +00:00
return (context.space_data.tree_type == 'ShaderNodeTree' and
not context.scene.render.use_shading_nodes)
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
Minor code simplification in previous commit.
2016-04-27 22:58:00 +02:00
class TextureNodeCategory(SortedNodeCategory):
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
@classmethod
def poll(cls, context):
return context.space_data.tree_type == 'TextureNodeTree'
Use toolbar tabs for node categories instead of just a long list of panels. Patch by @Severin (with minor modifications by me). As discussed in {D535} the node editor does not have real modal operator tools like the 3D view or image editors for instance, so it makes sense to utilise it this way. Tabs really help in this area due to the large amount of node types and categories. Further tweaks could be made later if the need arises.
2014-06-23 16:34:02 +02:00
# menu entry for node group tools
def group_tools_draw(self, layout, context):
Fix #35633, Cannot Add Group Node In Blender 2.67a. The menu entry for the "make group" operator was missing in the new categories system. Added an alternative NodeItemCustom to the standard NodeItem to allow custom draw functions such as this operator. Used in the group items callback to generate the basic group_make operator call.
2013-06-05 09:21:17 +00:00
layout.operator("node.group_make")
Use toolbar tabs for node categories instead of just a long list of panels. Patch by @Severin (with minor modifications by me). As discussed in {D535} the node editor does not have real modal operator tools like the 3D view or image editors for instance, so it makes sense to utilise it this way. Tabs really help in this area due to the large amount of node types and categories. Further tweaks could be made later if the need arises.
2014-06-23 16:34:02 +02:00
layout.operator("node.group_ungroup")
Fix #35633, Cannot Add Group Node In Blender 2.67a. The menu entry for the "make group" operator was missing in the new categories system. Added an alternative NodeItemCustom to the standard NodeItem to allow custom draw functions such as this operator. Used in the group items callback to generate the basic group_make operator call.
2013-06-05 09:21:17 +00:00
layout.separator()
A bit more pythonic way of using the items callback in node categories. The category.items attribute is now a function taking a context parameter instead of a property. This can be used for checking validity, e.g. for doing node group recursion checks, and filter out unusable items.
2013-05-08 15:41:05 +00:00
# maps node tree type to group node type
node_tree_group_type = {
pep8 cleanup
2013-06-27 03:05:19 +00:00
'CompositorNodeTree': 'CompositorNodeGroup',
'ShaderNodeTree': 'ShaderNodeGroup',
'TextureNodeTree': 'TextureNodeGroup',
A bit more pythonic way of using the items callback in node categories. The category.items attribute is now a function taking a context parameter instead of a property. This can be used for checking validity, e.g. for doing node group recursion checks, and filter out unusable items.
2013-05-08 15:41:05 +00:00
}
pep8 cleanup
2013-06-27 03:05:19 +00:00
A bit more pythonic way of using the items callback in node categories. The category.items attribute is now a function taking a context parameter instead of a property. This can be used for checking validity, e.g. for doing node group recursion checks, and filter out unusable items.
2013-05-08 15:41:05 +00:00
# generic node group items generator for shader, compositor and texture node groups
def node_group_items(context):
Fix T44822: python enums' itemf callback did not handle 'NULL' context case. Enum's itemf callback can be called without context in some cases (UI, doc generation...). Python's enum properties did not handle this at all - it's kind of odd this did not cause more trouble and wasn't notice earlier... Probably dynamic enums using context are not much used in py code. Note about nodes: those are heavy users of dynamic enum with context. Now, we expect `NodeCategory.poll()` and `NodeItem.poll()` to always be called with a valid context (since when there is no context available, we can assume `poll()` is always True). `NodeCategory.items()`, however, must accept NULL context, so if you use custom `items` callable for your custom node categories, you may need to update it (as was done here for builtin `node_group_items()`).
2015-05-25 14:19:51 +02:00
if context is None:
return
A bit more pythonic way of using the items callback in node categories. The category.items attribute is now a function taking a context parameter instead of a property. This can be used for checking validity, e.g. for doing node group recursion checks, and filter out unusable items.
2013-05-08 15:41:05 +00:00
space = context.space_data
if not space:
return
ntree = space.edit_tree
if not ntree:
return
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
Use toolbar tabs for node categories instead of just a long list of panels. Patch by @Severin (with minor modifications by me). As discussed in {D535} the node editor does not have real modal operator tools like the 3D view or image editors for instance, so it makes sense to utilise it this way. Tabs really help in this area due to the large amount of node types and categories. Further tweaks could be made later if the need arises.
2014-06-23 16:34:02 +02:00
yield NodeItemCustom(draw=group_tools_draw)
Fix #35633, Cannot Add Group Node In Blender 2.67a. The menu entry for the "make group" operator was missing in the new categories system. Added an alternative NodeItemCustom to the standard NodeItem to allow custom draw functions such as this operator. Used in the group items callback to generate the basic group_make operator call.
2013-06-05 09:21:17 +00:00
Added filter to the node group items callback to remove recursive node groups right from the start. These tree pointers would be polled out internally as well, but this way they don't show up in the menus in the first place.
2013-05-08 15:41:07 +00:00
def contains_group(nodetree, group):
if nodetree == group:
return True
else:
for node in nodetree.nodes:
if node.bl_idname in node_tree_group_type.values() and node.node_tree is not None:
if contains_group(node.node_tree, group):
return True
return False
A bit more pythonic way of using the items callback in node categories. The category.items attribute is now a function taking a context parameter instead of a property. This can be used for checking validity, e.g. for doing node group recursion checks, and filter out unusable items.
2013-05-08 15:41:05 +00:00
for group in context.blend_data.node_groups:
Added filter to the node group items callback to remove recursive node groups right from the start. These tree pointers would be polled out internally as well, but this way they don't show up in the menus in the first place.
2013-05-08 15:41:07 +00:00
if group.bl_idname != ntree.bl_idname:
continue
# filter out recursive groups
Fix for node item polling: recursion check was the wrong way around, needs to test is the parent tree is inside the group.
2013-05-08 15:41:09 +00:00
if contains_group(group, ntree):
Added filter to the node group items callback to remove recursive node groups right from the start. These tree pointers would be polled out internally as well, but this way they don't show up in the menus in the first place.
2013-05-08 15:41:07 +00:00
continue
pep8 cleanup
2013-06-27 03:05:19 +00:00
yield NodeItem(node_tree_group_type[group.bl_idname],
group.name,
{"node_tree": "bpy.data.node_groups[%r]" % group.name})
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
Fix for node menu: Show the group input/output nodes in the Input/Output categories respectively, so they can be added with the usual UI in case the user deletes them. These nodes are polled out for non-group trees (node trees not in the bpy.data.node_groups collection) to avoid confusion. For that purpose a new optional poll function argument has been added to NodeItem, which allows selectively polling individual items in an otherwise static list.
2013-05-28 09:45:34 +00:00
# only show input/output nodes inside node groups
def group_input_output_item_poll(context):
space = context.space_data
if space.edit_tree in bpy.data.node_groups.values():
return True
return False
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
Fix for line style shader nodes also shown in the Add menu of other shader types. Problem report by Nahuel Belich through Facebook, thanks!
2014-09-07 22:15:18 +09:00
# only show input/output nodes when editing line style node trees
def line_style_shader_nodes_poll(context):
snode = context.space_data
return (snode.tree_type == 'ShaderNodeTree' and
snode.shader_type == 'LINESTYLE')
Cycles: Filter Shader and Output nodes to their respective object/world node tree. Some nodes only work in certain node trees, so don't show them in the Add Node menu when this is the case. This can probably be expanded to Input Nodes too, but need to double check some cases here still.
2014-10-01 06:23:43 +02:00
# only show nodes working in world node trees
def world_shader_nodes_poll(context):
snode = context.space_data
return (snode.tree_type == 'ShaderNodeTree' and
Cleanup: replace dict /w list for module reload Never used keys and better reload in same order loaded.
2016-03-03 06:31:11 +11:00
snode.shader_type == 'WORLD')
Cycles: Filter Shader and Output nodes to their respective object/world node tree. Some nodes only work in certain node trees, so don't show them in the Add Node menu when this is the case. This can probably be expanded to Input Nodes too, but need to double check some cases here still.
2014-10-01 06:23:43 +02:00
# only show nodes working in object node trees
def object_shader_nodes_poll(context):
snode = context.space_data
return (snode.tree_type == 'ShaderNodeTree' and
snode.shader_type == 'OBJECT')
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
# All standard node categories currently used in nodes.
Nicer registration mechanism for node categories. The lists of node categories and items are now stored in a dictionary with an identifier key, so they can be registered and unregistered individually. The Add menu is now persistent and gets extended with a draw function for each of the registered node category lists. This allows pynodes to define their own list of node categories and items and register it at runtime without interfering with the standard nodes.
2013-04-22 16:25:35 +00:00
shader_node_categories = [
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
# Shader Nodes
ShaderOldNodeCategory("SH_INPUT", "Input", items=[
NodeItem("ShaderNodeMaterial"),
NodeItem("ShaderNodeCameraData"),
Fresnel node support for Blender Internal Render
2016-12-14 18:02:38 +03:00
NodeItem("ShaderNodeFresnel"),
Add 'Layer Weight' node to Blender internal node items
2017-01-17 12:02:05 +03:00
NodeItem("ShaderNodeLayerWeight"),
Blender Internal: Add "Lamp Data" shader node that allows shaders to acquire information such as light vector from specified Lamp. For now this provides the following outputs: - Color - Light Vector - Distance - Shadow - Visibility Factor Note: Color output is multiplied by the lamp energy. Multiplication of color*max(dot(light_vector,normal_vector),0)*shadow*visibility_factor produces the exact same result as the Lambert shader. Many thanks to Brecht for code review and discussion!
2013-11-25 20:58:23 +09:00
NodeItem("ShaderNodeLampData"),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
NodeItem("ShaderNodeValue"),
NodeItem("ShaderNodeRGB"),
NodeItem("ShaderNodeTexture"),
NodeItem("ShaderNodeGeometry"),
NodeItem("ShaderNodeExtendedMaterial"),
Particle Info node support for GLSL mode and the internal render. With this patch "Particle Info" node from Cycles works in GLSL and BI Alexander (Blend4Web Team) Reviewers: psy-fi Note: moved particle info to object render instance instead of shadeinput during review - Antony. Differential Revision: https://developer.blender.org/D1313
2015-07-14 18:48:54 +02:00
NodeItem("ShaderNodeParticleInfo"),
Object Info node support for GLSL mode and the internal render Object Info node can be useful to give some variation to a single material assigned to multiple instances. This patch adds support for Viewport and BI. {F499530} Example: {F499528} Reviewers: merwin, brecht, dfelinto Reviewed By: brecht Subscribers: duarteframos, fclem, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov Differential Revision: https://developer.blender.org/D2425
2017-04-14 18:13:44 +03:00
NodeItem("ShaderNodeObjectInfo"),
Fix for node menu: Show the group input/output nodes in the Input/Output categories respectively, so they can be added with the usual UI in case the user deletes them. These nodes are polled out for non-group trees (node trees not in the bpy.data.node_groups collection) to avoid confusion. For that purpose a new optional poll function argument has been added to NodeItem, which allows selectively polling individual items in an otherwise static list.
2013-05-28 09:45:34 +00:00
NodeItem("NodeGroupInput", poll=group_input_output_item_poll),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
]),
ShaderOldNodeCategory("SH_OUTPUT", "Output", items=[
NodeItem("ShaderNodeOutput"),
Fix for node menu: Show the group input/output nodes in the Input/Output categories respectively, so they can be added with the usual UI in case the user deletes them. These nodes are polled out for non-group trees (node trees not in the bpy.data.node_groups collection) to avoid confusion. For that purpose a new optional poll function argument has been added to NodeItem, which allows selectively polling individual items in an otherwise static list.
2013-05-28 09:45:34 +00:00
NodeItem("NodeGroupOutput", poll=group_input_output_item_poll),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
]),
ShaderOldNodeCategory("SH_OP_COLOR", "Color", items=[
NodeItem("ShaderNodeMixRGB"),
NodeItem("ShaderNodeRGBCurve"),
NodeItem("ShaderNodeInvert"),
NodeItem("ShaderNodeHueSaturation"),
Gamma node support for Blender Internal Patch by Blend4Web Team, thanks! Reviewers: psy-fi Subscribers: yurikovelenov, AlexKowel, Evgeny_Rodygin Differential Revision: https://developer.blender.org/D899
2014-12-31 13:29:38 +01:00
NodeItem("ShaderNodeGamma"),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
]),
ShaderOldNodeCategory("SH_OP_VECTOR", "Vector", items=[
NodeItem("ShaderNodeNormal"),
NodeItem("ShaderNodeMapping"),
NodeItem("ShaderNodeVectorCurve"),
Vector Transform node support for GLSL mode and the internal renderer The Vector Transform node is a useful node which is present in the Cycles renderer. {F144283} This patch implements the Vector Transform node for GLSL mode and the internal renderer. Example: {F273060} Alexander (Blend4Web Team) Reviewers: brecht, campbellbarton, sergey Reviewed By: campbellbarton, sergey Subscribers: psy-fi, duarteframos, RobM, lightbwk, sergey, AlexKowel, valentin_b4w, Evgeny_Rodygin, yurikovelenov Projects: #bf_blender:_next Differential Revision: https://developer.blender.org/D909
2016-01-23 15:27:36 +03:00
NodeItem("ShaderNodeVectorTransform"),
Support multiple tangents for BI render & viewport Normal Map node support for GLSL mode and the internal render (multiple tangents support). The Normal Map node is a useful node which is present in the Cycles render. It makes it possible to use normal mapping without additional material node in a node tree. This patch implements Normal Map node for GLSL mode and the internal render. Previously only the active UV layer was used to calculate tangents.
2016-04-26 18:43:02 +10:00
NodeItem("ShaderNodeNormalMap"),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
]),
ShaderOldNodeCategory("SH_CONVERTOR", "Converter", items=[
NodeItem("ShaderNodeValToRGB"),
NodeItem("ShaderNodeRGBToBW"),
NodeItem("ShaderNodeMath"),
NodeItem("ShaderNodeVectorMath"),
NodeItem("ShaderNodeSqueeze"),
NodeItem("ShaderNodeSeparateRGB"),
NodeItem("ShaderNodeCombineRGB"),
Blender Internal: Add shader nodes "Separate HSV" and "Combine HSV", same as Cycles' ones.
2013-11-21 04:02:00 +09:00
NodeItem("ShaderNodeSeparateHSV"),
NodeItem("ShaderNodeCombineHSV"),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
]),
A bit more pythonic way of using the items callback in node categories. The category.items attribute is now a function taking a context parameter instead of a property. This can be used for checking validity, e.g. for doing node group recursion checks, and filter out unusable items.
2013-05-08 15:41:05 +00:00
ShaderOldNodeCategory("SH_GROUP", "Group", items=node_group_items),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
ShaderOldNodeCategory("SH_LAYOUT", "Layout", items=[
Fix [#35127] Layout -> Frame doen't exist anymore
2013-04-28 13:02:46 +00:00
NodeItem("NodeFrame"),
Added an entry for Reroute node in the node categories. Reroute is not a "real" node, but for users it's a bit hard to find, so a menu entry is ok for now. Eventually a context menu for nodes could be a nicer solution: right-click on node link opening a popup with operators for the node, socket or link under cursor, including option "Insert Reroute".
2013-05-13 09:32:17 +00:00
NodeItem("NodeReroute"),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
]),
# New Shader Nodes (Cycles)
ShaderNewNodeCategory("SH_NEW_INPUT", "Input", items=[
NodeItem("ShaderNodeTexCoord"),
NodeItem("ShaderNodeAttribute"),
NodeItem("ShaderNodeLightPath"),
NodeItem("ShaderNodeFresnel"),
NodeItem("ShaderNodeLayerWeight"),
NodeItem("ShaderNodeRGB"),
NodeItem("ShaderNodeValue"),
NodeItem("ShaderNodeTangent"),
NodeItem("ShaderNodeNewGeometry"),
Cycles / Wireframe node: * Added a wireframe node (Input category) to get access to Mesh wireframe data. The thickness can be controlled via a "Size" parameter, and is available in world units (default) and screen pixel size. * Only the triangulated mesh is available now, quads is for later. Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/More#Wireframe Render and Example file: http://www.pasteall.org/pic/show.php?id=51731 http://www.pasteall.org/blend/21510
2013-05-20 15:58:37 +00:00
NodeItem("ShaderNodeWireframe"),
Cycles: add bevel shader, for raytrace based rounded edges. The algorithm averages normals from nearby surfaces. It uses the same sampling strategy as BSSRDFs, casting rays along the normal and two orthogonal axes, and combining the samples with MIS. The main concern here is that we are introducing raytracing inside shader evaluation, which could be quite bad for GPU performance and stack memory usage. In practice it doesn't seem so bad though. Note that using this feature can easily slow down renders 20%, and that if you care about performance then it's better to use a bevel modifier. Mainly this is useful for baking, and for cases where the mesh topology makes it difficult for the bevel modifier to work well. Differential Revision: https://developer.blender.org/D2803
2017-08-18 18:37:05 +02:00
NodeItem("ShaderNodeBevel"),
Cycles: change Ambient Occlusion shader to output colors. This means the shader can now be used for procedural texturing. New settings on the node are Samples, Inside, Local Only and Distance. Original patch by Lukas with further changes by Brecht. Differential Revision: https://developer.blender.org/D3479
2018-06-15 11:03:29 +02:00
NodeItem("ShaderNodeAmbientOcclusion"),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
NodeItem("ShaderNodeObjectInfo"),
NodeItem("ShaderNodeHairInfo"),
NodeItem("ShaderNodeParticleInfo"),
Shader nodes / order: * Have all "Info" nodes next to each other. * Moved "Material Output" to the top. * Have all light shaders (Emission, Background, AO) next to each other.
2013-04-14 09:34:59 +00:00
NodeItem("ShaderNodeCameraData"),
Cycles: add dedicated UV Map node, easier to find and has convenient auto complete. Fixes T37954. Reviewed By: brecht, dingto Differential Revision: https://developer.blender.org/D230
2014-04-02 11:40:29 +02:00
NodeItem("ShaderNodeUVMap"),
Fix for line style shader nodes also shown in the Add menu of other shader types. Problem report by Nahuel Belich through Facebook, thanks!
2014-09-07 22:15:18 +09:00
NodeItem("ShaderNodeUVAlongStroke", poll=line_style_shader_nodes_poll),
Fix for node menu: Show the group input/output nodes in the Input/Output categories respectively, so they can be added with the usual UI in case the user deletes them. These nodes are polled out for non-group trees (node trees not in the bpy.data.node_groups collection) to avoid confusion. For that purpose a new optional poll function argument has been added to NodeItem, which allows selectively polling individual items in an otherwise static list.
2013-05-28 09:45:34 +00:00
NodeItem("NodeGroupInput", poll=group_input_output_item_poll),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
]),
ShaderNewNodeCategory("SH_NEW_OUTPUT", "Output", items=[
Cycles: Filter Shader and Output nodes to their respective object/world node tree. Some nodes only work in certain node trees, so don't show them in the Add Node menu when this is the case. This can probably be expanded to Input Nodes too, but need to double check some cases here still.
2014-10-01 06:23:43 +02:00
NodeItem("ShaderNodeOutputMaterial", poll=object_shader_nodes_poll),
NodeItem("ShaderNodeOutputLamp", poll=object_shader_nodes_poll),
NodeItem("ShaderNodeOutputWorld", poll=world_shader_nodes_poll),
Fix for line style shader nodes also shown in the Add menu of other shader types. Problem report by Nahuel Belich through Facebook, thanks!
2014-09-07 22:15:18 +09:00
NodeItem("ShaderNodeOutputLineStyle", poll=line_style_shader_nodes_poll),
Fix for node menu: Show the group input/output nodes in the Input/Output categories respectively, so they can be added with the usual UI in case the user deletes them. These nodes are polled out for non-group trees (node trees not in the bpy.data.node_groups collection) to avoid confusion. For that purpose a new optional poll function argument has been added to NodeItem, which allows selectively polling individual items in an otherwise static list.
2013-05-28 09:45:34 +00:00
NodeItem("NodeGroupOutput", poll=group_input_output_item_poll),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
]),
ShaderNewNodeCategory("SH_NEW_SHADER", "Shader", items=[
NodeItem("ShaderNodeMixShader"),
NodeItem("ShaderNodeAddShader"),
Cycles: Filter Shader and Output nodes to their respective object/world node tree. Some nodes only work in certain node trees, so don't show them in the Add Node menu when this is the case. This can probably be expanded to Input Nodes too, but need to double check some cases here still.
2014-10-01 06:23:43 +02:00
NodeItem("ShaderNodeBsdfDiffuse", poll=object_shader_nodes_poll),
Squashed commit of the following: commit 90778901c9ea1e16d5907981e91bceba25ff207d Merge: 76eebd9 3bf0026 Author: Schoen <schoepas@deher1m1598.emea.adsint.biz> Date: Mon Apr 3 07:52:05 2017 +0200 Merge branch 'master' into cycles_disney_brdf commit 76eebd9379a5dad519ff01cf215fbe3db6de931e Author: Schoen <schoepas@deher1m1598.emea.adsint.biz> Date: Thu Mar 30 15:34:20 2017 +0200 Updated copyright for the new files. commit 013f4a152a3898946ba5c616141c6e44d928ccfd Author: Schoen <schoepas@deher1m1598.emea.adsint.biz> Date: Thu Mar 30 15:32:55 2017 +0200 Switched from multiplication of base and subsurface color to blending between them using the subsurface parameter. commit 482ec5d1f20ceabc9cbda4838d4ae37d1d673458 Author: Schoen <schoepas@deher1m1598.emea.adsint.biz> Date: Mon Mar 13 15:47:12 2017 +0100 Fixed a bug that caused an additional white diffuse closure call when using path tracing. commit 26e906d162a6a8d67f2ebc8880993fcbab69559e Merge: 0593b8c 223aff9 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Mon Feb 6 11:32:31 2017 +0100 Merge branch 'master' into cycles_disney_brdf commit 0593b8c51bf7db0ed5ca92ed6f68d0d984dad0dd Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Mon Feb 6 11:30:36 2017 +0100 Fixed the broken GLSL shader and implemented the Disney BRDF in the real-time view port. commit 8c7e11423be640dc44b1807912058480710e51f4 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Fri Feb 3 14:24:05 2017 +0100 Fix to comply strict compiler flags and some code cleanup commit 17724e9d2dbffb1aaa61401224ecbf2349c1dac3 Merge: 379ba34 520afa2 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue Jan 24 09:59:58 2017 +0100 Merge branch 'master' into cycles_disney_brdf commit 379ba346b0acd1ea779365b940fcd01f5ba1165f Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue Jan 24 09:28:56 2017 +0100 Renamed the Disney BSDF to Principled BSDF. commit f80dcb4f34f1dc41841ced5965787fc26ace22a2 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Fri Dec 2 13:55:12 2016 +0100 Removed reflection call when roughness is low because of artifacts. commit 732db8a57f6d4e5d6f44bbad176c15fd55377f0a Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Wed Nov 16 09:22:25 2016 +0100 Indication if to use fresnel is now handled via the type of the BSDF. commit 0103659f5e705b314cde98b0e4a01c14c55acd5e Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Fri Nov 11 13:04:11 2016 +0100 Fixed an error in the clearcoat where it appeared too bright for default light sources (like directional lights) commit 0aa68f533529c9fd197a3ab0427f9e41a15456b9 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Mon Nov 7 12:04:38 2016 +0100 Resolved inconsistencies in using tabs and spaces commit f5897a9494e352de274b99e7bee971336c0dc386 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Mon Nov 7 08:13:41 2016 +0100 Improved the clearcoat part by using GTR1 instead of GTR2 commit 3dfc240e61b3d4d0e7c476989792e4ada869ce91 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Mon Oct 31 11:31:36 2016 +0100 Use reflection BSDF for glossy reflections when roughness is 0.0 to reduce computational expense and some code cleanup Code cleanup includes: - Code style cleanup and removed unused code - Consolidated code in the bsdf_microfacet_multi_impl.h to reduce some computational expense commit a2dd0c5fafdabe1573299170fb3be98a3e46d17a Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Wed Oct 26 08:51:10 2016 +0200 Fixed glossy reflections and refractions for low roughness values and cleaned up the code. For low roughness values, the reflections had some strange behavior. commit 981737591231a1a5a1c85950950580b65d029505 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue Oct 25 12:37:40 2016 +0200 Removed default values in setup functions and added extra functions for GGX with fresnel. commit bbc5d9d4527346a74155cf17be21fb02ee3e0779 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue Oct 25 11:09:36 2016 +0200 Switched from uniform to cosine hemisphere sampling for the diffuse and the sheen part. commit d52d8f2813d64363713f11160a6c725d4cafbcfa Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Mon Oct 24 16:17:13 2016 +0200 Removed the color parameters from the diffuse and sheen shader and use them as closure weights instead. commit 8f3d92738532ad867a0a3543c00393626ab8f6ec Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Mon Oct 24 09:57:06 2016 +0200 Fixed the issue with artifacts when using anisotropy without linking the tangent input to a tangent node. commit d93f680db9acaaade0354b34857a3ccaf348557f Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Mon Oct 24 09:14:51 2016 +0200 Added subsurface radius parameter to control the per color channel effection radius of the subsurface scattering. commit c708c3e53b323773fc852bdc239bc51e157dcaef Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Mon Oct 24 08:14:10 2016 +0200 Rearranged the inputs of the shader. commit dfbfff9c389074d3e5c1f49dd38a95e9b317eb1f Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Fri Oct 21 09:27:05 2016 +0200 Put spaces in the parameter names of the shader node commit e5a748ced17c8f59e5e73309096adeea3ba95e04 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Fri Oct 21 08:51:20 2016 +0200 Removed code that isn't in use anymore commit 75992bebc128c8b44cab4f0d8855603787f57260 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Fri Oct 21 08:50:07 2016 +0200 Code style cleanup commit 4dfcf455f7769752044e051b399fb6a5dfcd0e22 Merge: 243a0e3 2cd6a89 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Thu Oct 20 10:41:50 2016 +0200 Merge branch 'master' into cycles_disney_brdf commit 243a0e3eb80ef82704d5ea2657384c3a4b9fb497 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Thu Oct 20 10:01:45 2016 +0200 Switching between OSL and SVM is more consistant now when using Disney BSDF. There were some minor differences in the OSL implementation, e.g. the refraction roughness was missing. commit 2a5ac509223c838285a00c4c12775567666e7154 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue Sep 27 09:17:57 2016 +0200 Fixed a bug that caused transparency to be always white when using OSL and selecting GGX as distribution of the Disney BSDF commit e1fa8623915407cea942a07fd0a106b04e113c09 Merge: d0530a8 7f76f6f Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue Sep 27 08:59:32 2016 +0200 Merge branch 'master' into cycles_disney_brdf commit d0530a8af0e076c0aca4c9a61b0a64cada45ac4d Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue Sep 27 08:53:18 2016 +0200 Cleanup the Disney BSDF implementation and removing unneeded files. commit 3f4fc826bd9c1f47c694c0f6b2947daf5b524b1a Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue Sep 27 08:36:07 2016 +0200 Unified the OSL implementation of the Disney clearcoat as a simple microfacet shader like it was previously done in SVM commit 4d3a0032ecea99031979f342bfd5f66ea5a8625a Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Mon Sep 26 12:35:36 2016 +0200 Enhanced performance for Disney materials without subsurface scattering commit 3cd5eb56cf5c9006837f111c8866e4c6e1c2a6fd Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Fri Sep 16 08:47:56 2016 +0200 Fixed a bug in the Disney BSDF that caused specular reflections to be too bright and diffuse is now reacting to the roughness again - A normalization for the fresnel was missing which caused the specular reflections to become too bright for the single-scatter GGX - The roughness value for the diffuse BSSRDF part has always been overwritten and thus always 0 - Also the performance for refractive materials with roughness=0.0 has been improved commit 7cb37d711938e5626651db21f20da50edd96abaf Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Thu Sep 8 12:24:43 2016 +0200 Added selection field to the Disney BSDF node for switching between "Multiscatter GGX" and "GGX" In the "GGX" mode there is an additional parameter for changing the refraction roughness for materials with smooth surfaces and rough interns (e.g. honey). With the "Multiscatter GGX" this effect can't be produced at the moment and so here will be no separation of the two roughness values. commit cdd29d06bb86672ed0779eefb8eee95796b8f939 Merge: 02c315a b40d1c1 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue Sep 6 15:59:05 2016 +0200 Merge branch 'master' into cycles_disney_brdf commit 02c315aeb0f0d7bb429d4396912e03dbb8a77340 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue Sep 6 15:16:09 2016 +0200 Implemented the OSL part of the Disney shader commit 5f880293aeeacf269032824248b46d613691a36c Merge: 630b80e b399a6d Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Fri Sep 2 10:53:36 2016 +0200 Merge branch 'master' into cycles_disney_brdf commit 630b80e08b6acf83834bc95264af4ccdbbc5f82c Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Fri Sep 2 10:52:13 2016 +0200 Fresnel in the microfacet multiscatter implementation improved commit 0d9f4d7acb2de65d1c98d425cea4bf364795c155 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Fri Aug 26 11:11:05 2016 +0200 Fixed refraction roughness problem (refractions were always 100% rough) and set IOR of clearcoat to 1.5 commit 9eed34c7d980e1b998df457c4f76021162c80f78 Merge: ef29aae ae475e3 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue Aug 16 15:22:32 2016 +0200 Merge branch 'master' into cycles_disney_brdf commit ef29aaee1af8074e0228c480d962700e97ea5b36 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue Aug 16 15:17:12 2016 +0200 Implemented the fresnel in the multi-scatter GGX for the Disney BSDF - The specular/metallic part uses the multi-scatter GGX - The fresnel of the metallic part is controlled by the specular value - The color of the reflection part when using transparency can be controlled by the specularTint value commit 88567af085ac94119b98c95246b6d6f63161bc01 Merge: cc267e5 285e082 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Wed Aug 3 15:05:09 2016 +0200 Merge branch 'master' into cycles_disney_brdf commit cc267e52f20d036a66aeeff127ee1c856f7c651b Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Wed Aug 3 15:00:25 2016 +0200 Implemented the Disney clearcoat as a variation of the microfacet bsdf, removed the transparency roughness again and added an input for anisotropic rotations commit 81f6c06b1f53180bf32a5c11ac1fa64e2b6abf52 Merge: ece5a08 7065022 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Wed Aug 3 11:42:02 2016 +0200 Merge branch 'master' into cycles_disney_brdf commit ece5a08e0d6e51a83c223ea87346134216e5b34e Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue Jul 26 16:29:21 2016 +0200 Base color now applied again to the refraction of transparent Disney materials commit e3aff6849e06853c56da7bd610210dcab70e6070 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue Jul 26 16:05:19 2016 +0200 Added subsurface color parameter to the Disney shader commit b3ca6d8a2f4f866b323fc2df0a3beff577218c27 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue Jul 26 12:30:25 2016 +0200 Improvement of the SSS in the Disney shader * Now the bump normal is correctly used for the SSS. * SSS in Disney uses the Disney diffuse shader commit d68729300ee557e90a8e7e4be6eb8ef98db80fe2 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue Jul 26 12:23:13 2016 +0200 Better calculation of the Disney diffuse part Now the values for NdotL und NdotV are clamped to 0.0f for a better look when using normal maps commit cb6e500b12e7bce884d3db19ee138c975c215f2d Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Mon Jul 25 16:26:42 2016 +0200 Now one can disable specular reflactions again by setting specular and metallic to 0 (cracked this in the previous commit) commit bfb9cb11b548103369de2a46ce18b4ddf661362c Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Mon Jul 25 16:11:07 2016 +0200 fixed the Disney SSS and cleaned the initialization of the Disney shaders commit 642c0fdad12548c1a2ccbf595bae3a995d3022f7 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Mon Jul 25 16:09:55 2016 +0200 fixed an error that was caused by the missing LABEL_REFLECT in the Disney diffuse shader commit c10b484dcad3412c34455736e9656cd38716bcb0 Author: Jens Verwiebe <info@jensverwiebe.de> Date: Fri Jul 22 01:15:21 2016 +0200 Rollback attempt to fix sss crashing, it prevented crash by disabling sss completely, thus useless commit 462bba3f97fcc41834e0e20cc806a7958e5106f5 Author: Jens Verwiebe <info@jensverwiebe.de> Date: Thu Jul 21 23:11:59 2016 +0200 Add an undef for sc_next for safety commit 32d348577d69be251aa04110c5f6156cd2645f48 Author: Jens Verwiebe <info@jensverwiebe.de> Date: Thu Jul 21 00:15:48 2016 +0200 Attempt to fix Disney SSS commit dbad91ca6d46f5a4a6f2ba7ed4c811ffa723942f Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Wed Jul 20 11:13:00 2016 +0200 Added a roughness parameter for refractions (for scattering of the rays within an object) With this, one can create a translucent material with a smooth surface and with a milky look. The final refraction roughness has to be calculated using the surface roughness and the refraction roughness because those two are correlated for refractions. If a ray hits a rough surface of a translucent material, it is scattered while entering the surface. Then it is scattered further within the object. The calculation I'm using is the following: RefrRoughnessFinal = 1.0 - (1.0 - Roughness) * (1.0 - RefrRoughness) commit 50ea5e3e34394a727e3cceb6203adb48834a9ab7 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue Jun 7 10:24:50 2016 +0200 Disney BSDF is now supporting CUDA commit 10974cc826a4bfa8fb3ef59177abf0b0dc441065 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue May 31 11:18:07 2016 +0200 Added parameters IOR and Transparency for refractions With this, the Disney BRDF/BSSRDF is extended by the BTDF part. commit 218202c0905a4ec93ee19850360d1a39966d2c25 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Mon May 30 15:08:18 2016 +0200 Added an additional normal for the clearcoat With this normal one can simulate a thin layer of clearcoat by applying a smoother normal map than the original to this input commit dd139ead7e04aa87a894ccf3732cfce711258ff1 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Mon May 30 12:40:56 2016 +0200 Switched to the improved subsurface scattering from Christensen and Burley commit 11160fa4e1c32230119d4506e7e9fd3da2ab37f2 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Mon May 30 10:16:30 2016 +0200 Added Disney Sheen shader as a preparation to get to a BSSRDF commit cee4fe0cc94515ee60d4afa4d4e10c41003f1579 Merge: 4f955d0 6b5bab6 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Mon May 30 09:08:09 2016 +0200 Merge branch 'cycles_disney_brdf' of git.blender.org:blender into cycles_disney_brdf Conflicts: intern/cycles/kernel/closure/bsdf_disney_clearcoat.h intern/cycles/kernel/closure/bsdf_disney_diffuse.h intern/cycles/kernel/closure/bsdf_disney_specular.h intern/cycles/kernel/closure/bsdf_util.h intern/cycles/kernel/osl/CMakeLists.txt intern/cycles/kernel/osl/bsdf_disney_clearcoat.cpp intern/cycles/kernel/osl/bsdf_disney_diffuse.cpp intern/cycles/kernel/osl/bsdf_disney_specular.cpp intern/cycles/kernel/osl/osl_closures.h intern/cycles/kernel/shaders/node_disney_bsdf.osl intern/cycles/render/nodes.cpp intern/cycles/render/nodes.h commit 4f955d052358206209454decf2c3539e6a21b42f Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue May 24 16:38:23 2016 +0200 SVM and OSL are both working for the simple version of the Disney BRDF commit 1f5c41874b01ad297eb8a6bad9985296c6c0a6e1 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue May 24 09:58:50 2016 +0200 Disney node can be used without SVM and started to cleanup the OSL implementation There is still some wrong behavior for SVM for the Schlick Fresnel part at the specular and clearcoat commit d4b814e9304ebb44cc7c291cd83f7b7cdebcd152 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Wed May 18 10:22:29 2016 +0200 Switched from a parameter struct for Disney parameters to ShaderClosure params commit b86a1f5ba5019c7818153cb70b49f5f7a0bc52a0 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Wed May 18 10:19:57 2016 +0200 Added additional variables for storing parameters in the ShaderClosure struct commit 585b88623695fa07dfca9c9909d6d9184c3519c8 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue May 17 12:03:17 2016 +0200 added output parameter to the DisneyBsdfNode That has been forgotten after removing the inheritance of BsdfNode commit f91a28639884cbda7804715b910d64abba0718ef Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue May 17 10:40:48 2016 +0200 removed BsdfNode class inheritance for DisneyBsdfNode That's due to a naming difference. The Disney BSDF uses the name 'Base Color' while the BsdfNode had a 'Color' input. That caused a text message to be printed while rendering. commit 30da91c9c51d8cbc6a7564c7aaa61c9efe2ab654 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Wed May 4 16:08:10 2016 +0200 disney implementation cleaned commit 30d41da0f0352fad29375a395ffcb9cb7891eeb1 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Wed May 4 13:23:07 2016 +0200 added the disney brdf as a shader node commit 1f099fce249cb35e949cc629f7cca2167fca881a Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue May 3 16:54:49 2016 +0200 added clearcoat implementation commit 00a1378b98e435e9cdbfbac86eb974c19b2a8151 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Fri Apr 29 22:56:49 2016 +0200 disney diffuse und specular implemented commit 6baa7a7eb787638661cddad0c4e7f78bd3a8fa5c Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Mon Apr 18 15:21:32 2016 +0200 disney diffuse is working correctly commit d8fa169bf3caf71c40a124101b33dee6c510188e Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Mon Apr 18 08:41:53 2016 +0200 added vessel for disney diffuse shader commit 6b5bab6cecde153122625cf8dc10e4209ed1eb0f Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Wed May 18 10:22:29 2016 +0200 Switched from a parameter struct for Disney parameters to ShaderClosure params commit f6499c2676e074a36033627ffc7540107777630d Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Wed May 18 10:19:57 2016 +0200 Added additional variables for storing parameters in the ShaderClosure struct commit 7100640b65c2ff5447a18c01fc4e93594b4f486a Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue May 17 12:03:17 2016 +0200 added output parameter to the DisneyBsdfNode That has been forgotten after removing the inheritance of BsdfNode commit 419ee5441100a906b4b3fd8373cb768a71bfdfe6 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue May 17 10:40:48 2016 +0200 removed BsdfNode class inheritance for DisneyBsdfNode That's due to a naming difference. The Disney BSDF uses the name 'Base Color' while the BsdfNode had a 'Color' input. That caused a text message to be printed while rendering. commit 6006f91e8730f78df5874f808690d3908db103ab Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Wed May 4 16:08:10 2016 +0200 disney implementation cleaned commit 0ed08959141fc7c5f8c6e37c6552ecb9fcc5749c Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Wed May 4 13:23:07 2016 +0200 added the disney brdf as a shader node commit 0630b742d71c658915575a4a71a325094a0fc313 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Tue May 3 16:54:49 2016 +0200 added clearcoat implementation commit 9f3d39744b85619750c79c901f678b8c07fe0ee2 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Fri Apr 29 22:56:49 2016 +0200 disney diffuse und specular implemented commit 9b262063767d6b05a617891c967d887d21bfb177 Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Mon Apr 18 15:21:32 2016 +0200 disney diffuse is working correctly commit 4711a3927dfcadaa1c36de0ba78fc304fac1dc8a Author: Pascal Schoen <pascal_schoen@gmx.net> Date: Mon Apr 18 08:41:53 2016 +0200 added vessel for disney diffuse shader Differential Revision: https://developer.blender.org/D2313
2017-04-18 11:43:09 +02:00
NodeItem("ShaderNodeBsdfPrincipled", poll=object_shader_nodes_poll),
Cycles: Filter Shader and Output nodes to their respective object/world node tree. Some nodes only work in certain node trees, so don't show them in the Add Node menu when this is the case. This can probably be expanded to Input Nodes too, but need to double check some cases here still.
2014-10-01 06:23:43 +02:00
NodeItem("ShaderNodeBsdfGlossy", poll=object_shader_nodes_poll),
NodeItem("ShaderNodeBsdfTransparent", poll=object_shader_nodes_poll),
NodeItem("ShaderNodeBsdfRefraction", poll=object_shader_nodes_poll),
NodeItem("ShaderNodeBsdfGlass", poll=object_shader_nodes_poll),
NodeItem("ShaderNodeBsdfTranslucent", poll=object_shader_nodes_poll),
NodeItem("ShaderNodeBsdfAnisotropic", poll=object_shader_nodes_poll),
NodeItem("ShaderNodeBsdfVelvet", poll=object_shader_nodes_poll),
NodeItem("ShaderNodeBsdfToon", poll=object_shader_nodes_poll),
NodeItem("ShaderNodeSubsurfaceScattering", poll=object_shader_nodes_poll),
NodeItem("ShaderNodeEmission", poll=object_shader_nodes_poll),
NodeItem("ShaderNodeBsdfHair", poll=object_shader_nodes_poll),
NodeItem("ShaderNodeBackground", poll=world_shader_nodes_poll),
NodeItem("ShaderNodeHoldout", poll=object_shader_nodes_poll),
Cycles Volume Render: support for rendering of homogeneous volume with absorption. This is the simplest possible volume rendering case, constant density inside the volume and no scattering or emission. My plan is to tweak, verify and commit more volume rendering effects one by one, doing it all at once makes it difficult to verify correctness and track down bugs. Documentation is here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume Currently this hooks into path tracing in 3 ways, which should get us pretty far until we add more advanced light sampling. These 3 hooks are repeated in the path tracing, branched path tracing and transparent shadow code: * Determine active volume shader at start of the path * Change active volume shader on transmission through a surface * Light attenuation over line segments between camera, surfaces and background This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-28 16:56:19 +01:00
NodeItem("ShaderNodeVolumeAbsorption"),
Cycles: Volume Scatter node was missing in the Add Node menu.
2014-01-07 15:24:35 +01:00
NodeItem("ShaderNodeVolumeScatter"),
Cycles: add Principled Volume shader. Similar to the Principled BSDF, this should make it easier to set up volume materials. Smoke and fire can be rendererd with just a single principled volume node, the appropriate attributes will be used when available. The node also works for simpler homogeneous volumes like water or mist. Differential Revision: https://developer.blender.org/D3033
2018-01-30 15:05:19 +01:00
NodeItem("ShaderNodeVolumePrincipled"),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
]),
ShaderNewNodeCategory("SH_NEW_TEXTURE", "Texture", items=[
NodeItem("ShaderNodeTexImage"),
NodeItem("ShaderNodeTexEnvironment"),
NodeItem("ShaderNodeTexSky"),
NodeItem("ShaderNodeTexNoise"),
NodeItem("ShaderNodeTexWave"),
NodeItem("ShaderNodeTexVoronoi"),
NodeItem("ShaderNodeTexMusgrave"),
NodeItem("ShaderNodeTexGradient"),
NodeItem("ShaderNodeTexMagic"),
NodeItem("ShaderNodeTexChecker"),
NodeItem("ShaderNodeTexBrick"),
Cycles: Point density texture support This commit implements point density texture for Cycles shading nodes. It's done via creating voxel texture at shader compilation time, Not totally memory efficient, but avoids adding sampling code to kernel (which keeps render time as low as possible), In the future this will be compensated by using OpenVDB for more efficient storage of sparse volume data. Sampling of the voxel texture is happening at blender side and the same code is used as for Blender Internal's renderer. This texture is controlled by only object, particle system and radius. Linear falloff is used and there's no turbulence. This is because falloff is expected to happen using Curve Mapping node. Turbulence will be done as a distortion on the input coordinate. It's already possible to fake it using nose textures and in the future we can add more proper turbulence distortion node, which then could also be used for 2D texture mapping. Particle color support is done by Lukas, thanks!
2015-07-18 22:36:09 +02:00
NodeItem("ShaderNodeTexPointDensity"),
Cycles: Add Support for IES files as textures for light strength This patch adds support for IES files, a file format that is commonly used to store the directional intensity distribution of light sources. The new IES node is supposed to be plugged into the Strength input of the Emission node of the lamp. Since people generating IES files do not really seem to care about the standard, the parser is flexible enough to accept all test files I have tried. Some common weirdnesses are distributing values over multiple lines that should go into one line, using commas instead of spaces as delimiters and adding various useless stuff at the end of the file. The user interface of the node is similar to the script node, the user can either select an internal Text or load a file. Internally, IES files are handled similar to Image textures: They are stored in slots by the LightManager and each unique IES is assigned to one slot. The local coordinate system of the lamp is used, so that the direction of the light can be changed. For UI reasons, it's usually best to add an area light, rotate it and then change its type, since especially the point light does not immediately show its local coordinate system in the viewport. Reviewers: #cycles, dingto, sergey, brecht Reviewed By: #cycles, dingto, brecht Subscribers: OgDEV, crazyrobinhood, secundar, cardboard, pisuke, intrah, swerner, micah_denn, harvester, gottfried, disnel, campbellbarton, duarteframos, Lapineige, brecht, juicyfruit, dingto, marek, rickyblender, bliblubli, lockal, sergey Differential Revision: https://developer.blender.org/D1543
2018-05-27 00:46:37 +02:00
NodeItem("ShaderNodeTexIES"),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
]),
ShaderNewNodeCategory("SH_NEW_OP_COLOR", "Color", items=[
NodeItem("ShaderNodeMixRGB"),
NodeItem("ShaderNodeRGBCurve"),
NodeItem("ShaderNodeInvert"),
NodeItem("ShaderNodeLightFalloff"),
NodeItem("ShaderNodeHueSaturation"),
NodeItem("ShaderNodeGamma"),
NodeItem("ShaderNodeBrightContrast"),
]),
ShaderNewNodeCategory("SH_NEW_OP_VECTOR", "Vector", items=[
NodeItem("ShaderNodeMapping"),
NodeItem("ShaderNodeBump"),
Cycles: add Displacement node. This converts object space height to world space displacement, to be linked to the new vector displacement material output. Differential Revision: https://developer.blender.org/D3015
2018-01-13 13:11:03 +01:00
NodeItem("ShaderNodeDisplacement"),
Cycles: add Vector Displacement node and extend Displacement node. This adds midlevel and object/world space for displacement, and a vector displacement node with tangent/object/world space, midlevel and scale. Note that tangent space vector displacement still is not exactly compatible with maps created by other software, this will require changes to the tangent computation. Differential Revision: https://developer.blender.org/D1734
2018-01-21 00:40:42 +01:00
NodeItem("ShaderNodeVectorDisplacement"),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
NodeItem("ShaderNodeNormalMap"),
NodeItem("ShaderNodeNormal"),
NodeItem("ShaderNodeVectorCurve"),
Cycles / Vector Transform Node: * First step towards a new vector transform node, to convert Points/Vectors between World/Object/Camera space. This only contains the Blender UI, RNA... code, no Cycles integration yet.
2013-06-20 08:20:30 +00:00
NodeItem("ShaderNodeVectorTransform"),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
]),
ShaderNewNodeCategory("SH_NEW_CONVERTOR", "Converter", items=[
NodeItem("ShaderNodeMath"),
NodeItem("ShaderNodeValToRGB"),
NodeItem("ShaderNodeRGBToBW"),
NodeItem("ShaderNodeVectorMath"),
NodeItem("ShaderNodeSeparateRGB"),
NodeItem("ShaderNodeCombineRGB"),
Cycles: Add dedicated nodes to split/combine vectors. This was already possible via the RGB nodes, but that seems weird.
2014-06-13 21:44:48 +02:00
NodeItem("ShaderNodeSeparateXYZ"),
NodeItem("ShaderNodeCombineXYZ"),
Cycles: * Added 2 new nodes to combine and separate HSV colors. Screenshot: http://www.pasteall.org/pic/show.php?id=54828
2013-07-03 23:46:56 +00:00
NodeItem("ShaderNodeSeparateHSV"),
NodeItem("ShaderNodeCombineHSV"),
Cycles / Wavelength to RGB node: * Added a node to convert wavelength (in nanometer, from 380nm to 780nm) to RGB values. This can be useful to match real world colors easier. Example render: http://www.pasteall.org/pic/show.php?id=53202 ToDo: * Move some functions into an util file, maybe a common util_color.h or so. * Test GPU, unfortunately sm_21 doesn't work for me yet.
2013-06-09 20:46:22 +00:00
NodeItem("ShaderNodeWavelength"),
Cycles / Blackbody node: * First step towards a Blackbody to RGB converter. You can specify a color in Kelvin inside the node. * Only implemented for OSL atm, SVM will follow.
2013-06-13 08:55:51 +00:00
NodeItem("ShaderNodeBlackbody"),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
]),
ShaderNewNodeCategory("SH_NEW_SCRIPT", "Script", items=[
NodeItem("ShaderNodeScript"),
]),
A bit more pythonic way of using the items callback in node categories. The category.items attribute is now a function taking a context parameter instead of a property. This can be used for checking validity, e.g. for doing node group recursion checks, and filter out unusable items.
2013-05-08 15:41:05 +00:00
ShaderNewNodeCategory("SH_NEW_GROUP", "Group", items=node_group_items),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
ShaderNewNodeCategory("SH_NEW_LAYOUT", "Layout", items=[
Fix [#35127] Layout -> Frame doen't exist anymore
2013-04-28 13:02:46 +00:00
NodeItem("NodeFrame"),
Added an entry for Reroute node in the node categories. Reroute is not a "real" node, but for users it's a bit hard to find, so a menu entry is ok for now. Eventually a context menu for nodes could be a nicer solution: right-click on node link opening a popup with operators for the node, socket or link under cursor, including option "Insert Reroute".
2013-05-13 09:32:17 +00:00
NodeItem("NodeReroute"),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
]),
Nicer registration mechanism for node categories. The lists of node categories and items are now stored in a dictionary with an identifier key, so they can be registered and unregistered individually. The Add menu is now persistent and gets extended with a draw function for each of the registered node category lists. This allows pynodes to define their own list of node categories and items and register it at runtime without interfering with the standard nodes.
2013-04-22 16:25:35 +00:00
]
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
Nicer registration mechanism for node categories. The lists of node categories and items are now stored in a dictionary with an identifier key, so they can be registered and unregistered individually. The Add menu is now persistent and gets extended with a draw function for each of the registered node category lists. This allows pynodes to define their own list of node categories and items and register it at runtime without interfering with the standard nodes.
2013-04-22 16:25:35 +00:00
compositor_node_categories = [
pep8 cleanup
2013-06-27 03:05:19 +00:00
# Compositor Nodes
CompositorNodeCategory("CMP_INPUT", "Input", items=[
Shader nodes / order: * Have all "Info" nodes next to each other. * Moved "Material Output" to the top. * Have all light shaders (Emission, Background, AO) next to each other.
2013-04-14 09:34:59 +00:00
NodeItem("CompositorNodeRLayers"),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
NodeItem("CompositorNodeImage"),
NodeItem("CompositorNodeMovieClip"),
NodeItem("CompositorNodeMask"),
NodeItem("CompositorNodeRGB"),
NodeItem("CompositorNodeValue"),
NodeItem("CompositorNodeTexture"),
NodeItem("CompositorNodeBokehImage"),
NodeItem("CompositorNodeTime"),
NodeItem("CompositorNodeTrackPos"),
Fix for node menu: Show the group input/output nodes in the Input/Output categories respectively, so they can be added with the usual UI in case the user deletes them. These nodes are polled out for non-group trees (node trees not in the bpy.data.node_groups collection) to avoid confusion. For that purpose a new optional poll function argument has been added to NodeItem, which allows selectively polling individual items in an otherwise static list.
2013-05-28 09:45:34 +00:00
NodeItem("NodeGroupInput", poll=group_input_output_item_poll),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
]),
pep8 cleanup
2013-06-27 03:05:19 +00:00
CompositorNodeCategory("CMP_OUTPUT", "Output", items=[
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
NodeItem("CompositorNodeComposite"),
NodeItem("CompositorNodeViewer"),
NodeItem("CompositorNodeSplitViewer"),
NodeItem("CompositorNodeOutputFile"),
NodeItem("CompositorNodeLevels"),
Fix for node menu: Show the group input/output nodes in the Input/Output categories respectively, so they can be added with the usual UI in case the user deletes them. These nodes are polled out for non-group trees (node trees not in the bpy.data.node_groups collection) to avoid confusion. For that purpose a new optional poll function argument has been added to NodeItem, which allows selectively polling individual items in an otherwise static list.
2013-05-28 09:45:34 +00:00
NodeItem("NodeGroupOutput", poll=group_input_output_item_poll),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
]),
pep8 cleanup
2013-06-27 03:05:19 +00:00
CompositorNodeCategory("CMP_OP_COLOR", "Color", items=[
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
NodeItem("CompositorNodeMixRGB"),
NodeItem("CompositorNodeAlphaOver"),
NodeItem("CompositorNodeInvert"),
NodeItem("CompositorNodeCurveRGB"),
NodeItem("CompositorNodeHueSat"),
NodeItem("CompositorNodeColorBalance"),
NodeItem("CompositorNodeHueCorrect"),
NodeItem("CompositorNodeBrightContrast"),
NodeItem("CompositorNodeGamma"),
NodeItem("CompositorNodeColorCorrection"),
NodeItem("CompositorNodeTonemap"),
NodeItem("CompositorNodeZcombine"),
]),
pep8 cleanup
2013-06-27 03:05:19 +00:00
CompositorNodeCategory("CMP_CONVERTOR", "Converter", items=[
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
NodeItem("CompositorNodeMath"),
NodeItem("CompositorNodeValToRGB"),
NodeItem("CompositorNodeSetAlpha"),
NodeItem("CompositorNodePremulKey"),
NodeItem("CompositorNodeIDMask"),
NodeItem("CompositorNodeRGBToBW"),
NodeItem("CompositorNodeSepRGBA"),
NodeItem("CompositorNodeCombRGBA"),
NodeItem("CompositorNodeSepHSVA"),
NodeItem("CompositorNodeCombHSVA"),
NodeItem("CompositorNodeSepYUVA"),
NodeItem("CompositorNodeCombYUVA"),
NodeItem("CompositorNodeSepYCCA"),
NodeItem("CompositorNodeCombYCCA"),
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
NodeItem("CompositorNodeSwitchView"),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
]),
pep8 cleanup
2013-06-27 03:05:19 +00:00
CompositorNodeCategory("CMP_OP_FILTER", "Filter", items=[
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
NodeItem("CompositorNodeBlur"),
NodeItem("CompositorNodeBilateralblur"),
NodeItem("CompositorNodeDilateErode"),
NodeItem("CompositorNodeDespeckle"),
NodeItem("CompositorNodeFilter"),
NodeItem("CompositorNodeBokehBlur"),
NodeItem("CompositorNodeVecBlur"),
NodeItem("CompositorNodeDefocus"),
NodeItem("CompositorNodeGlare"),
NodeItem("CompositorNodeInpaint"),
NodeItem("CompositorNodeDBlur"),
NodeItem("CompositorNodePixelate"),
New compositor node "Sun Beams" This allows adding a "fake" sun beam effect, simulating crepuscular rays from light being scattered in a medium like the atmosphere or deep water. Such effects can be created also by renderers using volumetric lighting, but the compositor feature is a lot cheaper and is independent from 3D rendering. This makes it ideally suited for motion graphics. The implementation uses am optimized accumulation method for gathering color values along a line segment. The inner buffer loop uses fixed offset increments to avoid unnecessary multiplications and avoids variables by using compile-time specialization (see inline comments for further details).
2014-07-26 12:59:29 +02:00
NodeItem("CompositorNodeSunBeams"),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
]),
pep8 cleanup
2013-06-27 03:05:19 +00:00
CompositorNodeCategory("CMP_OP_VECTOR", "Vector", items=[
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
NodeItem("CompositorNodeNormal"),
NodeItem("CompositorNodeMapValue"),
NodeItem("CompositorNodeMapRange"),
NodeItem("CompositorNodeNormalize"),
NodeItem("CompositorNodeCurveVec"),
]),
pep8 cleanup
2013-06-27 03:05:19 +00:00
CompositorNodeCategory("CMP_MATTE", "Matte", items=[
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
NodeItem("CompositorNodeKeying"),
NodeItem("CompositorNodeKeyingScreen"),
NodeItem("CompositorNodeChannelMatte"),
NodeItem("CompositorNodeColorSpill"),
NodeItem("CompositorNodeBoxMask"),
NodeItem("CompositorNodeEllipseMask"),
NodeItem("CompositorNodeLumaMatte"),
NodeItem("CompositorNodeDiffMatte"),
NodeItem("CompositorNodeDistanceMatte"),
NodeItem("CompositorNodeChromaMatte"),
NodeItem("CompositorNodeColorMatte"),
NodeItem("CompositorNodeDoubleEdgeMask"),
]),
pep8 cleanup
2013-06-27 03:05:19 +00:00
CompositorNodeCategory("CMP_DISTORT", "Distort", items=[
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
NodeItem("CompositorNodeScale"),
NodeItem("CompositorNodeLensdist"),
NodeItem("CompositorNodeMovieDistortion"),
NodeItem("CompositorNodeTranslate"),
NodeItem("CompositorNodeRotate"),
NodeItem("CompositorNodeFlip"),
NodeItem("CompositorNodeCrop"),
NodeItem("CompositorNodeDisplace"),
NodeItem("CompositorNodeMapUV"),
NodeItem("CompositorNodeTransform"),
NodeItem("CompositorNodeStabilize"),
Merge plane track feature from tomato branch This commit includes all the changes made for plane tracker in tomato branch. Movie clip editor changes: - Artist might create a plane track out of multiple point tracks which belongs to the same track (minimum amount of point tracks is 4, maximum is not actually limited). When new plane track is added, it's getting "tracked" across all point tracks, which makes it stick to the same plane point tracks belong to. - After plane track was added, it need to be manually adjusted in a way it covers feature one might to mask/replace. General transform tools (G, R, S) or sliding corners with a mouse could be sued for this. Plane corner which corresponds to left bottom image corner has got X/Y axis on it (red is for X axis, green for Y). - Re-adjusting plane corners makes plane to be "re-tracked" for the frames sequence between current frame and next and previous keyframes. - Kayframes might be removed from the plane, using Shit-X (Marker Delete) operator. However, currently manual re-adjustment or "re-track" trigger is needed. Compositor changes: - Added new node called Plane Track Deform. - User selects which plane track to use (for this he need to select movie clip datablock, object and track names). - Node gets an image input, which need to be warped into the plane. - Node outputs: * Input image warped into the plane. * Plane, rasterized to a mask. Masking changes: - Mask points might be parented to a plane track, which makes this point deforming in a way as if it belongs to the tracked plane. Some video tutorials are available: - Coder video: http://www.youtube.com/watch?v=vISEwqNHqe4 - Artist video: https://vimeo.com/71727578 This is mine and Keir's holiday code project :)
2013-08-16 09:46:30 +00:00
NodeItem("CompositorNodePlaneTrackDeform"),
New Corner Pin node: uses explicit corner values for a plane warp transformation. This was suggested by Christopher Barrett (terrachild). Corner pin is a common feature in compositing. The corners for the plane warping can be defined by using vector node inputs to allow using perspective plane transformations without having to go via the MovieClip editor tracking data. Uses the same math as the PlaneTrack node, but without the link to MovieClip and Object. {F78199} The code for PlaneTrack operations has been restructured a bit to share it with the CornerPin node. * PlaneDistortCommonOperation.h/.cpp: Shared generic code for warping images based on 4 plane corners and a perspective matrix generated from these. Contains operation base classes for both the WarpImage and Mask operations. * PlaneTrackOperation.h/.cpp: Current plane track node operations, based on the common code above. These add pointers to MovieClip and Object which define the track data from wich to read the corners. * PlaneCornerPinOperation.h/.cpp: New corner pin variant, using explicit input sockets for the plane corners. One downside of the current compositor design is that there is no concept of invariables (constants) that don't vary over the image space. This has already been an issue for Blur nodes (size input is usually constant except when "variable size" is enabled) and a few others. For the corner pin node it is necessary that the corner input sockets are also invariant. They have to be evaluated for each tile now, otherwise the data is not available. This in turn makes it necessary to make the operation "complex" and request full input buffers, which adds unnecessary overhead.
2014-03-11 14:07:49 +01:00
NodeItem("CompositorNodeCornerPin"),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
]),
A bit more pythonic way of using the items callback in node categories. The category.items attribute is now a function taking a context parameter instead of a property. This can be used for checking validity, e.g. for doing node group recursion checks, and filter out unusable items.
2013-05-08 15:41:05 +00:00
CompositorNodeCategory("CMP_GROUP", "Group", items=node_group_items),
pep8 cleanup
2013-06-27 03:05:19 +00:00
CompositorNodeCategory("CMP_LAYOUT", "Layout", items=[
Fix [#35127] Layout -> Frame doen't exist anymore
2013-04-28 13:02:46 +00:00
NodeItem("NodeFrame"),
Added an entry for Reroute node in the node categories. Reroute is not a "real" node, but for users it's a bit hard to find, so a menu entry is ok for now. Eventually a context menu for nodes could be a nicer solution: right-click on node link opening a popup with operators for the node, socket or link under cursor, including option "Insert Reroute".
2013-05-13 09:32:17 +00:00
NodeItem("NodeReroute"),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
NodeItem("CompositorNodeSwitch"),
]),
Nicer registration mechanism for node categories. The lists of node categories and items are now stored in a dictionary with an identifier key, so they can be registered and unregistered individually. The Add menu is now persistent and gets extended with a draw function for each of the registered node category lists. This allows pynodes to define their own list of node categories and items and register it at runtime without interfering with the standard nodes.
2013-04-22 16:25:35 +00:00
]
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
Nicer registration mechanism for node categories. The lists of node categories and items are now stored in a dictionary with an identifier key, so they can be registered and unregistered individually. The Add menu is now persistent and gets extended with a draw function for each of the registered node category lists. This allows pynodes to define their own list of node categories and items and register it at runtime without interfering with the standard nodes.
2013-04-22 16:25:35 +00:00
texture_node_categories = [
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
# Texture Nodes
pep8 cleanup
2013-06-27 03:05:19 +00:00
TextureNodeCategory("TEX_INPUT", "Input", items=[
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
NodeItem("TextureNodeCurveTime"),
NodeItem("TextureNodeCoordinates"),
NodeItem("TextureNodeTexture"),
NodeItem("TextureNodeImage"),
Fix for node menu: Show the group input/output nodes in the Input/Output categories respectively, so they can be added with the usual UI in case the user deletes them. These nodes are polled out for non-group trees (node trees not in the bpy.data.node_groups collection) to avoid confusion. For that purpose a new optional poll function argument has been added to NodeItem, which allows selectively polling individual items in an otherwise static list.
2013-05-28 09:45:34 +00:00
NodeItem("NodeGroupInput", poll=group_input_output_item_poll),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
]),
pep8 cleanup
2013-06-27 03:05:19 +00:00
TextureNodeCategory("TEX_OUTPUT", "Output", items=[
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
NodeItem("TextureNodeOutput"),
NodeItem("TextureNodeViewer"),
Fix for node menu: Show the group input/output nodes in the Input/Output categories respectively, so they can be added with the usual UI in case the user deletes them. These nodes are polled out for non-group trees (node trees not in the bpy.data.node_groups collection) to avoid confusion. For that purpose a new optional poll function argument has been added to NodeItem, which allows selectively polling individual items in an otherwise static list.
2013-05-28 09:45:34 +00:00
NodeItem("NodeGroupOutput", poll=group_input_output_item_poll),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
]),
pep8 cleanup
2013-06-27 03:05:19 +00:00
TextureNodeCategory("TEX_OP_COLOR", "Color", items=[
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
NodeItem("TextureNodeMixRGB"),
NodeItem("TextureNodeCurveRGB"),
NodeItem("TextureNodeInvert"),
NodeItem("TextureNodeHueSaturation"),
NodeItem("TextureNodeCompose"),
NodeItem("TextureNodeDecompose"),
]),
pep8 cleanup
2013-06-27 03:05:19 +00:00
TextureNodeCategory("TEX_PATTERN", "Pattern", items=[
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
NodeItem("TextureNodeChecker"),
NodeItem("TextureNodeBricks"),
]),
pep8 cleanup
2013-06-27 03:05:19 +00:00
TextureNodeCategory("TEX_TEXTURE", "Textures", items=[
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
NodeItem("TextureNodeTexNoise"),
NodeItem("TextureNodeTexDistNoise"),
NodeItem("TextureNodeTexClouds"),
NodeItem("TextureNodeTexBlend"),
NodeItem("TextureNodeTexVoronoi"),
NodeItem("TextureNodeTexMagic"),
NodeItem("TextureNodeTexMarble"),
NodeItem("TextureNodeTexWood"),
NodeItem("TextureNodeTexMusgrave"),
NodeItem("TextureNodeTexStucci"),
]),
pep8 cleanup
2013-06-27 03:05:19 +00:00
TextureNodeCategory("TEX_CONVERTOR", "Converter", items=[
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
NodeItem("TextureNodeMath"),
NodeItem("TextureNodeValToRGB"),
NodeItem("TextureNodeRGBToBW"),
NodeItem("TextureNodeValToNor"),
NodeItem("TextureNodeDistance"),
]),
pep8 cleanup
2013-06-27 03:05:19 +00:00
TextureNodeCategory("TEX_DISTORT", "Distort", items=[
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
NodeItem("TextureNodeScale"),
NodeItem("TextureNodeTranslate"),
NodeItem("TextureNodeRotate"),
Texture Nodes: "At" distortion node was missing from the add menu.
2014-02-07 20:12:42 +01:00
NodeItem("TextureNodeAt"),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
]),
A bit more pythonic way of using the items callback in node categories. The category.items attribute is now a function taking a context parameter instead of a property. This can be used for checking validity, e.g. for doing node group recursion checks, and filter out unusable items.
2013-05-08 15:41:05 +00:00
TextureNodeCategory("TEX_GROUP", "Group", items=node_group_items),
pep8 cleanup
2013-06-27 03:05:19 +00:00
TextureNodeCategory("TEX_LAYOUT", "Layout", items=[
Fix [#35127] Layout -> Frame doen't exist anymore
2013-04-28 13:02:46 +00:00
NodeItem("NodeFrame"),
Added an entry for Reroute node in the node categories. Reroute is not a "real" node, but for users it's a bit hard to find, so a menu entry is ok for now. Eventually a context menu for nodes could be a nicer solution: right-click on node link opening a popup with operators for the node, socket or link under cursor, including option "Insert Reroute".
2013-05-13 09:32:17 +00:00
NodeItem("NodeReroute"),
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
]),
]
def register():
pep8 cleanup
2013-06-27 03:05:19 +00:00
nodeitems_utils.register_node_categories('SHADER', shader_node_categories)
nodeitems_utils.register_node_categories('COMPOSITING', compositor_node_categories)
nodeitems_utils.register_node_categories('TEXTURE', texture_node_categories)
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
def unregister():
pep8 cleanup
2013-06-27 03:05:19 +00:00
nodeitems_utils.unregister_node_categories('SHADER')
nodeitems_utils.unregister_node_categories('COMPOSITING')
nodeitems_utils.unregister_node_categories('TEXTURE')
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
if __name__ == "__main__":
register()
Reference in New Issue Copy Permalink