BLI code for enums that are meant to be used as "bit flags" defined
an ENUM_OPERATORS macro in BLI_utildefines.h. This cleans up things
related to said macro:
- Move it out into a separate BLI_enum_flags.hh header, instead of
"random bag of things" that is the current place,
- Update it to no longer need manual indication of highest individual
bit value. This originally was added in a31a87f89 (2020 Oct), in
order to silence some UBSan warnings that were coming
from GPU related structures (looking at current GPU code, I don't
think this is happening anymore). However, that caused actual
user-visible bugs due to incorrectly specified max. enum bit value,
and today 14% of all usages have incorrect highest individual
bit value spelled out.
- I have reviewed all usages of operator ~ and none of them are
used for directly producing a DNA-serialized value; all the
usages are for masking out other bits for which the new ~
behavior that just flips all bits is fine.
- Make the macro define flag_is_set() function to ease check of bits
that are set in C++ enum class cases; update existing cases to use
that instead of three other ways that were used.
Pull Request: https://projects.blender.org/blender/blender/pulls/148230
This patch adds support for disabling outputs in built-in nodes based on
menu inputs using a custom usage_inference callback. This just
essentially calls usage_inference_fn for outputs as well, while it was
only being called for inputs. Additionally, the usage_by_menu methods
were adjusted to only consider outputs if it is being called on inputs.
Some types were renamed to be more general, and not just for inputs.
Pull Request: https://projects.blender.org/blender/blender/pulls/148132
Currently, sometimes shader code generation fails because the code of top-level
nodes is interleaved with the code of a repeat zone. See #147747 for more
details.
Previously, the code-generation order was just the standard toposort of the node
tree, but it does not guarantee that all nodes in a zone are next to each other.
Also, it can't easily, because the zone detection itself depends on the
toposort. This patch implements another sorting step on top of the default
toposort. It packs nodes in zones together without changing the validity of the
toposort.
This is an alternative to #147999.
Pull Request: https://projects.blender.org/blender/blender/pulls/148005
The inferencing algorithm does not work reliably when the tree has cycles. So
return early and assume everything is used. The user is expected to fix the bad
link as soon as possible.
Pull Request: https://projects.blender.org/blender/blender/pulls/148009
This speeds up drawing of the UI of the Geometry Nodes modifier, especially for
very large node trees like in the files from #146949.
A couple previous commits and #147883 speed up the inferencing significantly
already. However, there is a certain limit to how fast this can be on large
complex node trees. While there is some more optimization potential, this patch
implements a cache on the Geometry Nodes modifier level. This means that as long
as the inputs and the node tree stays the same, the inferencing only has to
happen once, instead of on every redraw.
The main difficulty with this cache is that we don't have a good way to
invalidate it eagerly when any of the modifier inputs changes. That can
hopefully become simpler with #138117. For now, we have to check all input
values on redraw to check if anything has changed compared to the last redraw
and recompute the cache if there is any change.
Pull Request: https://projects.blender.org/blender/blender/pulls/147930
Geometry Nodes can generate warnings inside node trees using a Warning
node. This is used to report warnings in the modifier interface.
This commit allows translation of these warnings in the interface
template, and extracts the messages from built-in asset node groups,
by looking at each warning node.
Pull Request: https://projects.blender.org/blender/blender/pulls/147584
Now every function node except for "Sample UV Surface" supports
both list and grid outputs. Any grid or list input means the output also
has that type (combinations of grids and lists aren't supported).
However note that some nodes also have inputs that are always fields
evaluated on the target geometry.
There is still plenty of room for optimization. For grids and lists, all
the outputs will be computed, and every function node is evaluated
completely separately. It would be better to build a network similar to
fields and evaluate it lazily (when topology doesn't change anyway).
Pull Request: https://projects.blender.org/blender/blender/pulls/147312
The geometry was copied later on when it was modified because there was still a
reference to it in the modifier. Since this uses implicit sharing, if there is
more than one reference, the data has to be copied before it can be modified.
Pull Request: https://projects.blender.org/blender/blender/pulls/147644
Support loops at the GLSL level instead of relying on
NOD_shader_nodes_inline.
This improves compilation and runtime performance, avoids causing
recompilations on iteration count changes, and allows supporting
dynamic iteration counts.
(EEVEE-only)
Pull Request: https://projects.blender.org/blender/blender/pulls/145269
This fixes two annoyances when working on node groups: * One has to constantly
switch between the Group and Node tab in the sidebar. * Finding a specific group
input/output in the tree view can be annoying when there are lots of inputs.
This patch implements two features which simplify the process significantly: *
When selecting a group input/output node, activate the corresponding item in the
tree view.
* When the node has multiple sockets, use the one that's closest to the
cursor.
* Show the group interface tree view in the node properties when selecting a
Group Input/Output node.
This constains one UI change that may affect other areas: When a new tree view
is added on a redraw, the active element is now scrolled into view, instead of
the scroll bar just being at the very top. It seems generally good to me, but
could be made optional.
Pull Request: https://projects.blender.org/blender/blender/pulls/147365
This was caused by a stack-use-after-free due to passing a lambda directly
into a `FunctionRef` that keeps a reference to it. This only happened for
me in an asan build, but not in a release/debug build.
This extracts the construction of the `SocketValueInferencer` out of
`SocketUsageInferencer`. This leads to better separation of concerns and gives
the caller more flexibility. In the future, I especially want to get information
about which group input values were required to determine the usage of other
group inputs. This might help with caching the inferenced values.
Pull Request: https://projects.blender.org/blender/blender/pulls/147352
This reduces the constant overhead for the evaluation of the Geometry Nodes
modifier. Currently, it has to detect which gizmos are currently used, because
it has to potentially trigger additional evaluation to make the gizmos work.
Part of that is detecting which inputs are used, because gizmos for inputs that
are not used are hidden. Previously, it would compute whether each input is
used. This patch changes it so that only the inputs that have gizmos are
checked.
This reduces the evaluation time in my test from 2.2ms to 1.5ms.
Pull Request: https://projects.blender.org/blender/blender/pulls/147286
Previously, Repeat Zones with non-static iterations would be fully
disconnected.
With this patch, they behave as if they have 0 iterations.
Co-authored-by: Jacques Lucke
Pull Request: https://projects.blender.org/blender/blender/pulls/147211
The pattern here is very similar to `SocketValueInferencer`. The goal is to make
it easier to reuse this functionality without calling a higher level wrapper
like `infer_group_interface_usage`. This is especially useful when determining
the usage of just a subset of group inputs. I intend to use that to speedup the
detection of what gizmos should be displayed in
`foreach_active_gizmo_exposed_to_modifier`.
Pull Request: https://projects.blender.org/blender/blender/pulls/147234
This was an issue with creatiung the correct `reference_relations` between
input and output sockets. Those are necessary for the automatic lifetime inferencing.
Very similar to the layer name search added somewhat recently.
This just displays the names of existing grids in the "Name"
inputs to the Store and Get Named Grid nodes.
Pull Request: https://projects.blender.org/blender/blender/pulls/147163
The purpose of this node is to create a grid with new voxel values on
the same grid topology as an existing grid. The new values are the
result of field evaluation. Multiple grids can be created at the same
time, so that intermediate results used for multiple grids can be
efficiently reused during evaluation. This is more efficient than the
"Volume Cube" node, for instance, because the output grid shares the
sparseness of the input topology grid.
Pull Request: https://projects.blender.org/blender/blender/pulls/147074
The motivation is to keep backward compatibility after deprecating
`material.use_nodes()` and `world.use_nodes`. For example the
following script would behave the same way in 4.5 and 5.0:
```python
mat = bpy.data.materials.new("My new mat")
mat.use_nodes = True
```
Pull Request: https://projects.blender.org/blender/blender/pulls/147052
The goal is to give more information to the user without having to open the
panel. Specifically, it's useful to know if there are any warnings/errors or
just info messages.
Pull Request: https://projects.blender.org/blender/blender/pulls/147103
Adds a Join Bundle node with a multi-input Bundle socket. Bundles are
iterated on the top level of each input bundle and items added to the resulting
single bundle. While creating the final bundle existing items have priority and
new items with an already existing name are discarded.
There is an info message when there are duplicate keys in the input bundles.
Co-authored-by: Brady Johnston
Co-authored-by: Jacques Lucke
Pull Request: https://projects.blender.org/blender/blender/pulls/146750
Built-in nodes already used the functionality to hide the input labels in a few
situations. However, this functionality was not exposed for node groups before.
It required some refactoring to get the semantics of the flag right. The tricky
aspect is that "Hide Label" would be an incorrect name, because the label is
still shown under various circumstances. Instead, the flag merely indicates that
drawing code may skip drawing the label.
This adds a new "Optional Label" input for node group inputs. Other names are
possible like "Requires Label" which would be the inverse.
Overall the implementation is pretty straight forward after
1f489ea31a,
469a70dba9 and
f79896f5b9.
Pull Request: https://projects.blender.org/blender/blender/pulls/146939
In 95259228d9 an optimization was made to
simplify geometry nodes socket names on panels when they contain the
exact group title as prefix, but this leads to issue where `Opening` can
be truncated as `ing` which is not desired. Now will check if a space
character is present after the prefix, then do the truncation.
Note that this implementation still doesn't truncate `CamelCase` or any
CJK name strings because they don't use the space character as
separator.
Pull Request: https://projects.blender.org/blender/blender/pulls/146973
This implements the Menu Switch node in shader nodes. It's the same node that is
used in Geometry Nodes and the Compositor.
The Menu Switch node is purely handled during preprocessing and thus builds on
top of #141936. Hence, it's input has to be a single value, just like the
iteration count for repeat zones. This limitation can be lifted in the future,
but currently there is no way to produce a non-single menu value in shader
nodes. This will become possible if other Switch nodes are added though.
Pull Request: https://projects.blender.org/blender/blender/pulls/146896
The multi-function node evaluation code correctly didn't create a grid
with an unsupported type, but then the code crashed in the logging
code when setting default for the outputs. Instead just use a common
utility for that goal. And also add support for executing a function node
if only outputs with supported types are required (for example when
creating a grid for the "Fac" output of the noise node, but not the
color output).
Pull Request: https://projects.blender.org/blender/blender/pulls/146937
Previously, the input socket drawing code did not cover all cases with required
and optional labels for all socket types. E.g. menu sockets were never drawn
with label (unless there was some error) regardless of whether `optional_label`
was set or not.
This patch unifies the handling of this flag, i.e. all socket types support
drawing with and without label. This is also required before we can expose this
functionality to users.
Since all menu inputs had optional labels by default before, this patch makes
labels optional explicitly by changing the declaration of all the nodes. This
way, there is no expected user-visible change with this patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/146935
The new name better represents the actual meaning of the value.
"hide_value" was wrong because it didn't even hide the label in
many cases.
This property just indicates that the input is still understandable
even if the label is not drawn. It's up to the drawing code to make
the final decision whether the label should be drawn or not. This
option just gives it the opportunity to skip the label if that results
in a cleaner UI.
This removes the `SOCK_NO_INTERNAL_LINK`, `SOCK_COMPACT` and `SOCK_HIDE_LABEL`
flags from `eNodeSocketFlag`. Those are not necessary, because they just store
a copy of the data that is stored in the socket declaration and are thus
effectively runtime data.
None of these flags were exposed to Python, so there is no breakage expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/146925
This was an oversight in the initial implementation. If there is no closure,
the node should behave like if it's muted, so it passes through inputs to
outputs when the names are equal. This is the same behavior as in
Geometry Nodes.
There were two issues:
* Missing null checks when the compute context of a socket can't be detected
statically.
* Incorrect parent compute context detection for closures. The tricky aspect is
that closures can be evaluated in a different compute context from where they
are created.
Pull Request: https://projects.blender.org/blender/blender/pulls/146922
#140856 added support for output visibility inferencing. Internally, it relied
on checking whether the output value of a group is a constant fallback value,
while on the user level this is mainly controlled with the new `Enable Output`
node. While it works, there are some unexpected behaviors when the user happens
to output the fallback value without expecting the socket to be hidden.
Additionally, this approach required the output value to be inferenced, which
may trigger more evaluation than we'd want.
This patch better aligns the internal behavior with the user-expected behavior.
This is achieved by not relying on any specific fallback values. Instead, for
each output socket it does an explicit check for whether it is connected to an
Enable Output node. Then the Enable input of that node is computed and the
output visibility is derived from that directly. This is still fully composable
with nested node groups etc. It also allows extending this check in the future
to e.g. automatically disable certain anonymous attribute outputs when the
corresponding output geometry is unused.
Note, since only changes in menu sockets are allowed to change visibility by
convention, this also applies here. Same as before.
The main design on the user-level with the Enable Output node is still exactly
the same as before.
Pull Request: https://projects.blender.org/blender/blender/pulls/146918
The goal here is to simplify working with the common pattern where a Menu Switch
node is followed by an Index Switch node. This is achieved by detecting this
pattern and drawing the item names from the menu switch node in the index switch
node.
This slightly refactors the custom socket drawing callback to make it easier for
it indirectly call the default drawing function.
Pull Request: https://projects.blender.org/blender/blender/pulls/145710
Previously, the closure and bundle nodes were a bit restrictive when it comes to
socket shapes. Especially the bundle nodes did not support customizing the
socket shape at all, so they always worked with dynamic values. This was
problematic, because it meant that e.g. the outputs of the Separate Bundle node
looked like they couldn't be used as single values, and other similar issues.
With this patch, the following is supported (a few aspects were supported before
but now it all fits better together): * Support manually selecting socket shapes
in Combine Bundle, Separate Bundle, Closure Input, Closure Output and Evaluate
Closure nodes. * Automatic inferencing of shapes in all these nodes, as long as
the socket shape is set to "auto". * A new "Define Signature" option can be
enabled in the nodes. If enabled, linked nodes will also sync the socket shapes
from that node. In the future, we also want to add support for naming the
signature.
Pull Request: https://projects.blender.org/blender/blender/pulls/145550
