Prepare for #140378 by replacing all uses of `ResourceHandle` inside
the engine code with `ResourceHandleRange`.
Aside from the replacement, this changes `ResourceHandleRange` itself
to ensure we use them correctly:
- Prevent direct access to the first handle, to avoid not taking ranges
into account by mistake.
- Add missing functions that are safe to use for ranges
(`has_inverted_handedness` and `is_valid`).
- Add functions that aren't safe to use for ranges, but are required
for the code paths that don't support them yet (these functions assert
that the range points to a single handle, and therefore can be used
safely).
The main change is in `draw_handle.hh`, everything else is just a 1:1
port to use these new functions.
Pull Request: https://projects.blender.org/blender/blender/pulls/140611
Improves the screenshot selection UX by ensuring the selection
rectangle stays within the window.
**Changes**
- Clamp the selection rectangle while dragging the cursor,
preventing it from extending outside the window.
- When shifting the selection area, movement is constrained
so that the entire rectangle remains within the window.
- When `force_square` is `true`, the square is clamped to the
largest possible square that fits within the window bounds
if it would otherwise exceed them.
Pull Request: https://projects.blender.org/blender/blender/pulls/139805
Fix#140813 crash, when bevel operation doesn't choose proper representative
face (called frep, facerep or rep_face in code). In such scenario a nullptr
would be assigned to uv_face->attached_frep field in register_uv_face function
and later, as a result of that, BM_face_vert_share_loop function would crash
during call to update_uv_vert_map function.
This commit also includes additional safety check in register_uv_face function,
as well as removes compiler warning about assigned but unused center_bme variable.
This is from PR https://projects.blender.org/blender/blender/pulls/140864
but applied to the 4.5 release branch.
Fix#140813 crash, when bevel operation doesn't choose proper representative
face (called frep, facerep or rep_face in code). In such scenario a nullptr
would be assigned to uv_face->attached_frep field in register_uv_face function
and later, as a result of that, BM_face_vert_share_loop function would crash
during call to update_uv_vert_map function.
This commit also includes additional safety check in register_uv_face function,
as well as removes compiler warning about assigned but unused center_bme variable.
This is from PR https://projects.blender.org/blender/blender/pulls/140864
but applied to the 4.5 release branch.
CustomData lookup is very expensive compared to everything else
happening in this function. Use a slightly ugly approach to avoid it
when the display type isn't "Attribute" or "Texture". This gives a 5%
FPS playback improvement in the Erindale Flower shop demo file.
Pull Request: https://projects.blender.org/blender/blender/pulls/140547
This patch removes the Texture node from the compositor, which was based
on the legacy Internal Textures system in Blender. The main motivation
for removing this node is as follows:
- Procedural texturing nodes that previously existed in shading and
geometry nodes are now supported in the compositor, which cover 95% of
what is previously possible using and even adds new possibilities like
Gabor, Bricks, and various improvements to existing texture types.
- The old texture system did not support GPU evaluation, so it was
always computed and cached on the CPU, which causes bad performance
especially for interactive use in the viewport compositor. While the
new nodes are fully GPU accelerated and do not require any caching.
- The Texture node didn't support Texture nodes, so it was not fully
supported and we so far had a warning about that.
- The general direction in Blender is to remove the old texture system,
and the compositor was one of the last main users of it. 5.0 is thus
the ideal time to remove such use.
- The Texture node was always and still is a source of bugs, since it
relies on proper tagging for cache invalidation and updates, which is
so far not perfect. It also suffers from UI/UX issues, since it needs
to be adjusted from the properties panel, which can break if there are
other texture nodes in the context.
This is a breaking change and no versioning was attempted since:
1. It is impossible to get the same results as before due to the use of
different random number generators, so any versioning would just give us
the general look.
2. The Texture node supports a lot of possible configurations. For
instance, each general texture can have many options for the basis type,
and each basis type might have multiple options. So versioning all of
that will take a lot of time, code, and effort.
Pull Request: https://projects.blender.org/blender/blender/pulls/140545
This change enables HDR support for wayland as an experimental feature.
It supports both non-linear extended sRGB and un-clamped sRGB.
Windows isn't supported as the HDR settings are not accessible via an
API and would require similar settings that games use to configure the
monitor. Adding those sliders isn't what we would like to add.
Vulkan (working group) is working on new extensions that might change
the shortcomings. It isn't clear yet what the extension will do and what
the impact is for applications that want to use it. When the extension
is out we should review at the situation again.
Pull Request: https://projects.blender.org/blender/blender/pulls/133159
Yesterday's 7276b2009a commit splitting idprops between 'user' and
'system' defined ones fully broke brushes in the UI.
The issue is, Asset metadata stores additional info in its idprops,
without exposing them to user, but without creating RNA access for them
either.
For now, revert their RNA definition to be 'user-defined' ones, enabling
their access through 'dict-like' syntax in Python.
On the longer run, we probably want a cleaner solution for them. While
the issue is similar to the 'Node Modifier' (and 'Node Tool') cases, not
sure if we would actually want to define RNA access for these asset
metadata, as they are likely more like a 'raw data' container, without
requirement for setters, getters, updates etc. that are provided by
actual RNA properties?
So maybe we rather need to define a proper way to access this type of
storage (raw idprops, but strictly managed by Blender, and not the
user)? Could be by exposing them as an explicit property, with probably
a new sub-type of `PropertyGroup`?
CC @JulianEisel & @dr.sybren
The metaball selection radius was inside the cube and could only
be selected with wire-frame shading.
Resolve by expanding the radius by the dimensions of the cube.
The issue was that the summary channel was marked as
possible to do NLA mapping in `ANIM_nla_mapping_allowed`.
When it comes to doing the actual mapping it would silently do nothing
though because `bAnimListElem.adt` is always a `nullptr` for the summary.
However in `action_select.cc:580` the `KED_F1_NLA_UNMAP`
and `KED_F2_NLA_UNMAP` flags were already removed.
Those flags tell the summary line to do NLA mapping in `keyframes_edit.cc:368`.
(We may be able to remove those in the future)
The fix is to ensure that the summary line is
recognized as unable to do NLA mapping. That makes sense to
me at least because the summary line points to data but in itself
does not know about the NLA.
As a side effect, this also fixes circle select.
Pull Request: https://projects.blender.org/blender/blender/pulls/140664
ASAN report errors for a value of -1 (all bits high) but
dones't for a value of 0. In this case it doesn't matter which
of the two values are used since they are both invalid and
will be updated inside `assign_if_different`.
The goal here is to reduce our reliance on the existing field inferencing code
and use the new and more general structure inferencing code instead.
This patch changes patch refactors link drawing so that whether links are drawn
dashed does not depend on field inferencing anymore. Same for the invalid field
links.
I don't expect that this changes the drawing of any existing links. It just
makes it easier to fully remove the old field inferencing in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/140869
Regression in [0] which moved the logic from
knife_closest_constrain_to_edge from 2D to 3D space.
The 3D location used (kcd->curr.cage) didn't have constraints
applied, causing snap not to lock to the constrained axis.
Resolve by passing in the constrained location which is then used when
edge snapping is calculated.
[0]: 7249b78b6b
One obvious problem is that `mr.use_simplify_normals` was assigned after
face corner normals were retrieved. The other more complex problem is
that now the normals caches automatically mix custom normals from other
domains. This can cause the expensive "Tangent Space" normals to be
calculated even though we don't explicitly request face corner normals.
To fix this, clarify the purpose of the option to only apply to that custom
normals format and use the true normals instead in that case.
Pull Request: https://projects.blender.org/blender/blender/pulls/140879
Problem - offset collision check for bevels did not consider the reduced
offset when using bevel edge weights, thus greatly reducing the allowed offset.
Solution - calculate the offset check using the weighted value and not
the full offset.
Alternatives - Since this error was introduced in the patch dd334faa58
a solution would be to revert the patch. This is not optimum since the
patch did correct the inf/inf condition in the offset calculation (ex at
90 degs, tan is 1/0).
Limitations - This patch is a correction to return the bevel function to
it's previous abilities. Further work is needed to properly handle edge
offset interference when looking at n-gons with reflex angles. There are
also situations where the bevel operation exceeds the checked offset distance
(exs. inner arc spread and bevel profiles that are not normal to the bevelled edge).
Caused by 7276b2009a.
Turns out that for the same reasons as the Nodes modifier, Operator RNA
struct also needs to keep the 'old' IDProperties access for now, to
support Node Tools.
Can't wait for #132129 to be implemented...
It is possible for a vertex to be processed by some function that
attempts to calculate the average of an attribute of all neighboring
elements when all elements are hidden. This results in NaN when using
`math::rcp` for the size of the related indices.
This commit switches the `rcp` call for the safe variant and removes an
invalid assert that previously existed.
Further cleanup to consolidate the various different average methods
will occur in the main branch (e.g. the `check_loose` and `interior`
functions)
Pull Request: https://projects.blender.org/blender/blender/pulls/140569
This commit cleanly splits IDProperties storage for its two very different
usages:
* "User-defined" data, also known as "custom properties". Mostly exposed
in UI and as 'dictionary' in Python scripting, these are unique to each data
(each object can have its own set of custom properties).
* "System-defined" data, mainly as backend-storage for runtime RNA
structures and properties. While these are not necessarily present in the
storage, they are registered for a data type, and therefore always available
to all data of that type through RNA access.
See #123232 for rationales, designs and alternative investigated solutions.
## User-facing Changes
When using Blender, the only noticeable change is that python-defined RNA
data are not listed anymore in the Custom Properties panels (e.g. Cycles
data).
From a Python API perspective, the main changes are:
* Runtime RNA structs defined by sub-classing `PropertyGroup` and
registering them are no more accessible through the 'dict' syntax.
* They remain accessible through a dedicated 'bl_system_properties_get()`
callback, but its usages are only expected to be for testing and
debugging.
* The result of this call will be `None` by default when there has been
nothing written into it yet, unless its optional `do_create` parameter
is set to `True`.
* Some types (like `Node`, `UIList`, etc.) cannot store raw IDProperties
anymore (using the 'dict' syntax).
## Technical Details
* Adds System idprops to some data types (IDs, ViewLayer...).
* Moves some other containers (e.g operator properties, or some UI types like
UILists) to only have system-defined properties.
* For a few specific types (like `PropertyGroup`), the same storage is used,
but exposed in RNA as both user and system properties.
* Adds RNA API accessor callback to system idprops.
* Adds a function `bl_system_properties_get()`, which wraps system-defined
idprops and gives 'dict-like' access to them. Currently mainly used by some
unittests.
* System IDProps are always ignored by RNA diffing code (and therefore
liboverride processing), as their value is already exposed through RNA
properties, and should always be processed through these RNA properties.
* Modifies bpy rna binding to use these new system idprops for property
accesses, and keeps using user-defined idprops for 'dict-type' accesses.
* Handles versioning by copying 'user idprops' (existing ones) into new
'system idprops'.
### IDProperties Split
These types keep their historic IDProperty storage for user properties,
and get a new `system_id_properties` storage for system properties:
`ID`, `ViewLayers`, `Bone`, `EditBone`, `BoneCollection`, `PoseBone`, `Strip`
These types can both be extended with registrable RNA properties, and
expose Custom Properties in the UI.
### IDProperties become System Ones
These types keep a single IDProperties storage (their DNA struct does not
change), but it is now exclusively used for system-defined properties.
`OperatorProperty`, `View3DShading`, `UIList`, `AddonPreferences`,
`KeyConfigPreferences`, `GizmoProperties`, `GizmoGroupProperties`,
`Node`, `NodeSocket`, `NodeTreeInterfaceSocket`, `TimelineMarker`,
`AssetMetaData``
Since user properties were never available in the UI for them, they lose
their 'dict-like' IDProperties access in the Python API.
### Single Storage, Exposed as Both in API
These types still use a single IDProperty storage, but expose it both as
user properties and as system ones through RNA API.
* `PropertyGroup`: They need both access APIs since they are both
used for raw IDProperty groups (the 'dict-like' access), and
internally to access data of runtime-defined RNA structs.
* `IDPropertyWrapPtr`: Done mainly to follow `PropertyGroup`.
* `NodesModifier`: cannot become purely system idprops currently, as
there is no other access than the 'raw ID properties' paths to their
values. This can be changed once #132129 is finally implemented.
Pull Request: https://projects.blender.org/blender/blender/pulls/135807
Maths nodes in files saved in late v4.5 will load as undefined in 5.0.
That's because versioning ran for versions before 4.5, not after. To fix
this, we move versioning to 5.0 to cover such cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/140868
Typically, we use this function to determine whether or not a subset of
data that has been collected with `gather` needs to be then persisted
into a larger array with `scatter`. As such, it makes sense to assert on
equality of the indices and smaller array size.
Pull Request: https://projects.blender.org/blender/blender/pulls/140752
We need to ensure that the compositor preview depsgraph gets updated
properly after undo, now that the compositing node tree is not embedded
in the scene anymore.
A test case will be committed separately in #140595
Pull Request: https://projects.blender.org/blender/blender/pulls/140596
This allows such functions' callbacks to receive the 'self' data as a
PointerRNA, instead of a pointer of the relevant DNA type.
This commit also adds some validation of flags when defining them for
a FunctionRNA.
Part of !135807.
