Some code attempted to use `BIFIconID` instead of `int` to pass around
icon-ids. Problem is, that this is just a subset of the allowed ids,
more icons may be created at runtime and extend the range of valid
icon-ids. Such icons could give runtime warning prints.
Idea is to use a `using BIFIconID = int;` instead. This way there is
still a descriptive type name, while the whole dynamic range of possible
icon-ids is supported.
Additionally multiple `using BIFIconID = int;` declarations are valid,
so we can place these in multiple headers and use the type name in APIs
instead of just `int`, whithout having to include a single header
defining them. A type mismatch (one instance differs from the others)
will result in a compiler error.
Pull Request: https://projects.blender.org/blender/blender/pulls/111052
With the end goal of simplifying ownership and memory management,
and allowing the use of `get_name` in contexts without statically
allocated strings, use `std::string` for the return values of these two
operator type callbacks instead of `const char *` and `char *`.
In the meantime things get uglier in some places. I'd expect `std::string`
to be used more in the future elsewhere in Blender though.
Pull Request: https://projects.blender.org/blender/blender/pulls/110823
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
Add a High Dynamic Range option in the Color Management > Display panel.
This enables display of extended color ranges above 1.0 for the 3D
viewport, image editor and render previews.
This requires a monitor that can display HDR colors, and a view
transform designed for HDR output. The Standard view transform works,
but Filmic does not as it was designed to bring values into the 0..1
range for SDR displays.
This patch is limited to allowing the display to visualize extended
colors, but does not include future looking work to better integrate HDR
into the full workflow.
It is implemented by rendering to high bit-depth texture formats for
the user interface, and uncapping the color range in color management.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/105662
Support name-spaced add-ons, exposed via user configurable extension
repositories.
Directories for add-ons can be added at run-time and are name-spaced to
avoid name-collisions with Python modules or add-ons from other
repositories.
This is exposed as an experimental feature "Extension Repositories".
Details:
- A `bUserExtensionRepo` type which represents a repository which is
listed in the add-ons repository.
- `JunctionModuleHandle` class to manage a package with sub-modules
which can point to arbitrary locations.
- `bpy.app.handlers._extension_repos_update_{pre/post}` internal
callbacks run before/after changes to extension repositories,
callbacks are used to sync the changes to the Python package that
exposes these to add-ons.
- The size of an add-on name has been increased so a user-defined package
prefix can be included without enforcing shorter add-on names.
- Functionality relating to package management has been left out of this
change and will be developed separately.
Further work:
- While a repository can be renamed, enabled add-ons aren't renamed.
Eventually we might want to support this although we could also
disallow renaming repositories with add-ons enabled as the name isn't
all that significant.
- Removing a repository should remove all the add-ons located in this
repository.
- Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*`
we might want to relax this to allow unicode characters (we might
still want to disallow `-` or any characters that would prevent
attribute access in code).
Ref !110869.
Reviewed By: brecht
No user visible changes expected, except of new experimental feature
option.
------------------------------------------------------------------------------
This introduces asset shelves as a new standard UI element for accessing
assets. Based on the current context (like the active mode and/or tool), they
can provide assets for specific workflows/tasks. As such they are more limited
in functionality than the asset browser, but a lot more efficient for certain
tasks.
The asset shelf is developed as part of the brush assets project (see #101895),
but is also meant to replace the current pose library UI.
Support for asset shelves can quite easily be added to different editor types,
the following commit will add support for the 3D View. If an editor type
supports asset shelves, add-ons can chose to register an asset shelf type for
an editor with just a few lines of Python.
It should be possible to entirely remove `UILayout.asset_view_template()` once
asset shelves are non-experimental.
Some changes are to be expected still, see #107881.
Task: #102879
Brush asset workflow blog post: https://code.blender.org/2022/12/brush-assets-workflow/
Initial technical documentation: https://developer.blender.org/docs/asset_system/user_interface/asset_shelf/
Pull Request: #104831
Context is needed to import and instantiate assets correctly. Previously
the context was stored as "evil" pointer in the drag data. Since
77794b1a7b, context is passed to the dragging callbacks doing the asset
import, so the context doesn't need to be stored that way anymore and
can simply be passed to the import function.
This implements the main aspects of changes to blendfile compatibility
as designed in #109151:
* Blender files which file minversion is newer than current Blender
executable won't be loaded at all.
* Blender files which file version is newer than current Blender will
triger systematic warning to user:
* In the status info bar (lower right corner in default UI).
* When attempting to save (overwrite) them.
This means that the file minversion becomes a hard limit, and not a
soft, warning-only as it used to be. Further more, forward compatibility
warning is now systematic (instead of depending on file minversion),
and more visible for users.
See also https://wiki.blender.org/wiki/Process/Compatibility_Handling
for details over the new policy.
Technically:
* Opening any file with a minversion newer than current Blender file one
now triggers an early abort, with an error message reported to the user.
This is handled by a new utils called from `blo_decode_and_check`.
* Any file newer than current Blender version sets a new
`has_forward_compatibility_issues` flag in Main struct at read time.
* Status bar info area is turned into a template, which uses this flag
to display special warning UI and tooltip when set.
* A new confirmation popup appears when user tries to save (overwrite)
such a 'newer' blendfile, stating potential loos of data, and
proposing by default to 'save as' instead.
* The 'quit unsaved' popup has also been updated to 'save as' instead of
'save' when the edited file is has potential forward compitibility
issues.
Part of #109151 (PR !110109).
The cleanup of blenkernel last weeks , caused the house of cards to
collapse on top of bf_gpu's shader_builder, which is off by default
but used on a daily basis by the rendering team.
Given the fixes forward in #110394 ran into a ODR violation in OSL that
was hiding there for years, I don't see another way forward without
impeding the rendering teams productivity for "quite a while" as there
is no guarantee the OSL issue would be the end of it.
the only way forward appears to be back.
this reverts :
19422044eda670b53abe0f541db97cbe516e8c813e88a2f44c4e64b772f59547e7a31707fe6c5a57
The problematic commit was 07fe6c5a57
as blenkernel links most of blender, it's a bit of a link order issue
magnet. Given all these commits stack, it's near impossible to revert
just that one without spending a significant amount of time resolving
merge conflicts. 99% of that work was automated, so easier to just
revert all of them, and re-do the work, than it is to deal with the
merge conflicts.
Pull Request: https://projects.blender.org/blender/blender/pulls/110438
Regression in [0] changed the order of execution for the load_post
handler which previously (in 3.5x) ran before driver evaluation.
Calling either load_post/load_post_fail handlers after loading was
changed intentionally to simplify the code-path for calling handlers
however it meant the handler couldn't be used to setup drivers,
so restore the original logic.
[0]: 46be42f6b1
Resolve a crash in !104831, which exposed an error in window creation
with an empty space type.
Creating a new window with an empty space type would do the following:
- Create a new screen with a single empty area.
- Refresh the screen,
- Initialize the area.
- Convert the empty area into a 3D viewport.
- Run SpaceType::init()
This doesn't cause any problems at the moment because `view3d_init`
isn't doing anything however !104831 accesses the View3D from
`area->spacedata.first` causing SCREEN_OT_area_dupli to crash.
Resolve by supporting an area setup callback for WM_window_open
so the area-data can be set before it's initialized.
The issue remains where an unknown/empty ScrArea::spacetype results in
a crash although it seems unlikely users run into this in practice.
Whatever the case, that can be resolved separately.
