This PR fixes several issues with the versioning that replaces the old
auto smooth flag with a modifier.
One issue is that the flag wasn't cleared in the initial versioning
code. That means some objects have the replacement modifier but their
meshes still have the flag set. The fix for that is to make the
versioning idempotent by trying to find an existing node group before
adding a new one. The versioning is now re-run on all objects to clear
the flags. Flags on all meshes are cleared too, even unused meshes.
That could cause loss of the auto-smooth when the mesh is linked from
a different blend-file, but that situation should be very rare.
Another issue was that the versioning wasn't run when linking objects.
That was simple to solve by adding the versioning where the proxy
versioning already existed for that case.
Finally, arguably the largest issue was that the the newly added node
groups were always added as local data-blocks. When linking, having
library data-blocks point to local data-blocks not in that library is
quite bad and breaks assumptions around Blender. This is solved by
having an auto smooth node group per library.
Resolves#119516, #119455, #119447
Pull Request: https://projects.blender.org/blender/blender/pulls/119539
This adds a "Solver" option to the geo boolean node, with the options
Exact and Float.
The current geo boolean node only uses the Exact solver.
This adds the ability to use the faster original floating point boolean solver.
The float solver has issues with coplanar and other coincident geometry,
but is generally much faster than the Exact solver, and users have asked
for this option (which is available in the Boolean Modifier and edit mode
boolean tool).
Like the modifier, the Float solver needs to convert the Mesh to BMesh,
do the operation, and then convert back to Mesh. It also has to do it
iteratively if more than two operands are supplied.
This is the first of a planned series of commits that will add a
new exact boolean solver, based on the Ember paper, as a solver option.
Ember will be much faster than the current exact solver, but may still not
be as fast as float, and also will not handle some non-volume-enclosing
inputs as well as Float, so it is likely that the Float solver will always remain.
We may eventually retire the old Exact Solver, however.
This commit also prepares for more sensible code in the future by
changing the internal enum names for the solvers to better reflect the
algorithms used: Fast -> Float, and Exact -> Mesh_Arr (which means
"Mesh Arrangments, the name of the paper upon which the current
exact solver is based).
Co-authored-by: Howard Trickey <trickey@google.com>
Co-authored-by: Hans Goudey <hans@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/119294
Use snapping increments matching values used before this was
customizable. [0] changed snapping increments from 5 degrees to 15,
from 1 to 5 degrees with precision enabled.
[0]: 060174cf14
The core of the issue was that `sculpt_flag` was used by three different enums (`eGP_Sculpt_Flag`, `eGP_Sculpt_Mode_Flag`, and `eBrushFlags`). This resulted in the flag getting overriden because `ENUM_OPERATORS` expected the maximum value of `eGP_Sculpt_Flag` to be `(1 << 3)` which it wasn't.
The `sculpt_flag` was exposed through python as `"direction"`.
In the UI this meant that it was effectively used as `brush.direction`. This fix replaces `brush.gpencil_settings.direction` with `brush.direction`.
It also makes sure `sculpt_flag` is only ever used with values from `eGP_Sculpt_Flag`.
Pull Request: https://projects.blender.org/blender/blender/pulls/119373
Add two snapping increment options: a regular value
(activated with Ctrl) and a precise value (activated with Ctrl+Shift).
These values are separate for 2D and 3D views.
Ref !118760
This PR initializes all brushes with the default automasking cavity
curve when a `startup.blend` file is loaded. Because there exists a
series of brushes that are added if they are not found in the
`startup.blend` file (e.g. "Paint") **after** the file is already
loaded, the existing fallback code to handle `nullptr` in the loader
code does not run.
Pull Request: https://projects.blender.org/blender/blender/pulls/118943
One of the consequences of the mistake in 3fcf535d2e (fixed in previous
commit), was that the more recent `LIB_EMBEDDED_DATA_LIB_OVERRIDE` ID
flag could be wrongly set in some nodetrees from pre-2.76 blendfiles.
This commit adds a check that embedded IDs flagged with
`LIB_EMBEDDED_DATA_LIB_OVERRIDE` are actually embedded IDs of a
liboverride.
Pull Request: https://projects.blender.org/blender/blender/pulls/118921
In 3fcf535d2e, the `ID.flag` data was split, keeping persisten flags in
`ID.flag`, and moving runtime ones into a new `ID.tag` data.
Some versionning code was then added to cleanup the existing `ID.flag`
on file read, but embedded IDs (root node trees only, back then) are not
stored in Main data-base, and were skipped.
Note that this fixes the conversion of older (2.76.4 and older) files.
There is no reliable way to cleanup files opened and saved from more
recent versions of Blender unfortunately.
This adds implicit sharing support for the `MemFile` undo-step. This decreases memory
usage and increases performance.
Implicit sharing allows the undo system to take (shared) ownership of some data.
Previously, the data would always be serialized and compared to the previous undo-step.
So this turns an O(n) operation into O(1) (in terms of memory usage and time).
Read/write code that wants to make use of this has to use the new `BLO_read_shared`
and `BLO_write_shared` functions respectively. Those either make use of implicit-sharing
internally or do the "full" read/write based on a passed-in function. It seems possible to
use the same API in the future to store shared data to .blend files.
Improvements:
* Much faster undo step creation in many cases by avoiding the majority data copies
and equality checks. This fixes#98574. I found undo step creation and undo step
decoding to be 2-5 times faster in some demo files from the blender website and in
some production files from the Heist project.
* Reduced memory usage when there is large data in `bmain`. For example, when
loading the same highly subdivided mesh that I used in #106228 the memory usage
is 1.03 GB now (compared to 1.62 GB in `main` currently). The main remaining copy
of the data now is done by rendering code.
* Some significant performance improvements were also measured for the new grease
pencil type (#105540).
There is one main downside of using implicit-sharing as implemented here: `MemFile`
undo steps can't be written as .blend files anymore. This has a few consequences:
* Auto-save becomes slower (up to 3x), because it can't just save the previous undo step
anymore and does a normal save instead. This has been discussed in more detail here:
https://devtalk.blender.org/t/remove-support-for-saving-memfile-undo-steps-as-blend-files-proposal/33544
It would be nice to work towards asynchronous auto-save to alleviate this problem.
Some previous work has been done to reduce the impact of this change in 41b10424c7
and f0f304e240. This has been committed separately in efb511a76d.
* Writing `quit.blend` has to do a normal file save now. So it's a bit slower too, but it's
less of a problem in practice.
* The `USE_WRITE_CRASH_BLEND` functionality does not work anymore. It doesn't seem
to be used by anyone (removed in e90f5d03c4)
There are also benefits to not writing `MemFile` from undo steps to disk. It allows us to
more safely do undo-specific optimizations without risking corrupted .blend files. This
is especially useful when we want to preserve forward compatibility in some cases.
This requires converting data before writing the .blend files, but this conversion is not
necessary for undo steps. Trying to implement this kind of optimization in the past has
often lead to bugs (e.g. 43b37fbc93).
Another new problem is that it is harder to know the size of each undo step. Currently, a
heuristic is used to approximate the memory usage, but better solutions could be found
if necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/106903
In many modes, Blender uses the `MemFile` undo step, which serializes all DNA
data in RAM almost as if writing a .blend file. For auto-save, Blender used to
write the last `MemFile` undo step to disk because that was faster serializing
all of DNA again. Furthermore, saving the `quit.blend` file when closing Blender
also used this.
This functionality is now removed in preparate for supporting implicit sharing
in the undo system (#106903). Auto-save and saving the quit.blend file now use
regular file saving.
The removal of this feature and its implications have also been discussed here:
https://devtalk.blender.org/t/remove-support-for-saving-memfile-undo-steps-as-blend-files-proposal/33544
Add percentage closer filtering to shadowmap sampling and a
`shadow_filter_radius` property to lights to control it.
Notes:
* This adds PCF to `eevee_shadow_tracing_lib`, but not to
`eevee_shadow_lib`, which is used by volumes (not required) and
thickness.
* PCF is computed based on the LOD0 size. This assumes that higher
LODs are only used when the shadowmap resolution is actually good
enough to match the render resolution.
Pull Request: https://projects.blender.org/blender/blender/pulls/118220
When an asset is heavily modified, all production files having
liboverrides of it will still try to link all their known linked
reference IDs, leading to potentially thousands of not-really-useful
warnings about missing IDs in the console.
Now that liboverrides resync cleans up better these left-over data, it's
better to report missing linked data _after_ the liboverride resync
process.
Note that the original place can still report all effectively missing
linked data if needed, but this is now a logging info, so it won't be
displayed anywhere unless explicitely requested.
Pull Request: https://projects.blender.org/blender/blender/pulls/118577
This is a migration of the current Line Art modifier to GPv3.
Note:
- The modifier is using the exact same DNA structure as the old one, it's re-defined in a different name. At the moment all the variable names and placement after the `ModifierData` part should stay exactly the same until we do proper versioning of the modifier data and completely remove the GPv2 support.
- Vertex weight transfer feature no longer supports name initial matching ("group" used to match "group1","group2" etc). Now it will only transfer vertex weight from source vertex groups that has the exact same name as specified.
Pull Request: https://projects.blender.org/blender/blender/pulls/117028
This adds an option `WITH_EXPERIMENTAL_FEATURES` which is `ON` by default.
Sometimes it's usefull to be able to turn off all experimental features
during development for testing purposes. This option is still enforced to be
`OFF` for release cycles other than `alpha`.
Pull Request: https://projects.blender.org/blender/blender/pulls/118513
Initialize a remote repository pointing to
https://extensions.blender.org and a local repository to use for
local (side-loaded) extensions installed from the file-system.
Blender had a very limited (only uncompressed or MJPEG frames) .avi file
support, for both reading and writing. This is something that ffmpeg can
fully do.
This removes all of that. 3500 lines of code gone, primary motivations being:
- ffmpeg can read and write .avi files just fine, including ones with
uncompressed or MJPEG frames.
- Blender's ffmpeg integration could also be taught to produce uncompressed or
MJPEG .avi files, but TBH I don't see a particular reason to do that. Modern
formats like H264 are better in every way, and already support "lossless"
option if needed.
- The "Lite" blender build configuration was excluding both ffmpeg and avi
anyway, so that config is something that can't read nor write any movies.
User visible changes:
- In scene image output type, under Video section now there's only Ffmpeg Video
(AVI Raw and AVI JPEG are gone)
- Whenever loading an existing file, if output was one of AVI Raw / AVI JPEG,
it is set to Ffmpeg Video.
Pull Request: https://projects.blender.org/blender/blender/pulls/118409
This patch adds a new `Stretching Opacity` slider to the overlays panel in the UV Editor.
This allows users to tweak the opacity of the UV stretching overlay, so the image texture
can still be visible through it.
Pull Request: https://projects.blender.org/blender/blender/pulls/117381
The depsgraph CoW mechanism is a bit of a misnomer. It creates an
evaluated copy for data-blocks regardless of whether the copy will
actually be written to. The point is to have physical separation between
original and evaluated data. This is in contrast to the commonly used
performance improvement of keeping a user count and copying data
implicitly when it needs to be changed. In Blender code we call this
"implicit sharing" instead. Importantly, the dependency graph has no
idea about the _actual_ CoW behavior in Blender.
Renaming this functionality in the despgraph removes some of the
confusion that comes up when talking about this, and will hopefully
make the depsgraph less confusing to understand initially too. Wording
like "the evaluated copy" (as opposed to the original data-block) has
also become common anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/118338
The tiled compositor code is mainly still around, which is only
expected to be a short-lived period. Eventually it will also be
removed.
The OpenCL, Group Buffers, and Chunk size options are already removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/118010
