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
The compositor currently executes when editing node trees that are not
compositor related, like geometry and shader node trees.
That's because the node space listener always tags the compositor to
execute for any node edit notifier. To fix this, we add the ID of the
edited node tree as a reference to the edit notifier and only tag for
an update when the space tree matches the reference one.
Pull Request: https://projects.blender.org/blender/blender/pulls/114978
The compositor executes superfluously on scene changes when adding or
removing objects.
This was due to an explicit handling of a certain notifier, which was
introduced in commit 1e948b251d. The exact reasoning behind the
addition is unknown, so this patch removes it until we have an informed
decision to keep it.
Makes it possible to swipe over panel header to batch open/collapse all
panels the mouse draged over. Normal panels and sub-panels support this
too.
Two changes were needed:
- Support "drag toggle" feature for `UI_BTYPE_BUT_TOGGLE` - all toggle
buttons should/can support this.
- Allow querying the pushed state from the button used for the
collapsing. Multiple ways to do this, in this case simply using the
pushed state query callback seemed simplest.
Pull Request: https://projects.blender.org/blender/blender/pulls/114560
If the draw_color method is not defined, try to use draw_color_simple as
a fallback. If not defined either, fallback to a magenta color.
The patch also updates the description of the method to clarify its use.
Pull Request: https://projects.blender.org/blender/blender/pulls/114527
Here is too many inconsistencies in used data type for coordinates.
That commit change int to float for socket draw. There is still many
node/text/other ui draw code with mix up int's and clamped floats
(to looks like int's). That fix is just small step to finally just use float.
Pull Request: https://projects.blender.org/blender/blender/pulls/114114
Customs sockets always ignore their draw_color method and are always
drawn using a magenta color.
This is a regression that was introduced in e071288ab2. The commit used
the simple variant even for drawing nodes where a context is available.
So this patch mostly reverts those changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/114148
The last good commit was 8474716abb.
After this commits from main were pushed to blender-v4.0-release. These are
being reverted.
Commits a4880576dc from to b26f176d1a that happend afterwards were meant for
4.0, and their contents is preserved.
Known limitations to be addressed separately:
* We are not warning/keeping track of the named layers.
* There is no lookup for layers (groups) yet.
Ref !113908.
Currently, we always prioritize the words in the last section of a search item
(the words that are highlighted). This generally works well, but the situation
is a bit different for link-drag-search, because there the last part is the socket
name, which is usually less descriptive than the node name.
This patch allows us to use different heuristics to select the prioritized section
per search.
Unfortunately, the link-drag-search is not fully consistent with itself. Sometimes
the last group is a socket name, but sometimes it's also the mode of a node
(`Math > Add`). Therefore, the patch currently simply prioritizes all words in the
same instead of prioritizing only the first part. This seems to work much better
than before even if not perfect in all cases yet.
Pull Request: https://projects.blender.org/blender/blender/pulls/113648
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
This helps solving the problem encountered in #113553. The problem is that we
currently can't support link-drag-search for nodes which have a dynamic declaration.
With this patch, there is only a single `declare` function per node type, instead of
the separate `declare` and `declare_dynamic` functions. The new `declare` function
has access to the node and tree. However, both are allowed to be null. The final
node declaration has a flag for whether it depends on the node context or not.
Nodes that previously had a dynamic declaration should now create as much of
the declaration as possible that does not depend on the node. This allows code
like for link-drag-search to take those sockets into account even if the other
sockets are dynamic.
For node declarations that have dynamic types (e.g. Switch node), we can also
add extra information to the static node declaration, like the identifier of the socket
with the dynamic type. This is not part of this patch though.
I can think of two main alternatives to the approach implemented here:
* Define two separate functions for dynamic nodes. One that creates the "static
declaration" without node context, and on that creates the actual declaration with
node context.
* Have a single declare function that generates "build instructions" for the actual
node declaration. So instead of building the final declaration directly, one can for
example add a socket whose type depends on a specific rna path in the node.
The actual node declaration is then automatically generated based on the build
instructions. This becomes quite a bit more tricky with dynamic amounts of sockets
and introduces another indirection between declarations and what sockets the node
actually has.
I found the approach implemented in this patch to lead to the least amount of
boilerplate (doesn't require a seperate "build instructions" data structure) and code
duplication (socket properties are still only defined in one place). At the same time,
it offers more flexibility to how nodes can be dynamic.
Pull Request: https://projects.blender.org/blender/blender/pulls/113742
The menu structure currently needs to be duplicated in the code to avoid
adding assets to more than one menu. This was done for geometry nodes
in b49c84276c but was missed for the compositor and shader
nodes. Also remove an unnecessary separator.
In !112591, nodes got the ability to group sockets into panels. The
labels for these sockets are automatically shortened if they begin
with the same text as their parent labels. For instance, "Transmission
Weight" will be shortened to just "Weight" because it is under the
"Transmission" panel.
While this is a good heuristic for English, it breaks down in
languages which do not have the same word order.
This commit adds a `.short_label()` callback to socket declarations so
that a shortened label can be explicitly declared.
It also adds two regexps to the translation script so that these new
fields can be extracted to the .po translation files. One extracts the
label with a translation context, the other without. Only the one
without context is currently in use.
The current automatic shortening logic is kept and will be used only
if a shortened label is not manually provided.
Fixes#112970: Node socket labels under panels are not shortened when
translated.
Pull Request: https://projects.blender.org/blender/blender/pulls/113070
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
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
Currently nodes are reordered so that the "on top" nodes are last in
the list. Node order changing for simple operations like selection
means we either have to reevaluate the node tree data-block on
selections or accept that the evaluated order can be different from the
original. Currently we do the latter (see d76a0e98ba), but
makes it complex to access nodes by index, and is hard to reason about.
Instead of reordering nodes, store the ui order in the node itself
and sort the nodes before drawing them or doing any processing
that depends on the "depth."
The "selected_nodes" list in the context is no longer ordered by the
recent selection.
Pull Request: https://projects.blender.org/blender/blender/pulls/113419
Move the three current 'status variables' (stop, update and progress)
into a single 'WorkerStatus' struct. This is cleaner and will allow for
future workin this area without having to edit tens of 'startjob'
callbacks signatures all the time.
No functional change expected here.
Note: jobs' specific internal code has been modified as little as
possible, in many cases the job's own data still just store pointers to
these three values. Ideally in the future more refactor will be using a
single pointer to the shared `wmJobWorkerStatus` data instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/113343
This replaces the older dynamic c arrays with blender::Vector as
appropriate. Many files required minimal changes and the before/after
are quite similar.
There's 3 remaining usages of the old machinery but those will require
more involved changes and design.
See #103343
Pull Request: https://projects.blender.org/blender/blender/pulls/110981
For some reasons, `WM_jobs_stop` and `WM_jobs_kill` would use their own
'type' of function pointer - and not even a matching one!
Among (many) other reasons why this was bad, it required very stupid
casting from code using these functions - and made editing wmJob `startjob`
signature needlessly complicated.
Nodes recently gained the ability to group inputs into collapsible
panels. These were untranslated, so this commit:
- Adds the appropriate regex to extract node panels defined with
the `add_panel()` callback.
- Adds the `IFACE()` translation macro to the drawing code for the
nodes, as well as the properties.
Pull Request: https://projects.blender.org/blender/blender/pulls/112968
