This commit implements #125759.
It removes:
* Blender does not build on big endian systems anymore.
* Support for opening blendfiles written from a big endian system is
removed.
It keeps:
* Support to generate thumbnails from big endian blendfiles.
* BE support in `extern` or `intern` libraries, including Cycles.
* Support to open big endian versions of third party file formats:
- PLY files.
- Some image files (cineon, ...).
Pull Request: https://projects.blender.org/blender/blender/pulls/140138
This commit effectively reverts the changes introduced in
23951e1b12 that changed how the brush
strength curve calculation works. Since that commit, a number of high
severity regressions have been reported, and the decision to remove
filtering from this method now seems dubious and likely to cause further
problems.
Other interim fixes that were made have not been reverted, as they are
generally correct to do, even if they cause an extra loop over all of
a node's factors & distances. In general, all existing unnecessary calls
to `filter_distances_with_radius` are planned to be removed in 5.0.
Finally, to address the original issue that the mentioned commit was
intended to fix, we now check distance for the constant falloff and
zero out the factor if necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/140181
In 884ef238c0 line art added a safe guard in depsgraph iterator to
properly handle dupli-objects, but it should check original objects id
for inclusion instead of evaluated objects. Now dupli-objects will show
up correctly.
Pull Request: https://projects.blender.org/blender/blender/pulls/140095
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
This is part of the short term roadmap goal of simplifying the
compositor workflow
(see https://projects.blender.org/blender/blender/issues/134214).
The problem is that many users don't know how to get started with
compositing in Blender, even when they have used Blender for other
areas, e.g. modeling.
Note: although the solution makes compositor node trees reusable
accross blend files, this is a nice side effect and not the main goal
of the PR.
This PR implements a "New" button that creates a new compositing node
tree, and manages trees as IDs. This has following advantages:
- Consistent with other node editors and other parts of Blender,
therefore making it easier to getting started with compositing if users
are familiar with shading or geometry nodes
- Give users the ability to reuse the compositing node tree by linking
or appending it.
Note: The parameter "Use Nodes" is still present in this PR, but will
be removed (in a backward compatible way) in a follow up PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/135223
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
This adds support for specifying structure types on closures. The main immediate
benefit is that this makes it possible to use fields with closures (without
having incorrect warnings in the UI).
A closure zone behaves very similar to a node group with respect to structure
type inferencing. The structure types can be inferenced fully automatically, or
the user can specify them manually on the closure inputs. On the evaluate
closure zone, the user has to specify the structure types of the inputs and
outputs explicitly (or leave them as dynamic).
Working on this, I was a bit surprised that `get_output_socket_shape` depended
on the field state. Is that a left-over? It feels like it shouldn't be necessary
since the socket shape shouldn't depend on field inferencing anymore. I removed
that now and couldn't see a difference yet.
The operator that creates a closure zone from an evaluate closure node copies
the input structure types already. Beyond that, there is no automatic syncing of
the structure types yet. The structure types only affect the UI and not what's
actually done during evaluation.
Pull Request: https://projects.blender.org/blender/blender/pulls/139713
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
This moves `PointCloud` to use the recently added `AttributeStorage`
at runtime. Mainly this involves implementing the higher level attribute
API on top, and implementing the RNA API as well. The attribute RNA type
is now backed by either CustomDataLayer or bke::Attribute. For now the
new code is specific to point clouds but next steps can reuse it for
Grease Pencil layer attributes, curves, and eventually meshes.
Point cloud attributes no longer have a name length limit.
Internally, the `AttributeStorage` API is extended with a few additions:
- The data structs have static constructors for convenience.
- A few functions give index-based access to attributes
- A "rename" function is added.
The `Attribute` RNA type now exposes a `storage_type` property.
For now the "single value" option is still unused at runtime, and
accessing the single value data isn't implemented yet.
Pull Request: https://projects.blender.org/blender/blender/pulls/139165
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
when there is no uv, we call the function `map_to_sphere()` to create
temporary uv for computing the tangent. It could happen that a triangle
has vertices with the u coordinates going across the line where u wraps
from 1 to 0. In this case, just computing the difference of the u
coordinates results in the wrong triangle area.
To fix this problem, we compute distance in toroidal (wrap around)
space.
This is safe for coordinates generated by `map_to_sphere()` function,
because it is not supposed to map the positions of a triangle to u
coordinates that span larger than 0.5.
Pull Request: https://projects.blender.org/blender/blender/pulls/139880
Removes various image filtering/mipmapping leftovers from
pre-2.80 days.
Code: removes all mipmap handling from ImBuf (which is about half of
ImBuf struct size), removes now unused "sample procedural texture
with mipmaps" code, now-unused FELINE filter, etc. The osatex
parameter to various CPU texture sampling functions is never
actually used, which means none of the mipmap code was ever executing.
User visible part: there were settings on the legacy Texture data
block (as used by Brushes etc.), under Sampling section: "MIP Map",
"Gaussian Filter", "Filter Type", "Eccentricity", "Minimum Size" --
they had no effect anywhere, so they are gone, and what remains is
only "Interpolation" and "Size".
RNA / Python API part: removes the ImageTexture RNA properties
corresponding to the above: filter_type, use_mipmap, use_mipmap_gauss,
filter_lightprobes, filter_eccentricity, use_filter_size_min.
Pull Request: https://projects.blender.org/blender/blender/pulls/139978
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
In `brush_blend_write` and `scene_blend_write` the brush/tool settings
brush size are doubled for 5.0 to store diameter instead of radius, it
should be divided back to original value after writing (for undo),
otherwise your will see your brush size doubles everytime an undo push
is involved.
The doubling was caused by 582c7d94b8, now it should not
happen.
Pull Request: https://projects.blender.org/blender/blender/pulls/139914
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
In certain cases, when a Mesh is generated from a BMesh as part of
Dyntopo sculpting, (e.g. when the data is invalidated when leaving
Dyntopo or Sculpt mode) the face and vert indices are compressed to
remove any gaps that may exist due to deletion of elements. This step is
redundant to perform prior to converting to a Mesh, as the process of
doing so already compresses the indices
To avoid doing extra work, this commit simply removes this conversion
and any associated helper methods.
Pull Request: https://projects.blender.org/blender/blender/pulls/139313
Complete the versioning and writing changes from these commits:
- f9b627d29c
- f2bcd73bd2
- c5ba8bd7c2
4.5 has the forward compatibility handling to support reading files
written by 5.0. This removes the conversion when writing files
and removes the lookup of ".uv_seam" as a fallback for "uv_seam".
Pull Request: https://projects.blender.org/blender/blender/pulls/139841
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
