Split code to separate functions depending on the source of info for
socket inspection. Each function retrieves some optional string.
Collecting of result string is just loop.
Pull Request: https://projects.blender.org/blender/blender/pulls/120496
There is no context in which socket can't have data to display in tooltip.
The most basic info is the name of the socket. Such tooltip can be even
for output Shader socket. If is there, socket tooltip can be built from
data of socket declaration. Description, constraints and so. Such as supported
components. At point socket was used in evaluation on CPU, there is value
to display. Any trivial types or statistic about them value. Fields can
have dependencies, which is also can be known from evaluated value.
Pull Request: https://projects.blender.org/blender/blender/pulls/120492
Remove all BLF "_ex" versions of functions by using default arguments.
These functions only differ by having an optional argument that can
return extra details about the result of the operation. This PR just
make these part of the main function as optional arguments with default
values - all nullptr.
Pull Request: https://projects.blender.org/blender/blender/pulls/119994
The "All" library didn't exist internally when this code was first
written. The "skip_local" check that complicated this isn't necessary
because we don't add local node groups that aren't assets anyway.
This patch refactors the backdrop offset to be stored as a float instead
of an int and to be stored in the image runtime structure instead of the
image itself.
Pull Request: https://projects.blender.org/blender/blender/pulls/119877
Now that all relevant code is C++, the indirection from the C struct
`GPUVertBuf` to the C++ `blender::gpu::VertBuf` class just adds
complexity and necessitates a wrapper API, making more cleanups like
use of RAII or other C++ types more difficult.
This commit replaces the C wrapper structs with direct use of the
vertex and index buffer base classes. In C++ we can choose which parts
of a class are private, so we don't risk exposing too many
implementation details here.
Pull Request: https://projects.blender.org/blender/blender/pulls/119825
Previously, we haven't added this because there were plans to use these
declarations at a higher abstraction level where one declaration potentially
contains more than one socket. This hasn't happened yet, and we are also using
other ways to achieve dynamic socket amounts (using dynamic declarations).
Therefore, it is reasonable to simplify the code by storing the integer socket
type in the declaration directly.
Pull Request: https://projects.blender.org/blender/blender/pulls/119691
For historical reasons, the `multi_input_socket_index` was actually reversed
(large index comes first). This patch renames it to `multi_input_sort_id` and
adds a comment. This new name makes it less confusing that the id is reversed.
Pull Request: https://projects.blender.org/blender/blender/pulls/119652
Consider offset caused by transform and translate nodes in backdrop.
Affected nodes are:
- Corner Pin
- Sun Beams.
The behavior is now slightly different for rotated images (using a transform or rotate node) compared to Tiled compositor: the gizmos might move when image is rotated. The reason is the Full Frame compositor changes the image dimensions after rotation
Pull Request: https://projects.blender.org/blender/blender/pulls/119025
Over the last couple years (!) UI buttons have moved to derived classes,
meaning we don't need to use the same "a1" and "a2" variables to store
different information. At this point, that information is set specifically
by internal UI code, or functions like `UI_but_*_set`.
These values are only set to their default 0 values now (or -1 in some
non-meaningful cases). This commit removes the values from buttons
and removes the remaining a1 and a2 arguments from the UI API.
Without the extra precision, `fmt::format` rounds the resulting float to one with
fewer significant digits. This is generally nice, but not desired in this specific
case for consistency with the value stored in the socket.
Pull Request: https://projects.blender.org/blender/blender/pulls/118797
Basic motivation is that `AssetCatalogService::get_catalog_tree()`
should return a const tree, since this tree is internal state and
shouldn't be modified from outside. This exposed a whole bunch of const
incorrectnesses and just generally allows to make much more of the API
const (as it should be).
Also use references instead of pointers in testing functions, where null
is not an expected value.
PR #118382 exposed an issue where creating a catalog with non-existing
parents would trigger an endless recursion. When creating the missing
parents, the tree would be rebuilt, which would again try to create the
missing parents, for which the tree would be rebuild, etc. It just
happend to work fine for creating single catalogs with existing parents.
Rather than rebuilding the tree immediately, tag the asset library as
having "dirty" catalog data, and let code requiring the up-to-date
catalog tree (node tool menus) ensure the tree is updated if needed.
The asset library loading API should be made clearer and generally
better defined/designed, currently it's all a bit messy & confusing.
Pull Request: https://projects.blender.org/blender/blender/pulls/118463
The depsgraph CoW mechanism is a bit of a misnomer. It creates an
evaluated copy for data-blocks regardless of whether the copy will
actually be written to. The point is to have physical separation between
original and evaluated data. This is in contrast to the commonly used
performance improvement of keeping a user count and copying data
implicitly when it needs to be changed. In Blender code we call this
"implicit sharing" instead. Importantly, the dependency graph has no
idea about the _actual_ CoW behavior in Blender.
Renaming this functionality in the despgraph removes some of the
confusion that comes up when talking about this, and will hopefully
make the depsgraph less confusing to understand initially too. Wording
like "the evaluated copy" (as opposed to the original data-block) has
also become common anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/118338
This changes the drawing of the zone nodes to align corresponding input
and output sockets. The resulting nodes are smaller and it's easier to see
how data is passed through them.
Drawing aligned sockets is already technically supported for quite a while
already, but we haven't used it so far. Using them for zone nodes seems to
provide benefits only. How we use aligned sockets in other nodes still has
to be discussed more.
This patch only changes run-time data. It doesn't affect what is written to
.blend files.
In the node declaration, aligned sockets are created by tagging a socket
so that it is aligned with the previous socket. This is a bit different from
what we had before where a single socket declaration would be used for
an input and output socket. I think the approach used here works better,
especially in a potential future scenario where the input and output socket
has a different type.
Pull Request: https://projects.blender.org/blender/blender/pulls/118335
The tiled compositor code is mainly still around, which is only
expected to be a short-lived period. Eventually it will also be
removed.
The OpenCL, Group Buffers, and Chunk size options are already removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/118010
Implements the design from #116067.
The socket type is called "Matrix" but it is often referred to as "Transform"
when that's what it is semantically. The attribute type is "4x4 Matrix" since
that's a lower level choice. Currently matrix sockets are always passed
around internally as `float4x4`, but that can be optimized in the future
when smaller types would give the same behavior.
A new "Matrix" utilities category has the following set of initial nodes"
- **Combine Transform**
- **Separate Transform**
- **Multiply Matrices**
- **Transform Direction**
- **Transform Vector**
- **Invert Matrix**
- **Transpose Matrix**
The nodes and socket type are behind an experimental flag for now,
which will give us time to make sure it's the right set of initial nodes.
The viewer node overlay doesn't support matrices-- they aren't supported
for rendering in general. They also aren't supported in the modifier interface
currently. But they are supported in the spreadsheet, where the value is
displayed in a tooltip.
Pull Request: https://projects.blender.org/blender/blender/pulls/116166
