This was caused by the base page tagging.
Since that the base page is now required for fixing
soft shadows, it would be the first level to be rendered
which, combined with the update throttle, lead to only
the min LOD to be available when the shadow was updated
in viewport.
This was affecting the jittered shadows, animation update
and viewport transform.
The fix is to only request the base page after throttling
the updates and only if there is no other LODs to be
rendered. This mean jittered shadow in viewport might
become affected by the missing base page artifacts, but
this is less noticeable than huge light leaking.
only if
The following operations have been removed for system repositories:
- Installing from disk.
- Uninstall extensions.
- Delete files (when removing the repository).
Also change the operator to remove a repository so the option to
remove files is now a boolean instead of an enum. While a dynamic
enum can be made to work, this option is logically a boolean.
The `Snap to Grid` and `Snap to Vertex` modes were being mixed if
either mode was enabled.
Support for mixed snap modes doesn't yet fully work for UVs.
When starting a navigation operation that uses `Auto Depth` or
`Orbit Around Selection` the value of `#RegionView3D::dist` is modified
to match the distance from the new pivot.
This value was incorrect when the pivot was behind the viewer.
In these cases `dist` is negative.
This commit, in addition to fixing `dist`, also limits the execution of
this code to only when `Auto Depth` is used.
Pull Request: https://projects.blender.org/blender/blender/pulls/122795
Allow precompiling specialization constants variations in parallel.
Only supported in OpenGL as the rest of the batch compilation API,
on the other backends the function is a no-op.
This also moves the `SpecializationConstant` from
`gpu_shader_create_info` (private API) into`GPU_common_types`
(public API).
Pull Request: https://projects.blender.org/blender/blender/pulls/122796
This changes fixes a wrong mesh as a result of apply base mesh from the Multires modifier
In the previous code some corner vertices where incorrectly assigned to null and skipped form processing as a safety guard
that was only relevant when the mesh had hidden faces in edit mode. The hidden corner vertices bug is handled now when checking
> if (corner_x_index < 0 || corner_y_index < 0) {
> continue;
> }
Since the patch that caused this error was a fix to a previous infinite loop bug,
I also tested and made sure this updated patch still fixes the original issue it was trying to fix.
Note: This PR replaces #122845 due to a large amount of git rebase issues.
Pull Request: https://projects.blender.org/blender/blender/pulls/122859
Previously selected strips in VSE timeline were drawing their outline
1px outside of the strip boundaries. This makes outlines of the strips
overlap each other when neighboring strips are selected.
Now the selected outline is fully within regular strip shape.
Pull Request: https://projects.blender.org/blender/blender/pulls/122890
The File Output node ignores color space overrides for EXR images. To
fix this, we save the images using save_as_render set to true. We don't
need to provide this as an option similar to other image types because
even when save_as_render is set to true, it will not have an effect
unless the user chooses to override the color space explicitly, since it
is not affected by view transforms and the like.
Pull Request: https://projects.blender.org/blender/blender/pulls/122791
The File Output node forces all inputs to have the same size, which
should only be the case for multilayer files. This is a regression in
931c188ce5. To fix this, we allow inputs to have any size, except for
multilayer files, which are realized on the automatic operation domain
of the operation.
Pull Request: https://projects.blender.org/blender/blender/pulls/122824
The CPU compositor does not recognize viewer groups inside node groups
unless a viewer node exists at the top level node group. This is caused
by bad logic when registering viewer node at the node operation builder.
And the fix is just to correct the logic to always register viewers if
no active viewer already exists, which can then later be overwritten if
a viewer node that takes precedence was discovered.
Pull Request: https://projects.blender.org/blender/blender/pulls/122869
Right now probe passes are compiled one by one, since passes are only
requested if `materials.queued_shaders_count` is 0 and requesting a
pass will increase the number.
This splits the logic into 2 functions, one for checking if sync is needed
and another to check if pass shaders are needed.
This allows compiling the shaders in parallel.
Pull Request: https://projects.blender.org/blender/blender/pulls/122799
PR #122576 added rounded corners to VSE timeline strips, but they were not
"snapped" to pixel grid so the outline that is normally 1px was sometimes
falling in between pixels and was blurred out.
Fix by rounding all SDF related coordinates inside the shader to the pixel
grid.
Pull Request: https://projects.blender.org/blender/blender/pulls/122764
Mainly correct/update some comments (e.g. missing reference to Boolean
type), and add some notes essentially about issues with current IDProp
String code (see also #86960 ).
No functional change.
In case a 'compatible' old IDProperty exists,
`update_input_properties_from_node_tree` would essentially reuse it
as-is, only keeping the UI data from the freshly new IDProp it created
for the socket.
This commit instead fully re-use the newly created idprop, only copying
(and converting as needed) the value from the old one.
That way, we can be sure that the actual type of the IDProperty is reset
to its expected type, instead of being kept forever in a 'wrong' type.
Having IDProps in a stable, expected type is a sounder behavior in
general, and critical for lower-levels of code to work as expected
(like RNA diffingi, and by extension, Library Overrides e.g.)
NOTE: This is a side-finding from work on #122743 to make some idprops
statically typed, and is a pre-requirement for this to work with the
GeoNodes modifiers case.
Pull Request: https://projects.blender.org/blender/blender/pulls/122876
This fixes a bug that happens when two drawings in the same grease pencil
data-block reference the same array. In this case, the same attribute array
pointer is written to .blend files for both drawings. However, when loading the
.blend file, it was not detected that the data is shared. Instead each drawing
would think that it was the single owner of the array even though it was shared.
The same problem can technically occur for all kinds of shared data, and not
just for grease pencil. However, only grease pencil shows this issue currently,
because it can easily happen that the same attribute is shared between different
`CustomData` within the same data-block. This very rarely happens with meshes or
curves, because different `CustomData` usually have different sizes and don't
share the same arrays.
A previous fix (cc891aa699) solved pretty much the same issues for the case
when two layers in the same `CustomData` share data. This original fix is now
generalized and is integrated with `BLO_read_shared` which makes it less error
prone. For each data-block, the `BlendDataReader` now remembers which shared
data it has loaded before so that it is not loaded again.
In the future this could be extended to support data that is shared between
data-blocks, but that's not as straight forward as one would hope currently. For
various reasons, different data-blocks could store independent data at the same
pointer. I specifically noticed that with a regression test file:
`blender/tests/data/modeling/geometry_nodes/attributes/attribute_statistics.blend`.
To support it, one solution could be to tag `BHead` in .blend files to indicate
that a specific pointer is shared and unique within the entire file. But that's
for another day.
Pull Request: https://projects.blender.org/blender/blender/pulls/122780
The buttons to upgrade or sync extensions called extension
operators via bpy.app.handlers, requiring awkward glue-code
which didn't show error reports in to the user.
Remove these operators and call the upgrade & sync operators directly.
Instead of using "box" layouts for these import/export operators, use
panels instead. Many choices for the layout and organization has come
from the `universal-scene-description` branch though it's not a 1:1
equivalent.
Motivation for using panels is two fold.
Firstly the use of panels instead of boxes is more consistent with other
parts of Blender and with the other IO features.
Secondly, in the case of an Import invoked from drag-n-drop or Export
configured on a Collection, the large number of options exposed results
in a very long layout. Panels allow us to close some sections by default
and allows the user to open/close panels based on their own needs in
general.
Along the way some effort went into standardizing the layout and wording
used as much as possible.
Pull Request: https://projects.blender.org/blender/blender/pulls/122415
Support for "System" extensions as an alternative to the current
"User" extensions repository.
The purpose of this change is to support bundling extensions for
offline work or in environments where users setting up thier own
extensions isn't desirable, see #122512.
Details:
The default "System" repository on Linux will for example use:
- `/usr/share/blender/4.2/extensions/{system}` For system installs.
- `./4.2/extensions/{system}` For portable installs.
- Blender's default startup now has a "System" repository
which users or administrators may populate.
- Repositories can select between User/System paths,
setting a custom path overrides overrides this setting.
- Add "BLENDER_SYSTEM_EXTENSIONS" (matching "BLENDER_LOCAL_EXTENSIONS").
Ref !122832
Changes in view3d_id_path_drop_copy from 8b6a21c122 assumed that
drag-drop filepaths was handled only with FileHandlers in View3d. This
adds the missing drop-box to FileHandler conversion for .vdb files.
Pull Request: https://projects.blender.org/blender/blender/pulls/122839
A few of the recently added submenus are not included in the list of builtin
menus, so node assets under those catalog names will generate redundant submenus.
Fixes same issue as b49c84276c for newly added nested menus.
Pull Request: https://projects.blender.org/blender/blender/pulls/122855
If the mesh has a curve builtin attribute that's not stored on the point domain,
the creation of the attribute will fail and it can't be interpolated. Possibly this
could be supported somehow, by averaging all the values in the curve's points
or so, but for now just avoid the crash.
Update PBVH GPU argument initialization to prefer using the PBVH mesh
attributes instead of the evaluated mesh attributes for color.
The values can be out of sync due to differences with the evaluated
and original mesh data.
Pull Request: https://projects.blender.org/blender/blender/pulls/122850
The goal is to simplify debugging the "current" simulation step. Previously, when a frame
was cached already, one would have to go back to the beginning to cache everything again.
Now, the last cached simulation step is discarded and simulated again if any property that
affects it is changed.
Pull Request: https://projects.blender.org/blender/blender/pulls/122736
Fix of conversion identity quaternion to axis angle. Basically,
if the length of the imaginary part-vector is zero, it is
incorrect to normalize it. Simple identity should be returned.
Pull Request: https://projects.blender.org/blender/blender/pulls/119762
Fixed a crash when dynamic topology is active on multires displacement smear brush
Added a check for this case at the start of the brush stroke, with a user visible error message
and cancels the operator early so no topology is modified either.
Pull Request: https://projects.blender.org/blender/blender/pulls/122453
Originally this would replace scripts that come bundled with Blender,
but it's unclear how this is useful.
Searching for this online mainly leads to people asking how they can
use it to add scripts. For example in a studio environment you might
want to deploy add-ons and startup scripts for all users.
Even if you wanted to use it for replacement though, it wasn't really
doing that and inconsistent for different types of scripts:
* startup: ignored
* modules: replaces bundled scripts
* presets: adds to bundled scripts
* addons (in 4.1): ignored
* addons_core (in 4.2): ignored
* startup/bl_app_templates_system: replaces bundled scripts
This change makes it add scripts from this path for all. This is a
breaking change, though arguably this feature was just broken to
begin with and not used much in practice because of that.
The alternative would be add a new set of environment variables to
avoid breaking existing behavior. But that also means keeping around the
broken behavior or fixing it in another way.
Supporting multiple paths may be used too, but for now just support
a single one as doing this for all BLENDER_SYSTEM variables is
non-trivial. The main use case for that would be add-ons anyway, and
those will mainly be handled through upcoming
BLENDER_SYSTEM_EXTENSIONS instead.
Ref #122512
Pull Request: https://projects.blender.org/blender/blender/pulls/122689
A bit on shaky ground here, but it looks like we actually dont want to
execute the hovered buttons value/op if we chose another item in the pie
menu. This can be achieved by using the **onfree** arg to
`button_activate_exit` called on the active(hovered) button.
Not sure if this is the correct solution tbh (but maybe it demonstrates
where the bug of #122526 can be located).
I have tested pie menus with this patch and they seems to behave
normally (even nested ones).
Pull Request: https://projects.blender.org/blender/blender/pulls/122567
Seems to be dependent on specific compiler/cmake version.
Is a typical mixture of missing dependencies between libraries,
object files which do not get referenced from other files in the
target, and whole-archive linking of the blender_test target.
Pull Request: https://projects.blender.org/blender/blender/pulls/122801
Allows to import multiple alembic files in single operator call.
When importing multiple alembic files as background job, import progress
will be divided by all files, so if `5` files are imported, each file
will make progress of `20%`. This can be improved if the job text can be
customized to display for example `Import Alembic 1/5` and using 100%
progress status display for each file, but that is out of the scope of
this pr.
The Scene min and max frame are set based on the minimum/maximum frame
ranges detected from all files.
Pull Request: https://projects.blender.org/blender/blender/pulls/121492
This change adds the ability to export MaterialX networks into the resulting
USD layer.
Details:
A new export option has been added to the USD export to enable MaterialX
export. It is off by default currently due to reasons in the caveats
section.
When enabled, it exports the MaterialX shading network alongside the
UsdPreviewSurface network, on the same USD Material. This allows the same
material to be used by renderers that don't support MaterialX, using the
USDPreviewSurface as a fallback. This is similar to setups in other DCC
packages, and matches the format we've used in our Reality Composer Pro
asset library.
It uses the existing MaterialX framework used to generate MaterialX
documents for rendering, to act as the basis for the USD graph. In this
process it also re-uses the existing texture export code as well if provided
and necessary.
Once the MaterialX document is created, use usdMtlx to generate a USD
shading network. Unfortunately, usdMtlx generates a graph that is unlike
what other DCCs that support MaterialX-embedded-in-USD generates. It
generates several extra prim hierarchies, and externalizes all shader
inputs, making them difficult to edit in other MaterialX graph editors.
To workaround this, generate the MaterialX shading network onto a
temporary stage, where we then run various pre-processing steps to prevent
prim collisions and to reflow the paths once they're converted.
The PrimSpecs are then copied over to their new path. The resulting prim
hierarchy matches what many artists we've worked with prefer to work with.
Caveats:
The Export MaterialX check is off by default. When using the Principled
BSDF, the resulting graph is very usable. However, when using some of the
other BSDFs, the shading networks generated by the existing MaterialX
framework in Blender generate some shading graphs that are difficult for
usdview and other DCC's to understand. The graph is still correct, but
because we're trying to prioritize compatibility, the default is off.
In future PRs we can aim to make the graphs for those other BSDFs play
better with other DCCs.
Other Implementation Details:
As part of this commit we've also done the following:
* Place some of the materialx graphs inside a passthrough nodegraph to
avoid node conflicts.
* Better handle some shader output types , and better handle some
conflict cases.
* Moved the ExportTextureFunction to materials.h due to some difficult
to resolve header ordering issues. This has no effect on any runtime code.
* There is a test for the MaterialX export that does some basic checking to
make sure we get an export out the other end that matches our expectations
Authored by Apple: Dhruv Govil
This PR is based on an earlier implementation by Brecht van Lommel , as well
as Brian Savery and his teams' work at AMD to implement the general
MaterialX framework within Blender.
Pull Request: https://projects.blender.org/blender/blender/pulls/122575
This is the first commit of the several required to support
subprocess-based parallel compilation on OpenGL.
This provides the base API and implementation, and exposes the max
subprocesses setting on the UI, but it's not used by any code yet.
More information and the rest of the code can be found in #121925.
This one includes:
- A new `GPU_shader_batch` API that allows requesting the compilation
of multiple shaders at once, allowing GPU backed to compile them in
parallel and asynchronously without blocking the Blender UI.
- A virtual `ShaderCompiler` class that backends can use to add their
own implementation.
- A `ShaderCompilerGeneric` class that implements synchronous/blocking
compilation of batches for backends that don't have their own
implementation yet.
- A `GLShaderCompiler` that supports parallel compilation using
subprocesses.
- A new `BLI_subprocess` API, including IPC (required for the
`GLShaderCompiler` implementation).
- The implementation of the subprocess program in
`GPU_compilation_subprocess`.
- A new `Max Shader Compilation Subprocesses` option in
`Preferences > System > Memory & Limits` to enable parallel shader
compilation and the max number of subprocesses to allocate (each
subprocess has a relatively high memory footprint).
Implementation Overview:
There's a single `GLShaderCompiler` shared by all OpenGL contexts.
This class stores a pool of up to `GCaps.max_parallel_compilations`
subprocesses that can be used for compilation.
Each subprocess has a shared memory pool used for sending the shader
source code from the main Blender process and for receiving the already
compiled shader binary from the subprocess. This is synchronized using
a series of shared semaphores.
The subprocesses maintain a shader cache on disk inside a
`BLENDER_SHADER_CACHE` folder at the OS temporary folder.
Shaders that fail to compile are tried to be compiled again locally for
proper error reports.
Hanged subprocesses are currently detected using a timeout of 30s.
Pull Request: https://projects.blender.org/blender/blender/pulls/122232
