Grouping the legacy DerivedMesh code in the same place helps keep
the actively maintained code clearer and clarifies what we are hoping
to remove in the future.
Move to a file with the more consistent "mesh_legacy" naming, out of the
modifier evaluation code which has nothing to do with this anymore. That
file can be renamed in a separate step.
Using a non-virtual derived struct for polymorphism is error prone,
especially combined with the requirements of DNA. Instead, use a
separately allocated runtime struct as done for many other DNA structs.
In a followup commit, the remaining runtime members of `PreviewImage`
could be moved to the new runtime struct.
Pull Request: https://projects.blender.org/blender/blender/pulls/121509
The function was declared in a BKE header but defined in
the sculpt_paint editors module. Move it to the slightly-less
arbitrary ED_sculpt.hh header instead.
Jittered Soft Shadows support.
Improves soft shadow quality at the cost of re-rendering shadow maps every sample.
Disabled by default in the viewport unless enabled in the Scene settings.
| Tracing-only | Jitter-only | Jitter+Over-blur |
| --- | --- | --- |
|  |  |  |
Tracing-only is the method used by default in EEVEE-Next.
Jitter-only is the method used by EEVEE-Legacy Soft Shadows.
Jitter+Over-blur combines both.
Co-authored by Miguel Pozo @pragma37 (initial patch #119753)
Pull Request: https://projects.blender.org/blender/blender/pulls/121836
This commit prevents considering Scenes (and a few other ID types, like
WindowManager or Library) as being part of liboverride hierarchies.
Having collections, objects, obdata etc. depend on a Scene ID is
typically not considered as a valid setup for linked data.
And in any case, Scenes are not officially supported for liboverrides
currently.
In the case of #121410, where a driver of the armature object was using
the Scene ID, it will simply keep that scene reference pointing to the
linked scene, instead of overriding the whole scene.
Code checking whether an ID should be considered as part of the
currently processed liboverride hierarchy or not was very similar all
over the liboverride code.
It is now deduplicated into two util functions, which helps ensuring
coherence in these checks, and future potential changes in this
filtering process.
NOTE: While no pratical changes are expected form user PoV with this
refactor, technically it does modifies the behavior in some cases (added
checks).
This required making a whole bunch of other functions in the call chain
take const parameters as well. It also required changing some function
pointers in some types to take const parameters, which in turn required
changing all the functions that are pointed to by those function
pointers to take const parameters as well.
Additionally, there was one mutable usage of the `FModifier *` parameter
in `fcm_cycles_time()` that had to be removed to make the call chain
const. However, this turned out to be a code path that shouldn't be
reachable, and would represent a bug elsewhere. So it was changed to
an assert.
All in all, the non-constness was deep and tangled.
There's still a lot more that we can make const, but I wanted to keep
this change as narrow and focused as possible.
Code used to tag liboverrides references as 'pre-existing' to force code
further down the way to always keep these IDs linked.
However, this was a (bad) hack, since it could have uncontrollable
side-effects, abusing a tag for somethig else than its original meaning.
And this should not have been needed for quite some time already, as
liboverrides handling was already properly done by append
post-processing code.
No behavior change expected here.
In a nutshell, the handling of dependencies in the 'append' part of the
code was not fully correct, and could break badly in some complex cases
(like appending complex hierarchies of data partially re-using some
dependencies from other previously appended data).
This could lead to e.g. some linked data referencing some local IDs...
straight way to crash in undo case (among many other problems).
Previous code was fairly compact and tried to be smart and efficient,
making some not-always-correct assumptions, and being quite hard to
fully understand.
So the first step of this fix was some refactoring:
* Splitting the post-process part of the 'link' case into its own
function (it is fairly trivial, and while it does duplicate some
logic to some extent, it makes the overall link/append process
clearer).
* Heavily refactoring the part of the 'append' code that decides how
to handle each linked ID.
The append-related post-processing is now significantly more complex,
but hopefully better divided in reasonably logical steps. And it is now
expected to deal with complex re-usability cases properly.
Pull Request: https://projects.blender.org/blender/blender/pulls/121867
Add new ID_IS_EDITABLE macro that checks if the ID can be edited in the
user interface. Replace usage of ID_IS_LINKED where it is used with this
meaning.
Also add a corresponding ID.is_editable property for Python.
This prepares for the ability to edit some linked datablocks for brush
assets.
Pull Request: https://projects.blender.org/blender/blender/pulls/121838
The end of a fixed duration frame is stored as a special
`GreasePencilFrame`, notably with a `drawing_index` of
-1.
These were previously called "null" frames (because they
don't point to a drawing). But this name wasn't great.
This commit renames these to the more descriptive
"end" frame. In code, they are `GreasePencilFrame::end()`
and can be checked for with `frame.is_end()`.
All comments and function names referring to "null"
frames have also been updated.
Pull Request: https://projects.blender.org/blender/blender/pulls/121868
This unify Cycles and EEVEE setting.
We always copy the Cycles setting in versionning
except if the first scene is using EEVEE as renderer.
Note that this currently breaks importers
addons who will try to `cycles.cast_shadow`property
on the light.
Pull Request: https://projects.blender.org/blender/blender/pulls/121804
The extensions system allows to extend Blender with connectivity to the internet. Right now it means Blender can
discover and install add-ons and themes directly from the internet, and notify users about their updates.
By default this is disabled (opt-in), and users can enable it the first time they try to install an extension or visit
the Prefences > Extensions tab. If this is enabled, Blender will automatically check for updates for
extensions.blender.org upon startup.
When will Blender access the remote repositories:
* Every time you open the Preferences → Extensions: ALL the enabled repositories get checked for the latest info (json)
* Every time you try to install by dragging: ALL the enabled repositories get checked for the latest info (json).
* Every time you start Blender: selected repositories get checked for the latest info (json).
------------------
From the Blender code point of view, this means that most of the add-ons and themes originally bundled with Blender
will now be available from the online platform, instead of bundled with Blender. The exception are add-ons which are
deemed core functionality which just happened to be written as Python add-ons.
Links:
* Original Extenesions Platform Announcement: https://code.blender.org/2022/10/blender-extensions-platform/
* Extensions website: https://extensions.blender.org/
* User Manual: https://docs.blender.org/manual/en/4.2/extensions/index.html#extensions-index
* Technical specifications: https://developer.blender.org/docs/features/extensions/
* Changes on add-ons bundling: https://devtalk.blender.org/t/changes-to-add-on-bundling-4-2-onwards/34593
------------------
This PR does the following:
* Move extensions out of experimental.
* No longer install `scripts/addons` & `scripts/addons_contrib`.
* Add `scripts/addons_core` to blender's repository.
These add-ons will still be bundled with Blender and will be always enabled in the future, with their preferences
moved to be more closely integrated with the rest of Blender. This will happen during the remaining bcon2 period.
For more details, see #121830
From scripts/addons:
* copy_global_transform.py
* hydra_storm
* io_anim_bvh
* io_curve_svg
* io_mesh_uv_layout
* io_scene_fbx
* io_scene_gltf2
* pose_library
* ui_translate
* viewport_vr_preview
Extra: bl_pkg (scripts/addons_contrib)
Note: The STL (legacy) add-on is going to be moved to the extensions platform. There is already a C++ version on core
which is enabled by default.
All the other add-ons are already available at extensions.blender.org. To use them you need to:
* Go to User Preferences > Extensions
* You will be greated with an "Online Extensions" message, click on "Enable Repository".
* Search the add-on you are looking for (e.g, Import Images as Planes).
* Click on Install
Over time their maintaince will be transferred over to the community so their development can carry on. If you used to
help maintain a bundled add-on please read: https://devtalk.blender.org/t/changes-to-add-on-bundling-4-2-onwards/34593
Ref: !121825
To simplify propagation of the attribute with joined geometry
(0.0 defaults are generally easier to handle with attributes, and
even more performant), store the inverse of the current "hardness"
attribute as "softness" instead. This change involves adding a few
`1.0f - value` operations, though in the future as the renderer is
replaced that mostly should become unnecessary.
Updated version of #118007.
Pull Request: https://projects.blender.org/blender/blender/pulls/121578
This PR changes the `vert_hide_update` function to flush visibility
from the selected vertices to their corresponding faces on the node
level instead of on the mesh level. This ensures that in certain cases
where vertices exist along the border of a nodes are selected that
all corresponding faces are updated and their PBVH nodes are tagged
for updating appropriately.
Additionally, this provides a roughly 15ms improvement over the current
implementation operating on a subdivided sphere of 32 million vertices
when selecting a relatively small portion of the mesh. (50ms -> 35ms).
Spawned from a discussion on #120798
Pull Request: https://projects.blender.org/blender/blender/pulls/121678
Caused by 85ce2a34e3
Default layers added with the primitive gpv3 object has the `use_mask`
property enabled. To fix this, set `GP_LAYER_TREE_NODE_HIDE_MASKS`
inside `add_layer/groups()` function instead of the operator's code.
Falk found this in #121734
Pull Request: https://projects.blender.org/blender/blender/pulls/121780
Sun extraction convert part of light comming from the world to a
sun light which increases the quality of the rendering. The goal
of this feature is to workaround the limitation of the storage
techniques used for environment lighting inside EEVEE.
This first implementation works by clamping the world lighting and
summing the excess lighting and (and its incomming directions) to
deduce the sun position.
All the lighting is then transfered into this light power. The sun
angle is computed based on the directionnality of the excess lighting,
the more divergent the excess lighting is, the bigger the angle.
This has a few benefits:
- It's stable and behave well under animation. This is because we
average a lot of data.
- It's fast as it can be done inside the remap shader in one pass.
- It requires only one parameter, the clamp threshold.
However, it has some issue:
- It modifies the lighting as we change the incomming direction for
excess lighting away from the chosen sun direction. This could be fixed
by masking only lighting around the chosen sun direction (requires 2
passes, slower).
- Given that this only average the direction, it behaves poorly if there
two opposite bright light sources (it puts the sun in the middle). This
could be fixed by extracting more suns, but that becomes more complex
and requires even more passes.
- It looks bad if the summed lighting is not supposed to be a perfect
disk in specular reflections or if the sources are too divergent as the
disk is too big and the approximation fails short. This could be
mitigated by adding an upper bound to the sun radius. For now we
workaround this issue by exposing the sun angle parameter in the UI.
A more precise algorithm can be implemented in the future to avoid
having to deal with these limitations. A possibility is to use
importance sampling to randomize sun position. But that would be only
for final render.
Pull Request: https://projects.blender.org/blender/blender/pulls/121455
This implements and exposes the `View`/`Scene` brush radius option.
* `View`: Brush units are in pixels. Zooming in and out in the viewport will make the brush stay the same size relative to the view, but grow/shrink relative to the scene.
* `Scene`: Brush units are in meters. Zooming in and out in the viewport will make the brush grow/shrink relative to the view, but stay the same size relative to the scene.
The default radius unit is `Scene`, which is what GPv2 did.
The "2D Animation Template" was updated to disable using the radius in the unified paint settings. This means that using the template by default will use the brush radius, which also mimics the behavior of GPv2.
The user can change the radius brush unit from the `Advanced` panel.
Pull Request: https://projects.blender.org/blender/blender/pulls/120257
The undo system needs to invalidate all caches when decoding
an undo step for now. This was not done for some caches
(probably because they were added at a later stage).
The fix makes sure all caches on the `Drawing` runtime data
are tagged after decoding a step.
Pull Request: https://projects.blender.org/blender/blender/pulls/121777
This just hid that freed memory was being passed to
CTX_wm_region_popup_set.
The change from [0] exposed this issue, however the problem has
existed for a long time (likely since the inclusion of popups in the
context) it's just that setting the context member when popups
are first displayed made problems more likely to show up.
[0]: 38d11482f5
The `LayerGroup` class had an API to add layers and layer groups.
The only thing these did was allocate a new layer/group and then
call the `add_node` API.
This removes these functions (they were only used in a single
place anyway) and does the allocation of the new layer/group
directly in the grease pencil API. This removes a few lines of
code and makes everything a bit easier to read.
There was an overloaded version of `add_layer` that took
a const reference to a source layer. The function would
duplicate that layer.
The function name `add_layer` was a bit confusing in this
case. Calling it `duplicate_layer` makes it a bit clearer.
Remove the `Action::binding_for_id()` method, as it is a bit dangerous,
only useful in a very specific situation, and can be removed altogether
with just a little bit of refactoring. This in turn made some other
functions a bit simpler too.
Almost no functional changes. The only change is that when through some
magic (aka data corruption or other bug) the Binding is no longer valid
for the animated ID's type, the IDs properties may still show as
animated in the interface.
Pull Request: https://projects.blender.org/blender/blender/pulls/121748
Move all header file into namespace.
Unnecessary namespaces was removed from implementations file.
Part of forward declarations in header was moved in the top part
of file just to do not have a lot of separate namespaces.
Pull Request: https://projects.blender.org/blender/blender/pulls/121637
The new/experimental, layered `Animation` data-block is merged with the
existing `bAction` data-block.
The `Animation` data-block is considerably newer than `bAction`, so the
supporting code that was written for it is also more modern. When moving
that code into `bAction`, I chose to keep the modernity where possible,
and thus some of the old code has been updated as well. Things like
preferring references over pointers.
The `Animation` data-block is now gone from DNA, the main database, etc.
As this was still an experimental feature, there is no versioning code
to convert any of that to Actions.
The DNA struct `bAction` now has a C++ wrapper `animrig::Action`, that
can be obtained via `some_action->wrap()`.
`animrig::Action` has functions `is_empty()`, `is_action_legacy()`, and
`is_action_layered()`. They **all** return `true` when the Action is
empty, as in that case none of the data that makes an action either
'legacy' or 'layered' is there.
The 'animation filtering' code (for showing things in the dope sheet,
graph editor, etc) that I wrote for `Animation` is intentionally kept
around. These types now target 'layered actions' and the
already-existing ones 'legacy actions'. A future PR may merge these two
together, but given how much work it was to add something new there, I'd
rather wait until the dust has settled on this commit.
There are plenty of variables (and some comments) named `anim` or
`animation` that now are of type `animrig::Action`. I haven't renamed
them all, to keep the noise level low in this commit (it's already big
enough). This can be done in a followup, non-functional PR.
Related task: #121355
Pull Request: https://projects.blender.org/blender/blender/pulls/121357
Reduce cognitive complexity by returning early in `BKE_pose_minmax()`.
Also rename `changed` to `found_pchan`, as that explains better what's
being tracked.
No functional changes.
Remove the `use_hidden` parameter of the `BKE_pose_minmax()` function.
This parameter was only used with `use_selected` set to the same value,
with the following effects:
- Both set to `true`: only selected bones are considered. Since hidden
bones are automatically deselected, this effectively excluded hidden
bones.
- Both set to `false`: explicitly excludes hidden bones.
So in both use cases hidden bones were ignored, which IMO is the correct
approach anyway, as the bounding box is used for centering in view,
snapping to bounding box, etc.
No functional changes.
