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).
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.
This change replaces a bare RenderEngine owned by a viewport
with a VeiwRender. This unlocks a possibility of accessing
RenderResult for viewport renders. Currently it is not done,
but it will be needed for an upcoming work towards unification
of the render passes handling.
Ref #108618
Pull Request: https://projects.blender.org/blender/blender/pulls/110244
Caused by fd3e44492e.
Images were drawn filling the entire window, now use available size/
offset inside the window and pass these as `rctf` to
`draw_display_buffer`.
Should be good for 3.6/3.3 LTS
Pull Request: https://projects.blender.org/blender/blender/pulls/110206
File > New> General tooltip is misleading, as explained in issue #109875
Changes the tooltip from the current "Open the default file (doesn't save the current file)" to simply "Open the default file".
It could be argued that the note is still valid for when people have Preferences > Save & Load > Save Prompt disabled, but we don't have a similar note in any of the other cases that open a different file.
Pull Request: https://projects.blender.org/blender/blender/pulls/110086
Use modifier keys that are pressed before activating a new window.
Allows call of `wm_window_update_eventstate_modifiers` on
`GHOST_kEventWindowActivate` by using `GetAsyncKeyState` instead of
`GetKeyState` in GHOST_SystemWin32::getModifierKeys, which retrieves
actual hardware state.
Pull Request: https://projects.blender.org/blender/blender/pulls/110020
This formats code that is disabled using `#if 0`. Formatting was achieved
by temporarily changing `#if 0` to `#if 1 /*something*/`, then formatting,
and then changing it back to `#if 0`.
Now that liboverride process on save (the diffing + pruning unused
override operations + reset of non-overridable changes) works better. it
leads to a bad side-effect: all system overrides data indirectly
modified through animation or drivers get reset.
Since in current system e.g. most objects of a rigged asset are system
overrides, but their transform is modified by bones animation, this
leads to entire overrides of assets being reset to their linked state
until next depsgraph evaluation.
While this is the expected and correct behavior in absolute, this is
very bad from a user experience PoV.
This commit address the issue by simply re-running a 'frame change'
despgraph update, to ensure all drivers, animations etc. are properly
re-applied after liboverride diffing cleanup & reset.
Note: Change applies to Grease Pencil 3.0 only (experimental feature).
Enables use of drag & drop to reorder grease pencil layers through the layer
tree UI, as well as inserting layers into groups. This is an intuitive and
often requested method of managing such data-structures. Visual feedback should
be improved still, and the gap between items be removed, to reduce flickering
while dragging. These are general improvements for tree views however which
should be done separately.
There is no support yet for dragging layer groups, this requires further
changes in the internal grease pencil APIs.
#109825 introduced the necessary drag & drop support for tree views, #109824
prepared the internal grease pencil API for it.
Pull Request: https://projects.blender.org/blender/blender/pulls/109826
