When using EEVEE-Next the final render data is readback from texture
views. This wasn't implemented yet.
This PR adds support for reading back texture views. It also makes sure
the correct layer is read when reading back data from framebuffers and
adds internal support to read back a partial texture.
Pull Request: https://projects.blender.org/blender/blender/pulls/114411
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
This usage of the whole USD `USDStageReader` as 'cache handle' feels a
bit... uncomfortable to me. It implicitely assumes that all data in this
owned by the reader (or has a lifetime that contains the whole handle
lifetime). IMHO, if such struct is expected to have a long lifetime, it
should be documented, and probably needs better design for sub-data
handling then. Am curious to know if there is a good reason why the
handle itself is not a simple trivial class, able to re-generate an
actual complete USD reader on demand?
Or maybe we need to find a better place to store the `wmJobWorkerStatus`
data?
Anyway, for now this PR addresses the issue by ensuring that the
`worker_status` stored in the `USDImportParams` is not `nullptr` before
trying to access it for the reports.
This is more of a short-term solution though, imho there should be a way
to pass a reportlist to this codepath, and ensure the `wmJobWorkerStatus`
is always valid?
Pull Request: https://projects.blender.org/blender/blender/pulls/114337
This patch changes how wrapped translations are handled by the Realtime
Compositor. Previously, translations were always stored on the result
and delayed until automatically realized later. The wrapping status was
also stored to control this later automatic realization.
This patch changes that such that translations are immediately realized
for the axes that has enabled wrapping. Consequently, the image will not
get translated, but its content will, in a clip on one side, wrap on the
opposite side manner.
Another change is that wrapping information is no longer propagated to
future automatic realizations, so tilling or repeating an image is no
longer possible. An alternative method of repetition will be introduced
in a later patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/113669
Changes to edit mode mesh overlays, use hue shift instead of color
fading/darkening for selection mode visual differentiation, and some
theme changes to improve the display of mesh edges and faces with good
selection visibility.
- Removed "edge" toggle from edit mode overlays panel.
- No longer halves the edge and face alpha depending on selection mode.
Half the face alpha in wire-frame mode. For better visibility on most
themes.
Ref !111431
Currently, the EXR reader only considers uppercase RGBA channel names in
single-layer EXRs, which leaves out the lower case rgba channel names we
started using for data and vector passes in Cycles and the compositor.
Further, a single V channel was also ignored, which is by convention
used for BW passes.
This patch extends the single-layer channel recognition methods to
include lowercase rgba and V channels.
Pull Request: https://projects.blender.org/blender/blender/pulls/114339
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
Create the face set layer in the BMesh when the face set brush is first
used. This requires iterating through all faces to set the default value
of 1 because the default of 0 (SCULPT_FACE_SET_NONE) has different
behavior defined elsewhere.
Pair-reviewed in person with Sergey
4e87b3004b made the logic to require all vertices in the face
to be covered by the brush. However, the behavior is closer to the non-
BMesh version if only one of the face's vertices needs to be in "inside".
Pair-reviewed in person with Sergey
These two values are already stored in the mesh, and they have no
relation to the PBVH's goal as an acceleration structure. Similar to
a6a2af5fdd, remove the values from the PBVH and
just access them from the mesh as necessary.
Pair-reviewed in person with Sergey
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
The old name was logic when the color of the stroke was using a palette and not materials, but now always a material is used so the name "color" is not logic.
As we are changing all the API, now is the moment to set the right name.
Also, the commit includes some cleanup of the code.
Pull Request: https://projects.blender.org/blender/blender/pulls/114186
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
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
This new member gives access to the current active panel category (i.e.
tab) if supported, and allows to set its value to another defined
category.
While typically add-ons should not force a tab to be the active one,
there are cases where this is a valid and necessary behavior, e.g. in
'Blender App' where an app can add some new tab to the UI and require
them to be active.
Note that there is a ctach here: typically at start time these panel
categories are unknown (enum is empty), since they are validated by
drawing code. So setting them usually needs to be done after initial
startup and drawing of the UI...
Pull Request: https://projects.blender.org/blender/blender/pulls/114070
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
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
