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
The ordering of geometry nodes in the menus is intended to be
alphabetic, but the new "Set Face Set" node was listed _after_ the
"Set Shade Smooth" node in the Mesh > Write menu. This fixes the order.
Pull Request: https://projects.blender.org/blender/blender/pulls/114475
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
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...
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
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
The issue crash was caused by non-safe cast from a bare C array
float[4][4] to float4x4*. Such cast is not safe because it might
break alignment.
Modified the code so that the transform matrices are passed by
value.
Technically it could mean higher memory usage, but odds that the
actual geometry which is a part of boolean operation consumes much
more memory. Additionally, avoiding indirection could potentially
lead to better performance.
Pull Request: https://projects.blender.org/blender/blender/pulls/114421
Adding strips or changing filepaths caused thatde movie files were loaded,
but memory was only released after new frame was rendered. Since FFmpeg
can take a lot of memory per strip, this can cause crash.
Free memory for each strip immediately after it is not needed after
these operations.
Pull Request: https://projects.blender.org/blender/blender/pulls/114381
When trying to sculpt a Grease Pencil object with a line art modifier
(other modifiers probably also casue issues), Blender would crash.
I wasn't able to track down the exact issue but it's related to how
the update-cache stores pointers to original data.
This reverts part of e2befa425a to not make use of the update
cache while sculpting. Combined with modifiers, this approach
is just too unstable right now.
Pull Request: https://projects.blender.org/blender/blender/pulls/114410
Issue was reported with a 3.6 file crashing 3.3LTS, but the underlying
problem still exists in current codebase, and could also potentially be
caused by other edge-cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/114397
Previous fix partially fixed the issue, there were still some left over
issues where that alpha channel wasn't loaded correctly and therefore
could lead to fully transparent stick bones.
Previous fix: 3da63377fc
Pull Request: https://projects.blender.org/blender/blender/pulls/114393
Blender 4.0 added new socket types that get written into legacy node
group interfaces by forward compatibility code. Such unsupported socket
types have to be handled by the socket declaration system and ignored
during execution.
Ported blender-v3.6-release fix#114056
Pull Request: https://projects.blender.org/blender/blender/pulls/114401
When there is a non-sculpt mode undo step before the operation,
redoing the node tool operation doesn't work correctly-- the undo
that happens before repeating the operator doesn't work.
The fix is using the sculpt geometry undo step system. Theoretically
this should be cheap because implicit sharing will avoid copying most
of the attribute layers. However in the future it would be good to avoid
a PBVH rebuild after the operation in some cases.
This is a last-minute patch to address #113898.
There are two remaining known limitations, which are accepted for now:
- Drivers/keyframes don't transfer to the extra nodes in automatic conversion setups (such as for Subsurface Color)
- Drivers/keyframes on Sheen Tint/Specular Tint only apply to the R channel, since they were changed to color inputs in 4.0
Pull Request: https://projects.blender.org/blender/blender/pulls/114300
Property `speed_factor` was used before retiming. It was kept for
potential versioning code for complex speed animation, that was
possible with even older `pitch` property.
Strips, where `speed_factor` is set to static value are already
correctly converted.
Such versioning code would be quite complex, possibly slow and maybe
could corrupt files. This is due to multiple factors:
- Sound seeking was broken, so conversion would have to ignore all
keyframes before strip starts to map frames properly.
- Because some animation was effectively ignored, it may cause
inconsistencies when doing conversion.
- It would have to integrate value of `speed_factor` to map keyframes
to strip space, but the animation is not limited to strip length.
- For each keyframe where speed gradually changes, at least one smooth
speed transition would be required, but there would be discrepancies
that would have to be accounted for. With simpler strategy it is
likely, that extent of ramps would be limited and thus animation would
be quite different from original.
Because of these reasons, I think it is best to not convert
`speed_factor` animation.
Pull Request: https://projects.blender.org/blender/blender/pulls/114295
Unsupported data can be removed, which reallocated the custom data layer
array. Since the temporary ID vectors referenced memory in that array
directly, this could lead to a use-after-free. Instead remove unsupported
data before collecting the referenced attribute IDs.
Also add data-blocks from the redo panel inputs to the temporary
dependency graph added by 2893dc8ab7. Then make a temporary
copy of the properties list to pass the updated "evaluated" pointers to
the geometry nodes evaluator.
Sharing code between the modifier and tools is starting to make things
more complicated than they should be. But for now it's still probably
worth it.
The remaining issue with data-block inputs is #113383. I'll look into
that next.
Pull Request: https://projects.blender.org/blender/blender/pulls/114347
Customs sockets always ignore their draw_color method and are always
drawn using a magenta color.
This is a regression that was introduced in e071288ab2. The commit used
the simple variant even for drawing nodes where a context is available.
So this patch mostly reverts those changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/114148
The description first described functionality that doesn't work properly.
Prefer text that is to the point with what works well, elaborating on
error prone & partially working solutions afterwards.
Also include a stub example for script authors who prefer to develop &
maintain their scripts outside of Blender.
Windows allows people to pin an application to their taskbar, when a
user pins blender, the data we set in
`GHOST_WindowWin32::registerWindowAppUserModelProperties` is used
which includes the path to the `blender-launcher.exe`. Now once that
shortcut is created on the taskbar, this will never be updated, if
people remove blender and install it again to a different path
(happens often when using nightly builds) this leads to the
situation where the shortcut on the taskbar points to a no longer
existing blender installation. Now you may think, just un-pin and
re-pin that should clear that right up! It doesn't, it'll keep using
the outdated path till the end of time and there's no window API call
we can do to update this information. However this shortcut is stored
in the user profile in a sub-foder we can easily query, from there, we
can iterate over all files, look for the one that has our appid in it, and
when we find it, update the path to the blender launcher to the
current installation, bit of a hack, but Microsoft seemingly offers no
other way to deal with this problem.
Pull Request: https://projects.blender.org/blender/blender/pulls/113859
Use more modern approaches for supporting all generic attribute types,
rather than hardcoding all of the types and mistakenly correlating types
and domains.
A "Converter" template class handles conversion to GPU data and
describing the GPU format. The class is based on recent work in Cycles
attribute upload and is meant to replace the `AttributeTypeConverter`
class in `extract_vbo_attributes.cc`. I will do that as a separate step.
This structure will give build errors if new attribute types are added
but not supported here, preventing the situation described in the
report.
All generic attribute types are supported now, consistently with non
sculpt mode drawing. The edge domain isn't supported though.
Typically edges are more costly and complex to access, and interpolation
is less well defined anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/114334
Done by passing USES_TERMINAL to the add_custom_command().
This allows to see sub-command messages early on, before they
are finished executing.
This should help buildbots to "see" that the kernels are still
being compiled and not kill the build because it did not output
anything in a long time.
Pull Request: https://projects.blender.org/blender/blender/pulls/114327
Currently the node tool node group and data-blocks referenced by it
may not be part of the active dependency graph. This means we
cannot retrieve their evaluated geometry when executing the operator.
Since operators almost always use the evaluated geometry of other
objects, and since geometry nodes is mostly set up to deal with
evaluated data-blocks currently, this must be fixed.
Instead, set up a temporary dependency graph and add the selected
objects and the data-blocks used by the node group. That graph is
evaluated to give simple access to evaluated data-blocks.
Unfortunately this will cause more work than necessary in a few ways:
1. Selected objects are reevaluated an extra time before execution.
2. All data-blocks referenced by the group are completely evaluated again.
3. The node group itself is reevaluated, which recreates the function graph.
These may or may not become bottlenecks in the future, but it's best to
keep it simple late in the release process. And between a completely
broken feature and a potentially slow feature, the choice is clear!
Pull Request: https://projects.blender.org/blender/blender/pulls/114293
After previous changes to allow command buffers to not require
execution and completion in submission order,
guarantees for releasing freed buffers back to the memory pool
within the frame life time had changed.
This could mean a released buffer could be returned to the
memory pool prematurely, if a subsequent command buffer
completes before a previously submitted one, flagging a resource as no
longer in use by the GPU, while it still may be in use by the orignal
command buffer.
This PR defers final reference count release for buffers
being actively used until the following call to GPU_render_step,
to ensure that buffers freed will be available for the lifetime of
the frame, covering all command submissions, rather than just
within the lifetime of the command buffer submission within which a
buffer was freed.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/114329
The issue was that when in tweak mode, there are other places than just
the strip list that keep pointers to the tweaked strip. So deleting
that strip would leave dangling pointers, which caused things to blow up
elsewhere.
Pull Request: https://projects.blender.org/blender/blender/pulls/114331
In certain cases bones can disappear in pose mode. The cause was
that the alpha channel was not set in all cases and might use uninitialized
memory as alpha value.
Pull Request: https://projects.blender.org/blender/blender/pulls/114324
If "Region Overlap" was disabled, the region coordinate calculations
would end up placing the header on the bottom, taking space away from
the main asset shelf region. This is because the header was abusing the
`RGN_SPLIT_PREV` flag a bit, because it gave the desired behavior of
hiding the regions together. This worked well because the regions
wouldn't actually do the splitting when one used region overlap and the
other not. But disabling region overlap would bring the splitting
usually enabled with the `RGN_SPLIT_PREV` flag.
This PR removes the `RGN_SPLIT_PREV` flag from the asset shelf header.
Instead a new flag is introduced to only enable the behavior of
`RGN_SPLIT_PREV` of hiding a region together with the previous one. So
the header stays at the top of the region, and labels stay visible.
The new flag is added to the `ARegion.alignment` flags, even though it's
more related to behavior than alignment. However this is more
convenient, and keeps it together with related flags.
Khmer was added for this release and is barely translated yet (about
1%), so it's not too bad. We will ensure that the Khmer script is added
to our default font for 4.1, but this is too late for 4.0.
Regression from 7ec7dac860 (I assume). While the block active state is
relevant during drawing to avoid glitches, it should be ignored during
handling. Explained further in comment.
The functionality to frame channels in the Graph Editor
did not take into account any NLA mapping, causing the
viewport to frame the wrong part.
Fix it by mapping the `rctf` x-values
I had to remove the `const` on a parameter from the function
since `ANIM_nla_mapping_get` doesn't take a `const`.
Pull Request: https://projects.blender.org/blender/blender/pulls/114325
The issue was that the undo system detected that node trees have been changed
even though they have not. This is because the memory dump of the node tree
changed after unrelated changes. The root issue was that
`bNodeTreeInterface::write` also wrote the struct, and the pointer of the
`bNodeTreeInterface` itself. While this pointer is generally stable, it is not
during file-write, because when IDs are written, a shallow copy is created
first (see `BLO_write_init_id_buffer_from_id`). The temporary buffer for this
shallow copy is allocated on the heap, so its pointer may change over time.
The fix is to simply not write the `bNodeTreeInterface` separately, since it's
already embedded in `bNodeTree`.
Pull Request: https://projects.blender.org/blender/blender/pulls/114322
