Node:
- Rename "Z Combine" node to "Depth Combine"
Sockets:
- First input "Image" -> "A"
- Second input "Image" -> "B"
- First Z -> "Depth A"
- Second Z -> "Depth B"
- Output Image -> "Result"
- Output Z -> "Depth"
This is a breaking change for the Python API
Pull Request: https://projects.blender.org/blender/blender/pulls/141676
This file is rather big. I'm working in it quite a lot, and find it very
hard to navigate in. I constantly get lost or spend time manually
looking for things.
Move the file to a directory, add an internal header, and split out
filtering and sorting code into own files. I'm sticking with these for
now to not cause too many conflicts with blender/blender!130543, which
does a lot of changes/additions to filelist.cc.
Pull Request: https://projects.blender.org/blender/blender/pulls/141744
The clipping flag of curve templates is applied only to point positions,
but allows zooming beyond the clip range due to numerial error.
If clipping is disabled the curve view rect is still restricted to
clip ranges (this could be considered a bug). However, zooming in and
back out leaves a tiny offset to the clip rect that allows one more
zoom-out step.
This patch ensures the curve rect is always within the clip rect.
When the difference is very small the view rect is snapped to the clip
rect.
Pull Request: https://projects.blender.org/blender/blender/pulls/141275
This patch allows allocating results on the host even if the context
uses GPU. It also adds support for uploading the host result into a GPU
allocated result. This is done to allow using results for storing data
that gets computed on the CPU be end up on the GPU, like some of the
cached resources used by the compositor. Those resources are refactored
accordingly in this patch as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/141745
Regression in 3.6 caused the orthographic camera gizmo to enter a
feedback loop where the gizmo range was changed while being interacted
with.
Resolve by preventing the range being updated during modal interaction.
Standardize on using `pxr::UsdTimeCode time` rather than the assortment
of other uses we had including:
- double motionSampleTime
- double motion_sample_time
- float time (!)
- pxr::UsdTimeCode timecode
This matches what the USD API itself uses.
The only exception is for the APIs and types defined in usd.hh that need
to be useable inside Blender itself. Those will remain unchanged and
continue to use "double motion_sample_time".
Pull Request: https://projects.blender.org/blender/blender/pulls/141756
Some Wintab drivers can randomly crash while loading. Guard against this
by catching such exceptions using SEH. Also save and restore the current
unhandled exception filter as some drivers replace it with their own for
some reason.
Pull Request: https://projects.blender.org/blender/blender/pulls/141685
Windows.h, otherwise we can get errors about the use of std::min
and std:max because of a conflict with macro definitions of "min"
and "max" in Windows.h. The reason for this being needed now and
not earlier is because of changes to an updated windows SDK
installed by a recent security update.
Pull Request: https://projects.blender.org/blender/blender/pulls/141696
This implementation is fatally flawed in a couple ways, the most
important of which is related to multiple windows on separate monitors.
Basically the refresh would cause recreation of action zones when they
are not expected to change, resulting in complaint #141521. This also
causes too many refreshes of gizmos. I don't currently have any ideas
on a better way of doing this so we'll have to do without for now.
Pull Request: https://projects.blender.org/blender/blender/pulls/141743
Blender expects float buffers to be in scene linear space, which was
violated bu the 1012bit movie reading code. While such image buffers
can be displayed correctly, performing operations in various areas
of Blender might lead to unexpected results.
The non-linear colorspace for ImBuf is expected to be "internal-only"
to a specific area, like VSE.
This is only done for Image and MovieClip data-blocks, sequencer still
reads movie files in their original colorspace as it helps performance and
sequencer can not be referenced from places where linear colorspace
for float buffer is really important.
Pull Request: https://projects.blender.org/blender/blender/pulls/141603
On systems with multiple Intel GPUs with a mix of recent and old
unsupported drivers (such as 101.3302), the Level-Zero stack may have
troubles initializing, leading to a crash while enumerating devices.
Luckily this condition actually leads to an exception we can catch,
as implemented here in this commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/141674
Fix the ID user count when changing `posebone.custom_shape`.
The code uses `reinterpret_cast<ID *>(pchan->custom)` instead of
`&pchan->custom->id`, as the former is `nullptr`-safe.
Pull Request: https://projects.blender.org/blender/blender/pulls/141726
Some parts of the UI (e.g., the boolean node) had renamed the 'fast'
solver to be the 'float' solver, since with the advent of the manifold
solver, it is no longer really right to characterize the float one
as the (sole) fast one. This commit finishes the job.
It does have the effect of changing the string needed within the
Python API to select the float solver, so this is a (minor)
API-breaking change.
In this report, adding the "resolution" attribute didn't clear the
evaluated positions cache. In some cases capturing an attribute on
the mesh might just add the mesh rather than using an attribute
writer.
When manually setting a group's vertex weight, auto-normalization would
fail in some circumstances, such as when all other groups are locked.
The root cause of this issue was our approach for ensuring that the
weight specified by the user remained as-is when possible during
normalization. Rather than "when possible", it erroneously *always*
ensured the weight stayed as-is even when that made normalization
impossible. It came down to this:
1. Normalization is done as a post process, with no knowledge of what
changes were just made to the weights.
2. In order to (try to) make up for that and ensure that the just-set
weight remains as the user specified, the active group was
temporarily locked during normalization, which could prevent
normalization in some cases.
This PR fixes the issue by introducing a new internal-only concept of
"soft locked" vertex groups to the normalization functions, intended to
be used in exactly these cases where there are weights that have just
been set and we want to avoid altering them when possible. Soft-locked
groups are left untouched whenever normalization is achievable without
touching them, but are still modified if normalization can't be achieved
otherwise.
This has been implemented by introducing a new bool array alongside the
"locked" bool array in the core normalization functions. Although all
uses in this PR only ever specify a single group as "soft locked", using
a bool array will make it easy to use this concept in other weight
painting tools in the future, which may modify more than one group at
once.
Pull Request: https://projects.blender.org/blender/blender/pulls/141045
- Add code documentation.
- Use Span and references rather than pointers everywhere.
- Move all core normalization logic into
`BKE_defvert_normalize_lock_map()`, and have the other variants call
that. This keeps all the logic in one place, which will help make
future changes easier since they only need to be made in one place.
- Add unit tests for `BKE_defvert_normalize_lock_map()`.
- Refactor `vgroup_normalize_all()` to be clearer and avoid an
unnecessary `goto`.
- Make both `vgroup_normalize_all()` and `paint_weight_gradient_exec()`
only call into a single core vertex normalization function, rather
than branching into one of many.
No functional change intended.
