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.
Part of #116901.
Includes a general standardization of the code, removing constant
checks from hot loops, standardizing naming, tweaking BMesh face
iteration. And includes parallelization too.
Part of #116901.
To avoid resizing the buffer, the data is added to a temporary vector
first. That should be fine because the number of roots is expected to
be quite small compared to the size of the mesh.
Part of #116901.
The algorithm is very complicated to I didn't adjust it. The changes are just
removing the data struct and un-sharing some code to make things a bit
simpler. I also changed the loop to iterate over faces rather than triangles
to avoid the reverse triangle to face lookup. This removes the need to
create the `corner_tri_faces` map, saving 4 bytes per triangle.
Part of #116901.
A straightfoward change this time; the algorithm wasn't adjusted,
it was just put inside of a single loop. I did change some nested if
statements to continue statements to reduce indentation though.
Part of #116901.
The BMesh version of the algorithm was parallelized because BMesh has
edge to face topology lookup available.
This also allows removing `GPU_vertbuf_steal_data`, by just generating
the correct data type in the first place. Removing that should help dealing
with improvements to VBO data ownership in the future.
