This patch removes node init functions that currently exist only for
forward compatibility and moves the logic to the forward compatibility
section of node writing. This is to avoid allocating unused data
throughout the 5.x series.
Pull Request: https://projects.blender.org/blender/blender/pulls/140273
Previously, the subdivision level was clamped to 11. While such high subdivision
levels are rare, there are still use-cases for going above those if hardware
resources allow for it.
This patch sets the hard upper limit to 15. When going above that, even
subdividing a single triangle would result in data that's too large to store in
`Mesh` because it has too many face corners for an `int`. Furthermore, instead
of clamping the subdiv level, there is an error when going above that. This
might help when accidentally connecting a value >= 16 to the subdiv level input.
Pull Request: https://projects.blender.org/blender/blender/pulls/140057
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
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
The versioning code for the new `Scale` input (a92b68939a)
always added new versioning nodes connected to the `Scale` input to ensure
that the node behaves as before.
But these versioning nodes are only necessary when a profile curve is connected.
Otherwise, they don't have any effect at all, since the node just outputs
a wire mesh in this case.
This skips adding the versioning nodes in case the profile socket
is unused. The default scale value will be 1.
Pull Request: https://projects.blender.org/blender/blender/pulls/138968
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 checks and related warnings detecting usage of blendfiles generated
by newer versions of Blender were not fully behaving as expected for
libraries. In particular, opening an older main blendfile linking
against newer library ones would not always detect and report the
`has_forward_compatibility_issues` status properly.
Found out while working on 'longer ID names' compatibility PR for 4.5
(!139336).
In Geometry Nodes workspace, the viewport has a default value of 0.0
for `gpencil_vertex_paint_opacity`, this causes material preview to not
show proper vertex color even when strokes have color. Considering this
property is a bit obscure, setting a default value of 1.0 here makes
sense and it's also consistent with the rest of the viewport editors in
other workspaces.
Pull Request: https://projects.blender.org/blender/blender/pulls/139356
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
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
- Previously, effects could be changed into types that take different
amount of inputs, e.g. from "add" to "glow", which led to undefined
and glitchy behavior (unreported bug). Fix by requiring same input count
for new effect.
- Previously, strip names were not updated when changing effect type,
which tended to be confusing. Now, if the default name was not changed,
update to the new effect type name.
- Remove "effect strip" menu from color and text strips. Although they
are effects internally, to a user, this is not clear, and providing the
option to modify effect inputs in these cases doesn't really make sense.
Pull Request: https://projects.blender.org/blender/blender/pulls/139514
The issue was the usage of `change_link_placeholder_to_real_ID_pointer`
to remap the removed duplicate Library ID pointer to its first instance.
Library ID pointers are _not_ placeholder ones, and therefore the check
on entries in `change_link_placeholder_to_real_ID_pointer_fd` would
fail, leading to never actually remapping this removed Library ID
pointer.
Added a dedicated separate util functions for this usage, as it is
important to keep it clearly distinct from the more usual remapping of
placeholder IDs to their real linked counterparts.
-----
This issue was likely never noticed before, because:
* 'Standard' Library ID pointers are rare, nowadays they are mostly
coming from the Outliner tree items. (`ID.lib` pointers and the like
are set by readfile code outside of/before the lib-linking process.)
* Files with duplicate libraries should not be possible to create for
quite a few years already.
Found out while working on forward compatibility for the Embedded Linked
IDs, since in this project 'duplicates' of libraries (from older code PoV)
are expected: the 'archive' Library IDs.
Overall the goal of the PR is to show the preview range in the
clip editor's dopesheet and graph mode.
To accomplish this, some cleanup and refactor were needed:
- Clip editor had a nearly 1:1 copy paste of the timeline draw code,
which has been replaced with `ANIM_draw_framerange`.
- Preview range draw code required `bContext`, which was only used to
access scene. Now scene is passed explicitly, without need to know the
context.
- The macro to access the preview range was removed. This is because the
code is within `PRVRANGEON` check, so `PSFRA`/`PEFRA` were doing
redundant checks.
Pull Request: https://projects.blender.org/blender/blender/pulls/138678
Implementation of #127106.
This is just a visual representation of the field/single/grid
status of sockets to make the workflow more intuitive. With
a visual representation for volume grid sockets, volume features
should be unblocked for further development. The structure type
will also be used to distinguish list sockets in the interface.
Group input nodes now have a "Structure Type" option instead of
the existing "Single Value Only". Usually the auto option should be
enough, but in some cases where the inferencing cannot (yet) make
a clear determination, it can be helpful to choose a specific type.
The new visualization and the group input structure type option
are hidden behind a new experimental option for now.
Pull Request: https://projects.blender.org/blender/blender/pulls/134811
This patch turns the Blur node options to inputs.
Size is now a 2D vector and replaces the Size X and Y option. Bokeh was
renamed to Separable to reflect its actual function. Relative was
removed in favor of the newly added Relative To Pixel node workflow.
There is a slight difference in variable size blurring due to float vs
integer computations, so two tests were updated.
Reference #137223.
Pull Request: https://projects.blender.org/blender/blender/pulls/139329
This patch adds support for 2D and 4D vector sockets. The default value
structure for vectors was extended to include a new dimensions input,
which can be 2, 3, or 4. The default value was also extended to be a
float4, but only some of its components might be used depending on the
dimensions members.
Each vector subtype now has three variants ending with 2D or 4D as a
prefix depending on its dimensions, and the 2D/4D prefix was taken into
account for the socket type RNA enum functions.
All node systems currently always treat the vectors as 3D, but support
for it in the compositor will shortly follow in another patch.
Depends on #138805.
Pull Request: https://projects.blender.org/blender/blender/pulls/138824
This patch adds a new Image Coordinates node for the compositor. The
Texture Coordinates and Pixel Coordinates outputs were removed from the
Image Info node and were added to the new node instead. Additionally, a
new Normalized Coordinates output was added.
The Pixel Coordinates output now no longer includes half pixel offsets.
Pull Request: https://projects.blender.org/blender/blender/pulls/138935
Readfile code would not always properly set the main file version number
in 'split' Mains created for a library, and would also not detect
'future versions' blendfiles.
This info is currently not used by linking code, so this should be a
no-op change in current main.
Regression from [0] this was meant to be `EXR_TOT_MAXNAME - 2`,
but wasn't updated when `EXR_TOT_MAXNAME` changed.
Also use UTF8 string copying since it's expected to be UTF8.
[0]: 2c8db87897
This patch turns the options of the Color Balance node into inputs.
In the process, each of the wheels were split into two inputs, a base
float and a color. For instance, Gain is controlled using both a Base
Gain and Color Gain, the former controls the gain for all channels while
the latter controls it per channel.
Reference #137223.
Pull Request: https://projects.blender.org/blender/blender/pulls/138610
The main goal of this patch is that the column widths and ordering is not reset
every time one switches between different contexts.
It does that by keeping track of multiple `SpreadsheetTable`. There is one for
each table that is viewed (so e.g. the point and edge domain of the same mesh
are two different tables). Each table has an identifier and an array of columns.
There is some garbage collection in place so that the number of stored tables
does not increase unbounded.
This also comes with an updated Python API:
```python
import bpy
spreadsheet = bpy.context.screen.areas[...].spaces.active
active_table = spreadsheet.tables.active
print(active_table.id.type)
print(active_table.id.attribute_domain)
print(active_table.columns[0].id.name)
```
In the future, we might add some smarter logic to keep tables with different
identifiers more in sync. We don't have a great heuristic for that yet.
Pull Request: https://projects.blender.org/blender/blender/pulls/139205
Use a similar convention for struct member identifiers,
(the identifiers without surrounding spaces). This allows the values
to be scanned and validated.
Similar to other renderers, this adds a temperature property to set the
light color using blackbody emission. This can be more convenient than
using nodes, and can improve interop with other software.
This is supported in Cycles, EEVEE, Hydra, USD, COLLADA and FBX.
Pull Request: https://projects.blender.org/blender/blender/pulls/134303
This patch adds snapping options for the playhead to all animation editors.
The options can be modified through a new dropdown in the editor header.
All editors will show all those options, and they are shared,
so toggling the option in on editor will change it for all other editors too.
Some options are not working/relevant in some editors for example
Strips in the Dope Sheet. However for consistency the option is still shown.
This is a separate menu from the transform snapping menu because
you can toggle the snapping for transform and playhead separately.
Putting it in the existing snapping transform menu would imply that it can
be turned off with the magnet which is not the case.
Playhead snapping is explicitly disabled for the drivers editor
because there is no playhead to drag around.
Snapping to Frame/Second intervals takes the scene start as a starting point.
That means you can snap to the n-th second of the animation even though
it might not start at frame 1. The preview range is NOT taken into account
by design since the use case is working on a sub-section of the animation
in which case the snap target should not change.
Snapping is toggled by pressing CTRL as indicated by the status bar.
Snapping to Frames/Seconds is absolute, meaning no matter
how far away your cursor it will snap to the closest snap point.
All others only snap to things if they are close to the cursor in pixel values.
When mixing those two behaviors, it prefers relative snapping.
If no point is close enough to snap relative,
it will fall back to absolute snapping.
Based on the prototype #135913
Part of #135794
Pull Request: https://projects.blender.org/blender/blender/pulls/137278
This patch turns the options of the Crop node into inputs.
Instead of specifying the bounds of the crop, the inputs now specify the
Width and Height of the crop region. The Crop Image Size option was
renamed to Alpha Crop and inverted, so it now defaults to actual
cropping. The Relative option was removed, as it is now superseded by
the Relative To Pixel node, and removal was done to facilitate the
options to inputs project.
Reference #137223.
Pull Request: https://projects.blender.org/blender/blender/pulls/139163
This patch removes the Relative option from the Translate node. This is
now superseded by the Relative To Pixel node, and removal was done to
facilitate the options to inputs project.
Pull Request: https://projects.blender.org/blender/blender/pulls/139147
It's not common for object data to reference it's object type
so name the struct member to make this clear.
Also remove BKE_curve_type_get which is no longer needed.
- Make Curve::type the source of truth for the curve type,
instead of Curve::vfont, since it's possible for this to be
set to null from RNA which effectively changed it's type.
See #138730.
- Update objects to match the curve type on file read.
Without this, an object may link to a curve in another file which
can be replaced by a curve data-block of a different type.
Note that updating the object type was already being done
when reloading library data and setting object data,
just not on file load.
Ref !139137
Calculating the curve type isn't needed for data which is only written
for text curves.
Note that this complicates a fix for #139133 which changes how curve
type data is accessed, where a version of BKE_curve_type_get that used
old behavior would have had to be kept for version patching.
- User visible rename: "Use Armature Setting" -> "Armature Defined"
(just added in 8bf73386f2)
- Internal code only: rename eArmature_Drawtype enum items to have
ARM_DRAW_TYPE_ prefix, instead of just ARM_ (just ARM_ is used in
several unrelated enums, leading to confusion)
This is re-apply of PR !138982 was backed out in cef7cb4534 due to
Win x64 buildbot failure. The error was:
```
view3d_navigate_view_all.cc(321): error C2672: 'blender::bounds::transform_bounds': no matching overloaded function found
view3d_navigate_view_all.cc(322): error C2784: 'blender::Bounds<blender::VecBase<T,3>> blender::bounds::transform_bounds(const blender::MatBase<T,Size,Size,NumCol*NumRow%4==0?4:1*sizeof(T)> &,const blender::Bounds<blender::VecBase<T,3>> &)': could not deduce template argument for 'const blender::MatBase<T,Size,Size,NumCol*NumRow%4==0?4:1*sizeof(T)> &' from 'const blender::float4x4'
```
which has nothing whatsoever to do with the PR. But something
in the PR (i.e. rename of a completely unrelated enum entries)
presumably makes this specific VS2019 compiler version not be
able to resolve template argument type. Again, in completely
unrelated file with completely unrelated types.
So "the fix" is to help VS2019 compiler in that place by explicitly
specifying the template types. What exactly in the original
change triggers the issue, remains a mystery. "It is known" that
VS2019 is quite funky in template argument deduction, maybe this
is one of these cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/138995
- User visible rename: "Use Armature Setting" -> "Armature Defined"
(just added in 8bf73386f2)
- Internal code only: rename eArmature_Drawtype enum items to have
ARM_DRAW_TYPE_ prefix, instead of just ARM_ (just ARM_ is used in
several unrelated enums, leading to confusion)
Pull Request: https://projects.blender.org/blender/blender/pulls/138982
Armature bone display mode (Octahedral, Stick, Envelope, B-Bone,
Wire) could only be set on the whole armature. This adds ability to
override the display mode per-bone (by default bones use the
same display mode as the armature).
Images in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/138445
This patch renames `seq1` and `seq2` to `input1` and `input2` in `Strip`
and `StripSelection` structs to consist with recent refactors in
#132179. It also renames other instances of `seq1` and `seq2` (e.g.
local variables) to `strip1` and `strip2` instead.
There is only one small breaking change to the Python API with
`strips.new_effect()` taking in the new names now. There should be
no other functional changes involved.
Pull Request: https://projects.blender.org/blender/blender/pulls/138296
Rework internals of how VSE caching is done. Primarily to make all the
caching logic more understandable from development point of view, but
also has several user visible implications (more details in the PR):
- Simpler and fewer caching UI options,
- Disk cache is gone (primary reason: proxies are kinda the same thing),
- VSE cache size set in preferences is actual size used for VSE caches
now (previously caching stopped as soon as whole Blender used that
much memory, even if some memory usage was not about VSE at all),
- Certain scenarios of cache invalidation are faster now.
Pull Request: https://projects.blender.org/blender/blender/pulls/137926
This patch removes the Gamma option from the Defocus and Blur nodes. The
reasoning is as follows.
- The option was originally added when the compositor wasn't working on
a strictly linear workflow. So this is rarely needed now.
- It is easy to insert a Gamma node around Blur nodes to perform any
gamma correction if really needed.
- Since we are moving options to inputs, it doesn't seem worth it to
provide this option as an input in the process.
Pull Request: https://projects.blender.org/blender/blender/pulls/138673
