Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
Override layers are a standard feature of Alembic, where archives can override
data from other archives, provided that the hierarchies match.
This is useful for modifying a UV map, updating an animation, or even creating
some sort of LOD system where low resolution meshes are swapped by high resolution
versions.
It is possible to add UV maps and vertex colors using this system, however, they
will only appear in the spreadsheet editor when viewing evaluated data, as the UV
map and Vertex color UI only show data present on the original mesh.
Implementation wise, this adds a `CacheFileLayer` data structure to the `CacheFile`
DNA, as well as some operators and UI to present and manage the layers. For both
the Alembic importer and the Cycles procedural, the main change is creating an
archive from a list of filepaths, instead of a single one.
After importing the base file through the regular import operator, layers can be added
to or removed from the `CacheFile` via the UI list under the `Override Layers` panel
located in the Mesh Sequence Cache modifier. Layers can also be moved around or
hidden.
See differential page for tests files and demos.
Reviewed by: brecht, sybren
Differential Revision: https://developer.blender.org/D13603
This patch implements the vector types (i.e:`float2`) by making heavy
usage of templating. All vector functions are now outside of the vector
classes (inside the `blender::math` namespace) and are not vector size
dependent for the most part.
In the ongoing effort to make shaders less GL centric, we are aiming
to share more code between GLSL and C++ to avoid code duplication.
####Motivations:
- We are aiming to share UBO and SSBO structures between GLSL and C++.
This means we will use many of the existing vector types and others
we currently don't have (uintX, intX). All these variations were
asking for many more code duplication.
- Deduplicate existing code which is duplicated for each vector size.
- We also want to share small functions. Which means that vector
functions should be static and not in the class namespace.
- Reduce friction to use these types in new projects due to their
incompleteness.
- The current state of the `BLI_(float|double|mpq)(2|3|4).hh` is a
bit of a let down. Most clases are incomplete, out of sync with each
others with different codestyles, and some functions that should be
static are not (i.e: `float3::reflect()`).
####Upsides:
- Still support `.x, .y, .z, .w` for readability.
- Compact, readable and easilly extendable.
- All of the vector functions are available for all the vectors types
and can be restricted to certain types. Also template specialization
let us define exception for special class (like mpq).
- With optimization ON, the compiler unroll the loops and performance
is the same.
####Downsides:
- Might impact debugability. Though I would arge that the bugs are
rarelly caused by the vector class itself (since the operations are
quite trivial) but by the type conversions.
- Might impact compile time. I did not saw a significant impact since
the usage is not really widespread.
- Functions needs to be rewritten to support arbitrary vector length.
For instance, one can't call `len_squared_v3v3` in
`math::length_squared()` and call it a day.
- Type cast does not work with the template version of the `math::`
vector functions. Meaning you need to manually cast `float *` and
`(float *)[3]` to `float3` for the function calls.
i.e: `math::distance_squared(float3(nearest.co), positions[i]);`
- Some parts might loose in readability:
`float3::dot(v1.normalized(), v2.normalized())`
becoming
`math::dot(math::normalize(v1), math::normalize(v2))`
But I propose, when appropriate, to use
`using namespace blender::math;` on function local or file scope to
increase readability.
`dot(normalize(v1), normalize(v2))`
####Consideration:
- Include back `.length()` method. It is quite handy and is more C++
oriented.
- I considered the GLM library as a candidate for replacement. It felt
like too much for what we need and would be difficult to extend / modify
to our needs.
- I used Macros to reduce code in operators declaration and potential
copy paste bugs. This could reduce debugability and could be reverted.
- This touches `delaunay_2d.cc` and the intersection code. I would like
to know @howardt opinion on the matter.
- The `noexcept` on the copy constructor of `mpq(2|3)` is being removed.
But according to @JacquesLucke it is not a real problem for now.
I would like to give a huge thanks to @JacquesLucke who helped during this
and pushed me to reduce the duplication further.
Reviewed By: brecht, sergey, JacquesLucke
Differential Revision: https://developer.blender.org/D13791
This patch implements the vector types (i.e:float2) by making heavy
usage of templating. All vector functions are now outside of the vector
classes (inside the blender::math namespace) and are not vector size
dependent for the most part.
In the ongoing effort to make shaders less GL centric, we are aiming
to share more code between GLSL and C++ to avoid code duplication.
Motivations:
- We are aiming to share UBO and SSBO structures between GLSL and C++.
This means we will use many of the existing vector types and others we
currently don't have (uintX, intX). All these variations were asking
for many more code duplication.
- Deduplicate existing code which is duplicated for each vector size.
- We also want to share small functions. Which means that vector functions
should be static and not in the class namespace.
- Reduce friction to use these types in new projects due to their
incompleteness.
- The current state of the BLI_(float|double|mpq)(2|3|4).hh is a bit of a
let down. Most clases are incomplete, out of sync with each others with
different codestyles, and some functions that should be static are not
(i.e: float3::reflect()).
Upsides:
- Still support .x, .y, .z, .w for readability.
- Compact, readable and easilly extendable.
- All of the vector functions are available for all the vectors types and
can be restricted to certain types. Also template specialization let us
define exception for special class (like mpq).
- With optimization ON, the compiler unroll the loops and performance is
the same.
Downsides:
- Might impact debugability. Though I would arge that the bugs are rarelly
caused by the vector class itself (since the operations are quite trivial)
but by the type conversions.
- Might impact compile time. I did not saw a significant impact since the
usage is not really widespread.
- Functions needs to be rewritten to support arbitrary vector length. For
instance, one can't call len_squared_v3v3 in math::length_squared() and
call it a day.
- Type cast does not work with the template version of the math:: vector
functions. Meaning you need to manually cast float * and (float *)[3] to
float3 for the function calls.
i.e: math::distance_squared(float3(nearest.co), positions[i]);
- Some parts might loose in readability:
float3::dot(v1.normalized(), v2.normalized())
becoming
math::dot(math::normalize(v1), math::normalize(v2))
But I propose, when appropriate, to use
using namespace blender::math; on function local or file scope to
increase readability. dot(normalize(v1), normalize(v2))
Consideration:
- Include back .length() method. It is quite handy and is more C++
oriented.
- I considered the GLM library as a candidate for replacement.
It felt like too much for what we need and would be difficult to
extend / modify to our needs.
- I used Macros to reduce code in operators declaration and potential
copy paste bugs. This could reduce debugability and could be reverted.
- This touches delaunay_2d.cc and the intersection code. I would like to
know @Howard Trickey (howardt) opinion on the matter.
- The noexcept on the copy constructor of mpq(2|3) is being removed.
But according to @Jacques Lucke (JacquesLucke) it is not a real problem
for now.
I would like to give a huge thanks to @Jacques Lucke (JacquesLucke) who
helped during this and pushed me to reduce the duplication further.
Reviewed By: brecht, sergey, JacquesLucke
Differential Revision: http://developer.blender.org/D13791
This commit improves the scaling of some ui widgets when
zooming by making the radius of the rounded corners
dependent on the element's zoom level.
Needed to fix T92278 without padding issues, see D13125.
Reviewed By: Hans Goudey, Julian Eisel
Differential Revision: https://developer.blender.org/D12842
This patch removes a bunch of specific code for drawing the spreadsheet
data set region, which was an overly specific solution for a generic UI.
Nowadays, the UI tree view API used for asset browser catalogs is a much
better way to implement this behavior.
To make this possible, the tree view API is extended in a few ways.
Collapsibility can now be turned off, and whether an item should
be active is moved to a separate virtual function.
The only visual change is that the items are now drawn in a box,
just like the asset catalog.
Differential Revision: https://developer.blender.org/D13198
Allow the use of floating-point values for font point sizes, which
allows greater precision and flexibility for text output.
See D8960 for more information, details, and justification.
Differential Revision: https://developer.blender.org/D8960
Reviewed by Campbell Barton
Adds a `wmOperatorCallContext` typedef for the existing `WM_OP_XXX`
operator context enum. This adds type safety, allows the compiler to
produce better warnings and helps understanding what a variable is for.
Differential Revision: https://developer.blender.org/D13113
Reviewed by: Campbell Barton
There was a bunch of special handling to support dropping data-blocks onto
string or search-menu buttons, to change the value of these. This refactor
makes that case use the normal drop-box design, where an operator is executed
on drop that gets input properties set by the drop-box. This should also make
it easier to add support for dragging assets into these buttons.
In addition this fixes an issue: Two tooltips were shown when dragging assets
over text buttons. None should be shown, because this isn't supported.
There was a bunch of special handling to support dropping data-blocks onto
string or search-menu buttons, to change the value of these. This refactor
makes that case use the normal drop-box design, where an operator is executed
on drop that gets input properties set by the drop-box. This should also make
it easier to add support for dragging assets into these buttons.
In addition this fixes an issue: Two tooltips were shown when dragging assets
over text buttons. None should be shown, because this isn't supported.
This change simplifies the parameter list for these functions
and reduces the chance of typos mixing up array indices.
Missed in rB69102786047dccdcbaee0df6307a8c3364d28fe0
This change simplifies the parameter list for these functions
and reduces the chance of typos mixing up array indices.
Reviewed By: campbellbarton
Ref D12950
Back in Blender 2.30, the GUI project brought panels into Blender among other important visual updates.
For the first time it was possible to move the wall of buttons around. Providing a clear separation
between sections (it even allowed the grouping of panels in tabs!)
During the 2.5 redesign, the separation between panels became a line on top of each panel, and panels received
theme settings for background and header colors. The default theme used the same color for both.
In 2.8 the background color of panels was different from headers in the default theme, so the separator
line was removed. While the separator line wasn't elegant (only on top, non-themeable, hard-coded emboss effect),
it provided a sort of separation between panels.
This patch solves the panels-separation by simply adding a margin space around them (not visible in default theme yet).
Even though the margin reduces the width of the working area slightly, it makes room for the upcoming always-visible scrollbars.
Other adjustments:
* Use arrow icon instead of triangle to collapse/expand
* Use rounded corners to match the rest of the UI (editor corners, nodes, etc).
{F10953929, size=full}
Margin on panels makes use of the `style->panelouter` property that hasn't been
used in a while. Also slight tweaks to `boxspace` and `templatespace` style properties so they
are multiples of 2 and operations on them round better.
There is technically no need to update the themes for them to work, so no theme changes are included in this patch.
{F10953931, size=full}
{F10953933, size=full}
{F10953934, size=full}
{F10954003, size=full}
----
A new theme setting under Style controls the roundness of all panels (added it to Style instead of ThemeSpace because I think controlling the panel roundness per editor is a bit overkill):
{F11091561, size=full, autoplay, loop}
Reviewed By: HooglyBoogly
Differential Revision: https://developer.blender.org/D12814
Tree-view items can now easily define their own context menu. This works
by overriding the `ui::AbstractTreeViewItem::build_context_menu()`
function. See the documentation:
https://wiki.blender.org/wiki/Source/Interface/Views#Context_Menus
Consistently with the Outliner and File Browser, the right-clicked item
also gets activated. This makes sure the correct context is set for the
operators and makes it clear to the user which item is operated on.
An operator to rename the active item is also added, which is something
you'd typically want to put in the context menu as well.
If the operator poll of a superimposed icon returned `false`, the
superimposed icon would just draw normally and fail silently. Instead it
will now be drawn grayed out, plus the tooltip of the icon can show the
usual "disabled hint" (a hint explaining why the button is disabled).
Now the icons to add or delete catalogs are only shown when mouse hovering a
catalog item in the tree. This is convenient for quick creation of catalogs,
and doesn't require activating a catalog to edit it first.
Determining if a tree item is hovered isn't trivial actually. The UI tree-view
code has to find the matching tree-row button in the previous layout to do so,
since the new layout isn't calculated yet.
If a renaming button was removed via `UI_but_active_only_ex()` and that
button was placed using the layout system, the button was still in the
layout.
So far this didn't cause issues, because all cases where the button may
be removed were not using the layout system.
Adds an easy way to add drop support for tree-view rows.
Most of the work is handled by the tree-view UI code. The tree items can
simply override a few functions (`can_drop()`, `on_drop()`,
`drop_tooltip()`) to implement their custom drop behavior.
While dragging over a tree-view item that can be dropped into/onto, the
item can show a custom and dynamic tooltip explaining what's gonna
happen on drop.
This isn't used yet, but will soon be for asset catalogs.
See documentation here:
https://wiki.blender.org/wiki/Source/Interface/Views#Further_Customizations
This follows three main targets:
* Make creation of new tree UIs easy.
* Groundwork to generalize tree UIs (so e.g. Outliner, animation
channels, asset catalogs and spreadsheet data-sets don't have to
re-implement basic tree UI code) or even other data-view UIs.
* Better separate data and UI state. E.g. with this, tree-item selection
or the open/collapsed state can be stored on the UI level, rather than
in data. (Asset Catalogs need this, storing UI state info in them is
not an option.)
In addition, the design should be well testable and could even be
exposed to Python.
Note that things will likely change in master still. E.g. the actually
resulting UI isn't very nice visually yet.
The design is documented here:
https://wiki.blender.org/wiki/Source/Interface/Views
Differential Revision: https://developer.blender.org/D12573
The asset view UI template is a mini-version of the Asset Browser that
can be placed in regular layouts, regions or popups. At this point it's
made specifically for placement in vertical layouts, it can be made more
flexible in the future.
Generally the way this is implemented will likely change a lot still as
the asset system evolves.
The Pose Library add-on will use the asset view to display pose
libraries in the 3D View sidebar.
References:
* https://developer.blender.org/T86139
* https://code.blender.org/2021/06/asset-browser-project-update/#what-are-we-building
* https://code.blender.org/2021/05/pose-library-v2-0/#use-from-3d-viewport
Notes:
* Important limitation: Due to the early & WIP implementation of the
asset list, all asset views showing the same library will show the
same assets. That is despite the ID type filter option the template
provides. The first asset view created will determine what's visible.
Of course this should be made to work eventually.
* The template supports passing an activate and a drag operator name.
The former is called when an asset is clicked on (e.g. to apply the
asset) the latter when dragging (e.g. to .blend a pose asset). If no
drag operator is set, regular asset drag & drop will be executed.
* The template returns the properties for both operators (see example
below).
* The argument list for using the template is quite long, but we can't
avoid that currently. The UI list design requires that we pass a
number of RNA or custom properties to work with, that for the Pose
Libraries should be registered at the Pose Library add-on level, not
in core Blender.
* Idea is that Python scripts or add-ons that want to use the asset view
can register custom properties, to hold data like the list of assets,
and the active asset index. Maybe that will change in future and we
can manage these internally.
As an example, the pose library add-on uses it like this:
```
activate_op_props, drag_op_props = layout.template_asset_view(
"pose_assets",
workspace,
"active_asset_library",
wm,
"pose_assets",
workspace,
"active_pose_asset_index",
filter_id_types={"filter_action"},
activate_operator="poselib.apply_pose_asset",
drag_operator="poselib.blend_pose_asset",
)
drag_op_props.release_confirm = True
drag_op_props.flipped = wm.poselib_flipped
activate_op_props.flipped = wm.poselib_flipped
```
This button type shows a preview image above centered text, similar to
the File Browser files in Thumbnail Display Mode or the default Asset
Browser display. In fact we may want to port these over to use the new
button type at some point.
Will be used by the asset view UI template that will be added in a
following commit. That is basically a mini version of the Asset Browser
that can be displayed elsewhere in the UI.
If a text button is activated that is not in view (i.e. scrolled away),
the scrolling will now be adjusted to have it in view (with some
small additional margin). While entering text, the view may also be
updated should the button move out of view, for whatever reason. For the
most part, this feature shouldn't be needed and won't kick in, except
when a clicked on text button is partially out of view or very close to
the region edge. It's however quite important for the previously
committed feature, that is, pressing Ctrl+F to start searching in a UI
list. The end of the list where the scroll button appears may not be in
view. Plus while filtering the number of visible items changes so the
scrolling has to be updated to keep the search button visible.
Note that I disabled the auto-scrolling for when the text button spawned
an additional popup, like for search-box buttons. That is because
current code assumes the button to have a fixed position while the popup
is open. There is no code to update the popup position together with the
button/scrolling.
I also think that the logic added here could be used in more places,
e.g. for the "ensure file in view" logic the File Browser does.
Makes it possible to create tooltips for UI list rows, which can be
filled in .py scripts, similar to how they can extend other menus. This
is used by the (to be committed) Pose Library add-on to display pose
operations (selecting bones of a pose, blending a pose, etc).
It's important that the Python scripts check if the UI list is the
correct one by checking the list ID.
For this to work, a new `bpy.context.ui_list` can be checked. For
example, the Pose Library add-on does the following check:
```
def is_pose_asset_view() -> bool:
# Important: Must check context first, or the menu is added for every kind of list.
list = getattr(context, "ui_list", None)
if not list or list.bl_idname != "UI_UL_asset_view" or list.list_id != "pose_assets":
return False
if not context.asset_handle:
return False
return True
```
For pose libraries, we need to be able to apply a pose whenever
activating (clicking) an item in the Pose Library asset view and blend
it by dragging (press & move). And since we want to allow Python scripts
to define what happens at least when activating an asset (so they can
define for example a custom "Apply" operator for preset assets), it
makes sense to just let them pass an operator name to the asset view
template. The template will be introduced in a following commit.
Support for begin/update/end callbacks allowing state to be cached
and reused while dragging a number button or slider.
This is done using `UI_block_interaction_set` to set callbacks.
- Dragging multiple buttons at once is supported,
passing multiple unique events into the update function.
- Update is only called once even when multiple buttons are edited.
- The update callback can detect the difference between click & drag
actions so situations to support skipping cache creation and
freeing for situations where it's not beneficial.
Reviewed by: Severin, HooglyBoogly
Ref D11861
This changes `UI_but_func_tooltip_set` so that it allows passing a custom free function, which has two benefits:
* The caller can pass `null` to indicate that the value should not be freed.
* Arbitrary c++ data can be passed to the callback (before the struct had to be trivially destructible).
I added `uiFreeArgFunc` and used it in other places where appropriate.
Differential Revision: https://developer.blender.org/D11738
This patch adds a left aligned sidebar to the spreadsheet editor. This
Sidebar can be used to navigate the geometry component types and
attribute domains. It also provides a quick overview of domain sizes.
It replaces the two dropdowns in the regions header.
Next step will be to add the domain cycling shortcut
using the CTRL + mouse wheel.
Reviewer: Dalai Felinto (dfelinto), Julian Eisel (Severin),
Hans Goudey (HooglyBoogly).
Differential Revision: https://developer.blender.org/D11046
This patch introduces non linear sliders. That means, that the movement
of the mouse doesn't map linearly to the value of the slider.
The following changes have been made.
- Free logarithmic sliders with maximum range of (`0 <= x < inf`)
- Logarithmic sliders with correct value indication bar.
- Free cubic sliders with maximum range of (`-inf < x < inf`)
- Cubic sliders with correct value indication bar.
Cubic mapping has been added as well, because it's used for brush sizes
in other applications (Krita for e.g.).
To make a slider have a different scale type use following line in RNA:
`RNA_def_property_ui_scale_type(prop, PROP_SCALE_LOGARITHMIC);`
or:
`RNA_def_property_ui_scale_type(prop, PROP_SCALE_CUBIC);`
Test the precision, step size and soft-min if you change the scale type
of a property as it will feel very different and may need tweaking.
Ref D9074
Increase range of internal flags & order UI_SEARCH_FILTER_NO_MATCH
within this range, so public button flags aren't accidentally added
that overlap with internal flags.
Using the button context for operators is useful for other cases as well (where
the operator isn't the button operator itself). For example we'll need this for
the asset view UI template, where there will be additional operators that
should be able to act on button context.
I landed D10527 in rB1a8aee0a7cec accidentally, and the version there was
missing a name change discussed in review. This commit just renames the
boolean variable controlling the special behavior for attribute search.
Original message meant for this change:
For geometry nodes we will use search buttons to display a list of
attributes available the last time the node tree was executed (D10519).
Because this list is just a hint, we need to be able to enter any string,
not just strings from the search items.
This patch adds a boolean option to string buttons to enable this.
The change is quite simple, changes to behavior are only required in
two places. The type-specific button struct changes help a lot here.
Differential Revision: https://developer.blender.org/D10527
