This adds a new `DNA_sdna_type_ids.hh` header:
```cpp
namespace blender::dna {
/**
* Each DNA struct has an integer identifier which is unique within a specific
* Blender build, but not necessarily across different builds. The identifier
* can be used to index into `SDNA.structs`.
*/
template<typename T> int sdna_struct_id_get();
/**
* The maximum identifier that will be returned by #sdna_struct_id_get in this
* Blender build.
*/
int sdna_struct_id_get_max();
} // namespace blender::dna
```
The `sdna_struct_id_get` function is used as replacement of
`SDNA_TYPE_FROM_STRUCT` in all places except the DNA defaults system. The
defaults system is C code and therefore can't use the template. There is ongoing
work to replace the defaults system as well though: #134531.
Using this templated function has some benefits over the old approach:
* No need to rely on macros.
* Can use type inferencing in functions like `BLO_write_struct` which avoids
redundancy on the call site. E.g. `BLO_write_struct(writer, ActionStrip,
strip);` can become `BLO_write_struct(writer, strip);` which could even become
`writer.write_struct(strip);`. None of that is implemented as part of this
patch though.
* No need to include the generated `dna_type_offsets.h` file which contains a
huge enum.
Implementation wise, this is done using explicit template instantiations in a
new file generated by `makesdna.cc`: `dna_struct_ids.cc`. The generated file
looks like so:
```cpp
namespace blender::dna {
template<typename T> int sdna_struct_id_get();
int sdna_struct_id_get_max();
int sdna_struct_id_get_max() { return 951; }
}
struct IDPropertyUIData;
template<> int blender:🧬:sdna_struct_id_get<IDPropertyUIData>() { return 1; }
struct IDPropertyUIDataEnumItem;
template<> int blender:🧬:sdna_struct_id_get<IDPropertyUIDataEnumItem>() { return 2; }
```
I tried using static variables instead of separate functions, but I didn't
manage to link it properly. Not quite sure yet if that's an actual limitation or
if I was just missing something.
Pull Request: https://projects.blender.org/blender/blender/pulls/138706
- FBX "root bone" should become the Armature object itself, and not
an extra bone (follow same logic as Python importer did).
- "World to armature matrix" was not correct for armatures that are
parented under some other objects with transforms.
- Parenting imported meshes under an Armature was not taking into
account that the mesh bind transform might not be the same as the
current mesh node transform (i.e. was not setting "matrix parent
inverse" to compensate like the Python importer did).
- The repro file in #137768 also exposed an issue that importing custom
vertex normals was not working correctly in the new importer, when
mesh is partially invalid (validation alters the mesh, custom normals
have to be set afterwards).
Pull Request: https://projects.blender.org/blender/blender/pulls/138736
It was unclear when the bone eyedropper could be used
since it stayed active even though it would be impossible to pick something.
The limitation is that an armature has to be in pose or edit mode to pick from.
Since that is the case we can check in the poll function if the active
object is an armature and if that armature is either in pose or edit mode.
Follow up to: #138182
Pull Request: https://projects.blender.org/blender/blender/pulls/138498
Minimized windows have the resolution of 0,0. The surface supports
swapchains with this resolution, however it doesn't work and leads
to crashes and UBs.
This PR fixes this to use a minimum resolution of 1,1.
Pull Request: https://projects.blender.org/blender/blender/pulls/138750
The current regression tests for the Glare Node cover most but not all
of the code. In this case, the simple_star test only tested for 45
degree rotation offset of the glare highlight.
This will add a simple_star_no_rotation.blend regression test and its
corresponding output_render png to cover the no offset case.
The function, line, and region coverage have improved by about ~9-10%
Pull Request: https://projects.blender.org/blender/blender/pulls/138587
There are two implementations:
- "Link to Viewer Node"
-- when clicking on a socket directly, link from that socket [done by
first selecting and then taking that selection state into account]
-- otherwise cycles through available sockets
- "Connect to Output" [python operator, made core from Node Wrangler]
-- does not take socket selection into account
-- only cycles through available sockets
So goal is to replicate behavior of "Link to Viewer Node" in "Connect to
Output" in terms of "which socket to link from"
This is done by
- exposing a sockets select state to python
- tweaking the call to bpy.ops.node.select so it does socket selection
as well
- take that selection into account
Pull Request: https://projects.blender.org/blender/blender/pulls/138323
Previously, nodes which had their own special internal-links-behavior were
hardcoded in node tree update code. Now that is decentralized so that more nodes
can use this functionality without leaking special cases into general code.
Pull Request: https://projects.blender.org/blender/blender/pulls/138712
Relative paths are supported, but the string input was showing an error.
This patch removes the error by tagging the string input as supporting relative files.
This feature was introduced recently in ab20edf469.
Pull Request: https://projects.blender.org/blender/blender/pulls/138707
For as long back as I have tested (2.91) using "Duplicate Area into New
Window" for Outliner when minimized (showing only header) will result
in an invalid area - at least on Windows. The area may have have a
black background, invalid screen area verts, and has the header on the
bottom. This is because it is created in a window that is our minimum
size but initialized smaller, at the height of the area (0-2 pixels).
This PR just adds a small minimum to our blender window creation.
Pull Request: https://projects.blender.org/blender/blender/pulls/138696
Sometimes, the default size of the search box is not wide enough for the items
it shows. Currently, we sometimes hardcode an extra width factor and rely on
automatic name shortening with `...`. Both options are not ideal because they
are either often too wide or are hard to read with shortened names.
This patch implements an alternative solution. It adds a new function that
computes a good width for the search box based on its content. A certain minimum
and maximum width are still enforced.
Right now, this feature is only used in the Ctrl+F search in node editors, but I
guess it makes sense in most search boxes.
This also fixes#138641. While it's nice to have ways to use shorter search
terms, the search box should generally be able to deal with long items too.
Pull Request: https://projects.blender.org/blender/blender/pulls/138653
Besides not using CustomData directly which allows future changes,
this should result in proper conversion of vertex groups to generic
point cloud attributes.
Previously, it was somewhat difficult to know if a dragged node will be attached
to a frame or not. This patch highlights the frame that dragged nodes will be
attached to which removes the guesswork. This is similar to how we highlight the
link that a dragged node will be inserted onto.
Pull Request: https://projects.blender.org/blender/blender/pulls/138648
Remove the addition of the position attribute from the default
"init data" callback where we don't know the desired number
of points. Add it in the other functions that add the data-block
(except the version that purposefully doesn't add attributes).
Pull Request: https://projects.blender.org/blender/blender/pulls/138697
Previously, nested frames were very hard to see and therefore to work with. This
patch solves this by alternating between two different frame colors depending on
the nesting depth.
Custom colors can still be used like before. There is still a single theme
option. The alternating color is derived from that.
Pull Request: https://projects.blender.org/blender/blender/pulls/138649
This converts the public `uiItemFullR` function to an object oriented
API (an overload of `uiLayout::prop`), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code (or vice-versa),
making it almost seamless.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138683
The Properties NavBar region can be resized by dragging an edge, but
this only allows either normal width or hidden. The edge is along the
line of category tabs and it is extremely easy to hide the region
rather than select a tab. This PR remove the ability to drag the edge,
but adds a "Hide" option to the region's context menu. It also leaves
the triangular disclosure widget visible while hidden so that it can
be shown again.
Pull Request: https://projects.blender.org/blender/blender/pulls/138628
While in 3D View Perspective Mode you are able to disable the Floor
and/or the XYZ axis lines. But in Orthographic views turning off the
axes lines has no effect, but turning off the grid also turns off the
lines. This PR just makes these work independently, as you'd expect
from the options in Viewport Overlays.
Pull Request: https://projects.blender.org/blender/blender/pulls/138694
The issue was caused by the shader always applying exposure even if
it is 1. When the input image had negative values this lead to nan
values to the input of the shader which converts to the display
space.
Solved by only doing to-scene-linear transform in the shader which
does this.
Caused by 18110744a2
Pull Request: https://projects.blender.org/blender/blender/pulls/138666
Going from fullscreen to temporary fullscreen (usually file browser),
and back, is AREA_FLAG_STACKED_FULLSCREEN. In this case we need to
ensure that we restore the last-used area subtype and not just the zero
base type.
Pull Request: https://projects.blender.org/blender/blender/pulls/138682
In some cases, multiple viewers can be active and the active viewer is
not the desired one. This is only a problem for the compositor
The fix has two parts:
1. Tag the node tree as changed after the output changes. This solves
the issue of two viewers being active at the same time
2. Deactivate all other viewers before activating the desired viewer
node (similar to how `NODE_OT_activate_viewer()` works). This ensures
that the only active viewer is the one that the user just set.
Pull Request: https://projects.blender.org/blender/blender/pulls/138671
As described in #122398, implement read and write support for a new
attribute storage system. Currently this is only implemented to support
forward compatibility; the format used at runtime isn't changed at all.
That can be done one step at a time during the 4.5 and 5.0 development
cycles. A new experimental option for testing tells Blender to always
save with the new format.
The main benefit of the new structure is that it matches the attribute
system design, it allows for future attribute storage optimization, and
each attribute is an allocated struct, which will give pointer stability
for the Python API.
The next step is to connect the attribute API and the RNA API to
AttributeStorage for the simplest geometry type, point clouds.
Pull Request: https://projects.blender.org/blender/blender/pulls/133874
This file is used to point to Blender's funding manifest hosted on
blender.org. This establishes provenance and verifies that that the
publisher of the manifest is authorised to solicit funding on behalf
of the URLs (entity, projects) described in the manifest.
This file is needed to participate in https://floss.fund/
(and potentially other funding initiatives).
Most of the fundraising info is hosted on blender.org/, but the format
requires a reference to the actual codebase. I think this is the least
intrusive way to achieve that.
In particular, the file is referenced by https://www.blender.org/funding.json
More info on the json file itself is available https://fundingjson.org/
Pull Request: https://projects.blender.org/blender/blender/pulls/138676
This commit improves the grammar when reporting which versions of
Blender a commit was backported to in the "bug fixes per major release"
script if it was backported to 3 or more verisons of Blender.
Before:
- Backported to 3.6.22 & 4.2.9 & 4.4.1
After:
- Backported to 3.6.22, 4.2.9, and 4.4.1
Along with this change, I now use the word "and" rather than the
symbol "&".
Pull Request: https://projects.blender.org/blender/blender/pulls/138500
The script for collecting bug fixes per release have a caching feature
to speed up frequent re-running of the script by triagers to sort
commits.
This commit changes the script so that fix commits that don't have a
known module are no longer cached.
This is done because part of the sorting of commits is making sure
they're assigned to the right module. This typically means checking
on commits with "Unknown" modules and giving them a module label.
However due to caching, triagers running the script won't see those
changes until they clear their cache. To fix this, we no longer cache
commits with unknown modules.
Pull Request: https://projects.blender.org/blender/blender/pulls/138503
This patch removes the translation Offset from the Scale node. The
reasoning is that it is easy to insert a Translate node afterwards to
perform any necessary translation. And since we are moving options to
inputs, it doesn't seem worth it to provide those offsets as inputs in
the process.
Pull Request: https://projects.blender.org/blender/blender/pulls/138668
There are two parts for this PR. One is to change some of our build pipeline to make certain libs reproducible. For this part I want to clarify two things:
1. Why change python to use `--disable-optimizations`?
This is because `--enable-optimizations` turns on PGO (Profile Guided Optimization). PGO is sadly not deterministic and will create different binaries on every recompile. So to create reproducible build this needs to be turned off. This also seems to only have been turned on for Linux specifically(?) on our side. So on Windows and Mac our python build already doesn't have PGO.
2. Why split out cython and zstandard from site-packages?
Sadly pip does not seem to respect `SOURCE_DATE_EPOCH`. It also creates temporary folders with random hashes in them that is then recorded into the Cython libraries (I'll touch on this again later). I've looked at the discussions about this upstream and sadly the pip maintainers do not really want people to use pip as a reproducible build system pipeline and instead directs users to other solutions if they want reproducible builds.
The other part is about setting up our pipeline to not introduce any random hashes or build timestamps into our libraries. Here I do two things:
1. We need to set the `SOURCE_DATE_EPOCH` environmental variable to a specific date that will not change.
This is needed as the compile time date is recorded in certain libraries and files. (So hard coding it with this env var will make the end result reproducible)
2. We need to strip the created static and shared libraries. This is because the static libraries are not created in a deterministic way. For shared libraries some of our libraries includes debug symbols which contains paths to temporary files with random hashes. To solve this without stripping in post, we would need to either patch the linker on Rocky8 or patch a lot of our libraries. I think it is better to just do this as a post build step. (This seems to be what most linux distributions do as well).
With all this, we can make our Linux library builds is almost 100% reproducible. (At least on my machine where I tested)
By almost, I mean that there is sadly a catch in that certain libraries like Cython saves the source code path in their libraries for error messages. However now the builds are reproducible if the folder path is the same.
IE if the libraries are always built in `/home/builder/build_linux/deps_x64`, then they should now be reproducible.
Pull Request: https://projects.blender.org/blender/blender/pulls/134221
Briefly about this change:
- OpenColorIO C-API is removed.
- The information about color spaces in ImBuf module is removed.
It was stored in global ListBase in colormanagement.cc.
- Both OpenColorIO and fallback implementation supports GPU drawing.
- Fallback implementation supports white point, RGB curves, etc.
- Removed check for support of GPU drawing in IMB.
Historically it was implemented in a separate library with C-API, this
is because way back C++ code needed to stay in intern. This causes all
sort of overheads, and even calls that are strictly considered bad
level.
This change moves OpenColorIO integration into a module within imbuf,
next to movie, and next to IMB_colormanagement which is the main user
of it. This allows to avoid copy of color spaces, displays, views etc
in the ImBuf: they were used to help quickly querying information to
be shown on the interface. With this change it can be stored in the
same data structures as what is used by the OpenColorIO integration.
While it might not be fully avoiding duplication it is now less, and
there is no need in the user code to maintain the copies.
In a lot of cases this change also avoids allocations done per access
to the OpenColorIO. For example, it is not needed anymore to allocate
image descriptor in a heap.
The bigger user-visible change is that the fallback implementation now
supports GLSL drawing, with the whole list of supported features, such
as curve mapping and white point. This should help simplifying code
which relies on color space conversion on GPU: there is no need to
figure out fallback solution in such cases. The only case when drawing
will not work is when there is some actual bug, or driver issue, and
shader has failed to compile.
The change avoids having an opaque type for color space, and instead
uses forward declaration. It is a bit verbose on declaration, but helps
avoiding unsafe type-casts. There are ways to solve this in the future,
like having a header for forward declaration, or to flatten the name
space a bit.
There should be no user-level changes under normal operation.
When building without OpenColorIO or the configuration has a typo or
is missing a fuller set of color management tools is applies (such as the
white point correction).
Pull Request: https://projects.blender.org/blender/blender/pulls/138433
With two or more monitors of different scales, Blender would fail to
start in some cases when it opened on a monitor at a size that wasn't
a multiple of the monitors scale.
This seemed only to cause problems with LIBDECOR however the buffer size
should always be a multiple of the buffer scale, so ensure its always
valid.
See #135764 for details (a closely related bug).
