This implements the core changes for this design: https://devtalk.blender.org/t/grease-pencil-integration-into-geometry-nodes/31220
The changes include:
* Add `CustomData` for layer attributes
* Add attribute support for the `GreasePencilComponent` to read/write layer attributes. Also introduces a `Layer` domain.
* Implement a `GreasePencilLayerFieldContext` and make `GeometryFieldContext` work with grease pencil layers.
* Implement `Set Position` node for `Grease Pencil`.
Note: These changes are only accessible/visible with the `Grease Pencil 3.0` experimental flag enabled.
Co-authored-by: Jacques Lucke <jacques@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/112535
Disambiguate:
- Rename "Near" to "Proximity" as a particle event type, because using
an adjective in this context is inconsistent and sounds
strange (even in English IMO).
Extract:
- "Skip" (Geometry nodes Simulation node output socket)
- "Bake" (Directory path to geometry nodes bake files in the modifier
UI)
- " (Recovered)" (File information in title bar)
Pull Request: https://projects.blender.org/blender/blender/pulls/112974
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 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
The goal is to make the search faster to use by dynamically adapting to the user.
This can be achieved using the simple but common approach of showing recently
selected items at the top. Note, that the "matching score" between the query and
each search item still has precedence when determining the order. So the last used
item is only at the top, if there is no other search item that matches the query better.
Besides making the search generally faster to use, my hope is that this can also
reduce the need for manually weighting search items in some places. This is
because while the ordering might not be perfect the first time, it will always be
once the user selected the element that should be at the top once.
This patch includes:
* Support for taking recent searches into account in string searching.
* Keep track of a global list of recent searches.
* Store recent searches on disk similar to recently opened files.
* A new setting in the user preferences that allows disabling the functionality.
This can be used if deterministic key strokes are required, e.g. for automated tests.
In the future this could be improved in different ways:
* Add some kind of separator in the search list to indicate which elements are at
the top because they have been used recently.
* Store the recent search items per search, instead of in a global list. This way
it could adapt to the user even better.
Pull Request: https://projects.blender.org/blender/blender/pulls/110828
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
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
When adding modifiers from assets in the new modifier menu, switching
the node group the modifier uses afterwards will not be common. The goal
is to replace the builtin modifier directly. In that case it's easier to
just add a new modifier. The "Empty Modifier" item makes it easy to
choose an arbitrary node group anyway.
Combined with hiding the two sub-panels when they are unnecessary,
many node-modifiers will look just as clean as their builtin counterparts.
The option to show the data-block selector is added to the menu
in the node header so it's still accessible though.
Pull Request: https://projects.blender.org/blender/blender/pulls/111995
There are a couple of functions that create rna pointers. For example
`RNA_main_pointer_create` and `RNA_pointer_create`. Currently, those
take an output parameter `r_ptr` as last argument. This patch changes
it so that the functions actually return a` PointerRNA` instead of using
the output parameters.
This has a few benefits:
* Output parameters should only be used when there is an actual benefit.
Otherwise, one should default to returning the value.
* It's simpler to use the API in the large majority of cases (note that this
patch reduces the number of lines of code).
* It allows the `PointerRNA` to be const on the call-site, if that is desired.
No performance regression has been measured in production files.
If one of these functions happened to be called in a hot loop where
there is a regression, the solution should be to use an inline function
there which allows the compiler to optimize it even better.
Pull Request: https://projects.blender.org/blender/blender/pulls/111976
The main goal here is to rename things in a way that makes sense for
simulation baking, but also for the upcoming bake node.
This also removes some versioning code from 3.6 which initialized the
default bake path. Baked data from back then can't be loaded anymore
anyway, and the way the default path is generated is different now as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/111845
Blob stands for "binary large object" and is a known term. I used to use the term `bdata`
to mean "binary data", mainly because I didn't think of a better name. Blob is a much
better name as it captures the intend of those files much better.
This change breaks existing bakes, because I rename the folder from `bdata` to `blobs`.
I think that is ok, because I also just broke bakes two days ago in a larger refactor
(e92c59bc9b).
Pull Request: https://projects.blender.org/blender/blender/pulls/111822
`BKE_simulation_state_serialize.hh` is not necessary anymore,
because the serialization is done at a lower level.
The functionality that lived there in the past is now part of
`BKE_bake_items_serialize.hh`.
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.
The simulation used to reset when the previously computed frame is the
same as the current one. However, in this case the output should just be
the same as in the previous computation.
Pull Request: https://projects.blender.org/blender/blender/pulls/110799
Show node group inputs in the redo panel, including the
"use attribute" toggle. There are a few limitations that will
be solved separately:
- The redo panel is _always_ drawn, there is no way to show it conditionally yet
- There is no way to add the operator name to the redo panel title yet
- Attribute search is still missing for attribute inputs
Pull Request: https://projects.blender.org/blender/blender/pulls/109975
Remove the "_for_read" suffix from methods to get geometry and geometry
components. That should be considered the default, so the suffix just
adds unnecessary text. This is consistent with the attribute API and
various implicit sharing data access methods.
Use "from_mesh" instead of "create_with_mesh". This is consistent with
the recently used naming for the `IndexMask` API.
Pull Request: https://projects.blender.org/blender/blender/pulls/110738
Previously the panel type name of a modifier (e.g. "MOD_PT_Smooth") was
created by copying from the ModifierTypeInfos name.
This meant that modifiers with the same default name would use
the same identifier for the panels.
Since different object types (e.g. OB_GREASE_PENCIL and OB_MESH)
might want to use the same default modifier name, this PR introduces
an idname field in the ModifierTypeInfo struct. This is then used to
generate the panel type name.
For compatibility reasons, the idname is the same as the name for now.
Note: Because the name was used previously, this means that some
modifiers have spaces in their panel type name.
E.g. "MOD_PT_Volume to Mesh".
Pull Request: https://projects.blender.org/blender/blender/pulls/110468
Implements the rest of #101689, after 5e9ea9243b.
- `vdata` -> `vert_data`
- `edata` -> `edge_data`
- `pdata` -> `face_data`
- `ldata` -> `loop_data`
A deeper rename of `loop` to `corner` will be proposed as a next
step, and renaming `totvert` and `totedge` can be done separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/110432
Implements part of #101689.
The "poly" name was chosen to distinguish the `MLoop` + `MPoly`
combination from the `MFace` struct it replaced. Those two structures
persisted together for a long time, but nowadays `MPoly` is gone, and
`MFace` is only used in some legacy code like the particle system.
To avoid unnecessarily using a different term, increase consistency
with the UI and with BMesh, and generally make code a bit easier to
read, this commit replaces the `poly` term with `poly`. Most variables
that use the term are renamed too. `Mesh.totface` and `Mesh.fdata` now
have a `_legacy` suffix to reduce confusion. In a next step, `pdata`
can be renamed to `face_data` as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/109819
This adds support for running a set of nodes repeatedly. The number
of iterations can be controlled dynamically as an input of the repeat
zone. The repeat zone can be added in via the search or from the
Add > Utilities menu.
The main use case is to replace long repetitive node chains with a more
flexible alternative. Technically, repeat zones can also be used for
many other use cases. However, due to their serial nature, performance
is very sub-optimal when they are used to solve problems that could
be processed in parallel. Better solutions for such use cases will
be worked on separately.
Repeat zones are similar to simulation zones. The major difference is
that they have no concept of time and are always evaluated entirely in
the current frame, while in simulations only a single iteration is
evaluated per frame.
Stopping the repetition early using a dynamic condition is not yet
supported. "Break" functionality can be implemented manually using
Switch nodes in the loop for now. It's likely that this functionality
will be built into the repeat zone in the future.
For now, things are kept more simple.
Remaining Todos after this first version:
* Improve socket inspection and viewer node support. Currently, only
the first iteration is taken into account for socket inspection
and the viewer.
* Make loop evaluation more lazy. Currently, the evaluation is eager,
meaning that it evaluates some nodes even though their output may not
be required.
Pull Request: https://projects.blender.org/blender/blender/pulls/109164
This data-block was originally added in eb4e3bbe68.
However, that original plan wasn't fully implemented, with simulations
now integrated with geometry nodes and modifiers instead of a separate
data-block. We kept the data-block around anyway since we have the
loose plan of using a similar data-block to make global simulations
connected between multiple objects. But it may be a while before we
implement that, and in the meantime having this just causes confusion.
When we don't need to preserve a persistent cache, we can use
the geometry from the last frame directly rather than copying it.
Though implicit lets us avoid copying large data arrays when they
aren't changed, this can still give a large improvement for something
like particle simulation where the majority of the data was copied
every frame.
Pull Request: https://projects.blender.org/blender/blender/pulls/109742
