| Age | Commit message (Collapse) | Author |
|---|
|
Now the list of masks can be ordered as is done in Layers.
This can be used to organize list and in the future refquired for new masking options.
|
|
|
|
|
|
Draw functions used RNA_pointer_create to create the pointer,
however this already exists in the operator.
|
|
Before only active frame was supported
Related to T87425
|
|
|
|
|
|
Any dynamic enum access would not use the callback.
Always set the owner_id to avoid this causing problems.
Oversight in 919558854d624f5db40acfa9f5674ac8c94873b6
|
|
Previously, clicking into a number field, changing nothing and then
clicking outside the field again would trigger an update (RNA prop
would be set to the same value again). This could potentially cause
an expensive operation (like a modifer) to run again, even if all the
parameters were identical.
The fix prevents this by treating unchanging values in the field as a
cancel operation.
Reviewed By: Severin
Maniphest Tasks: T87448
Differential Revision: https://developer.blender.org/D10976
|
|
Ref T78710
|
|
This is a first iteration of a switch node. It can only switch between
two inputs values based on a boolean. A more sophisticated switch
node that has an integer selector will probably come later.
Currently, the geometry nodes evaluator does not support lazy evaluation
of individual inputs. Therefore, all inputs will be computed currently.
An improvement to the evaluator will be worked on separately.
Ref: T85374
Differential Revision: https://developer.blender.org/D10460
|
|
|
|
|
|
|
|
|
|
Prevent drag events from changing the highlighted gizmo
unless the drag event activates the gizmo.
This resolves a glitch where testing a drag event would highlight
at the point the drag was initiated even when the event was not handled.
|
|
Non-functional change in preparation for fix.
|
|
|
|
gizmo_button2d_bounds result wasn't valid when the gizmo was part
of a 3D gizmo group.
Regression in cf6d17a6aa421e0038fc1f8e60e3f1f708887c3e
|
|
`ob` --> `ob_eval`
`me` --> `me_eval`
`em` --> `em_eval`
|
|
`has_loose_edge` -> `has_loose_vert`
|
|
The previous code had unclear hacks to avoid updating while transforming,
it was also duplicated in two functions causing an inconsistent
initialization of the looptris bvhtree (which could even generate
unpredictable snapping results).
Now, detection update and inicializatiom of common members are contained in
`snap_object_data_mesh_get` and `snap_object_data_editmesh_get`.
Also, the "Hack to avoid updating while transforming" is more evident.
|
|
This deduplicates the code making it easier to edit.
|
|
|
|
The logic assumed that there were only 3 basic snapping modes.
|
|
|
|
The order of the two parameters was incorrect.
|
|
|
|
|
|
|
|
|
|
For Measure tool, it is more useful to snap to what is really visible.
So use the cage instead of the geometry that may be hidden with Bmesh.
|
|
The Snap Gizmo now has options for occlusion, selection filter and edit
geometry.
It will be useful to implement in current tools.
|
|
It is important to check if editmesh eval cage is also bmesh.
|
|
This allows the addition of the `SNAP_GEOM_CAGE` option.
Currently unused.
|
|
|
|
The fast triangulator from Blenlib could leave a non-manifold mesh
after removing degenerate triangles. Switched to an exact triangulator.
|
|
|
|
|
|
|
|
|
|
This method is similar to `std::vector::emblace_back` in that it constructs
the new object inplace in the vector, removing the need for a move.
The `_as` suffix is consistent with similar behavior in Map and Set data structures.
|
|
It is important to limit the pixels read on `BLI_array_iter_spiral_square`.
Fortunately `ED_view3d_depth_read_cached` was not being called with a
`margin` parameter.
Wrong logic introduced in rB44c76e4ce310.
|
|
It is important to limit the pixels read on `BLI_array_iter_spiral_square`.
Fortunately `ED_view3d_depth_read_cached` was not being called with a
`margin` parameter.
Wrong logic introduced in rB44c76e4ce310.
|
|
This allows us to build more complex values in-place in the map.
Before those values had to be build separately and then moved into the map.
Existing calls to the Map API remain unchanged.
|
|
A virtual array is a data structure that is similar to a normal array
in that its elements can be accessed by an index. However, a virtual
array does not have to be a contiguous array internally. Instead, its
elements can be layed out arbitrarily while element access happens
through a virtual function call. However, the virtual array data
structures are designed so that the virtual function call can be avoided
in cases where it could become a bottleneck.
Most commonly, a virtual array is backed by an actual array/span or
is a single value internally, that is the same for every index.
Besides those, there are many more specialized virtual arrays like the
ones that provides vertex positions based on the `MVert` struct or
vertex group weights.
Not all attributes used by geometry nodes are stored in simple contiguous
arrays. To provide uniform access to all kinds of attributes, the attribute
API has to provide virtual array functionality that hides the implementation
details of attributes.
Before this refactor, the attribute API provided its own virtual array
implementation as part of the `ReadAttribute` and `WriteAttribute` types.
That resulted in unnecessary code duplication with the virtual array system.
Even worse, it bound many algorithms used by geometry nodes to the specifics
of the attribute API, even though they could also use different data sources
(such as data from sockets, default values, later results of expressions, ...).
This refactor removes the `ReadAttribute` and `WriteAttribute` types and
replaces them with `GVArray` and `GVMutableArray` respectively. The `GV`
stands for "generic virtual". The "generic" means that the data type contained
in those virtual arrays is only known at run-time. There are the corresponding
statically typed types `VArray<T>` and `VMutableArray<T>` as well.
No regressions are expected from this refactor. It does come with one
improvement for users. The attribute API can convert the data type
on write now. This is especially useful when writing to builtin attributes
like `material_index` with e.g. the Attribute Math node (which usually
just writes to float attributes, while `material_index` is an integer attribute).
Differential Revision: https://developer.blender.org/D10994
|
|
|
|
Now if one stroke in the extremes of the stack is selected, other strokes are moved.
Reviewed By: pepeland, Dantti
Maniphest Tasks: T87321
Differential Revision: https://developer.blender.org/D10997
|
|
This adds support for mutable virtual arrays and provides many utilities
for creating virtual arrays for various kinds of data. This commit is
preparation for D10994.
|
|
Better distinction between modifier key events and mouse position events.
No functional changes.
|
