This simplifies the code that creates the zone socket mappings at the cost of
slightly more memory per zone, which is not significant.
Previously, `IndexRange` was used where it now uses `Vector<int>`.
Pull Request: https://projects.blender.org/blender/blender/pulls/116939
`set_default_remaining_node_outputs` didn't work because the mapping
between the original node group sockets and the lazy function outputs
wasn't set up during the construction of the node type, as done by the
bake node and others.
Along with the 4.1 libraries upgrade, we are bumping the clang-format
version from 8-12 to 17. This affects quite a few files.
If not already the case, you may consider pointing your IDE to the
clang-format binary bundled with the Blender precompiled libraries.
Each value is now out of the global namespace, so they can be shorter
and easier to read. Most of this commit just adds the necessary casting
and namespace specification. `enum class` can be forward declared since
it has a specified size. We will make use of that in the next commit.
A similar issue was fixed in the commit below for inserting implicit
conversions for links, but it wasn't corrected for conversions in
muted nodes.
Caused by e1d0d70911
This adds a new `Bake` node which allows saving and loading intermediate geometries.
Typical use cases we want address with this currently are:
* Bake some data for use with a render engine.
* Bake parts of the node tree explicitly for better performance.
For now, the format that is written to disk is not considered to be an import/export format.
It's not guaranteed that data written with one Blender version can be read by another
Blender version. For that it's better to use proper interchange formats. Better support for
those will be added eventually as well. We also plan an `Import Bake` node that allows
reading the blender-specific baked data independent of the Bake node and at different frames.
The baking works very similar to the baking in the simulation zone (UI and implementation
wise). Major differences are:
* The Bake node has a `Bake Still` and `Bake Animation` mode.
* The Bake node doesn't do automatic caching.
Implementation details:
* Refactored how we create the Python operators for moving socket items so that it also
makes sense for non-zones.
* The `ModifierCache` stores an independent map of `SimulationNodeCache` and
`BakeNodeCache`, but both share a common data structure for the actually baked data.
* For baking, the `Bake` node is added as a side-effect-node in the modifier. This will make
sure that the node is baked even if it's currently not connected to the output.
* Had to add a new `DEG_id_tag_update_for_side_effect_request` function that is used
during baking. It's necessary because I want to evaluate the object again even though none
of its inputs changed. The reevaluation is necessary to create the baked data. Using
`DEG_id_tag_update` technically works as well, but has the problem that it also uses the
`DEG_UPDATE_SOURCE_USER_EDIT` flag which (rightly) invalidates simulation caches
which shouldn't happen here.
* Slightly refactored the timeline drawing so that it can also show the baked ranges of
Bake nodes. It does not show anything for baked nodes with a in Still mode though.
* The bake operator is refactored to bake a list of `NodeBakeRequest` which makes the
code easier to follow compared to the previous nested
`ObjectBakeData > ModifierBakeData > NodeBakeData` data structure.
* The bake operators are disabled when the .blend file is not yet saved. This is technically
only necessary when the bake path depends on the .blend file path but seems ok to force
the user anyway (otherwise the bake path may be lost as well if it's set explicitly).
* The same operators are used to bake and delete single bakes in `Bake` nodes and
`Simulation Zones`. On top of that, there are separate operators of baking and deleting all
simulation bakes (those ignore bake nodes).
* The `Bake` node remembers which inputs have been fields and thus may be baked as attributes.
For that it uses an `Is Attribute` flag on the socket item. This is needed because the baked data
may still contain attribute data, even if the inputs to the bake node are disconnected.
* Similar to simulation zones, the behavior of `Bake` nodes is passed into the geometry nodes
evaluation from the outside (from the modifier only currently). This is done by providing the
new `GeoNodesBakeParams` in `GeoNodesCallData` when executing geometry nodes.
Next Steps (mostly because they also involve simulations):
* Visualize nodes that have not been evaluated in the last evaluation.
* Fix issue with seemingly loosing baked data after undo.
* Improve error handling when baked data is not found.
* Show bake node in link drag search.
* Higher level tools for managing bakes.
Pull Request: https://projects.blender.org/blender/blender/pulls/115466
This refactors `SocketValueVariant` with the following goals in mind:
* Support type erasure so that not all users of `SocketValueVariant` have
to know about all the types sockets can have.
* Move towards supporting "rainbow sockets" which are sockets whoose
type is only known at run-time.
* Reduce complexity when dealing with socket values in general. Previously,
one had to use `SocketValueVariantCPPType` a lot to manage uninitialized
memory. This is better abstracted away now.
One related change that I had to do that I didn't see coming at first was that
I had to refactor `set_default_remaining_outputs` because now the default value
of a `SocketValueVariant` would not contain any value. Previously, it was
initialized the zero-value of the template parameter. Similarly, I had to change
how implicit conversions are created, because comparing the `CPPType` of linked
sockets was not enough anymore to determine if a conversion is necessary.
We could potentially use `SocketValueVariant` for the remaining socket types in the
future as well. Not entirely sure if that helps yet. `SocketValueVariant` can easily be
adapted to make that work though. That would also justify the name
"SocketValueVariant" better.
Pull Request: https://projects.blender.org/blender/blender/pulls/116231
Doing this in preparation for also supporting volume
grids in the same type (#115270).
At some point we could also actually use an `std::variant` in this
type, but that would change behavior without futher changes.
This avoids some duplication between the modifier and operator evaluation
contexts and also makes it easier to make independent from a specific
evaluation context (so e.g. the simulation nodes code shouldn't care whether
it's used from a modifier or operator.
Pull Request: https://projects.blender.org/blender/blender/pulls/115512
The ImplicitSharingPtr has an implicit constructor for raw pointers.
This has unintended effects when comparing an ImplicitSharingPtr to a
raw pointer: The raw pointer is implicitly converted to the shared
pointer (without change in refcount) and when going out of scope will
decrement user count, eventually freeing the data.
Conversion from raw pointer to shared pointer should not happen
implicitly. The constructor is made explicit now. This requires a little
more boilerplate when constructing a sharing pointer. A special
constructor for the nullptr is added so comparison with nullptr can
still happen without writing out a constructor.
Pull Request: https://projects.blender.org/blender/blender/pulls/115476
Add an "Index Switch" node which is meant as a simpler version of
the "Menu Switch" from #113445 that doesn't allow naming items
or displaying them in a dropdown, but still allows choosing between
an arbitrary number of items, unlike the regular "Switch" node.
Even when the Menu Switch is included (which should be in the
same release as this), it may still be helpful to have explicit mapping
of indices, and a fair amount of the internals can be shared anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/115250
Warnings created during evaluation of the node group are passed as
warnings to the operator. This is done using the existing logging
system, which we could also use to get socket inspection working
in the future.
See #101778
Pull Request: https://projects.blender.org/blender/blender/pulls/115237
`GroupNodeComputeContext` is the more correct name because it's
specifically about a group node that invokes another node tree.
The old name makes it sound like it should be used because a node group
is invoked but does not tell anything about what invoked it.
For example, the current context in a node group can also be a
`ModifierComputeContext` if that's what invoked it.
This struct is currently defined in the `functions` module but not actually used there. It's only used by the geometry nodes module, with an indirect dependency from blenkernel via simulation zone baking. This scope is problematic when adding grids as socket data, which should not be part of the functions module.
The `ValueOrField` struct is now moved to blenkernel, so it can be more easily extended to other kinds of data that might be passed around by geometry nodes sockets in future. No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/115087
In 3.6 the names of node group sockets were using char arrays, but now
use allocated strings. The RNA system assigns nullptr to such strings
when assigning an empty string through python (UI assignment appears to
always generate a valid string). This creates issues with many STL
functions, in particular assigning nullptr to `std::string` will crash.
We have to check for valid pointers before using them in places that
don't handle nullptrs.
Pull Request: https://projects.blender.org/blender/blender/pulls/113924
In order to recreate the behavior of some builtin nodes
which have implicit inputs for ID/Index or positions, provide
a hard-coded list of default/unconnected fields for sockets.
The point is to let assets recreate the behavior of builtin
nodes in a simple way that's easy to change in the future if
this becomes a more generalized feature. A hardcoded list
makes this predictable and simple in the meantime.
When the option is set to something besides "Default Value"
it overrides the "Hide Value" option. Otherwise the default
input would conflict with the visible default value button.
This makes it possible to add #109846 as an asset in the
essentials bundle. The design is meant to be easily
extendable for shader nodes, though that isn't included
in this commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/113175
`iota` is name that has no meaning, it's not an acronym or initialism.
It's usually very cryptic when I come across it. Replacing it with a
specialized function makes the code more readible.
This idea is of remapping parameters of lazy-functions is useful
not only for the repeat zone. For example, it could be used for the
for-each zone as well.
Also, moving it to a more general place indicates that there is no
repeat-zone specific stuff in it.
This makes it easier to read generated lazy-function graphs, especially when
there are zones or group nodes, because the socket identifiers on those
are some generated internal name.
Previously, the geometry nodes modifier was converting the
viewer path to a compute context at the same time as it was
setting up side effect nodes for the geometry nodes evaluation.
Now, this is changed to be a two step process. First, the viewer
path is converted to the corresponding compute context.
Afterwards, a separate function sets side effect nodes up so
that the given node in the given compute context will be evaluated.
This has three main benefits:
* More obvious separation of concerns.
* Can reuse the code that maps a viewer path element to a compute
context already.
* With gizmo nodes (#112677), it may become necessary to add side
effect nodes based on a compute context, but without having a
corresponding viewer path.
Previously, it was only possible to inspect the data from the first iteration. That
applied to both, the viewer node as well as socket inspection. Now, there is a
new `Inspection Index` setting in the zone properties. It specifies which iteration
should be used by the inspection features.
In theory we could support features like counting the index from the end, but
that can be done separately as well, as it likely requires more UI.
Pull Request: https://projects.blender.org/blender/blender/pulls/112818
The goal is to make the evaluation of repeat zones more efficient by making
use of the lazy-function evaluation system. Performance is improved in two ways:
* Unnecessary nodes are not evaluated anymore. E.g. if a repeat zone outputs two
geometries but only one of those is actually used, the other one will not be
computed anymore.
* Support evaluating different iteration indices at the same time on different threads.
It is possible that some uses of repeat zones become slower with this refactor,
especially when each iteration does very little work and there are a lot of iterations.
The old implementation was not optimized for this use case either but now there
is a bit more overhead constant overhead per iteration than before.
On the bright side, this change can result in some very significant speedups when
some computations can be skipped. See #112421 for some example setups.
There is one todo comment for adding back-links for socket usages. Properly linking
those up can result in better (shorter) life-times for anonymous attributes. Even without
that, performance is already better than before.
The implementation reuses the existing lazy-function graph system for the repeat
zone, by building a dynamically sized graph based on the number of iterations.
Building a lazy-function graph makes it possible to use the lazyness and multi-threading
features of the lazy-function graph executor. This is much easier than reimplementing
this behavior for repeat zones specifically (hence there was only single-threaded eager
execution before).
Pull Request: https://projects.blender.org/blender/blender/pulls/112421
The issue was that the `user_data` pointer in the local user data
is not necessarily valid, because a different user-data might be
passed in when a lazy-function is called a second time (it's semantically
the same user-data but, might have a different pointer).
The solution is to not keep around the dangling pointer but to pass
it in when it is actually needed. I still keep the old constructor of the
local-user-data, because more stuff might be added to it, that needs
the user-data, as was the case in the past already (before 142541c27).
The main goal of this refactor is to simplify how a geometry node group is executed.
Previously, there was duplicated logic that turned the lazy-function graph of a node
group into a single lazy-function. Now this is done only in one place and others can
just execute the lazy-function directly, without having to worry about the underlying graph.
Pull Request: https://projects.blender.org/blender/blender/pulls/112482
Goals of the refactor:
* Simplify adding (named) graph inputs and outputs.
* Add ability to refer to a graph input or output with an index.
* Get rid of the "dummy" terminology which doesn't really help.
Previously, one would add "dummy nodes" which can then serve as input
and output nodes of the graph. Now one directly adds input and outputs
using `Graph.add_input` and `Graph.add_output`. There is one interface
node that contains all inputs and another one that contains all outputs.
Being able to refer to a graph input or output with an index makes it
more efficient to implement some algorithms. E.g. one could have a
bit span for a socket that contains all the information what graph
inputs this socket depends on.
Pull Request: https://projects.blender.org/blender/blender/pulls/112474
This is a light weight solution to passing in some extra context into
a lazy-function that is invoked by the graph executor.
The new functionality is used by #112421.
This makes the code for creating a lazy-function for the body
of a zone more reusable. Currently, it is only used by the repeat
zone, but in the future the same could be used for simulations
and for-each zones.
Currently, we create a logger for every compute context that is evaluated,
even when we don't actually log anything in that context (due to other
optimizations). Now, the logger is not created eagerly anymore.
This can be especially benefitial when there are many compute contexts
that should not log anything, e.g. if there is a repeat zone with many iterations.
In an extrem case I measured a speedup for the modifier evaluation
from 24ms to 14ms.
Calling an API function after the node panels patch does not internally
tag the node tree with `NTREE_CHANGED_INTERFACE` any more, because the
node tree is not directly accessible from `bNodeTreeInterface`. Before
node panels the API functions for interfaces could tag the tree directly
for later update consideration, which now requires explicit tagging
calls.
The fix is to add a flag and mutex directly to `bNodeTreeInterface`, so
API methods can tag after updates. This mostly copies runtime data
concepts from `bNodeTree`. The `ensure_interface_cache` method is
equivalent to `ensure_topology_cache` and should be called before
accessing `interface_inputs` and similar cache data.
Pull Request: https://projects.blender.org/blender/blender/pulls/111741
This adds a new Skip input to the Simulation Output node (design task: #112082).
It is a convenience feature that makes it easy to conditionally forward the
output of the Simulation Input node to the Simulation Output node, without the
need for potentially multiple Switch nodes. When Skip is enabled, the other inputs
of the Simulation Output node are not evaluated, i.e. the nodes in the simulation
zone are ignored.
The implementation adds this new functionality directly to the `LazyFunction`
of the Simulation Output node. It has new inputs that are linked directly
to the Simulation Input node, so that the simulation state can be forwarded.
Pull Request: https://projects.blender.org/blender/blender/pulls/112140
Goals of the refactor:
* Internal support for baking individual simulation zones (not exposed in the UI yet).
* More well-defined access to simulation data in geometry nodes. Especially, it
should be more obvious where data is modified. A similar approach should also
work for the Bake node.
Previously, there were a bunch of simulation specific properties in `GeoNodesModifierData`
and then the simulation input and output nodes would have to figure out what to do with that
data. Now, there is a new `GeoNodesSimulationParams` which controls the behavior of
simulation zones. Contrary to before, different simulation zones can now be handled
independently, even if that is not really used yet. `GeoNodesSimulationParams` has to be
subclassed by a user of the geometry nodes API. The subclass controls what each simulation
input and output node does. This some of the logic that was part of the node before, into
the modifier.
The way we store simulation data is "transposed". Previously, we stored zone data per
frame, but now we store frame data per zone. This allows different zones to be more
independent. Consequently, the way the simulation cache is accessed changed. I kept
things simpler for now, avoiding many of the methods we had before, and directly
accessing the data more often which is often simple enough. This change also makes
it theoretically possible to store baked data for separate zones independently.
A downside of this is, that existing baked data can't be read anymore. We don't really
have compatibility guarantees for this format yet, so it's ok. Users will have to bake again.
The bake folder for the modifier now contains an extra subfolder for every zone.
Drawing the cached/baked frames in the timeline is less straight forward now. Currently,
it just draws the state of one of the zones, which usually is identical to that of all other
zones. This will change in the future though, and then the timeline drawing also needs
some new UI work.
Pull Request: https://projects.blender.org/blender/blender/pulls/111623
Part 3/3 of #109135, #110272
Switch to new node group interfaces and deprecate old DNA and API.
This completes support for panels in node drawing and in node group
interface declarations in particular.
The new node group interface DNA and RNA code has been added in parts
1 and 2 (#110885, #110952) but has not be enabled yet. This commit
completes the integration by
* enabling the new RNA API
* using the new API in UI
* read/write new interfaces from blend files
* add versioning for backward compatibility
* add forward-compatible writing code to reconstruct old interfaces
All places accessing node group interface declarations should now be
using the new API. A runtime cache has been added that allows simple
linear access to socket inputs and outputs even when a panel hierarchy
is used.
Old DNA has been deprecated and should only be accessed for versioning
(inputs/outputs renamed to inputs_legacy/outputs_legacy to catch
errors). Versioning code ensures both backward and forward
compatibility of existing files.
The API for old interfaces is removed. The new API is very similar but
is defined on the `ntree.interface` instead of the `ntree` directly.
Breaking change notifications and detailed instructions for migrating
will be added.
A python test has been added for the node group API functions. This
includes new functionality such as creating panels and moving items
between different levels.
This patch does not yet contain panel representations in the modifier
UI. This has been tested in a separate branch and will be added with a
later PR (#108565).
Pull Request: https://projects.blender.org/blender/blender/pulls/111348
Including <iostream> or similar headers is quite expensive, since it
also pulls in things like <locale> and so on. In many BLI headers,
iostreams are only used to implement some sort of "debug print",
or an operator<< for ostream.
Change some of the commonly used places to instead include <iosfwd>,
which is the standard way of forward-declaring iostreams related
classes, and move the actual debug-print / operator<< implementations
into .cc files.
This is not done for templated classes though (it would be possible
to provide explicit operator<< instantiations somewhere in the
source file, but that would lead to hard-to-figure-out linker error
whenever someone would add a different template type). There, where
possible, I changed from full <iostream> include to only the needed
<ostream> part.
For Span<T>, I just removed print_as_lines since it's not used by
anything. It could be moved into a .cc file using a similar approach
as above if needed.
Doing full blender build changes include counts this way:
- <iostream> 1986 -> 978
- <sstream> 2880 -> 925
It does not affect the total build time much though, mostly because
towards the end of it there's just several CPU cores finishing
compiling OpenVDB related source files.
Pull Request: https://projects.blender.org/blender/blender/pulls/111046
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.
Add support in the UI for the edit mode of curves, mesh, and point
cloud objects. It's possible to control for which mode sand object
types the asset is available with a dropdown in the node header.
To make this per-mode filtering possible, the static asset tree
cache is now unique per context mode.
See #101778
Pull Request: https://projects.blender.org/blender/blender/pulls/109526
