- Change variable names for consistency
- Split common code to function
- Create simple struct with curly brackets
- Avoid random access to IndexMask
- Remove obvious comments
- Use const references for float3
This commit adds a minimal, simple detection for future, incompatible
blendfiles (in case the header itself is modified).
The current available info does not allow to be more specific, but at
least this avoids telling users that it is not a blendfile.
In the future, the new header format designed in #129309 for Blender 5.0
should allow for a better report (since the first 16 bytes of the header
should always have the same meaning from there on).
Pull Request: https://projects.blender.org/blender/blender/pulls/129875
The issue was that changing the area did not immediately update the
`snode->edittree` when changing between different node editor types. That update
only happened later in `node_area_refresh`. However, by that time, the `poll`
function of the modal operator has already succeeded even though when there
operator actually starts `poll` would not succeed anymore.
Pull Request: https://projects.blender.org/blender/blender/pulls/129870
Caused by 2 issues:
- Incorrect logic when checking if added key matches last key
- FPS mismatch not compensated in `SEQ_retiming_key_speed_set()`
Also `seq_retiming_evaluate()` output was not clamped to 0-1 range. This
was not causing issues in sample .blend file, but output should be
clamped.
Pull Request: https://projects.blender.org/blender/blender/pulls/129838
Verge groups operations such as assign/remove/select/deselect from data
properties tab edits all drawings instead of visible drawings at current
frame. Now fixed with `retrieve_editable_drawings`.
For remove/remove_from operator, separate PR is created: !129890
Pull Request: https://projects.blender.org/blender/blender/pulls/129789
Mesh filter modes that use averaged neighbor data were not passing in
the mesh `hide_poly` attribute data, leading to incorrect behavior when
calculating averaged positions. To fix this and account for hidden
elements since we are operating on the entire mesh, we pass in the
attribute and use the `neighbor_data_average_mesh_check_loose` method to
account for vertices with no neighbors.
Pull Request: https://projects.blender.org/blender/blender/pulls/129886
For undo/redo of position undo steps, currently we do some processing
that scales with the size of the mesh. The code is also more complex
than necessary-- we don't make use of the relations between some
concepts to simplify things.
This commit unifies the loops, mostly by making use of the fact that we
only need to modify the original mesh positions. When there are deform
modifiers a reevaluation will update the evaluated positions, and other-
wise, the original and evaluated positions are the same anyway.
Related to #129496.
Pull Request: https://projects.blender.org/blender/blender/pulls/129783
This enables material displacement for UsdPreviewSurface import and
export. Scenarios are limited by what's supported by the preview surface
itself. Namely only Object Space displacement can be used (no vector
displacement)[1] and the Midlevel and Scale parameters are maintained by
adjusting the scale-bias on the image texture controlling the Height
(this means that Midlevel and Scale must be constants).
Hydra/MaterialX support is more complicated. First, there is a bug which
prevents scalar displacment from working correctly and that needs USD
2408+ for the fix[2]. Second, is that there's an open question about
which coordinate system to use for MaterialX's vector displacement maps.
Lastly, Hydra GL does not render displacement, making verification using
only Blender impossible[3]. As a result, this PR only makes MaterialX
"ready" for support, but stops short of actually connecting the final
piece of the node graph until more of the above can be sorted out.
Tests are added which cover:
- Variations of Midlevel and Scale values
- A constant Height setup
- Negative scenarios checking that only Object space is supported
and that midlevel and scale need to be constants
[1] https://openusd.org/release/spec_usdpreviewsurface.html
[2] https://github.com/PixarAnimationStudios/OpenUSD/issues/3325
[3] https://forum.aousd.org/t/materialx-displacement-hydra-storm/1098/2
Pull Request: https://projects.blender.org/blender/blender/pulls/128909
No idea why this was not reported before... Kind of critical info here.
Committed directly to 4.2 as:
* This is trivial change with extremely small risk of causing issues.
* Gold team at the studio needs it to better cleanup the production
files for publication.
Follow what was already done with the "reload" operator and tag the
Image ID during "replace".
A tag of "0" is used for now until we can investigate why the other more
appropriate values are not working.
Pull Request: https://projects.blender.org/blender/blender/pulls/129619
This would happen if the viewport with large enough
and a tile resolution of 1:1 was choosen.
This changes the fallback behavior from simply clamping
the resolution (which did break a lot of math downstream),
to simply finding the next largest tile size that fits
the hardware requirements.
Crash manifested after the inclusion of #128877.
The very tall 3D texture tested by the new code
were not supported / tested by the Metal Backend.
Simply adding the appropriate upfront checks fixes
the issue.
Needs to be backported to 4.2
Adding a dummy storage buffer to the classification shader
seems to fix the issue on Qualcomm drivers (WoA).
The workaround is added to the force workaround option to
allow other platforms to test the fix.
Rel #122837
Pull Request: https://projects.blender.org/blender/blender/pulls/129857
Code used library reloading which would reload all data-blocks from a
data-block library. Since the essentials brushes are stored in a single
.blend file (one per mode), they would all be reset. In general this
violates the design where multiple brushes in a single .blend file
should be usable just fine. (A single file per brush is only necessary
to allow saving edits to that file without opening it.)
Instead of library reloading, delete the brush from the current file and
re-link it.
The link/append API should probably get support for reloading a single
data-block (and optionally its dependencies) but for now this is not
supported yet.
Pull Request: https://projects.blender.org/blender/blender/pulls/129866
Part of overall #118493 task: video input/output support at 10 and 12
bit/component formats. (note: this is still LDR videos just at higher
precision; there's no HDR handling (yet)).
Movie reading/playback: when movie file pixel format has >8 bit
components, decode those into a floating point ImBuf result. Previously
all movies were decoded into 8 bit/channel ImBufs, so 10- and 12-bit
movie pixel colors were getting quantized.
Movie output: when ffmpeg video with suitable codec is selected,
there's a color depth setting under Encoding block. Currently that is:
- 10 bit option for H.264, H.265, AV1 (VP9 could do 10 bit in theory too,
but ffmpeg that is built in Blender does not have that compiled in)
- 12 bit option for H.265, AV1
When "lossless" is picked, then similar to how for regular 8-bit video
it switches from YUV 4:2:0 to 4:4:4, this also switches to 4:4:4
10- or 12-bit variant.
Pull Request: https://projects.blender.org/blender/blender/pulls/129298
Some modifiers expect the curves to be of type `POLY`.
For such modifiers we need to resample the curves to the
evaluated points so that the modifiers work as expected.
Resolves#129859.
Pull Request: https://projects.blender.org/blender/blender/pulls/129860
`writedata` used to align the written buffer size to a multiple of 4. This
causes multiple issues:
* Writes uninitialized data.
* Crash with ASAN due to a heap buffer overflow if the buffer is not any longer
than what is passed in.
* Modifies the length of the buffer which can't be undone when reading the
buffer again.
I don't know of any reason for this alignment here. I'd think that it doesn't
matter when writing to a file. If it would matter, then we should probably align
to at least 8 nowadays because that's the alignment of pointers. The original
reason for this alignment seems to be lost to history. It was already part of
the initial commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/129821
The issue was that with a96f1208cc the clamping
of the `View2D` happened in the drawing function
of the channel list. That of course won't work if the
channel list isn't drawn.
The fix is to ALSO clamp in the drawing function of
the main area. The reason this has to be in addition, is that
(I think) the channel box is drawn first. So if the clamping doesn't
happen there, the channels and their keys can lose their vertical
alignment.
Pull Request: https://projects.blender.org/blender/blender/pulls/129864
These have been removed since 4.0, this is not a pertinent information
to single out anymore.
Also downgrade report about missing obdata to `WARNING`, `ERROR` is a
bit strong for this.
