The null byte wasn't taken into account when allocating memory
to strcpy into.
The calculation to check if allocation was needed was also wrong,
causing allocation for every string.
In practice it's not so likely users would ever hit this since
the function tended to over allocate, even in the case an off by one
error occurred, in all likelihood the room would already be available.
Ref !114512
If the draw_color method is not defined, try to use draw_color_simple as
a fallback. If not defined either, fallback to a magenta color.
The patch also updates the description of the method to clarify its use.
Pull Request: https://projects.blender.org/blender/blender/pulls/114527
Selected active strip highlights effect inputs and input channels for
multicam strips. This was done as 3rd pass in `draw_seq_strips()`.
4th pass was highlighting strip when doing solo preview.
Now this is added to a column of functions in `draw_seq_strip()`.
Highlighting effect input and solo preview is done when drawing actual
highlighted strip, but this is still done via alpha blending.
Highlighting multicam has to be done as alpha blending since this is
done by drawing rectangle over whole channel.
Originally code iterated twice over whole listbase with a lot of
preconditions to draw unselected, then selected strips.
Use `sequencer_visible_strips_get()` to get vector of visible strips,
split iteration in 2 separate loops.
Also move `special_seq_update` case to own function.
Use `VectorSet`, `Vector` or `Span` instead of `SeqCollection` struct.
It is now possible to use native `for` loops and `SEQ_ITERATOR_FOREACH`
macro can be removed.
Another feature is, sets of strips no longer needs to be freed. However,
this poses a limitation, that query functions can not be used in case,
where these sets need to be available outside of scope where they are
created.
Pull Request: https://projects.blender.org/blender/blender/pulls/111909
Minor usability enhancement for the walk navigation mode. Previously
walk navigation had local movement for forward/back/left/right,
but only global movement for up/down.
This PR adds local up/down movement, bound to the R and F keys.
Ref: !111682
This progress report was utterly broken and useless when not exporting
animations, and not great either with animation export. This commit
fixes:
* Not generating any progress report when exporting a single frame.
* Assuming actual data export covers 100% of progress.
That last point is the biggest change, now actual export (be it
animated or still) only covers 75% of the whole range. The rest is used
to cover depsgraph building and updates (which can be noticiably slow
with big scenes), stage writing, etc.
Progression is still far from linear in time, but at least it gives
better feedback on actual progress of the whole export.
Pull Request: https://projects.blender.org/blender/blender/pulls/114416
Several improvements how PLY files containing vertex normals are imported:
- When they are present on a regular mesh, the code no longer sets
all faces as "flat" (since that makes custom normals be ignored).
- When they are present on a pure point cloud (i.e. no faces),
custom vertex normals are added as a float3 point domain attribute
(ref #114371).
A missing part since PR #110139: the nodes and relations builders
needs to be in-sync and build the same objects. The relations builder
was missing relations building for camera referenced by markers.
Pull Request: https://projects.blender.org/blender/blender/pulls/114443
Code tried to move such strips (using the same action on equal IDs such
as meshes or shapekeys) between tracks multiple times [even though they
were actually moved already] which could end up with the wrong track
index and things just went downhill from there.
So now skip strips we cannot find in the original track, saves
us from the whole codepatch about "Moving strip into track in the
requested direction".
Pull Request: https://projects.blender.org/blender/blender/pulls/114458
Vulkan API uses Flags and FlagBits for enumerations. The FlagBits
contains the options that can be hold with the Flags data type.
This wasn't well understood at the beginning of the project and
the FlagBits where used where Flags should have been used. This cleanup
fixes this, improving the readability of the code where bit
manipulations where used.
Pull Request: https://projects.blender.org/blender/blender/pulls/114459
Single channel JPEG files are stored in 4 channels image buffers, with their
bit planes set to 8.
When creating the GPU texture the number of bit planes is used to identify
if the data could be stored as a single channel texture, but in this case
the source data contains 4 channels and doesn't align with the GPU
texture format.
In Blender 3.6 the way how bit planes were stored changed (the planes
used to be 32 for the grayscale byte images matching the number of channels,
but now is set to 8, matching the original loaded image).
Since Blender 3.5 the grayscale byte images are uploaded using a single channel
GPU format, which leads to the mentioned artifacts. Grayscale byte buffers never
seems to have worked since its introduction in
https://archive.blender.org/developer/D15484
This PR disables using the grayscale GPU textures when it sourced from
a byte image.
Pull Request: https://projects.blender.org/blender/blender/pulls/114441
Root of the issue was that a1d7ec7139 (from !110109, new comptibility
handling) missed to update code of `handle_subversion_warning`, file
version numbers should be checked here now, not the minversion ones.
On top of that, this report has been changed to a `RPT_WARNING` instead
of a `RPT_ERROR`, and reports 'print level' for file reading was set to
`WARNING` level way too late to have any effect in existing code...
No functional changes.
Since the following functions are now in a C++ namespace, their prefix can be removed:
* ANIM_setting_get_rna_values -> get_rna_values
* ED_action_fcurve_find -> action_fcurve_find
* ED_action_fcurve_ensure -> action_fcurve_ensure
Pull Request: https://projects.blender.org/blender/blender/pulls/114450
No functional changes.
For all the recently moved keyframing code I did the following:
* Remove comments that just repeat what the code is doing.
* Move comments for public functions to their location in the header file.
* Make sure comments are formatted properly with a capital letter at the start and a dot at the end.
Pull Request: https://projects.blender.org/blender/blender/pulls/114448
The `anim` data (e.g. of a VSE sequence) would store the last frame read from
FFMPEG as an image buffer, increasing its refcounting and preventing it
to be freed until the whole `anim` data itself gets freed.
In current code, there is no reason to keep a reference to this image
buffer in the `anim` data, so removing it. This may also give a few
percent improvement on the memory usage of the VSE in some cases.
Found while investigating #114342.
Pull Request: https://projects.blender.org/blender/blender/pulls/114395
USDZ conversion currently requires to change the 'current working
directory', due to internal USD library limitations.
This can only be done from main thread (and is highly discouraged in
general). This implies that USDZ conversion cannot happen from the Job
worker thread.
This commit moves it to the `endjob` callback of the USD export job
instead, as it is guaranteed to be executed from caller thread, i.e.
main thread in this case.
Pull Request: https://projects.blender.org/blender/blender/pulls/114420
Here is too many inconsistencies in used data type for coordinates.
That commit change int to float for socket draw. There is still many
node/text/other ui draw code with mix up int's and clamped floats
(to looks like int's). That fix is just small step to finally just use float.
Pull Request: https://projects.blender.org/blender/blender/pulls/114114
This commit removes knowledge about face sets from the PBVH,
and changes iteration over faces to not depend on the PBVH face
iterator abstraction. Though this adds slightly more boilerplate to
iteration over faces, it makes the whole process more data oriented
and allows use of index-based utilities like `gather` and `scatter`
in the mesh case, and simpler iteration over BMesh faces for
dynamic topology.
Setting face sets is now specialized per PBVH type in a few places
in a similar way. The general goal is to reduce branching and function
calls at the lowest level of hot loops, and to make code more aware
of the data structures it uses, both for performance and clarity.
Since the remaining uses of the face iterator are removed,
the iterator itself is removed too.
Related commits:
- 97f2b01ea9
- 756dea7ca1
- a6a2af5fdd
Pull Request: https://projects.blender.org/blender/blender/pulls/114417
The file that reproduces this had some faces of a mesh with vertex
normals, while some other faces were without vertex normals.
The parsing code assigns INT32_MAX as a fallback of "I could not parse
the normal index as a number" case, but later on code was not
catching this "normal index might be invalid" case. Fixes#114304
