Paddings were applied a bit oddly, resulting in a double padding for the
drawing. Each "tile" (the space to draw the file in) already had a padding
applied (`FileLayout.tile_border_x`), we'd apply another one to it. This second
padding should only be used for spacing of individual items *inside* the tile.
Code makes more sense too now, there are fewer arbitrary/eyeballed numbers to
make things "look good".
Pull Request: https://projects.blender.org/blender/blender/pulls/135915
Fix an issue when the NLA is used in conjunction with a directly-
assigned Action.
When the directly-assigned Action is also used in an NLA strip, that
strip would not be evaluated any more. This was even the case when
different slots were used, which entirely muted the strip when there
was no slot directly assigned. Now the "this has been handled already"
logic considers the action and the slot.
Pull Request: https://projects.blender.org/blender/blender/pulls/135911
The Ashikmin Shirley microfacet option for the glossy BSDF has it's own
blurring function for the filter glossy feature.
This commit adjusts the glossy_ashikhmin test to make use of filter
glossy so that this code path can be tested.
Ref: blender/blender-test-data!72
The "Merge Animation" operator now properly tags the affected Actions
with `ID_RECALC_ANIMATION_NO_FLUSH` so that new 'evaluated copies' are
created. Because this was missing, the animation evaluation code didn't
see the moved channelbags yet, which caused animation playback to be
broken.
Pull Request: https://projects.blender.org/blender/blender/pulls/135906
Vulkan handles are currently only requested once. In the future OpenXR
also needs acces to these handles and additional handles will be needed
when introducing copy queues and async compute.
This PR will collect the handles in a struct to ensure we don't need to
alter the GHOST interface for every change.
Pull Request: https://projects.blender.org/blender/blender/pulls/135905
This patch refactors GPU implicit conversion code by generating the name
of the shaders on the fly using fmt. This reduces boilerplate and makes
it easier to add new types.
In Cycles there are three closures (Diffuse Ramp, Phong Ramp,
and Burley diffuse) which are only avaliable through OSL. This commit
adds tests for these closures.
Ref: blender/blender-test-data!70
This commit adds a test for the shading offset feature in Cycles,
testing different material types (Diffuse, Glossy, and Transmissive)
and with different strengths.
Ref: blender/blender-test-data!71
When sync select is enabled, the data layers aren't accessed
so there is no need to add them.
Also skip adding a "pin" layer when clearing pinned UV's.
Context path in the header of material properties tab always indicates
material is on object. Include object.data in context path when material
is on mesh for example.
Pull Request: https://projects.blender.org/blender/blender/pulls/134968
Similar changes done elsewhere (#116901), replace usage of the GPU API's
`GPU_indexbuf_add_generic_vert` function by simply writing the index
data that we need. This avoids a function call and min/max tests for
every index added.
Pull Request: https://projects.blender.org/blender/blender/pulls/135404
Instead of computing an index mask for all curves, then returning an
intersection with the visible curves, just use the visible curves as
a universe for the original calculation. Also add another early out
for when there are no NURBS curves.
Currently the drawing data extraction code uses the offset indices API
quite inefficiently, copying the size of every selected every curve, then
accumulating those sizes. Instead just use the existing API function that
counts the size of all selected curves. Also for the weight overlay, avoid
doing the same calculation twice.
It was always hard-coded to be 0.
It does not seem to result in any extra tests passing, but they are
probably not sophisticated enough.
Noticed while looking into details for the #135856.
Pull Request: https://projects.blender.org/blender/blender/pulls/135878
There is no real reason to keep these read-only, they are not exposed in
the UI anyway, and being able to edit them can become necessary in a
pipeline mamangement context.
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/135870
This patch refactors the result class to replace proxy results with the
possibility of doing data sharing through a shared heap allocated data
reference count. This is more robust and simpler since proxy results no
longer need to be handled as a special case in a lot of the results
code. Additionally, it allows stronger const correctness since inputs to
operations can now be const.
This is somewhat similar to implicit sharing used in other parts of
Blender, so we can look into using that in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/135778
It seems that this was 'fine', as non-trivial data in `BVHTreeFromMesh`
appear to be 'safe' when simply zero-initialized instead of being
properly constructed.
Note that this 'calloced' data was already 'MEM_deleted', this is
currently considered as a valid use-case unfortunately, otherwise the
issue would have been detected earlier.
Directly use 'copy' `MEM_new` code instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/135862
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/135855
Fix a few small mistakes in the action baking code:
- Assigning an action slot should only happen after the action itself has
been assigned.
- `_ensure_channelbag_exists()` didn't actually ensure the channelbag
always exists; now it also creates the layer & strip if necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/135853
