2023-08-16 00:20:26 +10:00
|
|
|
# SPDX-FileCopyrightText: 2020-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
|
2020-12-02 13:25:25 +01:00
|
|
|
|
|
|
|
|
import bpy
|
2021-03-23 16:08:02 +11:00
|
|
|
from bpy.types import Operator
|
2020-12-02 13:25:25 +01:00
|
|
|
|
2022-08-04 16:13:18 +02:00
|
|
|
from bpy.app.translations import pgettext_data as data_
|
|
|
|
|
|
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 bpy.props import (
|
|
|
|
|
EnumProperty,
|
|
|
|
|
)
|
|
|
|
|
|
2020-12-16 18:02:40 +11:00
|
|
|
|
2023-09-23 20:32:21 -04:00
|
|
|
def add_empty_geometry_node_group(name):
|
2023-02-14 18:21:50 +01:00
|
|
|
group = bpy.data.node_groups.new(name, 'GeometryNodeTree')
|
2023-09-23 20:32:21 -04:00
|
|
|
|
2023-09-18 11:01:05 -04:00
|
|
|
group.interface.new_socket(data_("Geometry"), in_out='INPUT', socket_type='NodeSocketGeometry')
|
2020-12-01 21:35:26 +01:00
|
|
|
input_node = group.nodes.new('NodeGroupInput')
|
2023-09-23 20:32:21 -04:00
|
|
|
input_node.select = False
|
|
|
|
|
input_node.location.x = -200 - input_node.width
|
|
|
|
|
|
|
|
|
|
group.interface.new_socket(data_("Geometry"), in_out='OUTPUT', socket_type='NodeSocketGeometry')
|
2020-12-01 21:35:26 +01:00
|
|
|
output_node = group.nodes.new('NodeGroupOutput')
|
|
|
|
|
output_node.is_active_output = True
|
2021-01-08 16:28:53 -06:00
|
|
|
output_node.select = False
|
2020-12-01 21:35:26 +01:00
|
|
|
output_node.location.x = 200
|
|
|
|
|
|
2023-02-14 18:21:50 +01:00
|
|
|
return group
|
|
|
|
|
|
2020-12-01 21:35:26 +01:00
|
|
|
|
2023-09-23 20:32:21 -04:00
|
|
|
def geometry_node_group_empty_new(name):
|
|
|
|
|
group = add_empty_geometry_node_group(name)
|
2023-02-17 16:42:27 +01:00
|
|
|
group.links.new(group.nodes[data_("Group Input")].outputs[0], group.nodes[data_("Group Output")].inputs[0])
|
2020-12-01 21:35:26 +01:00
|
|
|
return group
|
2020-12-02 13:25:25 +01:00
|
|
|
|
2020-12-16 18:02:40 +11:00
|
|
|
|
2023-09-23 20:32:21 -04:00
|
|
|
def geometry_node_group_empty_modifier_new(name):
|
2023-09-24 18:58:08 -04:00
|
|
|
group = geometry_node_group_empty_new(data_("Geometry Nodes"))
|
2023-09-23 20:32:21 -04:00
|
|
|
group.is_modifier = True
|
|
|
|
|
return group
|
|
|
|
|
|
|
|
|
|
|
2023-09-07 19:46:40 +02:00
|
|
|
def geometry_node_group_empty_tool_new(context):
|
2023-09-23 20:32:21 -04:00
|
|
|
group = geometry_node_group_empty_new(data_("Tool"))
|
2023-09-26 16:12:33 -04:00
|
|
|
# Node tools have fake users by default, otherwise Blender will delete them since they have no users.
|
|
|
|
|
group.use_fake_user = True
|
2023-09-07 19:46:40 +02:00
|
|
|
group.is_tool = True
|
|
|
|
|
|
|
|
|
|
ob_type = context.object.type if context.object else 'MESH'
|
|
|
|
|
if ob_type == 'CURVES':
|
|
|
|
|
group.is_type_curve = True
|
|
|
|
|
elif ob_type == 'POINTCLOUD':
|
|
|
|
|
group.is_type_point_cloud = True
|
|
|
|
|
else:
|
|
|
|
|
group.is_type_mesh = True
|
|
|
|
|
|
|
|
|
|
mode = context.object.mode if context.object else 'EDIT'
|
|
|
|
|
if mode in {'SCULPT', 'SCULPT_CURVES'}:
|
|
|
|
|
group.is_mode_sculpt = True
|
|
|
|
|
else:
|
|
|
|
|
group.is_mode_edit = True
|
|
|
|
|
|
|
|
|
|
return group
|
|
|
|
|
|
|
|
|
|
|
2021-03-10 15:36:23 +11:00
|
|
|
def geometry_modifier_poll(context):
|
2020-12-02 13:25:25 +01:00
|
|
|
ob = context.object
|
|
|
|
|
|
2022-04-15 09:07:00 +02:00
|
|
|
# Test object support for geometry node modifier
|
2023-10-10 16:49:30 +02:00
|
|
|
if not ob or ob.type not in {'MESH', 'POINTCLOUD', 'VOLUME', 'CURVE', 'FONT', 'CURVES', 'GREASEPENCIL'}:
|
2020-12-02 13:25:25 +01:00
|
|
|
return False
|
|
|
|
|
|
|
|
|
|
return True
|
|
|
|
|
|
2020-12-16 18:02:40 +11:00
|
|
|
|
2023-02-14 18:21:50 +01:00
|
|
|
def get_context_modifier(context):
|
2023-06-13 14:33:15 +10:00
|
|
|
# Context only has a "modifier" attribute in the modifier extra operators drop-down.
|
|
|
|
|
modifier = getattr(context, "modifier", ...)
|
|
|
|
|
if modifier is ...:
|
2023-04-28 16:36:15 +10:00
|
|
|
ob = context.object
|
|
|
|
|
if ob is None:
|
2023-04-24 20:47:20 +02:00
|
|
|
return False
|
2023-04-28 16:36:15 +10:00
|
|
|
modifier = ob.modifiers.active
|
2023-02-14 18:21:50 +01:00
|
|
|
if modifier is None or modifier.type != 'NODES':
|
|
|
|
|
return None
|
|
|
|
|
return modifier
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def edit_geometry_nodes_modifier_poll(context):
|
|
|
|
|
return get_context_modifier(context) is not None
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def socket_idname_to_attribute_type(idname):
|
|
|
|
|
if idname.startswith("NodeSocketInt"):
|
2023-09-13 13:36:00 +10:00
|
|
|
return 'INT'
|
2023-02-14 18:21:50 +01:00
|
|
|
elif idname.startswith("NodeSocketColor"):
|
2023-09-13 13:36:00 +10:00
|
|
|
return 'FLOAT_COLOR'
|
2023-02-14 18:21:50 +01:00
|
|
|
elif idname.startswith("NodeSocketVector"):
|
2023-09-13 13:36:00 +10:00
|
|
|
return 'FLOAT_VECTOR'
|
2023-02-14 18:21:50 +01:00
|
|
|
elif idname.startswith("NodeSocketBool"):
|
2023-09-13 13:36:00 +10:00
|
|
|
return 'BOOLEAN'
|
2023-02-14 18:21:50 +01:00
|
|
|
elif idname.startswith("NodeSocketFloat"):
|
2023-09-13 13:36:00 +10:00
|
|
|
return 'FLOAT'
|
2023-02-14 18:21:50 +01:00
|
|
|
raise ValueError("Unsupported socket type")
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def modifier_attribute_name_get(modifier, identifier):
|
|
|
|
|
try:
|
|
|
|
|
return modifier[identifier + "_attribute_name"]
|
|
|
|
|
except KeyError:
|
|
|
|
|
return None
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def modifier_input_use_attribute(modifier, identifier):
|
|
|
|
|
try:
|
|
|
|
|
return modifier[identifier + "_use_attribute"] != 0
|
|
|
|
|
except KeyError:
|
|
|
|
|
return False
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def get_socket_with_identifier(sockets, identifier):
|
|
|
|
|
for socket in sockets:
|
|
|
|
|
if socket.identifier == identifier:
|
|
|
|
|
return socket
|
|
|
|
|
return None
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def get_enabled_socket_with_name(sockets, name):
|
|
|
|
|
for socket in sockets:
|
|
|
|
|
if socket.name == name and socket.enabled:
|
|
|
|
|
return socket
|
|
|
|
|
return None
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
class MoveModifierToNodes(Operator):
|
|
|
|
|
"""Move inputs and outputs from in the modifier to a new node group"""
|
|
|
|
|
|
|
|
|
|
bl_idname = "object.geometry_nodes_move_to_nodes"
|
|
|
|
|
bl_label = "Move to Nodes"
|
|
|
|
|
bl_options = {'REGISTER', 'UNDO'}
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def poll(cls, context):
|
|
|
|
|
return edit_geometry_nodes_modifier_poll(context)
|
|
|
|
|
|
|
|
|
|
def execute(self, context):
|
|
|
|
|
modifier = get_context_modifier(context)
|
|
|
|
|
if not modifier:
|
|
|
|
|
return {'CANCELLED'}
|
|
|
|
|
old_group = modifier.node_group
|
|
|
|
|
if not old_group:
|
|
|
|
|
return {'CANCELLED'}
|
|
|
|
|
|
|
|
|
|
wrapper_name = old_group.name + ".wrapper"
|
2023-09-23 20:32:21 -04:00
|
|
|
group = bpy.data.node_groups.new(wrapper_name, 'GeometryNodeTree')
|
|
|
|
|
group.interface.new_socket(data_("Geometry"), in_out='OUTPUT', socket_type='NodeSocketGeometry')
|
|
|
|
|
group.is_modifier = True
|
|
|
|
|
|
|
|
|
|
first_geometry_input = next((item for item in old_group.interface.items_tree if item.item_type == 'SOCKET' and
|
|
|
|
|
item.in_out == 'INPUT' and
|
|
|
|
|
item.bl_socket_idname == 'NodeSocketGeometry'), None)
|
|
|
|
|
if first_geometry_input:
|
|
|
|
|
group.interface.new_socket(data_("Geometry"), in_out='INPUT', socket_type='NodeSocketGeometry')
|
|
|
|
|
group_input_node = group.nodes.new('NodeGroupInput')
|
|
|
|
|
group_input_node.location.x = -200 - group_input_node.width
|
|
|
|
|
group_input_node.select = False
|
|
|
|
|
|
|
|
|
|
group_output_node = group.nodes.new('NodeGroupOutput')
|
|
|
|
|
group_output_node.is_active_output = True
|
|
|
|
|
group_output_node.location.x = 200
|
|
|
|
|
group_output_node.select = False
|
|
|
|
|
|
2023-02-14 18:21:50 +01:00
|
|
|
group_node = group.nodes.new("GeometryNodeGroup")
|
|
|
|
|
group_node.node_tree = old_group
|
|
|
|
|
group_node.update()
|
|
|
|
|
|
|
|
|
|
# Copy default values for inputs and create named attribute input nodes.
|
|
|
|
|
input_nodes = []
|
2023-09-18 18:07:26 +02:00
|
|
|
for input_socket in old_group.interface.items_tree:
|
2023-09-02 14:08:45 +02:00
|
|
|
if input_socket.item_type != 'SOCKET' or (input_socket.in_out not in {'INPUT', 'BOTH'}):
|
|
|
|
|
continue
|
2023-02-14 18:21:50 +01:00
|
|
|
identifier = input_socket.identifier
|
|
|
|
|
group_node_input = get_socket_with_identifier(group_node.inputs, identifier)
|
|
|
|
|
if modifier_input_use_attribute(modifier, identifier):
|
|
|
|
|
input_node = group.nodes.new("GeometryNodeInputNamedAttribute")
|
|
|
|
|
input_nodes.append(input_node)
|
|
|
|
|
input_node.data_type = socket_idname_to_attribute_type(input_socket.bl_socket_idname)
|
|
|
|
|
attribute_name = modifier_attribute_name_get(modifier, identifier)
|
|
|
|
|
input_node.inputs["Name"].default_value = attribute_name
|
|
|
|
|
output_socket = get_enabled_socket_with_name(input_node.outputs, "Attribute")
|
|
|
|
|
group.links.new(output_socket, group_node_input)
|
|
|
|
|
elif hasattr(input_socket, "default_value"):
|
|
|
|
|
group_node_input.default_value = modifier[identifier]
|
|
|
|
|
|
2023-09-23 20:32:21 -04:00
|
|
|
if first_geometry_input:
|
|
|
|
|
group.links.new(group_input_node.outputs[0],
|
|
|
|
|
get_socket_with_identifier(group_node.inputs, first_geometry_input.identifier))
|
2023-02-14 18:21:50 +01:00
|
|
|
|
2023-09-23 20:32:21 -04:00
|
|
|
# Adjust locations of named attribute input nodes and group input node to make some space.
|
|
|
|
|
if input_nodes:
|
|
|
|
|
for i, node in enumerate(input_nodes):
|
|
|
|
|
node.location.x = -175
|
|
|
|
|
node.location.y = i * -50
|
|
|
|
|
group_input_node.location.x = -350
|
2023-02-14 18:21:50 +01:00
|
|
|
|
|
|
|
|
# Connect outputs to store named attribute nodes to replace modifier attribute outputs.
|
|
|
|
|
store_nodes = []
|
|
|
|
|
first_geometry_output = None
|
2023-09-18 18:07:26 +02:00
|
|
|
for output_socket in old_group.interface.items_tree:
|
2023-09-02 14:08:45 +02:00
|
|
|
if output_socket.item_type != 'SOCKET' or (output_socket.in_out not in {'OUTPUT', 'BOTH'}):
|
|
|
|
|
continue
|
2023-02-14 18:21:50 +01:00
|
|
|
identifier = output_socket.identifier
|
|
|
|
|
group_node_output = get_socket_with_identifier(group_node.outputs, identifier)
|
|
|
|
|
attribute_name = modifier_attribute_name_get(modifier, identifier)
|
|
|
|
|
if attribute_name:
|
|
|
|
|
store_node = group.nodes.new("GeometryNodeStoreNamedAttribute")
|
|
|
|
|
store_nodes.append(store_node)
|
|
|
|
|
store_node.data_type = socket_idname_to_attribute_type(output_socket.bl_socket_idname)
|
|
|
|
|
store_node.domain = output_socket.attribute_domain
|
|
|
|
|
store_node.inputs["Name"].default_value = attribute_name
|
|
|
|
|
input_socket = get_enabled_socket_with_name(store_node.inputs, "Value")
|
|
|
|
|
group.links.new(group_node_output, input_socket)
|
|
|
|
|
elif output_socket.bl_socket_idname == 'NodeSocketGeometry':
|
|
|
|
|
if not first_geometry_output:
|
|
|
|
|
first_geometry_output = group_node_output
|
|
|
|
|
|
|
|
|
|
# Adjust locations of store named attribute nodes and move group output.
|
2023-02-17 16:42:27 +01:00
|
|
|
# Note that the node group has its sockets names translated, while the built-in nodes don't.
|
2023-02-14 18:21:50 +01:00
|
|
|
if store_nodes:
|
|
|
|
|
for i, node in enumerate(store_nodes):
|
|
|
|
|
node.location.x = (i + 1) * 175
|
|
|
|
|
node.location.y = 0
|
|
|
|
|
group_output_node.location.x = (len(store_nodes) + 1) * 175
|
|
|
|
|
|
|
|
|
|
group.links.new(first_geometry_output, store_nodes[0].inputs["Geometry"])
|
|
|
|
|
for i in range(len(store_nodes) - 1):
|
|
|
|
|
group.links.new(store_nodes[i].outputs["Geometry"], store_nodes[i + 1].inputs["Geometry"])
|
2023-02-17 16:42:27 +01:00
|
|
|
|
|
|
|
|
group.links.new(store_nodes[-1].outputs["Geometry"], group_output_node.inputs[data_("Geometry")])
|
2023-02-14 18:21:50 +01:00
|
|
|
else:
|
2023-08-02 14:00:32 +02:00
|
|
|
if not first_geometry_output:
|
2023-09-13 13:36:00 +10:00
|
|
|
self.report({'WARNING'}, "Node group must have a geometry output")
|
|
|
|
|
return {'CANCELLED'}
|
2023-02-17 16:42:27 +01:00
|
|
|
group.links.new(first_geometry_output, group_output_node.inputs[data_("Geometry")])
|
2023-02-14 18:21:50 +01:00
|
|
|
|
|
|
|
|
modifier.node_group = group
|
|
|
|
|
|
|
|
|
|
return {'FINISHED'}
|
|
|
|
|
|
|
|
|
|
|
2021-03-23 16:08:02 +11:00
|
|
|
class NewGeometryNodesModifier(Operator):
|
2020-12-01 21:35:26 +01:00
|
|
|
"""Create a new modifier with a new geometry node group"""
|
|
|
|
|
|
2020-12-01 11:32:36 +01:00
|
|
|
bl_idname = "node.new_geometry_nodes_modifier"
|
2020-12-01 21:35:26 +01:00
|
|
|
bl_label = "New Geometry Node Modifier"
|
|
|
|
|
bl_options = {'REGISTER', 'UNDO'}
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def poll(cls, context):
|
|
|
|
|
return geometry_modifier_poll(context)
|
|
|
|
|
|
|
|
|
|
def execute(self, context):
|
2023-04-28 16:36:15 +10:00
|
|
|
ob = context.object
|
|
|
|
|
modifier = ob.modifiers.new(data_("GeometryNodes"), 'NODES')
|
2020-12-01 21:35:26 +01:00
|
|
|
if not modifier:
|
|
|
|
|
return {'CANCELLED'}
|
|
|
|
|
|
2023-09-23 20:32:21 -04:00
|
|
|
group = geometry_node_group_empty_modifier_new(data_("Geometry Nodes"))
|
2022-03-29 22:28:02 +02:00
|
|
|
modifier.node_group = group
|
|
|
|
|
|
2020-12-01 21:35:26 +01:00
|
|
|
return {'FINISHED'}
|
|
|
|
|
|
|
|
|
|
|
2021-03-23 16:08:02 +11:00
|
|
|
class NewGeometryNodeTreeAssign(Operator):
|
2021-01-04 15:42:15 -06:00
|
|
|
"""Create a new geometry node group and assign it to the active modifier"""
|
2020-12-02 13:25:25 +01:00
|
|
|
|
2020-12-01 21:35:26 +01:00
|
|
|
bl_idname = "node.new_geometry_node_group_assign"
|
|
|
|
|
bl_label = "Assign New Geometry Node Group"
|
2020-12-02 13:25:25 +01:00
|
|
|
bl_options = {'REGISTER', 'UNDO'}
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def poll(cls, context):
|
|
|
|
|
return geometry_modifier_poll(context)
|
|
|
|
|
|
|
|
|
|
def execute(self, context):
|
2023-06-30 11:53:40 -04:00
|
|
|
space = context.space_data
|
2023-09-17 20:09:14 -04:00
|
|
|
modifier = get_context_modifier(context)
|
|
|
|
|
if not modifier:
|
|
|
|
|
return {'CANCELLED'}
|
2023-09-23 20:32:21 -04:00
|
|
|
group = geometry_node_group_empty_modifier_new(data_("Geometry Nodes"))
|
2023-09-17 20:09:14 -04:00
|
|
|
modifier.node_group = group
|
2020-12-02 13:25:25 +01:00
|
|
|
|
|
|
|
|
return {'FINISHED'}
|
|
|
|
|
|
|
|
|
|
|
2023-08-04 18:22:45 +02:00
|
|
|
class NewGeometryNodeGroupTool(Operator):
|
2023-09-25 13:22:03 -04:00
|
|
|
"""Create a new geometry node group for a tool"""
|
2023-08-04 18:22:45 +02:00
|
|
|
bl_idname = "node.new_geometry_node_group_tool"
|
|
|
|
|
bl_label = "New Geometry Node Tool Group"
|
|
|
|
|
bl_options = {'REGISTER', 'UNDO'}
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def poll(cls, context):
|
2023-08-30 10:57:15 +10:00
|
|
|
space = context.space_data
|
|
|
|
|
return space and space.type == 'NODE_EDITOR' and space.geometry_nodes_type == 'TOOL'
|
2023-08-04 18:22:45 +02:00
|
|
|
|
|
|
|
|
def execute(self, context):
|
2023-09-07 19:46:40 +02:00
|
|
|
group = geometry_node_group_empty_tool_new(context)
|
2023-09-27 15:47:22 +02:00
|
|
|
context.space_data.geometry_nodes_tool_tree = group
|
2023-08-04 18:22:45 +02:00
|
|
|
return {'FINISHED'}
|
|
|
|
|
|
|
|
|
|
|
2023-10-04 15:38:17 +02:00
|
|
|
class ZoneOperator:
|
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
|
|
|
@classmethod
|
|
|
|
|
def get_output_node(cls, context):
|
|
|
|
|
node = context.active_node
|
|
|
|
|
if node.bl_idname == cls.input_node_type:
|
|
|
|
|
return node.paired_output
|
|
|
|
|
if node.bl_idname == cls.output_node_type:
|
|
|
|
|
return node
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def poll(cls, context):
|
|
|
|
|
space = context.space_data
|
|
|
|
|
# Needs active node editor and a tree.
|
|
|
|
|
if not space or space.type != 'NODE_EDITOR' or not space.edit_tree or space.edit_tree.library:
|
|
|
|
|
return False
|
|
|
|
|
node = context.active_node
|
|
|
|
|
if node is None or node.bl_idname not in [cls.input_node_type, cls.output_node_type]:
|
|
|
|
|
return False
|
|
|
|
|
if cls.get_output_node(context) is None:
|
|
|
|
|
return False
|
|
|
|
|
return True
|
|
|
|
|
|
|
|
|
|
|
2023-10-04 15:38:17 +02:00
|
|
|
class ZoneItemAddOperator:
|
|
|
|
|
items_name = None
|
|
|
|
|
active_index_name = None
|
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
|
|
|
default_socket_type = 'GEOMETRY'
|
|
|
|
|
|
|
|
|
|
def execute(self, context):
|
|
|
|
|
node = self.get_output_node(context)
|
2023-10-04 15:38:17 +02:00
|
|
|
items = getattr(node, self.items_name)
|
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
|
|
|
# Remember index to move the item.
|
2023-10-04 15:38:17 +02:00
|
|
|
old_active_index = getattr(node, self.active_index_name)
|
|
|
|
|
if 0 <= old_active_index < len(items):
|
|
|
|
|
old_active_item = items[old_active_index]
|
|
|
|
|
dst_index = old_active_index + 1
|
|
|
|
|
dst_type = old_active_item.socket_type
|
|
|
|
|
dst_name = old_active_item.name
|
2023-06-26 14:07:26 +02:00
|
|
|
else:
|
2023-10-04 15:38:17 +02:00
|
|
|
dst_index = len(items)
|
2023-06-26 14:07:26 +02:00
|
|
|
dst_type = self.default_socket_type
|
|
|
|
|
# Empty name so it is based on the type.
|
|
|
|
|
dst_name = ""
|
2023-10-04 15:38:17 +02:00
|
|
|
items.new(dst_type, dst_name)
|
|
|
|
|
items.move(len(items) - 1, dst_index)
|
|
|
|
|
setattr(node, self.active_index_name, dst_index)
|
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
|
|
|
return {'FINISHED'}
|
|
|
|
|
|
|
|
|
|
|
2023-10-04 15:38:17 +02:00
|
|
|
class ZoneItemRemoveOperator:
|
|
|
|
|
items_name = None
|
|
|
|
|
active_index_name = None
|
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 execute(self, context):
|
|
|
|
|
node = self.get_output_node(context)
|
2023-10-04 15:38:17 +02:00
|
|
|
items = getattr(node, self.items_name)
|
|
|
|
|
old_active_index = getattr(node, self.active_index_name)
|
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
|
|
|
|
2023-10-04 15:38:17 +02:00
|
|
|
if 0 <= old_active_index < len(items):
|
|
|
|
|
items.remove(items[old_active_index])
|
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
|
|
|
|
|
|
|
|
return {'FINISHED'}
|
|
|
|
|
|
|
|
|
|
|
2023-10-04 15:38:17 +02:00
|
|
|
class ZoneMoveItemOperator:
|
|
|
|
|
items_name = None
|
|
|
|
|
active_index_name = None
|
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
|
|
|
|
|
|
|
|
direction: EnumProperty(
|
|
|
|
|
name="Direction",
|
|
|
|
|
items=[('UP', "Up", ""), ('DOWN', "Down", "")],
|
|
|
|
|
default='UP',
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
def execute(self, context):
|
|
|
|
|
node = self.get_output_node(context)
|
2023-10-04 15:38:17 +02:00
|
|
|
items = getattr(node, self.items_name)
|
|
|
|
|
old_active_index = getattr(node, self.active_index_name)
|
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
|
|
|
|
2023-10-04 15:38:17 +02:00
|
|
|
if self.direction == 'UP' and old_active_index > 0:
|
|
|
|
|
items.move(old_active_index, old_active_index - 1)
|
|
|
|
|
setattr(node, self.active_index_name, old_active_index - 1)
|
|
|
|
|
elif self.direction == 'DOWN' and old_active_index < len(items) - 1:
|
|
|
|
|
items.move(old_active_index, old_active_index + 1)
|
|
|
|
|
setattr(node, self.active_index_name, old_active_index + 1)
|
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
|
|
|
|
|
|
|
|
return {'FINISHED'}
|
|
|
|
|
|
|
|
|
|
|
2023-10-04 15:38:17 +02:00
|
|
|
class SimulationZoneOperator(ZoneOperator):
|
|
|
|
|
input_node_type = 'GeometryNodeSimulationInput'
|
|
|
|
|
output_node_type = 'GeometryNodeSimulationOutput'
|
2023-07-11 22:36:10 +02:00
|
|
|
|
2023-10-04 15:38:17 +02:00
|
|
|
items_name = "state_items"
|
|
|
|
|
active_index_name = "active_index"
|
2023-07-11 22:36:10 +02:00
|
|
|
|
2023-10-04 15:38:17 +02:00
|
|
|
|
|
|
|
|
class SimulationZoneItemAddOperator(SimulationZoneOperator, ZoneItemAddOperator, Operator):
|
|
|
|
|
"""Add a state item to the simulation zone"""
|
|
|
|
|
bl_idname = "node.simulation_zone_item_add"
|
|
|
|
|
bl_label = "Add State Item"
|
|
|
|
|
bl_options = {'REGISTER', 'UNDO'}
|
2023-07-11 22:36:10 +02:00
|
|
|
|
|
|
|
|
|
2023-10-04 15:38:17 +02:00
|
|
|
class SimulationZoneItemRemoveOperator(SimulationZoneOperator, ZoneItemRemoveOperator, Operator):
|
|
|
|
|
"""Remove a state item from the simulation zone"""
|
|
|
|
|
bl_idname = "node.simulation_zone_item_remove"
|
|
|
|
|
bl_label = "Remove State Item"
|
2023-07-11 22:36:10 +02:00
|
|
|
bl_options = {'REGISTER', 'UNDO'}
|
|
|
|
|
|
|
|
|
|
|
2023-10-04 15:38:17 +02:00
|
|
|
class SimulationZoneItemMoveOperator(SimulationZoneOperator, ZoneMoveItemOperator, Operator):
|
|
|
|
|
"""Move a simulation state item up or down in the list"""
|
|
|
|
|
bl_idname = "node.simulation_zone_item_move"
|
|
|
|
|
bl_label = "Move State Item"
|
|
|
|
|
bl_options = {'REGISTER', 'UNDO'}
|
2023-07-11 22:36:10 +02:00
|
|
|
|
|
|
|
|
|
2023-10-04 15:38:17 +02:00
|
|
|
class RepeatZoneOperator(ZoneOperator):
|
|
|
|
|
input_node_type = 'GeometryNodeRepeatInput'
|
|
|
|
|
output_node_type = 'GeometryNodeRepeatOutput'
|
|
|
|
|
|
|
|
|
|
items_name = "repeat_items"
|
|
|
|
|
active_index_name = "active_index"
|
2023-07-11 22:36:10 +02:00
|
|
|
|
2023-10-04 15:38:17 +02:00
|
|
|
|
|
|
|
|
class RepeatZoneItemAddOperator(RepeatZoneOperator, ZoneItemAddOperator, Operator):
|
|
|
|
|
"""Add a repeat item to the repeat zone"""
|
|
|
|
|
bl_idname = "node.repeat_zone_item_add"
|
|
|
|
|
bl_label = "Add Repeat Item"
|
|
|
|
|
bl_options = {'REGISTER', 'UNDO'}
|
2023-07-11 22:36:10 +02:00
|
|
|
|
|
|
|
|
|
2023-10-04 15:38:17 +02:00
|
|
|
class RepeatZoneItemRemoveOperator(RepeatZoneOperator, ZoneItemRemoveOperator, Operator):
|
2023-07-11 22:36:10 +02:00
|
|
|
"""Remove a repeat item from the repeat zone"""
|
|
|
|
|
bl_idname = "node.repeat_zone_item_remove"
|
|
|
|
|
bl_label = "Remove Repeat Item"
|
|
|
|
|
bl_options = {'REGISTER', 'UNDO'}
|
|
|
|
|
|
|
|
|
|
|
2023-10-04 15:38:17 +02:00
|
|
|
class RepeatZoneItemMoveOperator(RepeatZoneOperator, ZoneMoveItemOperator, Operator):
|
2023-07-11 22:36:10 +02:00
|
|
|
"""Move a repeat item up or down in the list"""
|
|
|
|
|
bl_idname = "node.repeat_zone_item_move"
|
|
|
|
|
bl_label = "Move Repeat Item"
|
|
|
|
|
bl_options = {'REGISTER', 'UNDO'}
|
|
|
|
|
|
|
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
classes = (
|
2020-12-01 11:32:36 +01:00
|
|
|
NewGeometryNodesModifier,
|
2020-12-01 21:35:26 +01:00
|
|
|
NewGeometryNodeTreeAssign,
|
2023-08-29 11:32:19 -07:00
|
|
|
NewGeometryNodeGroupTool,
|
2023-02-14 18:21:50 +01:00
|
|
|
MoveModifierToNodes,
|
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
|
|
|
SimulationZoneItemAddOperator,
|
|
|
|
|
SimulationZoneItemRemoveOperator,
|
|
|
|
|
SimulationZoneItemMoveOperator,
|
2023-07-11 22:36:10 +02:00
|
|
|
RepeatZoneItemAddOperator,
|
|
|
|
|
RepeatZoneItemRemoveOperator,
|
|
|
|
|
RepeatZoneItemMoveOperator,
|
2020-12-02 13:25:25 +01:00
|
|
|
)
|