With libepoxy we can choose between EGL and GLX at runtime, as well as
dynamically open EGL and GLX libraries without linking to them.
This will make it possible to build with Wayland, EGL, GLVND support while
still running on systems that only have X11, GLX and libGL. It also paves
the way for headless rendering through EGL.
libepoxy is a new library dependency, and is included in the precompiled
libraries. GLEW is no longer a dependency, and WITH_SYSTEM_GLEW was removed.
Includes contributions by Brecht Van Lommel, Ray Molenkamp, Campbell Barton
and Sergey Sharybin.
Ref T76428
Differential Revision: https://developer.blender.org/D15291
This is a port of sculpt-dev's `SculptVertRef` refactor
(note that `SculptVertRef was renamed to PBVHVertRef`)
to master. `PBVHVertRef` is a structure that abstracts
the concept of a vertex in the sculpt code; it's simply
an `intptr_t` wrapped in a struct.
For `PBVH_FACES` and `PBVH_GRIDS` this struct stores a
vertex index, but for `BMesh` it stores a direct pointer
to a BMVert. The intptr_t is wrapped in a struct to prevent
the accidental usage of it as an index.
There are many reasons to do this:
* Right now `BMesh` verts are not logical sculpt verts;
to use the sculpt API they must first be converted to indices.
This requires a lot of indirect lookups into tables, leading to performance
loss. It has also led to greater code complexity and duplication.
* Having an abstract vertex type makes it feasible to have one unified
temporary attribute API for all three PBVH modes, which in turn
made it rather trivial to port sculpt brushes to DynTopo in
sculpt-dev (e.g. the layer brush, draw sharp, the smooth brushes,
the paint brushes, etc). This attribute API will be in a future patch.
* We need to do this anyway for the eventual move to C++.
Differential Revision: https://developer.blender.org/D14272
Reviewed By: Brecht Van Lommel
Ref D14272
No user visible changes expected.
Similar to rBc355be6faeac, but for view items now instead of the view.
Not much of the item code is ported to use it yet, it's actually a bit
tricky for the most part. But just introducing the base class already
allows me to start unifying the view item buttons (`uiButTreeRow` and
`uiButGridTile`). This would be a nice improvement.
No user visible changes expected.
There's plenty of duplicated code in the grid and the tree view, and I expect
this to become more. This starts the process of unifying these parts, which
should also make it easier to add new views. Complexity in the view classes is
reduced, and some type shenanigans for C compatibility and general view
management can be removed, since there is now a common base type.
For the start this ports some of the view reconstruction, where the view and
its items are compared to the version of itself in the previous redraw, so that
state (highlighted, active, renaming, collapsed, ...) can be preserved.
Notifier listening is also ported.
Part of T98560.
See https://wiki.blender.org/wiki/Source/Interface/Views
Adds all the basic functionality needed for grid views. They display
items in a grid of rows and columns, typically with a preview image and
a label underneath. Think of the main region in the Asset Browser.
Current features:
- Active item
- Notifier listening (also added this to the tree view)
- Performance: Skip adding buttons that are not scrolled into view
(solves performance problems for big asset libraries, for example).
- Custom item size
- Preview items (items that draw a preview with a label underneath)
- Margins between items scale so the entire region width is filled with
column, rather than leaving a big empty block at the right if there's
not enough space for another column (like the File and current Asset
Browser does it).
- "Data-View Item" theme colors. Not shown in the UI yet.
No user visible changes expected since the grid views aren't used for
anything yet.
This was developed as part of a rewrite of the Asset Browser UI
(`asset-browser-grid-view` branch), see T95653. There's no reason to
keep this part in a branch, continuing development in master makes
things easier.
Grid and tree views have a lot of very similar code, so I'm planning to
unify them to a degree. I kept things separate for the start to first
find out how much and what exactly makes sense to override.
Moves code for managing dragging data from buttons to a separate file.
This way all this closely related code is in one location, making it
easier to see how it all relates, and easier to find.
Moves all `interface_region*` files to C++ except for the tooptip region
which is slightly more complicated. Also move a few other files as well.
This helps to simplify and speed up code, especially through the use
of better C++ data structures. This change builds on all platforms on
the buildbot.
Lets `makesrna` generate a `RNA_prototypes.h` header with declarations for all
RNA properties. This can be included in regular source files when needing to
reference RNA properties statically.
This solves an issue on MSVC with adding such declarations in functions, like
we used to do. See 800fc17367. Removes any such declarations and the related
FIXME comments.
Reviewed By: campbellbarton, LazyDodo, brecht
Differential Revision: https://developer.blender.org/D13837
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
This allows the use of better/more readable data structures,
and will also make some refactors to the search button easier.
The build completed on the buildbot for all platforms.
This patch upgrades node editor breadcrumbs to have slightly more
visual weight, to including the base path of object/modifier/world,
etc, have more visually pleasing spacing, and contain icons.
In the code, a generic "context path" is added to interface code.
The idea is that this could be used to draw other breadcrumbs in areas
like the property editor or the spreadsheet, and features could be added
to all of those areas at the same time.
Ideally we would be able to control the color of the breadcrumbs with a
specific theme color, but since they are drawn with the regular layout
system, that is not easily possible.
Thanks to @fabian_schempp for the original patch.
Differential Revision: https://developer.blender.org/D10413
This adds attribute search to the geometry nodes modifier
for the input and output attributes. The "New" search item
is only shown for the output attributes.
Some of the attribute search code is extracted to a new file
in the interface code, to avoid some code duplication.
The UI code required two fixes so that the search would work
for dynamic length strings (IDProperties do not have a fixed size).
Since this does changes to the UI layout of the modifier, I also
addressed T91485 here.
Differential Revisiion: https://developer.blender.org/D12788
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
```
So far all UI lists had to be defined in Python, this makes it possible
to define them in C as well. Note that there is a whole bunch of special
handling for the Python API that isn't there for C. I think most
importantly custom properties support, which currently can't be added
for C defined UI lists.
The upcoming asset view UI template will use this, which needs to be
defined in C.
Adds a new file `interface_template_list.cc`, which at this point is
mostly a dummy to have a place for the `ED_uilisttypes_ui()` definition.
I plan a separate cleanup to move the UI-list template to that file.
Blender did not support to input East Asian characters (Chinese, Japanese,
Korean) on macOS. This patch adds support for Japanese input, by implementing
the appropriate processing for the NSTextInputClient protocol.
Technical notes:
* The conversion candidate window is drawn by the input method program calling
`firstRectForCharacterRange`.
* The string before confirmation (called `composite` in blender) is handled in
the `setMarkedText` method called by the input method program.
* The string after confirmation (called `result` in the blender) is processed
in the `insertText` method called by the input method program.
Ref T51283
Differential Revision: https://developer.blender.org/D11695
Starts scrolling when dragging a node or node link and going outside the current window.
Largely copied from the VIEW2D_OT_edge_pan operator.
Edge panning operator customdata and supporting functions now in
UI_view2d.h, so they could be used by operators in other editor
libraries. The VIEW2D_OT_edge_pan operator also uses this customdata and
shared functions now. Operators properties can be used to configure
edge panning margins and speed for each use case, rather than using
hardcoded values.
The speed function for edge panning has been tweaked somewhat:
* "Speed per pixel" has been replaced with a "speed ramp" distance.
This is more intuitive and also creates an upper bound for the speed,
which can otherwise become extreme with large cursor distance.
* "Max speed" is reached at the end of the speed ramp.
* Padding the region inside and outside is applied as before, but both
values are operator properties now.
Node transform operator also supports edge panning. This requires
an offset for changes in the view2d rect, otherwise nodes are "stuck"
to the original view.
Transform operator had cursor wrapping categorically enabled, but this
gets quite confusing with the edge scrolling mechanism. A new TransInfo
option T_NO_CURSOR_WRAP has been introduced to disable this behavior.
The double negative is a bit annoying, but want to avoid affecting the
existing transform modes, so by default it should still set the
OP_IS_MODAL_GRAB_CURSOR flag (which then sets the WM_CURSOR_WRAP_XY
flag during modal execution).
Reviewed By: HooglyBoogly, JacquesLucke
Differential Revision: https://developer.blender.org/D11073
In the current implementation, cryptomatte passes are connected to the node
and elements are picked by using the eyedropper tool on a special pick channel.
This design has two disadvantages - both connecting all passes individually
and always having to switch to the picker channel are tedious.
With the new design, the user selects the RenderLayer or Image from which the
Cryptomatte layers are directly loaded (the type of pass is determined by an
enum). This allows the node to automatically detect all relevant passes.
Then, when using the eyedropper tool, the operator looks up the selected
coordinates from the picked Image, Node backdrop or Clip and reads the picked
object directly from the Renderlayer/Image, therefore allowing to pick in any
context (e.g. by clicking on the Combined pass in the Image Viewer). The
sampled color is looked up in the metadata and the actual name is stored
in the cryptomatte node. This also allows to remove a hash by just removing
the name from the matte id.
Technically there is some loss of flexibility because the Cryptomatte pass
inputs can no longer be connected to other nodes, but since any compositing
done on them is likely to break the Cryptomatte system anyways, this isn't
really a concern in practise.
In the future, this would also allow to automatically translate values to names
by looking up the value in the associated metadata of the input, or to get a
better visualization of overlapping areas in the Pick output since we could
blend colors now that the output doesn't have to contain the exact value.
Idea + Original patch: Lucas Stockner
Reviewed By: Brecht van Lommel
Differential Revision: https://developer.blender.org/D3959
For a future patch (D9006) we need these groups for longer than just the
the layout process, in order to differentiate buttons in panel headers.
It may also be helpful in the future to have a way to access related
buttons added in the same uiLayout.prop call. With this commit, the
groups are stored in and destructed with the uiBlock.
This patch is only for the eyedropper to create materials.
Options:
Click: Create Stroke Material
Shift+Click: Create Fill Material.
Shift+Ctrl+Click: Create Stroke and Fill Material.
Toolbar:
{F7718606}
Reviewed By: brecht, mendio
Differential Revision: https://developer.blender.org/D5688
This affects the timeline, dopesheet, graph editor, sequencer,
clip editor and nla editor.
Removed structs and enums: `V2D_ARG_DUMMY`, `eView2D_Units`,
`eView2D_Clamp`, `eView2D_Gridlines`, `View2DGrid`.
A main goal of this refactor is to get rid of the very generic
`View2DGrid` struct. The drawing code became very complex
because there were many different combinations of settings.
This refactor implements a different approach.
Instead of one very generic API, there are many slighly
different functions that do exactly, what we need in the
different editors. Only very little code is duplicated,
because the API functions compose some shared low level code.
This structure makes the code much easier to debug and change,
because every function has much fewer responsibilities.
Additionally, this refactor fixes some long standing bugs.
E.g. when `Show Seconds` is enabled, you zoom in and pan the view.
Or that the step size between displayed frame numbers was
always `>= 2`, no matter how close you zoom in.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4776
No functional change, this adds LIB definition and args to cmake files.
Without this it's difficult to migrate away from 'BLENDER_SORTED_LIBS'
since there are many platforms/configurations that could break when
changing linking order.
Manually add and enable WITHOUT_SORTED_LIBS to try building
without sorted libs (currently fails since all variables are empty).
This check will eventually be removed.
See T46725.
It's more convenient to keep version patching in the same place,
this also splits out some function calls from version patching
and supports updating UserDef structs besides the 'U'l global.
This is the first step to moving redo out of the top-bar, see: T55039
- Support for floating panels in the ScrArea has been added.
- A new region type RGN_TYPE_HUD is used for floating settings input.
- Only one HUD should be visible at a time.
- Currently HUD regions are only visible
for 3D view and image space types.
- There are currently some remaining glitches with hide/show
that need further investigation.
