2023-08-16 00:20:26 +10:00
|
|
|
# SPDX-FileCopyrightText: 2012-2023 Blender Authors
|
2023-06-15 13:09:04 +10:00
|
|
|
#
|
2022-02-11 09:07:11 +11:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-or-later
|
2023-06-15 13:09:04 +10:00
|
|
|
|
2021-02-21 21:21:18 +11:00
|
|
|
from __future__ import annotations
|
2012-08-08 16:44:16 +00:00
|
|
|
|
2013-06-27 03:05:19 +00:00
|
|
|
import bpy
|
2015-01-27 17:46:07 +11:00
|
|
|
from bpy.types import (
|
2017-03-25 11:07:05 +11:00
|
|
|
Operator,
|
|
|
|
|
PropertyGroup,
|
|
|
|
|
)
|
2015-01-27 17:46:07 +11:00
|
|
|
from bpy.props import (
|
2017-03-25 11:07:05 +11:00
|
|
|
BoolProperty,
|
|
|
|
|
CollectionProperty,
|
2023-06-14 18:02:40 +02:00
|
|
|
EnumProperty,
|
Geometry Nodes: add simulation support
This adds support for building simulations with geometry nodes. A new
`Simulation Input` and `Simulation Output` node allow maintaining a
simulation state across multiple frames. Together these two nodes form
a `simulation zone` which contains all the nodes that update the simulation
state from one frame to the next.
A new simulation zone can be added via the menu
(`Simulation > Simulation Zone`) or with the node add search.
The simulation state contains a geometry by default. However, it is possible
to add multiple geometry sockets as well as other socket types. Currently,
field inputs are evaluated and stored for the preceding geometry socket in
the order that the sockets are shown. Simulation state items can be added
by linking one of the empty sockets to something else. In the sidebar, there
is a new panel that allows adding, removing and reordering these sockets.
The simulation nodes behave as follows:
* On the first frame, the inputs of the `Simulation Input` node are evaluated
to initialize the simulation state. In later frames these sockets are not
evaluated anymore. The `Delta Time` at the first frame is zero, but the
simulation zone is still evaluated.
* On every next frame, the `Simulation Input` node outputs the simulation
state of the previous frame. Nodes in the simulation zone can edit that
data in arbitrary ways, also taking into account the `Delta Time`. The new
simulation state has to be passed to the `Simulation Output` node where it
is cached and forwarded.
* On a frame that is already cached or baked, the nodes in the simulation
zone are not evaluated, because the `Simulation Output` node can return
the previously cached data directly.
It is not allowed to connect sockets from inside the simulation zone to the
outside without going through the `Simulation Output` node. This is a necessary
restriction to make caching and sub-frame interpolation work. Links can go into
the simulation zone without problems though.
Anonymous attributes are not propagated by the simulation nodes unless they
are explicitly stored in the simulation state. This is unfortunate, but
currently there is no practical and reliable alternative. The core problem
is detecting which anonymous attributes will be required for the simulation
and afterwards. While we can detect this for the current evaluation, we can't
look into the future in time to see what data will be necessary. We intend to
make it easier to explicitly pass data through a simulation in the future,
even if the simulation is in a nested node group.
There is a new `Simulation Nodes` panel in the physics tab in the properties
editor. It allows baking all simulation zones on the selected objects. The
baking options are intentially kept at a minimum for this MVP. More features
for simulation baking as well as baking in general can be expected to be added
separately.
All baked data is stored on disk in a folder next to the .blend file. #106937
describes how baking is implemented in more detail. Volumes can not be baked
yet and materials are lost during baking for now. Packing the baked data into
the .blend file is not yet supported.
The timeline indicates which frames are currently cached, baked or cached but
invalidated by user-changes.
Simulation input and output nodes are internally linked together by their
`bNode.identifier` which stays the same even if the node name changes. They
are generally added and removed together. However, there are still cases where
"dangling" simulation nodes can be created currently. Those generally don't
cause harm, but would be nice to avoid this in more cases in the future.
Co-authored-by: Hans Goudey <h.goudey@me.com>
Co-authored-by: Lukas Tönne <lukas@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/104924
2023-05-03 13:18:51 +02:00
|
|
|
FloatVectorProperty,
|
2017-03-25 11:07:05 +11:00
|
|
|
StringProperty,
|
|
|
|
|
)
|
Geometry Nodes: add simulation support
This adds support for building simulations with geometry nodes. A new
`Simulation Input` and `Simulation Output` node allow maintaining a
simulation state across multiple frames. Together these two nodes form
a `simulation zone` which contains all the nodes that update the simulation
state from one frame to the next.
A new simulation zone can be added via the menu
(`Simulation > Simulation Zone`) or with the node add search.
The simulation state contains a geometry by default. However, it is possible
to add multiple geometry sockets as well as other socket types. Currently,
field inputs are evaluated and stored for the preceding geometry socket in
the order that the sockets are shown. Simulation state items can be added
by linking one of the empty sockets to something else. In the sidebar, there
is a new panel that allows adding, removing and reordering these sockets.
The simulation nodes behave as follows:
* On the first frame, the inputs of the `Simulation Input` node are evaluated
to initialize the simulation state. In later frames these sockets are not
evaluated anymore. The `Delta Time` at the first frame is zero, but the
simulation zone is still evaluated.
* On every next frame, the `Simulation Input` node outputs the simulation
state of the previous frame. Nodes in the simulation zone can edit that
data in arbitrary ways, also taking into account the `Delta Time`. The new
simulation state has to be passed to the `Simulation Output` node where it
is cached and forwarded.
* On a frame that is already cached or baked, the nodes in the simulation
zone are not evaluated, because the `Simulation Output` node can return
the previously cached data directly.
It is not allowed to connect sockets from inside the simulation zone to the
outside without going through the `Simulation Output` node. This is a necessary
restriction to make caching and sub-frame interpolation work. Links can go into
the simulation zone without problems though.
Anonymous attributes are not propagated by the simulation nodes unless they
are explicitly stored in the simulation state. This is unfortunate, but
currently there is no practical and reliable alternative. The core problem
is detecting which anonymous attributes will be required for the simulation
and afterwards. While we can detect this for the current evaluation, we can't
look into the future in time to see what data will be necessary. We intend to
make it easier to explicitly pass data through a simulation in the future,
even if the simulation is in a nested node group.
There is a new `Simulation Nodes` panel in the physics tab in the properties
editor. It allows baking all simulation zones on the selected objects. The
baking options are intentially kept at a minimum for this MVP. More features
for simulation baking as well as baking in general can be expected to be added
separately.
All baked data is stored on disk in a folder next to the .blend file. #106937
describes how baking is implemented in more detail. Volumes can not be baked
yet and materials are lost during baking for now. Packing the baked data into
the .blend file is not yet supported.
The timeline indicates which frames are currently cached, baked or cached but
invalidated by user-changes.
Simulation input and output nodes are internally linked together by their
`bNode.identifier` which stays the same even if the node name changes. They
are generally added and removed together. However, there are still cases where
"dangling" simulation nodes can be created currently. Those generally don't
cause harm, but would be nice to avoid this in more cases in the future.
Co-authored-by: Hans Goudey <h.goudey@me.com>
Co-authored-by: Lukas Tönne <lukas@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/104924
2023-05-03 13:18:51 +02:00
|
|
|
from mathutils import (
|
|
|
|
|
Vector,
|
|
|
|
|
)
|
2012-12-12 12:50:43 +00:00
|
|
|
|
2022-07-18 15:09:37 +02:00
|
|
|
from bpy.app.translations import pgettext_tip as tip_
|
|
|
|
|
|
2013-01-15 23:15:32 +00:00
|
|
|
|
2013-05-08 15:40:53 +00:00
|
|
|
class NodeSetting(PropertyGroup):
|
2018-07-11 22:18:09 +02:00
|
|
|
value: StringProperty(
|
2018-06-26 19:41:37 +02:00
|
|
|
name="Value",
|
|
|
|
|
description="Python expression to be evaluated "
|
|
|
|
|
"as the initial node setting",
|
|
|
|
|
default="",
|
|
|
|
|
)
|
2013-05-08 15:40:53 +00:00
|
|
|
|
2013-06-27 03:05:19 +00:00
|
|
|
|
2023-04-18 10:42:00 +10:00
|
|
|
# Base class for node "Add" operators.
|
2015-01-29 15:35:06 +11:00
|
|
|
class NodeAddOperator:
|
2013-05-08 15:40:53 +00:00
|
|
|
|
2018-07-11 22:18:09 +02:00
|
|
|
use_transform: BoolProperty(
|
2018-06-26 19:41:37 +02:00
|
|
|
name="Use Transform",
|
|
|
|
|
description="Start transform operator after inserting the node",
|
|
|
|
|
default=False,
|
|
|
|
|
)
|
2018-07-11 22:18:09 +02:00
|
|
|
settings: CollectionProperty(
|
2018-06-26 19:41:37 +02:00
|
|
|
name="Settings",
|
|
|
|
|
description="Settings to be applied on the newly created node",
|
|
|
|
|
type=NodeSetting,
|
|
|
|
|
options={'SKIP_SAVE'},
|
|
|
|
|
)
|
2013-05-08 15:40:53 +00:00
|
|
|
|
2012-12-12 12:50:43 +00:00
|
|
|
@staticmethod
|
|
|
|
|
def store_mouse_cursor(context, event):
|
|
|
|
|
space = context.space_data
|
2013-04-04 15:10:52 +00:00
|
|
|
tree = space.edit_tree
|
2012-12-12 12:50:43 +00:00
|
|
|
|
|
|
|
|
# convert mouse position to the View2D for later node placement
|
2013-04-04 15:10:52 +00:00
|
|
|
if context.region.type == 'WINDOW':
|
2013-09-05 13:03:03 +00:00
|
|
|
# convert mouse position to the View2D for later node placement
|
2016-03-23 04:25:08 +11:00
|
|
|
space.cursor_location_from_region(
|
2018-06-26 19:41:37 +02:00
|
|
|
event.mouse_region_x, event.mouse_region_y)
|
2013-04-04 15:10:52 +00:00
|
|
|
else:
|
|
|
|
|
space.cursor_location = tree.view_center
|
2012-12-12 12:50:43 +00:00
|
|
|
|
Geometry Nodes: add simulation support
This adds support for building simulations with geometry nodes. A new
`Simulation Input` and `Simulation Output` node allow maintaining a
simulation state across multiple frames. Together these two nodes form
a `simulation zone` which contains all the nodes that update the simulation
state from one frame to the next.
A new simulation zone can be added via the menu
(`Simulation > Simulation Zone`) or with the node add search.
The simulation state contains a geometry by default. However, it is possible
to add multiple geometry sockets as well as other socket types. Currently,
field inputs are evaluated and stored for the preceding geometry socket in
the order that the sockets are shown. Simulation state items can be added
by linking one of the empty sockets to something else. In the sidebar, there
is a new panel that allows adding, removing and reordering these sockets.
The simulation nodes behave as follows:
* On the first frame, the inputs of the `Simulation Input` node are evaluated
to initialize the simulation state. In later frames these sockets are not
evaluated anymore. The `Delta Time` at the first frame is zero, but the
simulation zone is still evaluated.
* On every next frame, the `Simulation Input` node outputs the simulation
state of the previous frame. Nodes in the simulation zone can edit that
data in arbitrary ways, also taking into account the `Delta Time`. The new
simulation state has to be passed to the `Simulation Output` node where it
is cached and forwarded.
* On a frame that is already cached or baked, the nodes in the simulation
zone are not evaluated, because the `Simulation Output` node can return
the previously cached data directly.
It is not allowed to connect sockets from inside the simulation zone to the
outside without going through the `Simulation Output` node. This is a necessary
restriction to make caching and sub-frame interpolation work. Links can go into
the simulation zone without problems though.
Anonymous attributes are not propagated by the simulation nodes unless they
are explicitly stored in the simulation state. This is unfortunate, but
currently there is no practical and reliable alternative. The core problem
is detecting which anonymous attributes will be required for the simulation
and afterwards. While we can detect this for the current evaluation, we can't
look into the future in time to see what data will be necessary. We intend to
make it easier to explicitly pass data through a simulation in the future,
even if the simulation is in a nested node group.
There is a new `Simulation Nodes` panel in the physics tab in the properties
editor. It allows baking all simulation zones on the selected objects. The
baking options are intentially kept at a minimum for this MVP. More features
for simulation baking as well as baking in general can be expected to be added
separately.
All baked data is stored on disk in a folder next to the .blend file. #106937
describes how baking is implemented in more detail. Volumes can not be baked
yet and materials are lost during baking for now. Packing the baked data into
the .blend file is not yet supported.
The timeline indicates which frames are currently cached, baked or cached but
invalidated by user-changes.
Simulation input and output nodes are internally linked together by their
`bNode.identifier` which stays the same even if the node name changes. They
are generally added and removed together. However, there are still cases where
"dangling" simulation nodes can be created currently. Those generally don't
cause harm, but would be nice to avoid this in more cases in the future.
Co-authored-by: Hans Goudey <h.goudey@me.com>
Co-authored-by: Lukas Tönne <lukas@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/104924
2023-05-03 13:18:51 +02:00
|
|
|
# Deselect all nodes in the tree.
|
|
|
|
|
@staticmethod
|
|
|
|
|
def deselect_nodes(context):
|
2012-12-12 12:50:43 +00:00
|
|
|
space = context.space_data
|
|
|
|
|
tree = space.edit_tree
|
|
|
|
|
for n in tree.nodes:
|
2012-12-12 15:41:15 +00:00
|
|
|
n.select = False
|
|
|
|
|
|
Geometry Nodes: add simulation support
This adds support for building simulations with geometry nodes. A new
`Simulation Input` and `Simulation Output` node allow maintaining a
simulation state across multiple frames. Together these two nodes form
a `simulation zone` which contains all the nodes that update the simulation
state from one frame to the next.
A new simulation zone can be added via the menu
(`Simulation > Simulation Zone`) or with the node add search.
The simulation state contains a geometry by default. However, it is possible
to add multiple geometry sockets as well as other socket types. Currently,
field inputs are evaluated and stored for the preceding geometry socket in
the order that the sockets are shown. Simulation state items can be added
by linking one of the empty sockets to something else. In the sidebar, there
is a new panel that allows adding, removing and reordering these sockets.
The simulation nodes behave as follows:
* On the first frame, the inputs of the `Simulation Input` node are evaluated
to initialize the simulation state. In later frames these sockets are not
evaluated anymore. The `Delta Time` at the first frame is zero, but the
simulation zone is still evaluated.
* On every next frame, the `Simulation Input` node outputs the simulation
state of the previous frame. Nodes in the simulation zone can edit that
data in arbitrary ways, also taking into account the `Delta Time`. The new
simulation state has to be passed to the `Simulation Output` node where it
is cached and forwarded.
* On a frame that is already cached or baked, the nodes in the simulation
zone are not evaluated, because the `Simulation Output` node can return
the previously cached data directly.
It is not allowed to connect sockets from inside the simulation zone to the
outside without going through the `Simulation Output` node. This is a necessary
restriction to make caching and sub-frame interpolation work. Links can go into
the simulation zone without problems though.
Anonymous attributes are not propagated by the simulation nodes unless they
are explicitly stored in the simulation state. This is unfortunate, but
currently there is no practical and reliable alternative. The core problem
is detecting which anonymous attributes will be required for the simulation
and afterwards. While we can detect this for the current evaluation, we can't
look into the future in time to see what data will be necessary. We intend to
make it easier to explicitly pass data through a simulation in the future,
even if the simulation is in a nested node group.
There is a new `Simulation Nodes` panel in the physics tab in the properties
editor. It allows baking all simulation zones on the selected objects. The
baking options are intentially kept at a minimum for this MVP. More features
for simulation baking as well as baking in general can be expected to be added
separately.
All baked data is stored on disk in a folder next to the .blend file. #106937
describes how baking is implemented in more detail. Volumes can not be baked
yet and materials are lost during baking for now. Packing the baked data into
the .blend file is not yet supported.
The timeline indicates which frames are currently cached, baked or cached but
invalidated by user-changes.
Simulation input and output nodes are internally linked together by their
`bNode.identifier` which stays the same even if the node name changes. They
are generally added and removed together. However, there are still cases where
"dangling" simulation nodes can be created currently. Those generally don't
cause harm, but would be nice to avoid this in more cases in the future.
Co-authored-by: Hans Goudey <h.goudey@me.com>
Co-authored-by: Lukas Tönne <lukas@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/104924
2023-05-03 13:18:51 +02:00
|
|
|
def create_node(self, context, node_type):
|
|
|
|
|
space = context.space_data
|
|
|
|
|
tree = space.edit_tree
|
|
|
|
|
|
2022-04-07 10:31:52 +02:00
|
|
|
try:
|
|
|
|
|
node = tree.nodes.new(type=node_type)
|
2023-07-30 16:14:13 +10:00
|
|
|
except RuntimeError as ex:
|
|
|
|
|
self.report({'ERROR'}, str(ex))
|
2022-04-07 10:31:52 +02:00
|
|
|
return None
|
2013-05-08 15:40:53 +00:00
|
|
|
|
|
|
|
|
for setting in self.settings:
|
|
|
|
|
# XXX catch exceptions here?
|
|
|
|
|
value = eval(setting.value)
|
2020-06-30 18:00:03 +02:00
|
|
|
node_data = node
|
|
|
|
|
node_attr_name = setting.name
|
|
|
|
|
|
|
|
|
|
# Support path to nested data.
|
|
|
|
|
if '.' in node_attr_name:
|
|
|
|
|
node_data_path, node_attr_name = node_attr_name.rsplit(".", 1)
|
|
|
|
|
node_data = node.path_resolve(node_data_path)
|
2013-06-27 03:05:19 +00:00
|
|
|
|
2013-05-08 15:40:53 +00:00
|
|
|
try:
|
2020-06-30 18:00:03 +02:00
|
|
|
setattr(node_data, node_attr_name, value)
|
2023-07-30 16:14:13 +10:00
|
|
|
except AttributeError as ex:
|
2016-03-23 04:25:08 +11:00
|
|
|
self.report(
|
2018-06-26 19:41:37 +02:00
|
|
|
{'ERROR_INVALID_INPUT'},
|
2023-05-07 12:25:34 +02:00
|
|
|
tip_("Node has no attribute %s") % setting.name)
|
2023-07-30 16:14:13 +10:00
|
|
|
print(str(ex))
|
2013-05-08 15:40:53 +00:00
|
|
|
# Continue despite invalid attribute
|
2012-12-12 15:41:15 +00:00
|
|
|
|
|
|
|
|
node.select = True
|
2012-12-12 12:50:43 +00:00
|
|
|
tree.nodes.active = node
|
|
|
|
|
node.location = space.cursor_location
|
|
|
|
|
return node
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def poll(cls, context):
|
|
|
|
|
space = context.space_data
|
|
|
|
|
# needs active node editor and a tree to add nodes to
|
2021-05-18 20:00:51 +10:00
|
|
|
return (space and (space.type == 'NODE_EDITOR') and
|
2016-03-23 04:25:08 +11:00
|
|
|
space.edit_tree and not space.edit_tree.library)
|
2012-12-12 12:50:43 +00:00
|
|
|
|
|
|
|
|
# Default invoke stores the mouse position to place the node correctly
|
2013-05-08 15:40:53 +00:00
|
|
|
# and optionally invokes the transform operator
|
2012-12-12 12:50:43 +00:00
|
|
|
def invoke(self, context, event):
|
|
|
|
|
self.store_mouse_cursor(context, event)
|
2013-05-08 15:40:53 +00:00
|
|
|
result = self.execute(context)
|
2012-12-12 12:50:43 +00:00
|
|
|
|
2013-05-08 15:40:53 +00:00
|
|
|
if self.use_transform and ('FINISHED' in result):
|
2015-02-27 15:41:50 +11:00
|
|
|
# removes the node again if transform is canceled
|
2015-08-01 17:39:48 +02:00
|
|
|
bpy.ops.node.translate_attach_remove_on_cancel('INVOKE_DEFAULT')
|
2013-05-08 15:40:53 +00:00
|
|
|
|
|
|
|
|
return result
|
2012-12-12 12:50:43 +00:00
|
|
|
|
Geometry Nodes: add simulation support
This adds support for building simulations with geometry nodes. A new
`Simulation Input` and `Simulation Output` node allow maintaining a
simulation state across multiple frames. Together these two nodes form
a `simulation zone` which contains all the nodes that update the simulation
state from one frame to the next.
A new simulation zone can be added via the menu
(`Simulation > Simulation Zone`) or with the node add search.
The simulation state contains a geometry by default. However, it is possible
to add multiple geometry sockets as well as other socket types. Currently,
field inputs are evaluated and stored for the preceding geometry socket in
the order that the sockets are shown. Simulation state items can be added
by linking one of the empty sockets to something else. In the sidebar, there
is a new panel that allows adding, removing and reordering these sockets.
The simulation nodes behave as follows:
* On the first frame, the inputs of the `Simulation Input` node are evaluated
to initialize the simulation state. In later frames these sockets are not
evaluated anymore. The `Delta Time` at the first frame is zero, but the
simulation zone is still evaluated.
* On every next frame, the `Simulation Input` node outputs the simulation
state of the previous frame. Nodes in the simulation zone can edit that
data in arbitrary ways, also taking into account the `Delta Time`. The new
simulation state has to be passed to the `Simulation Output` node where it
is cached and forwarded.
* On a frame that is already cached or baked, the nodes in the simulation
zone are not evaluated, because the `Simulation Output` node can return
the previously cached data directly.
It is not allowed to connect sockets from inside the simulation zone to the
outside without going through the `Simulation Output` node. This is a necessary
restriction to make caching and sub-frame interpolation work. Links can go into
the simulation zone without problems though.
Anonymous attributes are not propagated by the simulation nodes unless they
are explicitly stored in the simulation state. This is unfortunate, but
currently there is no practical and reliable alternative. The core problem
is detecting which anonymous attributes will be required for the simulation
and afterwards. While we can detect this for the current evaluation, we can't
look into the future in time to see what data will be necessary. We intend to
make it easier to explicitly pass data through a simulation in the future,
even if the simulation is in a nested node group.
There is a new `Simulation Nodes` panel in the physics tab in the properties
editor. It allows baking all simulation zones on the selected objects. The
baking options are intentially kept at a minimum for this MVP. More features
for simulation baking as well as baking in general can be expected to be added
separately.
All baked data is stored on disk in a folder next to the .blend file. #106937
describes how baking is implemented in more detail. Volumes can not be baked
yet and materials are lost during baking for now. Packing the baked data into
the .blend file is not yet supported.
The timeline indicates which frames are currently cached, baked or cached but
invalidated by user-changes.
Simulation input and output nodes are internally linked together by their
`bNode.identifier` which stays the same even if the node name changes. They
are generally added and removed together. However, there are still cases where
"dangling" simulation nodes can be created currently. Those generally don't
cause harm, but would be nice to avoid this in more cases in the future.
Co-authored-by: Hans Goudey <h.goudey@me.com>
Co-authored-by: Lukas Tönne <lukas@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/104924
2023-05-03 13:18:51 +02:00
|
|
|
|
|
|
|
|
# Simple basic operator for adding a node.
|
|
|
|
|
class NODE_OT_add_node(NodeAddOperator, Operator):
|
|
|
|
|
"""Add a node to the active tree"""
|
|
|
|
|
bl_idname = "node.add_node"
|
|
|
|
|
bl_label = "Add Node"
|
|
|
|
|
bl_options = {'REGISTER', 'UNDO'}
|
|
|
|
|
|
|
|
|
|
type: StringProperty(
|
|
|
|
|
name="Node Type",
|
|
|
|
|
description="Node type",
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
# Default execute simply adds a node.
|
|
|
|
|
def execute(self, context):
|
|
|
|
|
if self.properties.is_property_set("type"):
|
|
|
|
|
self.deselect_nodes(context)
|
|
|
|
|
self.create_node(context, self.type)
|
|
|
|
|
return {'FINISHED'}
|
|
|
|
|
else:
|
|
|
|
|
return {'CANCELLED'}
|
|
|
|
|
|
2022-06-07 15:40:20 +02:00
|
|
|
@classmethod
|
2022-06-14 14:30:09 +10:00
|
|
|
def description(cls, _context, properties):
|
2022-06-07 15:40:20 +02:00
|
|
|
nodetype = properties["type"]
|
|
|
|
|
bl_rna = bpy.types.Node.bl_rna_get_subclass(nodetype)
|
|
|
|
|
if bl_rna is not None:
|
2022-07-18 15:09:37 +02:00
|
|
|
return tip_(bl_rna.description)
|
2022-06-07 15:40:20 +02:00
|
|
|
else:
|
|
|
|
|
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
|
|
|
|
2023-07-11 22:36:10 +02:00
|
|
|
class NodeAddZoneOperator(NodeAddOperator):
|
Geometry Nodes: add simulation support
This adds support for building simulations with geometry nodes. A new
`Simulation Input` and `Simulation Output` node allow maintaining a
simulation state across multiple frames. Together these two nodes form
a `simulation zone` which contains all the nodes that update the simulation
state from one frame to the next.
A new simulation zone can be added via the menu
(`Simulation > Simulation Zone`) or with the node add search.
The simulation state contains a geometry by default. However, it is possible
to add multiple geometry sockets as well as other socket types. Currently,
field inputs are evaluated and stored for the preceding geometry socket in
the order that the sockets are shown. Simulation state items can be added
by linking one of the empty sockets to something else. In the sidebar, there
is a new panel that allows adding, removing and reordering these sockets.
The simulation nodes behave as follows:
* On the first frame, the inputs of the `Simulation Input` node are evaluated
to initialize the simulation state. In later frames these sockets are not
evaluated anymore. The `Delta Time` at the first frame is zero, but the
simulation zone is still evaluated.
* On every next frame, the `Simulation Input` node outputs the simulation
state of the previous frame. Nodes in the simulation zone can edit that
data in arbitrary ways, also taking into account the `Delta Time`. The new
simulation state has to be passed to the `Simulation Output` node where it
is cached and forwarded.
* On a frame that is already cached or baked, the nodes in the simulation
zone are not evaluated, because the `Simulation Output` node can return
the previously cached data directly.
It is not allowed to connect sockets from inside the simulation zone to the
outside without going through the `Simulation Output` node. This is a necessary
restriction to make caching and sub-frame interpolation work. Links can go into
the simulation zone without problems though.
Anonymous attributes are not propagated by the simulation nodes unless they
are explicitly stored in the simulation state. This is unfortunate, but
currently there is no practical and reliable alternative. The core problem
is detecting which anonymous attributes will be required for the simulation
and afterwards. While we can detect this for the current evaluation, we can't
look into the future in time to see what data will be necessary. We intend to
make it easier to explicitly pass data through a simulation in the future,
even if the simulation is in a nested node group.
There is a new `Simulation Nodes` panel in the physics tab in the properties
editor. It allows baking all simulation zones on the selected objects. The
baking options are intentially kept at a minimum for this MVP. More features
for simulation baking as well as baking in general can be expected to be added
separately.
All baked data is stored on disk in a folder next to the .blend file. #106937
describes how baking is implemented in more detail. Volumes can not be baked
yet and materials are lost during baking for now. Packing the baked data into
the .blend file is not yet supported.
The timeline indicates which frames are currently cached, baked or cached but
invalidated by user-changes.
Simulation input and output nodes are internally linked together by their
`bNode.identifier` which stays the same even if the node name changes. They
are generally added and removed together. However, there are still cases where
"dangling" simulation nodes can be created currently. Those generally don't
cause harm, but would be nice to avoid this in more cases in the future.
Co-authored-by: Hans Goudey <h.goudey@me.com>
Co-authored-by: Lukas Tönne <lukas@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/104924
2023-05-03 13:18:51 +02:00
|
|
|
offset: FloatVectorProperty(
|
|
|
|
|
name="Offset",
|
|
|
|
|
description="Offset of nodes from the cursor when added",
|
|
|
|
|
size=2,
|
|
|
|
|
default=(150, 0),
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
def execute(self, context):
|
|
|
|
|
space = context.space_data
|
|
|
|
|
tree = space.edit_tree
|
|
|
|
|
|
|
|
|
|
props = self.properties
|
|
|
|
|
|
|
|
|
|
self.deselect_nodes(context)
|
|
|
|
|
input_node = self.create_node(context, self.input_node_type)
|
|
|
|
|
output_node = self.create_node(context, self.output_node_type)
|
|
|
|
|
if input_node is None or output_node is None:
|
|
|
|
|
return {'CANCELLED'}
|
|
|
|
|
|
|
|
|
|
# Simulation input must be paired with the output.
|
|
|
|
|
input_node.pair_with_output(output_node)
|
|
|
|
|
|
|
|
|
|
input_node.location -= Vector(self.offset)
|
|
|
|
|
output_node.location += Vector(self.offset)
|
|
|
|
|
|
|
|
|
|
# Connect geometry sockets by default.
|
2023-05-15 15:38:35 +02:00
|
|
|
# Get the sockets by their types, because the name is not guaranteed due to i18n.
|
|
|
|
|
from_socket = next(s for s in input_node.outputs if s.type == 'GEOMETRY')
|
|
|
|
|
to_socket = next(s for s in output_node.inputs if s.type == 'GEOMETRY')
|
Geometry Nodes: add simulation support
This adds support for building simulations with geometry nodes. A new
`Simulation Input` and `Simulation Output` node allow maintaining a
simulation state across multiple frames. Together these two nodes form
a `simulation zone` which contains all the nodes that update the simulation
state from one frame to the next.
A new simulation zone can be added via the menu
(`Simulation > Simulation Zone`) or with the node add search.
The simulation state contains a geometry by default. However, it is possible
to add multiple geometry sockets as well as other socket types. Currently,
field inputs are evaluated and stored for the preceding geometry socket in
the order that the sockets are shown. Simulation state items can be added
by linking one of the empty sockets to something else. In the sidebar, there
is a new panel that allows adding, removing and reordering these sockets.
The simulation nodes behave as follows:
* On the first frame, the inputs of the `Simulation Input` node are evaluated
to initialize the simulation state. In later frames these sockets are not
evaluated anymore. The `Delta Time` at the first frame is zero, but the
simulation zone is still evaluated.
* On every next frame, the `Simulation Input` node outputs the simulation
state of the previous frame. Nodes in the simulation zone can edit that
data in arbitrary ways, also taking into account the `Delta Time`. The new
simulation state has to be passed to the `Simulation Output` node where it
is cached and forwarded.
* On a frame that is already cached or baked, the nodes in the simulation
zone are not evaluated, because the `Simulation Output` node can return
the previously cached data directly.
It is not allowed to connect sockets from inside the simulation zone to the
outside without going through the `Simulation Output` node. This is a necessary
restriction to make caching and sub-frame interpolation work. Links can go into
the simulation zone without problems though.
Anonymous attributes are not propagated by the simulation nodes unless they
are explicitly stored in the simulation state. This is unfortunate, but
currently there is no practical and reliable alternative. The core problem
is detecting which anonymous attributes will be required for the simulation
and afterwards. While we can detect this for the current evaluation, we can't
look into the future in time to see what data will be necessary. We intend to
make it easier to explicitly pass data through a simulation in the future,
even if the simulation is in a nested node group.
There is a new `Simulation Nodes` panel in the physics tab in the properties
editor. It allows baking all simulation zones on the selected objects. The
baking options are intentially kept at a minimum for this MVP. More features
for simulation baking as well as baking in general can be expected to be added
separately.
All baked data is stored on disk in a folder next to the .blend file. #106937
describes how baking is implemented in more detail. Volumes can not be baked
yet and materials are lost during baking for now. Packing the baked data into
the .blend file is not yet supported.
The timeline indicates which frames are currently cached, baked or cached but
invalidated by user-changes.
Simulation input and output nodes are internally linked together by their
`bNode.identifier` which stays the same even if the node name changes. They
are generally added and removed together. However, there are still cases where
"dangling" simulation nodes can be created currently. Those generally don't
cause harm, but would be nice to avoid this in more cases in the future.
Co-authored-by: Hans Goudey <h.goudey@me.com>
Co-authored-by: Lukas Tönne <lukas@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/104924
2023-05-03 13:18:51 +02:00
|
|
|
tree.links.new(to_socket, from_socket)
|
|
|
|
|
|
|
|
|
|
return {'FINISHED'}
|
|
|
|
|
|
2023-07-12 11:55:18 +02:00
|
|
|
|
2023-07-11 22:36:10 +02:00
|
|
|
class NODE_OT_add_simulation_zone(NodeAddZoneOperator, Operator):
|
|
|
|
|
"""Add simulation zone input and output nodes to the active tree"""
|
|
|
|
|
bl_idname = "node.add_simulation_zone"
|
|
|
|
|
bl_label = "Add Simulation Zone"
|
|
|
|
|
bl_options = {'REGISTER', 'UNDO'}
|
|
|
|
|
|
|
|
|
|
input_node_type = "GeometryNodeSimulationInput"
|
|
|
|
|
output_node_type = "GeometryNodeSimulationOutput"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
class NODE_OT_add_repeat_zone(NodeAddZoneOperator, Operator):
|
|
|
|
|
"""Add a repeat zone that allows executing nodes a dynamic number of times"""
|
|
|
|
|
bl_idname = "node.add_repeat_zone"
|
|
|
|
|
bl_label = "Add Repeat Zone"
|
|
|
|
|
bl_options = {'REGISTER', 'UNDO'}
|
|
|
|
|
|
|
|
|
|
input_node_type = "GeometryNodeRepeatInput"
|
|
|
|
|
output_node_type = "GeometryNodeRepeatOutput"
|
|
|
|
|
|
|
|
|
|
|
2012-08-14 17:56:33 +00:00
|
|
|
class NODE_OT_collapse_hide_unused_toggle(Operator):
|
2023-04-18 10:42:00 +10:00
|
|
|
"""Toggle collapsed nodes and hide unused sockets"""
|
2012-08-14 17:56:33 +00:00
|
|
|
bl_idname = "node.collapse_hide_unused_toggle"
|
|
|
|
|
bl_label = "Collapse and Hide Unused Sockets"
|
|
|
|
|
bl_options = {'REGISTER', 'UNDO'}
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def poll(cls, context):
|
|
|
|
|
space = context.space_data
|
|
|
|
|
# needs active node editor and a tree
|
2021-05-18 20:00:51 +10:00
|
|
|
return (space and (space.type == 'NODE_EDITOR') and
|
2016-03-23 04:25:08 +11:00
|
|
|
(space.edit_tree and not space.edit_tree.library))
|
2012-08-14 17:56:33 +00:00
|
|
|
|
|
|
|
|
def execute(self, context):
|
|
|
|
|
space = context.space_data
|
|
|
|
|
tree = space.edit_tree
|
|
|
|
|
|
|
|
|
|
for node in tree.nodes:
|
|
|
|
|
if node.select:
|
2012-08-14 18:43:15 +00:00
|
|
|
hide = (not node.hide)
|
|
|
|
|
|
2012-08-14 17:56:33 +00:00
|
|
|
node.hide = hide
|
|
|
|
|
# Note: connected sockets are ignored internally
|
|
|
|
|
for socket in node.inputs:
|
|
|
|
|
socket.hide = hide
|
|
|
|
|
for socket in node.outputs:
|
|
|
|
|
socket.hide = hide
|
|
|
|
|
|
2012-08-14 18:43:15 +00:00
|
|
|
return {'FINISHED'}
|
2013-03-18 16:34:57 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
class NODE_OT_tree_path_parent(Operator):
|
2023-04-18 10:42:00 +10:00
|
|
|
"""Go to parent node tree"""
|
2013-03-18 16:34:57 +00:00
|
|
|
bl_idname = "node.tree_path_parent"
|
|
|
|
|
bl_label = "Parent Node Tree"
|
|
|
|
|
bl_options = {'REGISTER', 'UNDO'}
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def poll(cls, context):
|
|
|
|
|
space = context.space_data
|
|
|
|
|
# needs active node editor and a tree
|
2021-05-18 20:00:51 +10:00
|
|
|
return (space and (space.type == 'NODE_EDITOR') and len(space.path) > 1)
|
2013-03-18 16:34:57 +00:00
|
|
|
|
|
|
|
|
def execute(self, context):
|
|
|
|
|
space = context.space_data
|
|
|
|
|
|
|
|
|
|
space.path.pop()
|
|
|
|
|
|
|
|
|
|
return {'FINISHED'}
|
2017-03-18 20:03:24 +11:00
|
|
|
|
|
|
|
|
|
2023-08-30 12:37:21 +02:00
|
|
|
class NodeInterfaceOperator():
|
|
|
|
|
@classmethod
|
|
|
|
|
def poll(cls, context):
|
|
|
|
|
space = context.space_data
|
|
|
|
|
if not space or space.type != 'NODE_EDITOR' or not space.edit_tree:
|
|
|
|
|
return False
|
|
|
|
|
if space.edit_tree.is_embedded_data:
|
|
|
|
|
return False
|
|
|
|
|
return True
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
class NODE_OT_interface_item_new(NodeInterfaceOperator, Operator):
|
|
|
|
|
'''Add a new item to the interface'''
|
|
|
|
|
bl_idname = "node.interface_item_new"
|
|
|
|
|
bl_label = "New Item"
|
|
|
|
|
bl_options = {'REGISTER', 'UNDO'}
|
|
|
|
|
|
|
|
|
|
item_type: EnumProperty(
|
|
|
|
|
name="Item Type",
|
|
|
|
|
description="Type of the item to create",
|
|
|
|
|
items=[
|
|
|
|
|
('INPUT', "Input", ""),
|
|
|
|
|
('OUTPUT', "Output", ""),
|
|
|
|
|
('PANEL', "Panel", "")],
|
|
|
|
|
default='INPUT',
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
socket_type = 'NodeSocketFloat'
|
|
|
|
|
|
|
|
|
|
def execute(self, context):
|
|
|
|
|
snode = context.space_data
|
|
|
|
|
tree = snode.edit_tree
|
|
|
|
|
interface = tree.interface
|
|
|
|
|
|
|
|
|
|
# Remember active item and position to determine target position.
|
|
|
|
|
active_item = interface.active
|
|
|
|
|
active_pos = active_item.position if active_item else -1
|
|
|
|
|
|
|
|
|
|
if self.item_type == 'INPUT':
|
2023-09-18 11:01:05 -04:00
|
|
|
item = interface.new_socket("Socket", socket_type=self.socket_type, in_out='INPUT')
|
2023-08-30 12:37:21 +02:00
|
|
|
elif self.item_type == 'OUTPUT':
|
2023-09-18 11:01:05 -04:00
|
|
|
item = interface.new_socket("Socket", socket_type=self.socket_type, in_out='OUTPUT')
|
2023-08-30 12:37:21 +02:00
|
|
|
elif self.item_type == 'PANEL':
|
|
|
|
|
item = interface.new_panel("Panel")
|
|
|
|
|
else:
|
|
|
|
|
return {'CANCELLED'}
|
|
|
|
|
|
|
|
|
|
if active_item:
|
|
|
|
|
# Insert into active panel if possible, otherwise insert after active item.
|
|
|
|
|
if active_item.item_type == 'PANEL' and item.item_type != 'PANEL':
|
|
|
|
|
interface.move_to_parent(item, active_item, len(active_item.interface_items))
|
|
|
|
|
else:
|
|
|
|
|
interface.move_to_parent(item, active_item.parent, active_pos + 1)
|
|
|
|
|
interface.active = item
|
|
|
|
|
|
|
|
|
|
return {'FINISHED'}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
class NODE_OT_interface_item_duplicate(NodeInterfaceOperator, Operator):
|
|
|
|
|
'''Add a copy of the active item to the interface'''
|
|
|
|
|
bl_idname = "node.interface_item_duplicate"
|
|
|
|
|
bl_label = "Duplicate Item"
|
|
|
|
|
bl_options = {'REGISTER', 'UNDO'}
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def poll(cls, context):
|
|
|
|
|
if not super().poll(context):
|
|
|
|
|
return False
|
|
|
|
|
|
|
|
|
|
snode = context.space_data
|
|
|
|
|
tree = snode.edit_tree
|
|
|
|
|
interface = tree.interface
|
|
|
|
|
return interface.active is not None
|
|
|
|
|
|
|
|
|
|
def execute(self, context):
|
|
|
|
|
snode = context.space_data
|
|
|
|
|
tree = snode.edit_tree
|
|
|
|
|
interface = tree.interface
|
|
|
|
|
item = interface.active
|
|
|
|
|
|
|
|
|
|
if item:
|
|
|
|
|
item_copy = interface.copy(item)
|
|
|
|
|
interface.active = item_copy
|
|
|
|
|
|
|
|
|
|
return {'FINISHED'}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
class NODE_OT_interface_item_remove(NodeInterfaceOperator, Operator):
|
|
|
|
|
'''Remove active item from the interface'''
|
|
|
|
|
bl_idname = "node.interface_item_remove"
|
|
|
|
|
bl_label = "Remove Item"
|
|
|
|
|
bl_options = {'REGISTER', 'UNDO'}
|
|
|
|
|
|
|
|
|
|
def execute(self, context):
|
|
|
|
|
snode = context.space_data
|
|
|
|
|
tree = snode.edit_tree
|
|
|
|
|
interface = tree.interface
|
|
|
|
|
item = interface.active
|
|
|
|
|
|
|
|
|
|
if item:
|
|
|
|
|
interface.remove(item)
|
2023-09-18 18:07:26 +02:00
|
|
|
interface.active_index = min(interface.active_index, len(interface.items_tree) - 1)
|
2023-08-30 12:37:21 +02:00
|
|
|
|
|
|
|
|
return {'FINISHED'}
|
|
|
|
|
|
|
|
|
|
|
2017-03-18 20:03:24 +11:00
|
|
|
classes = (
|
|
|
|
|
NodeSetting,
|
|
|
|
|
|
|
|
|
|
NODE_OT_add_node,
|
Geometry Nodes: add simulation support
This adds support for building simulations with geometry nodes. A new
`Simulation Input` and `Simulation Output` node allow maintaining a
simulation state across multiple frames. Together these two nodes form
a `simulation zone` which contains all the nodes that update the simulation
state from one frame to the next.
A new simulation zone can be added via the menu
(`Simulation > Simulation Zone`) or with the node add search.
The simulation state contains a geometry by default. However, it is possible
to add multiple geometry sockets as well as other socket types. Currently,
field inputs are evaluated and stored for the preceding geometry socket in
the order that the sockets are shown. Simulation state items can be added
by linking one of the empty sockets to something else. In the sidebar, there
is a new panel that allows adding, removing and reordering these sockets.
The simulation nodes behave as follows:
* On the first frame, the inputs of the `Simulation Input` node are evaluated
to initialize the simulation state. In later frames these sockets are not
evaluated anymore. The `Delta Time` at the first frame is zero, but the
simulation zone is still evaluated.
* On every next frame, the `Simulation Input` node outputs the simulation
state of the previous frame. Nodes in the simulation zone can edit that
data in arbitrary ways, also taking into account the `Delta Time`. The new
simulation state has to be passed to the `Simulation Output` node where it
is cached and forwarded.
* On a frame that is already cached or baked, the nodes in the simulation
zone are not evaluated, because the `Simulation Output` node can return
the previously cached data directly.
It is not allowed to connect sockets from inside the simulation zone to the
outside without going through the `Simulation Output` node. This is a necessary
restriction to make caching and sub-frame interpolation work. Links can go into
the simulation zone without problems though.
Anonymous attributes are not propagated by the simulation nodes unless they
are explicitly stored in the simulation state. This is unfortunate, but
currently there is no practical and reliable alternative. The core problem
is detecting which anonymous attributes will be required for the simulation
and afterwards. While we can detect this for the current evaluation, we can't
look into the future in time to see what data will be necessary. We intend to
make it easier to explicitly pass data through a simulation in the future,
even if the simulation is in a nested node group.
There is a new `Simulation Nodes` panel in the physics tab in the properties
editor. It allows baking all simulation zones on the selected objects. The
baking options are intentially kept at a minimum for this MVP. More features
for simulation baking as well as baking in general can be expected to be added
separately.
All baked data is stored on disk in a folder next to the .blend file. #106937
describes how baking is implemented in more detail. Volumes can not be baked
yet and materials are lost during baking for now. Packing the baked data into
the .blend file is not yet supported.
The timeline indicates which frames are currently cached, baked or cached but
invalidated by user-changes.
Simulation input and output nodes are internally linked together by their
`bNode.identifier` which stays the same even if the node name changes. They
are generally added and removed together. However, there are still cases where
"dangling" simulation nodes can be created currently. Those generally don't
cause harm, but would be nice to avoid this in more cases in the future.
Co-authored-by: Hans Goudey <h.goudey@me.com>
Co-authored-by: Lukas Tönne <lukas@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/104924
2023-05-03 13:18:51 +02:00
|
|
|
NODE_OT_add_simulation_zone,
|
2023-07-11 22:36:10 +02:00
|
|
|
NODE_OT_add_repeat_zone,
|
2017-03-18 20:03:24 +11:00
|
|
|
NODE_OT_collapse_hide_unused_toggle,
|
2023-08-30 12:37:21 +02:00
|
|
|
NODE_OT_interface_item_new,
|
|
|
|
|
NODE_OT_interface_item_duplicate,
|
|
|
|
|
NODE_OT_interface_item_remove,
|
2017-03-18 20:03:24 +11:00
|
|
|
NODE_OT_tree_path_parent,
|
|
|
|
|
)
|