Two quality-of-life additions to juggle the `Strip` and `KeyframeStrip`
types:
- New function `Layer.strip_add<KeyframeStrip>()` that returns a
`KeyframeStrip` instead of a `Strip`.
- Implicit conversion operator `operator Strip &()` on `KeyframeStrip`
so that `KeyframeStrip` can be passed to a parameter of type
`Strip &`.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/122659
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
Code was often referring to pie menus using the term "radial" which just
obfuscates that it relates to pie menus. Just call it what it is
directly.
Doesn't replace usages of the term for names that are not strictly tied
to pie menus. Also doesn't change instances of the term in the Python
API to keep compatibility, noted in #110461.
Pull Request: https://projects.blender.org/blender/blender/pulls/122825
This lookup is only necessary for certain events and if not done in a
pie menu, so it can easily be avoided in many cases. Also reduces
variable scope.
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
Change `UndoSculpt` to `StepData` and `usculpt` to `step-data`.
Previously it wasn't clear that the struct contained the data for a
single undo step and wasn't some more general thing.
It's semantically wrong to "create" undo system data just to retrieve
it as original data. This is similar to 28f2383477 which
already made this change in a few places.
Currently, during baking each pixel stores a seed input that comes from the
Blender side. This is only needed for vertex color baking, however -
for regular image baking, we can just as well hash the pixel coordinates.
Therefore, we can save some memory (4 byte per pixel) by splitting the seed
info out into a separate pass and only storing it when needed.
Pull Request: https://projects.blender.org/blender/blender/pulls/122806
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
The code for recalculating bounds was fairly tricky to understand, with a
mixture of various flags, a mixture of recursive and parallel code, and
the "original bounds" concept.
This commit separates that update code into two separate paths. The regular
bounds update is split from the resetting of original bounds, which is only
needed in a few places and is best described by a separate function call.
The bounds update itself is split clearly into a parallel update of leaf node
bounds and a recursive merging of child node bounds.
The high level goals this helps to support are:
1. Use data-oriented storage to replace PBVHNode struct.
2. Document concepts like "original bounds", provide a self-descriptive API.
3. Allow brushes to update bounds themselves, for better CPU cache use.
Pull Request: https://projects.blender.org/blender/blender/pulls/122746
For some reason this was not inlined. Considering it's a very simple function
and function call overhead could be measurable. In the case of the simple
brush benchmark file from the current sculpting project (#118145), this
improved performance by 6%, from 2.44s to 2.29s.
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
There is a mechanism to store config files in the same folder as the
Blender executable. The typical use case is putting Blender on a USB
drive and taking the config with you.
However the problem is that this is using the 4.2/ folder, which is fine
for config/ but with e.g. addons, studiolights and now extensions this
is mixing user and system files. This requires exceptions, doesn't
work well in some cases and is just generally not great design.
Instead use a folder named portable/ that is separate.
Pull Request: https://projects.blender.org/blender/blender/pulls/122778
This was caused by float imprecision in the NDF computation when
alpha was very close to 0. The alpha clamping threshold for the
eval function needs to be higher than the one for the sampling
function.
Fix#118997
With two viewports, and one viewport with overlays turned off, one viewport
first requests positions without calculating loose geometry, then the second
viewport can request the loose geometry index buffer. In that case the
previously-calculated positions VBO has the wrong size.
To fix this, always calculate loose geometry when the positions are requested.
That's required because we no simple way of checking whether the previously
uploaded positions included loose geometry. That was the state before recent
refactors in this area anyway.
This makes it clear that the optimization to not calculate loose geometry is
meaningless, because the positions buffer will always be requested at some
point when drawing a mesh.
It seems that when ensure_nodetree_previews calls duplicate_material,
ntreeLocalize removes the muted node from the copy of the nodetree,
so later in ensure_nodetree_previews nodeFindNodebyName can't find it
and therefore parent is NULL.
With this change, the muted node just doesn't get its preview updated.
Pull Request: https://projects.blender.org/blender/blender/pulls/122776
This fixes a number of issue with the pixel radius calculation.
- Fix factor of 2 being in the wrong place.
- `narrowing` is removed as this is not what we want
to compute (see comment).
- The `lod_min` is not the actual minimum LOD. Clamp by
both `clipmap_lod_min` and `clipmap_lod_max`.
Previously, the "Simplify" option was a world space distance threshold.
This meant that zooming in and out of the view changed the way
this option behaved. There were complaints from artists about this.
This change improves two things:
* The simplify algorithm uses the screen space coordinates rather than the
3D positions.
* The UI setting is in pixels making it much easier to tweak (no need
for values in the 1e-4 range).
Pull Request: https://projects.blender.org/blender/blender/pulls/122719
In GPv2 the brush strength was it's own setting in the
`brush->gpencil_settings`. Now we just use the `brush->alpha`
like all other brushes.
Note: The versioning will be done when GPv3 becomes the default.
Pull Request: https://projects.blender.org/blender/blender/pulls/122565
Part of #116901.
This file contains the creation of four different UV edit index buffers:
triangles, lines, points, and face dots. The main changes are about making
it clearer when faces are skipped. Other than that, changes are faily
extensive but straightfoward. In a few places some parts of existing
loops have been split out and parallelized, but the bulk of the work for
each IBO remains largely single threaded.
