Mixing testing and actual action in a single function is just not a good
way to do things, and the 'testing' feature is not used anywhere
anymore, time to get rid of it.
This flag became a full duplicate of `IDTYPE_FLAGS_NO_LIBLINKING`, which
is a good thing (don't think we ever want to be able to link some data,
without being able to make it local...).
So we can now remove it and use `IDTYPE_FLAGS_NO_LIBLINKING` instead.
Scene and related pointer parameter can be NULL in link/append code, in
which case there is no instantiation of new objects/collections/obdata.
Link code in blendloader was already checking that, new instantiation
code in WM area from yesterday did not.
Issue introduced by rB3be5ce4aad5e.
This allows a hack to be removed that temporarily overwrote
the 3D views gizmo display flag.
Also reverse change from fb27a9bb98
that runs poll on modal gizmo groups as there is some risk
that the poll function unlinks the gizmo.
Follow up to fix for T73684,
which allowed some modal gizmos to hide all others.
Also resolve an issue from 917a972b56
where shear the shear gizmo would be visible during interaction.
Internally there are some changes to gizmo behavior
- The gizmo with modal interaction wont draw if it's poll function fails.
- The WM_GIZMOGROUPTYPE_DRAW_MODAL_ALL flag now causes these gizmo
groups to draw when another group is being interacted with.
This commit fully refactors the way linked IDs are made local when
appended.
Previously, `BKE_library_make_local` was (ab)used for this task, but it
was missing some contextual data and doing complex processing to try to
work around this, with limited sucess. Further more, it was nearly
impossibe to extend (e.g. to get new append behaviors necessary for the
asset project).
The new code is a dedicated append step in WM linking process.
NOTE: BPY API (`libray.load()` context manager) uses its own code here,
which still relies on `BKE_library_make_local` for appending.
Unfortunately, merging those two different code paths is not trivial so
for now this API will remain unchanged.
Fix T55629: Append already linked Data is impossible.
Changing active side was introduced in {rB7ff6bfd1e0af} but was never
working for tools/operators other than the sculpt line mask tool.
While for most tools/operators this actually does not make sense, the
bisect tool/operator can actually benefit from it.
thx @campbellbarton for additional input!
Maniphest Tasks: T91320
Differential Revision: https://developer.blender.org/D12473
This was implemented in {rB14d56b4217f8} but was never working for
tools/operators other than the sculpt line mask tool.
To be precise, the preview actually snapped but the operations (e.g.
mesh bisect, vertex weight gradient) still happened "unsnapped" in
modal. For the sculpt line mask tool this wasnt a problem, because it
only draws a preview while modal, the actual mask was only applied
later.
This solves part one of T91320 (snapping), sculpting also introduced
flipping in {rB7ff6bfd1e0af} which does not make much sense for all
tools, but in bisect this could actually be supported, will add that in
a separate Diff.
ref T91320
Maniphest Tasks: T91320
Differential Revision: https://developer.blender.org/D12470
Addresses T76082.
Since the DirectX backend does not work for AMD gpus
(wglDXRegisterObjectNV() fails to register the shared OpenGL-DirectX
render buffer, displaying a pink screen to the user), the original
solution was to use SteamVR's OpenGL backend, which, as tested
recently, seems to work without any issues on AMD hardware.
However, the SteamVR OpenGL backend (on Windows) was disabled in
fe492d922d6d since it resulted in crashes with NVIDIA gpus (and still
crashes, as tested recently), so SteamVR would always use the
AMD-incompatible DirectX backend (on Windows).
This patch restores use of the SteamVR OpenGL backend for non-NVIDIA
(AMD, etc.) gpus while maintaining the DirectX workaround for NVIDIA
gpus. In this way, issues are still resolved on the NVIDIA side but
AMD users can once again use the SteamVR runtime, which may be their
only viable option of using Blender in VR.
Reviewed By: Julian Eisel
Differential Revision: https://developer.blender.org/D12409
Reuse temporary windows when they share the same single area type, not
because they share the same title.
See D12401 for more details.
Differential Revision: https://developer.blender.org/D12401
Reviewed by Campbell Barton
Caused by {rB3e4d720ae483}.
Before above commit, this had a different path handling and
RNA_path_from_ID_to_struct() was always used [which kind of took care of
this]. Now this is only used if ptr represents an ID itself, so we are
"loosing" part of the path.
This patch adds the path back on the member_id in
wm_context_member_from_ptr() for everthing related to space_data, so
WM_context_path_resolve_property_full() can construct a full path even
for these.
Maniphest Tasks: T91225
Differential Revision: https://developer.blender.org/D12418
This adds an option to use a capture of the entire main window as the
blend file preview thumbnail.
See D10492 for details and examples.
Differential Revision: https://developer.blender.org/D10492
Reviewed by Campbell Barton
Increase effective resolution of blend preview images from 128x128 to
256x256 for versions saved in the file system thumbnail cache.
See D10491 for details and examples.
Differential Revision: https://developer.blender.org/D10491
Reviewed by Campbell Barton
Use context members instead of not working well or failing due to:
- Missing "path" functions (in the case of edit-bones).
- Paths containing names (in the case of sequence-strips or pose-bones).
While technically correct it's not useful for shortcuts or
menu items to lookup data by name.
Only append RNA_path_from_ID_to_struct to context attributes if those
paths resolve to ID types.
Also simplify creating RNA paths by adding utility functions:
- WM_context_path_resolve_property_full
- WM_context_path_resolve_full
Part of fix for T90723.
This reverts 151eed752b. Originally thought it was necessary to
initialize selected/active indices to -1 to prevent out-of-bounds
list access, but this is not needed since null checks are already
performed after obtaining list members via BLI_findlink().
In addition, leaving indices zero-initialized facilitates use of the
Python API, for example when displaying action map information in a
UI list.
Add null check for runtime data since it could already have been
freed via wm_xr_exit() (called on file read) prior to the session
exit callback.
Also, fix potential memory leak by freeing session data in
wm_xr_runtime_data_free() instead of session exit callback.
This fixes two memory leaks related to XR action maps.
1. Freeing of action maps needs to be moved from wm_xr_exit() to
wm_xr_runtime_data_free() since the runtime may have already been
freed when calling wm_xr_exit().
2. Action bindings for action map items were not being freed. This
was mistakenly left out of e844e9e8f3 since the patch needed to be
updated after d3d4be1db3.
Compressing blendfiles can help save a lot of disk space, but the slowdown
while loading and saving is a major annoyance.
Currently Blender uses Zlib (aka gzip aka Deflate) for compression, but there
are now several more modern algorithms that outperform it in every way.
In this patch, I decided for Zstandard aka Zstd for several reasons:
- It is widely supported, both in other programs and libraries as well as in
general-purpose compression utilities on Unix
- It is extremely flexible - spanning several orders of magnitude of
compression speeds depending on the level setting.
- It is pretty much on the Pareto frontier for all of its configurations
(meaning that no other algorithm is both faster and more efficient).
One downside of course is that older versions of Blender will not be able to
read these files, but one can always just re-save them without compression or
decompress the file manually with an external tool.
The implementation here saves additional metadata into the compressed file in
order to allow for efficient seeking when loading. This is standard-compliant
and will be ignored by other tools that support Zstd.
If the metadata is not present (e.g. because you manually compressed a .blend
file with another tool), Blender will fall back to sequential reading.
Saving is multithreaded to improve performance. Loading is currently not
multithreaded since it's not easy to predict the access patterns of the
loading code when seeking is supported.
In the future, we might want to look into making this more predictable or
disabling seeking for the main .blend file, which would then allow for
multiple background threads that decompress data ahead of time.
The compression level was chosen to get sizes comparable to previous versions
at much higher speeds. In the future, this could be exposed as an option.
Reviewed By: campbellbarton, brecht, mont29
Differential Revision: https://developer.blender.org/D5799
Instead of handling mmap, compression etc. all directly in readfile.c, refactor
the code to use a generic FileReader.
This makes it easier to add new compression methods or similar, and allows to
reuse the logic in other places (e.g. thumbnail reading).
Reviewed By: campbellbarton, brecht, mont29
Differential Revision: https://developer.blender.org/D5799
This addresses reduced visibility of scenes (as displayed in the VR
headset) that can result from the 8-bit color depth format currently
used for XR swapchain images.
By switching to a swapchain format with higher color depth (RGB10_A2,
RGBA16, RGBA16F) for supported runtimes, visibility in VR should be
noticeably improved.
However, current limitations are lack of support for these higher
color depth formats by some XR runtimes, especially for OpenGL.
Also important to note that GPU_offscreen_create() now explicitly
takes in the texture format (eGPUTextureFormat) instead of a
"high_bitdepth" boolean.
Reviewed By: Julian Eisel, Clément Foucault
Differential Revision: http://developer.blender.org/D9842
There was already some code for that, but it was broken, and proper
resync was completely missing.
There might still be more resync needed in library linking operators
though.
Clearing the window was done in wm_file_read_post which was deferred.
This was needed as it left the context in an invalid state
where the window was set but the screen wasn't.
Crashing when setting up keymaps that attempted to access the
scene from the window in the property update function.
Regression in 497bc4d199
- Remove old comment for editors with weak syntax highlighting.
- Remove disabled code to initialize Blender with a file path.
- Remove file name references to function names since these
were outdated, modern development environments can look up this info.
Resolve order of initialization error reading startup file,
support postponing running wm_file_read_post until Blender
has been initialized.
Deferring updates allows duplicate initialization
to be removed from WM_init.
Reviewed By: mont29
Ref D12184
ID data-blocks that could be accessed from Python and weren't freed
using BKE_id_free_ex did not release the Python reference count.
Add BKE_libblock_free_data_py function to clear the Python reference
in this case.
Add asserts to ensure no Python reference is held in situations
when ID's are copied for internal use (not exposed through the RNA API),
to ensure these kinds of leaks don't go by unnoticed again.
Although the relevant structs (wmXrRuntime/XrActionMap/
XrActionMapItem) are zero-allocated, the selected and active action
map indices need to be initialized to -1 to prevent potential
out-of-bounds list access.
