This is related to #140381, where the symptom of the bug was a crash
caused by an undefined behavior. In that case, setting a valid active
viewer key was the proper fix. However,
`find_active_context_recursive()` could return `nullptr` in theory so
the same problem might occur in the future.
The commit resolves the undefined behavior by avoiding the
dereferencing of a null pointer.
Pull Request: https://projects.blender.org/blender/blender/pulls/141270
Previously in 95259228d9, property names
within geometry nodes panels are trimmed to make it less verbose if the
property name contains the parent panel's name as prefix, this didn't
take into account where property name can be the same as panel name, in
which case there will be an empty property name which is undesired. So
we should not trim the name in this case.
Pull Request: https://projects.blender.org/blender/blender/pulls/141500
Previously, if a socket inside a panel has the same name prefix as the
panel name, the panel name will be removed from socket names when
displayed inside nodes, but this is not done when displaying them on the
modifier interface, which is too verbose visually. Now panel names are
removed from these property labels as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/140448
Use `N_` for default labels in case value is invalid.
So no double translation.
Synchronize translation context with related property if exist.
So enum item translated like property with such enum.
Use nodes context for zone labels.
Pull Request: https://projects.blender.org/blender/blender/pulls/138393
This replaces uiItemMContents, uiItemDecoratorR* and
uiItemProgressIndicator API with uiLayout methods following
uiLayout refactors and the Python API.
`eButProgressType` is changed to a typed enum class
`blender::ui::ButProgressType`
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/141189
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.
Change `eCustomDataType` to `bke::AttrType` for uses of the attribute
API (the `AttributeAccessor` one anyway). I didn't touch any values that
might be saved in files; those should be handled on a case by case basis.
Part of #122398
Pull Request: https://projects.blender.org/blender/blender/pulls/141301
This patch adds support for the experimental structure types currently
used bu Geometry Nodes. Pixel nodes were declared as function nodes,
which gives dynamic structures for all their sockets. Other nodes now
explicitly declared their inputs as dynamic if not single value, while
the compositor_expects_single_value marker was removed in favor of the
StructureType::Single type.
Pull Request: https://projects.blender.org/blender/blender/pulls/140910
This removes the need to deal with void pointers and explicit casts in many
places. Also it simplifies possibly extending what kind of values can be stored
for each socket in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/140844
Previously, there was the issue that `SocketValueVariant` had a constructor that
took a forwarding reference as parameter. This was problematic, because this
could potentially hide copy/move constructors which is not intentional. This
patch makes sure that these special constructors are not overridden and adds two
static utility functions to make sure it's still straight forward to construct
the `SocketValueVariant` on a single line.
Clangd also warned about this case.
Pull Request: https://projects.blender.org/blender/blender/pulls/140842
This replaces API for accessing the uiLayout fixed_size,
red_alert, root_panel, search_weight and width properties
with methods, following uiLayout refactors and the
Python API naming
Pull Request: https://projects.blender.org/blender/blender/pulls/140673
This replaces uiLayout aligment API with uiLayout methods,
following uiLayout refactors and the Python API naming.
Also this converts the layout aligment enum to a fixed enum class.
Pull Request: https://projects.blender.org/blender/blender/pulls/140622
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
We have to execute math node both for real Grid tree nodes and for background
values. So internal logic of sharing background values will work in case such
values are used by some nodes.
A field input is evaluated on a tile with maximum bounds to get the background
value.
Pull Request: https://projects.blender.org/blender/blender/pulls/140410
This is part of the short term roadmap goal of simplifying the
compositor workflow
(see https://projects.blender.org/blender/blender/issues/134214).
The problem is that many users don't know how to get started with
compositing in Blender, even when they have used Blender for other
areas, e.g. modeling.
Note: although the solution makes compositor node trees reusable
accross blend files, this is a nice side effect and not the main goal
of the PR.
This PR implements a "New" button that creates a new compositing node
tree, and manages trees as IDs. This has following advantages:
- Consistent with other node editors and other parts of Blender,
therefore making it easier to getting started with compositing if users
are familiar with shading or geometry nodes
- Give users the ability to reuse the compositing node tree by linking
or appending it.
Note: The parameter "Use Nodes" is still present in this PR, but will
be removed (in a backward compatible way) in a follow up PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/135223
This adds support for specifying structure types on closures. The main immediate
benefit is that this makes it possible to use fields with closures (without
having incorrect warnings in the UI).
A closure zone behaves very similar to a node group with respect to structure
type inferencing. The structure types can be inferenced fully automatically, or
the user can specify them manually on the closure inputs. On the evaluate
closure zone, the user has to specify the structure types of the inputs and
outputs explicitly (or leave them as dynamic).
Working on this, I was a bit surprised that `get_output_socket_shape` depended
on the field state. Is that a left-over? It feels like it shouldn't be necessary
since the socket shape shouldn't depend on field inferencing anymore. I removed
that now and couldn't see a difference yet.
The operator that creates a closure zone from an evaluate closure node copies
the input structure types already. Beyond that, there is no automatic syncing of
the structure types yet. The structure types only affect the UI and not what's
actually done during evaluation.
Pull Request: https://projects.blender.org/blender/blender/pulls/139713
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
This patch adds support for Group Input nodes in scene compositor node
trees. The inputs return the pass that correspond to their name in the
active scene and view-layer. Image is an alias for the combined pass.
This fixes#137943 for the compositor.
Pull Request: https://projects.blender.org/blender/blender/pulls/139584
This adds a new Format String node which simplifies constructing strings from
multiple values. The node takes a format string and a dynamic number of
additional parameters as input. The format string determines how the other
inputs are inserted into the string. Only integer, float and string inputs are
supported for now.
It supports two different format syntaxes:
* Python compatible format syntax which also mostly matches the behavior of the
`fmt` C++ library. Most of this is supported, but there are some small
limitations.
* Syntax of the form `###.##` where each `#` stands for a digit. This is the
syntax that was introduced in #134860.
This node greatly simplifies common string operations which would have required
potentially many nodes before to convert numbers to strings and to concatenate
them. It also makes new conversions possible that were not supported before.
This node can also be used to insert e.g. frame numbers into a file path which
was surprisingly complex before.
This node has special behavior for the name of new inputs. For the purpose of
the node, the name of the inputs must be valid identifiers and it's usually
helpful when they are short. New names are therefore initialized to be single
characters. If possible, the first character of the linked input is used. This
works well when connecting e.g. a Separate Vector/Color node. Otherwise, inputs
are named `a` to `z` by default. If that's not possible, the source socket name
is used instead (converted to be a valid identifier). If that still doesn't
work, the name is made unique using the normal `.001` mechanism except that `_`
instead of `.` is used as separator to make the name a valid identifier.
Python Syntax references:
* Python: https://docs.python.org/3/library/string.html#formatspec
* `fmt`: https://fmt.dev/latest/syntax/
More detailed notes about compatibility with the above syntax specifications:
* Conversion using e.g. `!r` like in Python is not supported (maybe the future).
* Sub-attribute access like `{vector.x}` is not supported (maybe the future).
* Using `%` like in Python is not supported (maybe in future).
* Using `#` for an alternate form is not supported. This might help in the
future to make the syntax compatible with #134860.
* Using `L` like in the `fmt` library is not supported because it depends on the
locale which is not good for determinism.
* Grouping with e.g. thousands separators using e.g. `,` or `_` like in Python
is not supported (maybe in future). Need to think about the locale here too.
* Mixing of unnamed (`{}`) and named (`{x} or {0}`) specifiers is allowed.
However, all unnamed specifiers must come before any named specifier.
The implementation uses the `fmt` library for the actual formatting. However,
the inputs are preprocessed to give us more control over the exact supported
syntax and error messages. The code is already somewhat written so that many
strings could be formatted with the same format but that's not actually used yet
because we don't have string fields yet.
Error messages are propagated using a new mechanism that allows a limited form
of error propagation from multi-functions to the node that evaluates them.
Currently, this only works in fairly limited circumstances, e.g. it does not
work during field evaluation. Since this node is never part of field evaluation
yet, that limitation seems ok, but it's something to work on at some point.
Properly supporting that requires some more changes to propagate enough context
information everywhere. Also showing errors of field evaluation on the field
node itself (instead of on the evaluation node) requires even more work because
our current logging system is not setup to support that yet.
This node comes with a few new requirements for the socket items system: names
must be valid identifiers and they are initialized in a non-trivial way.
Overall, this was fairly straight forward to implement but currently it requires
to adding a bunch of new members to all the accessors that don't really need it.
This is something that we should simplify at some point even if I'm not entirely
sure how yet. The same new requirements used in this node would probably also
exist in a potential future expression node.
Pull Request: https://projects.blender.org/blender/blender/pulls/138860
Function nodes can be evaluated when determining which inputs are used. However,
for general function nodes the output value is considered to be unknown if any
of the inputs is considered to be unknown. For some built-in nodes we can do
better than that.
This patch improves the behavior for the following cases, previously the output
was always unknown:
* Float Math:
* `0.0 * x = 0.0`
* `x * 0.0 = 0.0`
* Integer Math:
* `0 * x = 0`
* `x * 0 = 0`
* Boolean Math:
* `false AND x = false`
* `x AND false = false`
* `true OR x = true`
* `x OR true = true`
* `false NAND x = true`
* `x NAND false = true`
* `true NOR x = false`
* `x NOR true = false`
* `false IMPLY x = true`
* `x IMPLY true = true`
* `false NIMPLY x = false`
* `x NIMPLY true = false`
This helps the inferencing code to be smarter on some cases.
This partially solves #139319. Although in the provided file even more complex
reasoning is necessary to fully support it. For integers it would need to keep
track of the current possible values e.g. `{0, 1}` so that when the integer is
compared to 2, it can be determined that this will always be false. This kind of
inferencing is a bit out of reach for the time being, it's not impossible
though.
Pull Request: https://projects.blender.org/blender/blender/pulls/139331
Implementation of #127106.
This is just a visual representation of the field/single/grid
status of sockets to make the workflow more intuitive. With
a visual representation for volume grid sockets, volume features
should be unblocked for further development. The structure type
will also be used to distinguish list sockets in the interface.
Group input nodes now have a "Structure Type" option instead of
the existing "Single Value Only". Usually the auto option should be
enough, but in some cases where the inferencing cannot (yet) make
a clear determination, it can be helpful to choose a specific type.
The new visualization and the group input structure type option
are hidden behind a new experimental option for now.
Pull Request: https://projects.blender.org/blender/blender/pulls/134811
This removes redundant labels from various input nodes like the Value, Integer
and Object node.
Design wise, this is mostly straight forward except for two aspects:
* Some input nodes some have a gizmo icon. In this case I just added the gizmo
icon on the same row.
* The checkbox in the Boolean input node should probably still have a label, so
I kept that.
Implementation wise this adds a new function to socket declarations that allows
us to override the draw behavior of individual sockets per node.
Pull Request: https://projects.blender.org/blender/blender/pulls/139432
This patch adds support for 2D and 4D vector sockets. The default value
structure for vectors was extended to include a new dimensions input,
which can be 2, 3, or 4. The default value was also extended to be a
float4, but only some of its components might be used depending on the
dimensions members.
Each vector subtype now has three variants ending with 2D or 4D as a
prefix depending on its dimensions, and the 2D/4D prefix was taken into
account for the socket type RNA enum functions.
All node systems currently always treat the vectors as 3D, but support
for it in the compositor will shortly follow in another patch.
Depends on #138805.
Pull Request: https://projects.blender.org/blender/blender/pulls/138824
Previously, the node group operator only had fairly basic flat drawing for the
inputs. Due to previous refactors, it's now possible to reuse the drawing code
of the Geometry Nodes modifier. That way the redo panel now has all the features
that also exist in the modifier. Also, future improvements will benefit both
systems and potentially more in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/139389
The goal is to simplify reusing the same code to draw the inputs of the node
tool operator.
This patch simply extracted all the modifier-specific code into callbacks which
are passed in from a higher level. The operator drawing code would basically
just need to provide different callback functions. Although some more additional
cleanups may become necessary to make that fully work.
Pull Request: https://projects.blender.org/blender/blender/pulls/139384
The goal is to be able to reuse parts of this code in all the places that call
Geometry Nodes. Currently, that's only a modifier and an operator. More places
may follow in the future though.
This patch does not implement any of the code-reuse yet, it just extracts the
code into a separate file. Follow-up patches will work towards better
code-reuse.
Note, this extracts the entire modifier drawing, including error messages,
baking etc. I found this to be easier, because they still often share a common
core (like getting the logged data).
Pull Request: https://projects.blender.org/blender/blender/pulls/139379
Nowadays, Geometry Nodes is not only evaluated by a modifier, but also by an
operator and in the future potentially by brushes. Therefore, the old name was
misleading because it sounded like it was specific to the modifier.
Pull Request: https://projects.blender.org/blender/blender/pulls/139378
This is used as base class for the compute contexts for group and evaluate
closure nodes. Furthermore, in the future this can be used for the compute
context that is passed into field evaluation.
Pull Request: https://projects.blender.org/blender/blender/pulls/139377
Node sockets have many different aspects that affect their visibility and
whether they are grayed out. This patch cleans up the methods used to check if
sockets are visible and adds descriptions that should make it more obvious which
ones should be used.
This also fixes a few places where the wrong method was used which is more
obvious now.
Pull Request: https://projects.blender.org/blender/blender/pulls/139251
