This moves code used for tracing bundles and closures to a separate file. This
code is used to e.g. detect which Separate Bundle node a Combine Bundle node is
linked to. This allows providing automatic socket update operators for these
nodes. Similarly for closures.
Pull Request: https://projects.blender.org/blender/blender/pulls/143734
This moves most of the code to deal with syncable nodes (such as
Combine/Separate Bundle) to the nodes module. Over time it might be possible to
decentralize it more.
This also changes the caching mechanism from storing a flag on the node to
storing a map on the node editor runtime data. This simplifies the code quite
significantly and also removes the need to store any of this data in DNA.
The node tree update code now always clears this cache because before it was
missing many cases, e.g. when creating links that would connect a Combine to a
Separate Bundle node.
Pull Request: https://projects.blender.org/blender/blender/pulls/143661
This is extracted from #140967.
Previously, it was possible to sync a bundle/closure node based on what's linked.
However, it was not possible to detect if the syncing was possible or necessary
in the first place. Knowing this helps building UI features that inform the user
about outdated nodes.
Previously, the right sockets were already created on closure/bundle nodes when
link-drag-search is used. However, after initialization, there was no automatic
way to synchronize the sockets again after changes to one of the nodes. Instead
one had to copy the changes manually.
This patch adds a new operator that can automatically update the sockets on the
following nodes based on what is connected: Combine Bundle, Separate Bundle,
Closure (zone), Evaluate Closure.
The button is always visible in the side bar. In the future we may also want to
show it inside of the node when syncing is necessary. However, that's not done
in this patch. It's also a little bit tricky because detecting whether syncing
is necessary is not necessarily cheap (it requires traversing the tree including
going into nested node groups).
If no signature or conflicting signatures for the bundle or closure are found,
the operator does nothing. In this case, the user is currently responsible to
create/remove the sockets manually.
Pull Request: https://projects.blender.org/blender/blender/pulls/140449
When creating a Combine Bundle node using link-drag-search from a
bundle-input-socket, the new node will be initialized to have all the sockets
that linked Separate Bundle nodes have. This uses the same mechanism that's used
for creating closure zones, so it works even if the Separate Bundle node is in
some nested node group.
Pull Request: https://projects.blender.org/blender/blender/pulls/140185
Baking and storing simulation state within loops or closures is not supported.
Previously, attempting to use the bake node or simulation zone in such a zone
would just silently fail. Now there is an error on the node and the bake
settings are grayed out.
Pull Request: https://projects.blender.org/blender/blender/pulls/140041
Previously, it was somewhat difficult to know if a dragged node will be attached
to a frame or not. This patch highlights the frame that dragged nodes will be
attached to which removes the guesswork. This is similar to how we highlight the
link that a dragged node will be inserted onto.
Pull Request: https://projects.blender.org/blender/blender/pulls/138648
This adds support for having viewer nodes in closures. The code attempt to
detect where the closure is evaluated and shows the data from there.
If the closure is evaluated in multiple Evaluate Closure nodes, currently it
just picks the first one it finds. Support for more user control in this case
may be added a bit later. If the Evaluate Closure node is in e.g. the repeat or
foreach zone, it will automatically use the inspection index of that zone to
determine what evaluation to look at specifically.
Overall, not too much had to change conceptually to support viewers in closures.
Just some code like converting between viewer paths and compute contexts had to
be generalized a little bit.
Pull Request: https://projects.blender.org/blender/blender/pulls/137625
This adds initial support for showing logged data in closures. This is more
tricky than the other zone types, because the zone content is evaluated
elsewhere. The main new thing here is a function that attempts to find where a
given closure is evaluated statically.
Finding this place statically is also important because we generally decide
which compute contexts we want to log before evaluation starts. That's because
we don't want to log everything (which is expensive), but just the places that
the user is currently looking at.
This also changed a bunch of CMakeLists.txt files so that these modules can
include NOD_* stuff, which is generally fine everywhere in editors code.
Pull Request: https://projects.blender.org/blender/blender/pulls/137403
This adds a simple `compute_context_for_edittree` function that returns the
"active" compute context for the given node editor. This is used in various
places, but previously one had to construct the compute context in multiple
steps (first find the root context (modifier/operator), then handle the tree
path). Since the edittree already has a specific active context, there should be
an easy way to retrieve that.
This also adds a few extra check that avoid redundant work that was done before.
Pull Request: https://projects.blender.org/blender/blender/pulls/137525
While `ComputeContextBuilder` worked well for building simple linear compute
contexts, it was fairly limiting for all the slightly more complex cases where
an entire tree of compute contexts is built. Using `ComputeContextCache` that is
easier to do more explicitly. There were only very few cases where using
`ComputeContextBuilder` would have still helped a bit, but it's not really worth
keeping that abstraction around just for those few cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/137370
Add a new shader specifically for node sockets rather than using the
keyframe shader.
Motivation:
1. Allow easier addition of new socket shapes
2. Simplify socket drawing by avoiding special handling of multi-inputs
3. Support multi-inputs for all socket types (diamond, square, etc.)
The new shader is tweaked to look the same to the old ones.
**Comparison**
The biggest difference is that the multi socket is now more consistent
with the other sockets.
For single sockets there can be small size differences depending on zoom
level because the old socket shader always aligned the sockets to the
pixel grid. This could cause a bit of jiggling compared to the rest of
the node when slowly zooming. Therefore I left it out of the new shader
and it now scales strictly linear with the view.
**Multi Socket Types**
While there currently is no need for (.) internally, there are a few
obvious use-cases for multi-input field (diamond) sockets like
generalized math nodes with an arbitrary number of inputs (Add,
Multiply, Minimum etc.).
Co-authored-by: Jacques Lucke <jacques@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/119243
The issue was that changing the area did not immediately update the
`snode->edittree` when changing between different node editor types. That update
only happened later in `node_area_refresh`. However, by that time, the `poll`
function of the modal operator has already succeeded even though when there
operator actually starts `poll` would not succeed anymore.
Pull Request: https://projects.blender.org/blender/blender/pulls/129870
Fixes an issue with the new node insertion feature where, after a link drag search,
the main input of the new node is connected to, regardless of which one was chosen.
Pull Request: https://projects.blender.org/blender/blender/pulls/128640
This makes link-drag-search more convenient when one wants to insert a new node
between existing nodes. The change currently also affects normal node-insertion
when dragging it. The exact behavior still has to be figured out.
Pull Request: https://projects.blender.org/blender/blender/pulls/128197
Previously, when dropping a node on a link with incompatible sockets, the link
would be removed. While sometimes useful in super simple setup, it is generally
useless for most work. Even worse, users might not notice that they accidentally
removed a link (this has been reported in the recent geometry nodes workshop).
This patch changes this behavior in two ways:
* A node can't be inserted onto an incompatible link anymore.
* A link will be dimmed while dragging a node over it, if it is incompatible or if
alt is pressed.
Pull Request: https://projects.blender.org/blender/blender/pulls/121975
Previously, it was only possible to bake all simulations at once. This is great
for simple use-cases that, but in more complex setups one can have independent
simulations that should also be baked independently. This patch allows baking
individual simulation zones.
Furthermore, each simulation zone can now also have its own bake path and
simulation frame range. By default the simulation frame range is the scene frame
range, but it can also be customized on the scene or simulation zone level. The
bake path is generated based on the modifier bake path by default, but can be
set to another absolute or relative (to the .blend file) path.
The timeline drawing has been modified as well to be able to show more information
in the case when some simulations are baked and others are not. Instead of showing
a line for every simulation, it shows a condensed view of the important information
using at most two lines:
Is something baked? Is something valid or invalid? Also see #112232.
Pull Request: https://projects.blender.org/blender/blender/pulls/112723
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
