When units were initially defined having each on their own line was
compact, since them more fields have been added, making the lines
overly long and the difference between each field non-obvious.
Further, the conversion from C to C++ [0], wrapped definitions onto the
same line (for some reason), resulting in lines over 700 wide.
Use clang-format & add struct ID's for clarity.
[0]: 129f78eee7
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
A regression since d579ac2b3f.
Cycles delays allocation of the render buffers, which makes it impossible
to access effective render resolution during rendering. This was making the
drawing code to fall-back to the full scene resolution with only percentage
and crop accounted for.
This change makes it so an empty ImBuf is used to communicate the render
result resolution. It does not have any pixel buffer associated with it,
which actually matches the behaivor prior to the offending commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/113282
The Grease Pencil 3.0 layers and groups were not properly translated:
- The layers and groups' names were translated during display in the
layer list. Since they are data, they should be left untranslated at
this time.
- On object creation, the names "GP_Layer", "Color", "Lines", and
"Fills" were not translated at all.
This adds DATA_() macros around to translate them if the user has
enabled translation of new data names.
- The functions returning unique names for layers and groups
unique_layer_group_name() and unique_layer_name() would return
"GP_Layer" and "GP_Group" by default.
These defaults are now translated.
- When adding new layers and groups, the name was always hardcoded to
"GP_Layer" and "GP_Group" because the operators' properties for the
names defaulted to that, and prop defaults cannot be translated.
Instead, make them default to a null string, but choose an
appropriate name when executing the op. This name is chosen by
unique_layer_name() and unique_layer_group_name(), whose defaults
are now translated.
Pull Request: https://projects.blender.org/blender/blender/pulls/112930
This preserves the light linking state when collection is copied manually
via the copy-paste or duplicate functionality, but also should fix the
problem of lost light linking state when adding a collection override.
Pull Request: https://projects.blender.org/blender/blender/pulls/113243
This patch implements the Keying Screen node for the Realtime
Compositor. Draw data was introduced to the Movie Clip ID to allow
caching of the keying screen.
Pull Request: https://projects.blender.org/blender/blender/pulls/113055
Caused by d579ac2b3f
This change restores the behavior of the flag to how it was prior to
the refactor which used ImBuf for storage in the RenderResult.
This flag still has issues with configurations when there are multiple
scenes in the .blend file, and that it is only "valid" when the image
is actually displayed. However, these limitations and quirks already
existed prior to the refactor commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/113199
Previously, the geometry nodes modifier was converting the
viewer path to a compute context at the same time as it was
setting up side effect nodes for the geometry nodes evaluation.
Now, this is changed to be a two step process. First, the viewer
path is converted to the corresponding compute context.
Afterwards, a separate function sets side effect nodes up so
that the given node in the given compute context will be evaluated.
This has three main benefits:
* More obvious separation of concerns.
* Can reuse the code that maps a viewer path element to a compute
context already.
* With gizmo nodes (#112677), it may become necessary to add side
effect nodes based on a compute context, but without having a
corresponding viewer path.
The position validation when manipulating node group items now includes
outputs..inputs order in addition to sockets..panels order. The method
for finding a valid position has been simplified, it's just a single
iteration of insertion sort.
Versioning has been added to ensure files from 4.0 alpha with
potentially unsorted sockets get re-sorted. This uses `std::stable_sort`
so that sockets keep their relative order apart from the input/output
grouping.
Pull Request: https://projects.blender.org/blender/blender/pulls/113060
This case probably hasn't been triggered before because we rarely move individual
const-components around between geometry sets. This happened in #113083 in the
optimization when all elements are in the same group.
Pull Request: https://projects.blender.org/blender/blender/pulls/113160
Sometimes .blend files have compatibility issues between Blender versions,
because .blend files depended on the specific order of geometry elements
generated by some nodes/modifiers (#112746, #113018). While we make
guarantees about the order in some places, that is relatively rare, because it
makes future improvements much harder. The functionality in this patch
makes it easier for users to notice when they depend on things that are not
expected to be stable between Blender builds.
This is achieved by adding a new global flag which indicates whether some
algorithms should randomize their output. The functionality can be toggled
on or off by searching for `Set Geometry Randomization`. If there are no
differences (or acceptable minor ones) when the flag is on or off, one can
be reasonably sure that one does not on unspecified behavior (can't be 100%
sure though, because randomization might be missing in some places). If
there are big differences, one should consider fixing the file before it comes
to an actual breakage in the next Blender version.
Currently, the setting is only available when `Developer Extras` is turned on,
because the setting is in no menu.
With this patch, if we get bug reports with compatibility issues caused by
depending on indices, one of the following three cases should always apply:
* We actually accidentally broke something, which requires a fix commit.
* Turning on geometry randomization shows that the .blend file depends on
things it shouldn't depend on. In this case the user has to fix the file.
* We are missing geometry randomization somewhere, which requires a fix
commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/113030
Separate user configuration of subpixel antialiasing from the hinting
options. For example, this allows turning this on while hinting is
"None", or off when hinting is "Full".
Pull Request: https://projects.blender.org/blender/blender/pulls/113027
The grid was pointer was moved to the next element at every loop, which
made `vi.grid` and `vi.mask` disagree. Instead, iterate the grid before
accessing data, so the pointers agree. To avoid unrolling the first loop
iteration or adding a branch for the first iteration, start the grid at
a -1 offset.
Pull Request: https://projects.blender.org/blender/blender/pulls/113015
For text objects, the CharInfo mat_nr material index used to start at 1
(not at zero like for meshes or nurbs).
Code was mostly considering this (but not in all places, so material
index handling (removing/moving) could still go wrong.
As an alternative to !109746 (where it was made sure all places would
make the right assumption about mat_nr starting at 1), this PR now
changes the mat_nr to be zero-based.
This is more in line with other places handling material indices.
Versioning code is in place to properly convert old files.
Fixes#109491
Pull Request: https://projects.blender.org/blender/blender/pulls/112954
After 97f2b01ea9, the iterator's mask data is just read only,
so there's no point in storing it as a pointer. This simplifies the code
using the mask data, since the default only needs to be handled once.
The expand operator reused `SCULPT_UPDATE_MASK` even when it
changed face sets, not the mask. That triggered incorrect behavior in
`node_update_mask_redraw` when there was no mask layer, which caused
nodes to be incorrectly marked as fully masked (and therefore optimized
out of later operations).
The expand operator reused `SCULPT_UPDATE_MASK` even when it
changed face sets, not the mask. That triggered incorrect behavior in
`node_update_mask_redraw` when there was no mask layer, which caused
nodes to be incorrectly marked as fully masked (and therefore optimized
out of later operations).
For Blender 4.0 we decided to support individual icons for different
snap elements.
This was originally contributed by Erik Abrahamsson as !107054 with
some contributions by myself (Germano).
This set of icons being simple geometric symbols, that should be
familiar to CAD artists.
Note that Face and Volume share the same icon (circle). This is
deliberate since they communicate a similar functionality - are not
aimed at precision snapping the same way the vertex or perpendicular
are.
Also note that later we should also try to change the icons shown in
the snap menu to match the symbols that the artists see in the preview
window.
———
On the decision process:
The version currently in main (and rolled back here) was an initial
attempt of aggregating more information to the icons (e.g., by aligning
the icons to the target edges) while making them more suitable to
Blender. After presenting both options to (parts of the) community,
there was nothing fundamentally broken found with either option, though
options diverged over personal preference.
With that in mind, in the latest UI module meeting it was agreed to use
the original proposal then.
This final call was proposed by Dalai Felinto on his role of
commissioner (stakeholder) for the snap polishing tasks (#73993) and
designer for the related Snap Base design #66484.
———
This commit reverts commit 9c2e768f5b.
The reverted icons (referred originally as minimalistic icons) may be
proposed later as a separate theme option.
Caused by a subtle logic change in 17d161f565 and follow ups.
Because they used to be stored in a singly-linked list, the old storage
for `corners_by_space` was backwards compared to the order each corner
was discovered in `split_loop_nor_fan_do`. I don't fully understand how
yet, but the logic when setting edges sharp based on divergence between
neighboring corner normals in a space relied on the iteration direction,
so as a fix, just iterate backwards over the corners in each space.
