Fixed by not doing async loading and always stage correct
texture reference.
Unfortunately the code is getting a bit messy since the
texture loading is not done at the GPUMaterial level.
So we need one async and one synchronous path inside
`PassBase<T>::material_set`.
`ImageGPUTextures` now contains references to the location
of the future `GPUTexture *`.
Also fix#140001
Pull Request: https://projects.blender.org/blender/blender/pulls/140203
Code selecting objects in collections that have been instanced was only
handling objects directly owned by the collection, not the objects in
the hierarchy of children collections.
The objects from the whole hierarchy need to be hanlded here, since
children collections will not be processed (as they are already
instanced by their parent one).
Pull Request: https://projects.blender.org/blender/blender/pulls/140068
Depending on things like order or processing etc., appending
liboverrides data could generate error message in the console regarding
invalid override hierarchy data.
While this could probably be solved, it feels fairly brittle and risky
to directly make linked liboverride hierarchies locale anyway, so just
alsways make local copies of these on append.
Currently, there is the general rule that outputs must be above inputs in any
given panel. Since internally a panel toggle input is part of the panel that it
toggles and has to be the first item in a panel, it was not possible to have a
panel toggle for a panel with outputs.
This patch relaxes the rule for ordering of inputs and outputs for the special
case of panel toggles.
Pull Request: https://projects.blender.org/blender/blender/pulls/140054
This allows to reduce the waiting time caused by
shader compilation on some GPU-driver combo.
A new settings in the User Preferences make it
possible to override the default amount of worker
threads and optionally use subprocesses.
We still use only one worker thread in cases where
there is no benefit with adding more workers
(like AMD pro driver and Intel windows).
It doesn't scale as much as subprocesses for material
shader compilation but that is for other reasons
explained in #139818.
Add some heuristic to avoid too much memory usage
and / or too many stalls.
Also add some heuristic to the default number of subprocess for
the platform that shows scalling.
Historically, multithreaded compilation was prevented by the
need of context per thread inside `DRWShader` module.
Also there was no good scaling at that time. But
nowadays numbers shows different results with
good scaling with reasonable amount of threads on many
platforms.
Even if we are going for vulkan in the next release
most of the legacy hardware will still use OpenGL for
a few other releases. So it is relevant to make this
easy improvement.
See pull request for measurements.
Pull Request: https://projects.blender.org/blender/blender/pulls/139821
Also unifies the min/default/max width of all group nodes. The minimum width
has been increased from 40 to 60 for Geometry Nodes because there was is
an assert when the node was that thin already. The other group nodes already
used 60 as min width.
From what I know, we don't really have a good way to detect whether a material
index is non-sensical in the right places. That's because the same material
index on a mesh may not make sense on one object but can still make sense on
another. This is the issue we fixed in the first place when the regression was
introduced.
What we can do though is to check which exact material indices a mesh is
actually using (not just the maximum). This allows us to skip a lot of work for
unused material indices. This doesn't help when a mesh has thousands of unique
non-sensical material indices, but it should be an improvement in the majority
of cases.
This patch adds a cache of used material indices to `Mesh`. The drawing code
requests that cache if the maximum material index is above some threshold (16
currently). We don't want to compute it all the time, because it requires
iterating over the mesh (at least once, then it is cached). So it's only worth
the extra cost of the there is at least one large material index. The threshold
also ensure that the large majority of scenes is not affected by this patch
performance wise.
Pull Request: https://projects.blender.org/blender/blender/pulls/139781
When constant falloff is used, `BKE_brush_calc_curve_factors` doesn't do
any extra filtering of the given distances. The Plane brush previously
didn't filter the distances, leading to incorrect deformations when the
constant falloff was used.
To fix this, this commit makes a number of changes:
* `BKE_brush_calc_curve_factors` no longer sets the factor for an
element to 0 if it is outside of the provided distance. This is
replaced with an assert.
* The Plane brush and Cloth brush have an explicit
`filter_distances_with_radius` added.
Pull Request: https://projects.blender.org/blender/blender/pulls/139851
This commit enables Blender 4.5 to use (to some extent) blendfiles from
Blender 5.0 and later using 'long' ID names (i.e. ID names over 63 bytes).
On a more general perspective, it also introduces safer handling of
potentially corrupted ID names in a blendfile.
This is achieved by carefully checking for non-null terminated ID names
early on in readfile process, and then:
* Truncating and ensuring uniqueness of ID names.
* Doing similar process for action slot and slot users identifiers.
* In linking (and appending) context, such IDs are totally ignored. They are
not listed, and are considered as missing if some other (valid) linked ID
attempt to indirectly link them).
* Informing users through usual reporting ways.
Technically, this mainly changes two areas of the readfile code related to IDs
themselves:
* The utils `blo_bhead_id_name` that returns the ID name of an ID BHead,
without actually reading that ID, now check for a valid null-terminated
string of `MAX_ID_NAME` max size, and returns a `nullptr` on error.
_This essentially prevents listing and linking such IDs, in any way._
* The actual ID reading code (`read_id_struct`) does the same check, and
truncate the ID name to its maximum allowed length.
* Both of above checks also set a new FileData flag
(`FD_FLAGS_HAS_LONG_ID_NAME`), which is used to ensure that ID names (and
related actions slots identifiers) remain unique, and report to info to the
user.
Implements #137608.
Branched out from !137196.
Co-authored-by: michal.krupa <michal.krupa@cdprojektred.com>
Co-authored-by: Campbell Barton <ideasman42@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/139336
This mainly adds DNA level IDProp storage for system properties, their
handling in data management code, and the forward-versioning code
copying back content from system properties into 'all-in-one' single
IDProperties storage, for data types that will support both in Blender
5.0.
There is no user-facing changes expected here.
Part of #123232.
Pull Request: https://projects.blender.org/blender/blender/pulls/139257
In 5.0, we plan to change the brush size from representing radius to
diameter. This means that for 5.0 files loaded in 4.5, we need to
scale the stored value when reading the relevant brush fields.
Related to #134204
Pull Request: https://projects.blender.org/blender/blender/pulls/139561
Current strategy to deal with operators not supporting custom NURBS
knots is to fall back to calculated knots for curves of the custom mode
but with no `CurvesGeometry::custom_knots` allocated. Such curves are
the result of operators that copy only `Point` and `Curve` domains. This
way the problem is only postponed. It is not possible to add new custom
knot curves to such `CurvesGeometry` as custom knot offsets are
calculated all together and there is no way to distinguish between old
curves with lost knots and new ones. This is more a future problem.
The actual problem in `main` can be shown with an attached blend file
(see PR) by applying `Subdivide` to some points and then adding new
`Bezier` curve to the same object. This particular problem could be
addressed somewhere in `realize_instances.cc` but the actual problem
would persist.
This PR handles custom knots in all places where `BKE_defgroup_copy_list`
is iused, and where `bke::curves::copy_only_curve_domain` is called.
Here the assumption is made that only these places can copy custom knots
modes without copying custom knots. Depending on operator logic knots are
handled most often in one of two ways:
- `bke::curves::nurbs::copy_custom_knots`:
copies custom knots for all curves excluding `selection`. Knot modes
for excluded curves are altered from the custom mode to calculated.
This way only curves modified by the operator will loose custom knots.
- `bke::curves::nurbs::update_custom_knot_modes;`
alters all curves to calculated mode.
In some places (e.g. `reorder.cc`) it is possible to deal with knots
without side effects.
PR also adds `BLI_assert` in `load_curve_knots` function to check if
`CurvesGeometry::custom_knots` exists for custom mode curves. Thus
versioning code is needed addressing the issue in files in case such
already exists.
Pull Request: https://projects.blender.org/blender/blender/pulls/139554
The Movie distortion node crops its data if the movie size differs from
the input size. That's because boundary extensions do not take
calibration size into account. To fix this, we use the same coordinates
range as the distortion grid computation, which computes the distortion
in the space of the calibration size.
Pull Request: https://projects.blender.org/blender/blender/pulls/139822
It would run into using the same frame twice, looking like "freeze
frames"
Apparently we had a similar issue before, see 3f8ec963e3
Just a PoC to show that this looks like a precision/rounding issue when
getting a "working" `UsdTimeCode`.
In the modifier code, we are doing a roundtrip going from frame >> time
(in seconds -- via `BKE_cachefile_time_offset`) and then back to frame
before we store that in `USDMeshReadParams`.
To avoid the precision loss, this PR introduces
`BKE_cachefile_frame_offset` to stay in the "frame" domain and
circumvent going through FPS alltogether.
There might be better ways to let USD handle the "sightly off"
`UsdTimeCode` better though.
Pull Request: https://projects.blender.org/blender/blender/pulls/139793
This adds a new function to query GPUtexture from an
Image datablock without actually creating them.
This allows to keep track of all the texture that
needs to be loaded and defer their loading in
end_sync. The texture are then only used in the
next sync. This is because we do not want to stage
the texture for drawing as it would require a
valid texture.
Multithreading is used to load the texture from disk
as soon as possible in a threaded way. It is still
blocking, but it is much faster (depending on
hardware).
Before (5.7s):
After (2.5s):
On Linux workstation: 2.28x speedup in texture loading
On M1 Backbook pro: 2.72x speedup in texture loading
This includes redraw overhead but it is not super significant.
Having a vector of all the textures to be loaded
will eventually be helpful in making the
texture uploading multi-threaded. Currently, it is
a bit difficult given the need of a valid GPUContext
per thread.
- [x] Bypass deffered loading on animated textures
- [x] Add throttling to only load a few textures per frame
- [x] Do not delay for viewport render
Pull Request: https://projects.blender.org/blender/blender/pulls/139644
`BKE_id_material_used_with_fallback_eval` doesn't account for the case
the evaluated mesh is empty and `SubdivCCG` is used for drawing instead,
which only happens for workbench/EEVEE in sculpt mode. Instead of
further complicating the logic, change the multires modifier to produce
a copy of the input mesh with the SubdivCCG attached, rather than that
mesh being empty. This makes things like detecting the max material
index work "for free."
Pull Request: https://projects.blender.org/blender/blender/pulls/139742
Previously, the armature modifier retrieved the list of available vertex group
names from the original mesh. However, that list may contain different vertex
groups then are actually on the mesh that is being deformed. This patch makes it
so that the vertex group list (`defbase`) is taken directly from the
mesh-to-deform if possible.
Pull Request: https://projects.blender.org/blender/blender/pulls/139734
The path templates feature implemented in #134860 highlights path
properties that have syntax errors in red and provides a list of those
errors in the path's tool tip. However, syntax errors are not the only
kind of error.
For example, if given the render output path `//render/{blend_nam}`,
with a typo in the variable `blend_name`, this error is not indicated
until actually trying to render. This is because the path is
*syntactically* correct, and the error is due to `blend_nam` not being
an available variable.
This PR resolves this: paths with path template support now indicate all
errors in the UI, not just syntax errors, with red highlights and a list
of errors in the tool tip.
The primary mechanisms for this are:
- A new function `BKE_build_template_variables_for_prop()`, which takes
an RNA pointer and produces an appropriate template variable map for the
given property, which can then be used to fully validate a path
property's value in the UI code.
- A new enum `PropertyPathTemplateType` has been added to `PropertyRNA`,
which determines what variables should be made available to a property
and how they should be build. This is used by
`BKE_build_template_variables_for_prop()`.
Additionally, the following changes have been made to help ensure that
`BKE_path_apply_template()` and `BKE_path_validate_template()` produce
identical errors:
- Both functions now call into a third static function `eval_template()`
that does the actual work, optionally modifying the input path or not.
- Previously only `BKE_path_apply_template()` had unit tests, but now
the unit tests have been reorganized to simultaneously test both
`BKE_path_apply_template()` and `BKE_path_validate_template()`.
Pull Request: https://projects.blender.org/blender/blender/pulls/138679
Add ability to randomize color of each stroke for or use perlin noise
randomization during the stroke. Works similarly to grease pencil stroke
color randomization. This feature is available for all mesh color
painting modes (Sculpt Paint brush, Texture Paint and Vertex Paint)
This setting is available both as a per-brush setting and a unified
setting on the scene level. Additionally, the equivalent Grease Pencil
options have been migrated to these more generic flags and values.
Based on this [1] RCS request.
[1]: https://blender.community/c/rightclickselect/mwgbbc/
Pull Request: https://projects.blender.org/blender/blender/pulls/128953
So far this is unused, but it's used in #139165, and that pointed out
some obvious flaws in the code, like the resulting AttributeStorage
being completely ignored, and old CustomData layers not being freed.
Restructure the API a bit to make it simpler to use, and also make it
keep the non-generic layers in CustomData. That's not necessary for
point clouds but it will be necessary for curves (the next step) since
they have vertex groups.
Pull Request: https://projects.blender.org/blender/blender/pulls/139609
It is possible on file load that the `previous_active_brush_reference`
is an invalid old memory location. To prevent this, set the ptr to
nullptr on file load, as it should only be used within a given session.
Pull Request: https://projects.blender.org/blender/blender/pulls/139618
Set fuzzy=1 when softbody modifier is added. As of now, value is 0, this
raises concern of division by zero so bump it to 1.
Updated `softbody_test.blend` to fix the failing test.
Resolves#137849
Pull Request: https://projects.blender.org/blender/blender/pulls/137878
In a prior commit, the Mesh Paint BVH leaf node limit was reduced from
10000 faces to 2500 faces. This commit makes a proportional change
for the Multires paint BVH.
In performance testing of just the brush evaluation, this change
represents a 3x speedup (from 0.6326s to 0.2135s) on a Multires grid
with 25m vertices at multires level 5.
In a simulated brush stroke testing similar to what a user would do,
on a grid of 6m vertices at multires level 5 this change equals a 1.4x
improvement from 41.8 to 58.6 FPS.
See the related PR for the raw data and testing methodology.
Related to #137871
Pull Request: https://projects.blender.org/blender/blender/pulls/139311
e.g. stands for "exempli gratia" in Latin which means "for example".
The best way to make sure it makes sense when writing is to just expand
it to "for example". In these cases where the text was "for e.g.", that
leaves us with "for for example" which makes no sense. This commit fixes
all 110 cases, mostly just just replacing the words with "for example",
but also restructuring the text a bit more in a few cases, mostly by
moving "e.g." to the beginning of a list in parentheses.
Pull Request: https://projects.blender.org/blender/blender/pulls/139596
This adds a new Format String node which simplifies constructing strings from
multiple values. The node takes a format string and a dynamic number of
additional parameters as input. The format string determines how the other
inputs are inserted into the string. Only integer, float and string inputs are
supported for now.
It supports two different format syntaxes:
* Python compatible format syntax which also mostly matches the behavior of the
`fmt` C++ library. Most of this is supported, but there are some small
limitations.
* Syntax of the form `###.##` where each `#` stands for a digit. This is the
syntax that was introduced in #134860.
This node greatly simplifies common string operations which would have required
potentially many nodes before to convert numbers to strings and to concatenate
them. It also makes new conversions possible that were not supported before.
This node can also be used to insert e.g. frame numbers into a file path which
was surprisingly complex before.
This node has special behavior for the name of new inputs. For the purpose of
the node, the name of the inputs must be valid identifiers and it's usually
helpful when they are short. New names are therefore initialized to be single
characters. If possible, the first character of the linked input is used. This
works well when connecting e.g. a Separate Vector/Color node. Otherwise, inputs
are named `a` to `z` by default. If that's not possible, the source socket name
is used instead (converted to be a valid identifier). If that still doesn't
work, the name is made unique using the normal `.001` mechanism except that `_`
instead of `.` is used as separator to make the name a valid identifier.
Python Syntax references:
* Python: https://docs.python.org/3/library/string.html#formatspec
* `fmt`: https://fmt.dev/latest/syntax/
More detailed notes about compatibility with the above syntax specifications:
* Conversion using e.g. `!r` like in Python is not supported (maybe the future).
* Sub-attribute access like `{vector.x}` is not supported (maybe the future).
* Using `%` like in Python is not supported (maybe in future).
* Using `#` for an alternate form is not supported. This might help in the
future to make the syntax compatible with #134860.
* Using `L` like in the `fmt` library is not supported because it depends on the
locale which is not good for determinism.
* Grouping with e.g. thousands separators using e.g. `,` or `_` like in Python
is not supported (maybe in future). Need to think about the locale here too.
* Mixing of unnamed (`{}`) and named (`{x} or {0}`) specifiers is allowed.
However, all unnamed specifiers must come before any named specifier.
The implementation uses the `fmt` library for the actual formatting. However,
the inputs are preprocessed to give us more control over the exact supported
syntax and error messages. The code is already somewhat written so that many
strings could be formatted with the same format but that's not actually used yet
because we don't have string fields yet.
Error messages are propagated using a new mechanism that allows a limited form
of error propagation from multi-functions to the node that evaluates them.
Currently, this only works in fairly limited circumstances, e.g. it does not
work during field evaluation. Since this node is never part of field evaluation
yet, that limitation seems ok, but it's something to work on at some point.
Properly supporting that requires some more changes to propagate enough context
information everywhere. Also showing errors of field evaluation on the field
node itself (instead of on the evaluation node) requires even more work because
our current logging system is not setup to support that yet.
This node comes with a few new requirements for the socket items system: names
must be valid identifiers and they are initialized in a non-trivial way.
Overall, this was fairly straight forward to implement but currently it requires
to adding a bunch of new members to all the accessors that don't really need it.
This is something that we should simplify at some point even if I'm not entirely
sure how yet. The same new requirements used in this node would probably also
exist in a potential future expression node.
Pull Request: https://projects.blender.org/blender/blender/pulls/138860
In most cases this is a simple switch for `reinterpret_cast` or
`static_cast`, but for `BKE_paint_brush` and `BKE_paint_eraser_brush`
code is duplicated to avoid a `const_cast`.
Pull Request: https://projects.blender.org/blender/blender/pulls/139119
