While in practice an overflow seems unlikely in this particular case,
internal path manipulation assume FILE_MAX_LIBEXTRA so passing in
smaller buffer sizes is error prone.
Many "UV island" style operations internally use #UvElementMap, including:
- Transform tools
- Smart-Stitch
- UV Pinch, UV Grab and UV Relax sculpt tools.
Normally, every UV in the mesh is included in the #UvElementMap.
However, with hidden geometry, only the visible geometry is included in the map. [0]
This change enforces stricter usage, reducing the chance of crashes in other areas.
Regression from [0] which was a fix for "UV Island calculation doesn't ignore hidden faces" [1].
[0]: 8f543a73abc42843fb924fc6d849e3055e3ae011
[1]: #99659
Pull Request: https://projects.blender.org/blender/blender/pulls/108130
Adds stencil texture view support for Metal, allowing reading of
stencil component during texture sample/read.
Stencil view creation refactored to use additional parameter in
textureview creation function, due to deferred stencil parameter
causing double texture view creation in Metal, when this should
ideally be provided upfront.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/107971
Only Embree CPU BVH was built in the multi-device case. However, one
Embree GPU BVH is needed per GPU, so we now reuse the same logic as in
the other backends.
Pull Request: https://projects.blender.org/blender/blender/pulls/107992
Similar to other screen options, add one for Spreadsheet editors that
makes them update when playing animation.
NOTE: there are some editors that always update when playback was
invoked from an animation editor while others only do this when their
respective option is specifically set (think the later behavior fits the
spreadsheet better).
Pull Request: #108002
In the DrawManager a dummy texture was attached to the a, au, c, ac
binding points. In the shader those binding points are actual texture
buffers.
The reason for the dummy texture was to work around some OpenGL driver
bugs. In Vulkan (and expected also in Metal) it is not allowed to attach
a texture as a texel buffer. Fixing this would require copying buffers into a
buffer during binding.
This patch will remove the binding of the textures and use the vbos
instead. Also it fixes an issue where a platform does support compute
shaders, but don't support transform feedback. This is currently the
case for the Vulkan backend.
Pull Request: https://projects.blender.org/blender/blender/pulls/108139
In dd32dac60f, the "A" and "B" input socket from the Mix node were
disambiguated, so as not to confuse them with Alpha and Blue.
These messages are used in other nodes and elsewhere in the same
sense, so this commit adds translation contexts to these occurrences
as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/108051
The Vector Math node's label has a special function used to compute
its label based on the currently selected operation. This operation,
like that of the Math node, is extracted using the "NodeTree"
translation context.
Therefore, in this function it must also use the same context to
translate the label.
In addition, a few node types can have an "Unknown" label if there is
a problem with their internal state (operation, filter type, blending
type). This message can also be translated.
Pull Request: https://projects.blender.org/blender/blender/pulls/108029
Some property labels need a context to disambiguate them from others
which have the same name.
The only way to show the proper text currently for such properties is
to override it in the UI code with a translation context, like:
```python
layout.prop(obj, "area", text="Area",
context=i18n_contexts.amount)
```
Python properties already store a translation context though, but this
context cannot be chosen from a Python script.
For instance, typing:
```python
bpy.types.Scene.test_area = bpy.props.BoolProperty(name="Area")
print(bpy.context.scene.bl_rna.properties['test_area'].translation_context)
```
will print `*`, the default context for Python props.
This commit allows specifying a context in this manner:
```python
from bpy.app.translations import contexts as i18n_contexts
bpy.types.Scene.test_number_area = bpy.props.BoolProperty(
name="Area", translation_context=i18n_contexts.amount
)
print(bpy.context.scene.bl_rna.properties['test_number_area'].translation_context)
```
will now print `Amount` and can be translated differently from other
labels. In this instance, the word for a surface area measurement,
instead of a UI area.
-----
This is what translated properties look like using the existing ("Area", "") and ("Area", "Amount") messages:
The panel can be generated with this script:
[python_prop_contexts_test.py](/attachments/ab613cdc-8eba-46bc-8f3c-ad0a97e7a6e5)
Pull Request: https://projects.blender.org/blender/blender/pulls/107150
Some property labels need a context to disambiguate them from others
which have the same name.
The only way to show the proper text currently for such properties is
to override it in the UI code with a translation context, like:
```python
layout.prop(obj, "area", text="Area",
context=i18n_contexts.amount)
```
Python properties already store a translation context though, but this
context cannot be chosen from a Python script.
For instance, typing:
```python
bpy.types.Scene.test_area = bpy.props.BoolProperty(name="Area")
print(bpy.context.scene.bl_rna.properties['test_area'].translation_context)
```
will print `*`, the default context for Python props.
This commit allows specifying a context in this manner:
```python
from bpy.app.translations import contexts as i18n_contexts
bpy.types.Scene.test_number_area = bpy.props.BoolProperty(
name="Area", translation_context=i18n_contexts.amount
)
print(bpy.context.scene.bl_rna.properties['test_number_area'].translation_context)
```
will now print `Amount` and can be translated differently from other
labels. In this instance, the word for a surface area measurement,
instead of a UI area.
-----
This is what translated properties look like using the existing ("Area", "") and ("Area", "Amount") messages:
The panel can be generated with this script:
[python_prop_contexts_test.py](/attachments/ab613cdc-8eba-46bc-8f3c-ad0a97e7a6e5)
Pull Request: https://projects.blender.org/blender/blender/pulls/107150
The node socket extraction regexes introduced in 6d39ba7b41 suffered
from two issues:
1. the contextless name extraction would also extract socket names
which did have a context. To solve, this, use a negative lookahead
at the end of the regex, containing ".translation_context(".
2. the number of characters in a message was limited to 1, because the
_str_base component would match one or more chars after the first
one, while it should have matched zero or more.
This last issues existed before, and the fix allows the extraction of
three new messages.
Pull Request: https://projects.blender.org/blender/blender/pulls/108052
Mark `NlaStrip.frame_{start,end}` and `NlaStrip.frame_{start,end}_ui` as
to-be-ignored for the library override system, and add a new set of RNA
properties `frame_{start,end}_raw` that the library override system can
use.
Versioning code ensures that overrides on `frame_{start,end}` are
altered to be applied to the `..._raw` counterpart instead.
The override system uses RNA to update properties one-by-one, and the
RNA code trying its best to keep things consistent / valid. This is very
much desired behaviour while a human is editing the data.
However, when the library override system is doing this, it is not
replaying the individual steps (that each end in a valid configuration),
but just setting each property one by one. As a result, the intermediate
state can be invalid (for example moving one strip into another) even
when the end result is perfectly fine.
This is what the `..._raw` properties do -- they set the values without
doing any validation, so they allow the library overrides system to move
strips around.
This assumes that the result of the override is still valid. Logic to
detect invalid situations, and reshuffle the NLA strips if necessary, is
left for a future commit as it is related to #107990 (NLA Vertical
Reorder).
Additionally, this commit adds functions
`BKE_lib_override_library_property_rna_path_change()` and
`BKE_lib_override_library_property_search_and_delete()` to the library
override API. The former is used to change RNA paths of property
overrides, and the latter is used to remove a property override
identified by its RNA path.
Hardware Raytracing wasn't properly disabled or enabled in the
subdevices of the multi-device.
This construct:
foreach ( DeviceInfo &info,
(device.multi_devices.size() != 0 ?
device.multi_devices : vector<DeviceInfo>({device}))
)
was a nice trap - it was giving a copy to iterate on.
Pull Request: https://projects.blender.org/blender/blender/pulls/107989
This is necessary for correctness of the code to avoid duplicate symbols.
In practice, this wasn't necessary yet, because usually we pass lambdas
into these functions which cause every instantiation to have a different
signature.
Alignment here means that the size of the range passed into callback
is a multiple of the alignment value (which has to be a power of two).
This can help with performance when loops in the callback are are
unrolled and/or vectorized. Otherwise, it can potentially reduce
performance by splitting work into more unequally sized chunks.
For example, chunk sizes might be 4 and 8 instead of 6 and 6 when
alignment is 4.
