This patch enables property search for all tabs in the property editor.
To make interaction faster, if the editor's current tab doesn't have a
result, the current tab changes to the next tab that has a match.
This patch implements basic code that only searches panels.
While we could run the existing "single tab" property search for every
tab, that would also do everything else related to the layout pass,
which would be less efficient, and maybe more complicated to maintain.
The search match status for every current tab of the property editor is
stored in a runtime bitfield and them displayed later by dimming icons
in the tab selector panel to the left. Using `BLI_bitmap` properly in
the runtime struct required moving it to `buttons_intern.h` and
adding a small API to access the search filter instead.
To make sure the editor isn't influenced by anything that happens while
building the layout for other tabs, most of the context is duplicated
and the new search is run in the duplicated editor.
Note that the tool settings tab works slightly different than the other
tabs, so I've disabled searching it for this commit. That would be a
relatively simple improvement, but would just require a bit of
refactoring of existing code.
Differential Revision: https://developer.blender.org/D8859
This adds arguments to `uiLayout.prop_tabs_enum` and the C equivalent
(`uiItemTabsEnumR_prop`) to gray out tabs based on a boolean array.
For property search in multiple tabs, we need a way to show which tabs
have a search result, but we still need to show which tab is active.
Differential Revision: https://developer.blender.org/D8858
Changing the color of monochrome alert icons would not change until the theme was reloaded.
Differential Revision: https://developer.blender.org/D9062
Reviewed by Harley Acheson
This diff adds support for respecting the `BLENDER_USER_SCRIPTS`
environment variable when setting up the IDE environment.
Previously the scripts from the users profile folder were always
used even when this variable was set, leading to the possibility
of the wrong scripts being visible in the IDE.
Differential Revision: https://developer.blender.org/D9189
Reviewed By: Ray Molenkamp
With this patch the build system checks whether the "CUDA10_NVCC_EXECUTABLE" CMake
variable is set and if so will use that to build sm_30 kernels. Similarily for sm_8x kernels it
checks "CUDA11_NVCC_EXECUTABLE". All other kernels are built using the default CUDA
toolkit. This makes it possible to use either the CUDA 10 or CUDA 11 toolkit by default and
only selectively use the other for the kernels where its a hard requirement.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D9179
Seems to be an oversight/typo in rB83980506957c.
Now set back to 0.01m (as it was before).
Maniphest Tasks: T81672
Differential Revision: https://developer.blender.org/D9193
A .blend file cannot use itself as a library.
This is prevented when linking manually, but was still possible when
relocating, which is now prevented.
Maniphest Tasks: T81656
Differential Revision: https://developer.blender.org/D9191
This was reported for sculpting, the same is true for weightpaint or
vertexpaint though.
When viewport clipping and radial symmetry are enabled, the
'sculpt_brush_test_clipping()' function was not considering radial
symmetry at all, so if the coordinate was outside the clipping planes,
no action would take place. Now the coordinte is brought back to where
the stroke actually happens and that is checked against clipping.
Since other mirroring options while painting/sculpting (as well as
editmode operations with mirroring) usually still take place even if the
mirrored coord is outside the clipping planes, this should also be the
case for radial symmetry.
This grows the 'SculptBrushTest' struct a bit, but should be acceptable?
Fixes T81466
Maniphest Tasks: T81466
Differential Revision: https://developer.blender.org/D9120
When we override a whole collection, we want to add non-instantiated
objects to a hidden sub-collection at the end of the process.
However, this makes no sense when instantiating an object, if other
dependencies objects get also overridden on the process, we should just
add them to the same collection owning the root object.
- BKE_bezt_subdivide_handles -> BKE_fcurve_bezt_subdivide_handles
- binarysearch_bezt_index -> BKE_fcurve_bezt_binarysearch_index
These functions are specific to F-Curves and don't make sense for other
uses of BezTriple (curve-object data for e.g.)
Also:
- Move detailed doxygen comment above code, following code-style.
- Mark bezt_add_to_cfra_elem unused.
The problem is related to the `use_index_order` option of `BLI_kdtree_3d_calc_duplicates_fast`.
With this option, the higher index is expected to be less than `tree->nodes_len`.
Blender crashed when dragging and dropping color into the outliner.
This issue was cause by a missing check for the correct drag type
in `datastack_drop_poll`. The check is added in this commit.
Additionally, a new drag type is introduced for the "data stack"
drag option, that was introduced in commit 1572da858d, to
differentiate it from the existing WM_DRAG_ID type.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D9169
Change to monochrome version of the large alert icons and use 'Question' for the the Quit Confirm dialog box.
Differential Revision: https://developer.blender.org/D9062
Reviewed by Pablo Vazquez
Default text output routines (which do not specify a size) will now use Text Style point size.
Differential Revision: https://developer.blender.org/D9107
Reviewed by Brecht Van Lommel
When changing the selected, active or visible object(s), the Outliner
has to be rebuilt while using the corresponding object state filters.
The object hiding operators also have to send the proper notifiers (they
changed visibility without notifying about that).
Check selection state in `BKE_fcurve_active_keyframe_index()`, and only
return the active keyframe index when that keyframe is actually selected.
This is now also asserted in the `BKE_fcurve_active_keyframe_set()` function,
which is now also used when inserting a keyframe.
While there are other bundles which show up as directories,
`.app` are the most common ones.
*Users should not be saving anything inside .app bundles, nor using
Blender to edit any of the files.
*This declutters the File Browser for say ~/Applications folder
or recursive search on a path with apps.
*Matches Finder's behavior of showing apps as files. (We don't have a
"right click > show package contents" button like Finder though)
This change shows `.app` files like incompatible files, or `.exe`s
on Windows.
{F8970986}
Reviewed By: #platform_macos, brecht, mont29
Differential Revision: https://developer.blender.org/D9162
That was a suboptimal decision from back in the days, which ended up
being problematic. It is no longer used, so remove it from API making
it so new code does not depend on this weak concept.
The order got broken when Brown distortion model has been added.
Made it so the indexing of parameters is strictly defined in the
parameter block, matching how parameters are used in the cost
function.
There is some duplication going on accessing parameters. This can
be refactored in the future, by either moving common parts packing
and cost function to an utility function in bundle.cc.
Alternatively, can introduce a public PackedIntrinsics class which
will contain a continuous block of parameters, and each of the
camera models will have API to be initialized from packed form and
to create this packed form.
The benefit of this approach over alternative solutions previously
made in the master branch or suggested in D9116 is that the specific
implementation of BA does not dictate the way how public classes need
to be organized. It is API which needs to define how implementation
goes, not the other way around.
Thanks Bastien and Ivan for the investigation!
This reverts commit 7e836bde11.
Reverting the incomplete workaround, due to the following reasoning:
- There should be no dependency between CameraIntrinsics and the bundler
code. This violates intended abstraction of the intrinsics class.
- The fix was not complete, or wrong. Even in the world where there is
a requirement to the parameters storage size this should have applied
to all distortion models, including Divisions, Nuke.
Proper fix will be committed next.
The leak was happening when problem did not have any parameters blocks
defined. This happens, for example, if there are no 3D points at all,
or when all markers are set to 0 weight.
Was noticeable in libmv_modal_solver_test when building with LSAN
enabled.
Fix regression introduced in rBe12767a0352a9e113892b4a07c6c8446d3ff361f
The volumes are not a line type and should not be render into the line
framebuffer nor it should change the framebuffer.
Before I was double confused about how openvdb stores its
transformation matrices. Now, I know they have the same layout
physically in memory, but are logically transposed (i.e. the translation
is in the last row instead of in the last column).
Previously Blender would only match the existing curve slope when the
to-be-inserted key value was already very close to the curve. This check
is now removed, allowing for sliders in the graph editor to subtly
change the curve, and for keyframes added with ctrl+click to follow the
curve better.
`CustomData_bmesh_interp` use the same CustomData decryptor (in this case, `bm->ldata`) in both blocks.
So make sure that all CustomData layers match.
This commit also removes redundant `BM_elem_attrs_copy_ex` calls.
Maniphest Tasks: T81060
Differential Revision: https://developer.blender.org/D9159
This resolves a long list of linker warnings that is currently only showing up on macOS arm builds.
The warnings themselves are of this shape (one example):
```
ld: warning: direct access in function 'Manta::MeshDataImpl<Manta::Vector3D<float> >::_W_39(_object, object, object*)' from file '../../lib/libextern_mantaflow.a(mesh.h.reg.cpp.o)' to global weak symbol 'typeinfo for Manta::MeshDataImpl<Manta::Vector3D<float> >' from file '../../lib/libextern_mantaflow.a(mesh.cpp.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
```
Just would like to get your opinion to make sure this is an acceptable way to handle this on all platforms.
Reviewed By: LazyDodo
Differential Revision: https://developer.blender.org/D9002
The strength has a high impact on performance. With the previous
step and default one could easily and accidentally make Blender unusably
slow, because of a too high displacement strength.
