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 commit adds a new face nearest snapping mode, adds new snapping
options, and (lightly) refactors code around snapping.
The new face nearest snapping mode will snap transformed geometry to the
nearest surface in world space. In contrast, the original face snapping
mode uses projection (raycasting) to snap source to target geometry.
Face snapping therefore only works with what is visible, while nearest
face snapping can snap geometry to occluded parts of the scene. This new
mode is critical for retopology work, where some of the target mesh
might be occluded (ex: sliding an edge loop that wraps around the
backside of target mesh).
The nearest face snapping mode has two options: "Snap to Same Target"
and "Face Nearest Steps". When the Snap to Same Object option is
enabled, the selected source geometry will stay near the target that it
is nearest before editing started, which prevents the source geometry
from snapping to other targets. The Face Nearest Steps divides the
overall transformation for each vertex into n smaller transformations,
then applies those n transformations with surface snapping interlacing
each step. This steps option handles transformations that cross U-shaped
targets better.
The new snapping options allow the artist to better control which target
objects (objects to which the edited geometry is snapped) are considered
when snapping. In particular, the only option for filtering target
objects was a "Project onto Self", which allowed the currently edited
mesh to be considered as a target. Now, the artist can choose any
combination of the following to be considered as a target: the active
object, any edited object that isn't active (see note below), any non-
edited object. Additionally, the artist has another snapping option to
exclude objects that are not selectable as potential targets.
The Snapping Options dropdown has been lightly reorganized to allow for
the additional options.
Included in this patch:
- Snap target selection is more controllable for artist with additional
snapping options.
- Renamed a few of the snap-related functions to better reflect what
they actually do now. For example, `applySnapping` implies that this
handles the snapping, while `applyProject` implies something entirely
different is done there. However, better names would be
`applySnappingAsGroup` and `applySnappingIndividual`, respectively,
where `applySnappingIndividual` previously only does Face snapping.
- Added an initial coordinate parameter to snapping functions so that
the nearest target before transforming can be determined(for "Snap to
Same Object"), and so the transformation can be broken into smaller
steps (for "Face Nearest Steps").
- Separated the BVH Tree getter code from mesh/edit mesh to its own
function to reduce code duplication.
- Added icon for nearest face snapping.
- The original "Project onto Self" was actually not correct! This option
should be called "Project onto Active" instead, but that only matters
when editing multiple meshes at the same time. This patch makes this
change in the UI.
Reviewed By: Campbell Barton, Germano Cavalcante
Differential Revision: https://developer.blender.org/D14591
If `cancel` is `false`, `NULL` `inter` pointer dereferencing could occur.
Currently I haven't found a case where this can happen.
But it's best to avoid.
Since [0], transform gizmos are no longer hidden during transform.
The same can be observed for rotation gizmos.
However, as a workaround for these rotation gizmos, there was already a
drawing utility running.
With the gizmo and the utility this drawing is now being done twice.
So remove the utility/workaround and update the gizmo accordingly.
[0] {648350e456490f8d6258e7de9bf94d3a6a34dbb2}
Differential Revision: https://developer.blender.org/D9542
The transformation snapping code contains a bunch of `#define`s, some ambiguously or incorrectly named attributes. This patch contains refactored code to improve this. This patch does (should) not change functionality of snapping.
Clarified ambiguously / incorrectly named attributes.
- "Target" is used to refer to the part of the source that is to be snapped (Active, Median, Center, Closest), but several other areas of Blender use the term "target" to refer to the thing being snapped to and "source" to refer to the thing getting snapped. Moreover, the implications of the previous terms do not match the descriptions. For example: `SCE_SNAP_TARGET_CENTER` does not snap the grabbed geometry to the center of the target, but instead "Snap transforamtion center onto target".
- "Select" refers to the condition for an object to be a possible target for snapping.
- `SCE_SNAP_MODE_FACE` is renamed to `SCE_SNAP_MODE_FACE_RAYCAST` to better describe its affect and to make way for other face snapping methods (ex: nearest).
Refactored related `#define` into `enum`s. In particular, constants relating to...
- `ToolSettings.snap_flag` are now in `enum eSnapFlag`
- `ToolSettings.snap_mode` are now in `enum eSnapMode`
- `ToolSettings.snap_source` (was `snap_target`) are now in `enum eSnapSourceSelect`
- `ToolSettings.snap_flag` (`SCE_SNAP_NO_SELF`) and `TransSnap.target_select` are now in `enum eSnapTargetSelect`
As the terms became more consistent and the constants were packed together into meaningful enumerations, some of the attribute names seemed ambiguous. For example, it is unclear whether `SnapObjectParams.snap_select` referred to the target or the source. This patch also adds a small amount of clarity.
This patch also swaps out generic types (ex: `char`, `short`, `ushort`) and unclear hard coded numbers (ex: `0`) used with snap-related enumerations with the actual `enum`s and values.
Note: I did leave myself some comments to follow-up with further refactoring. Specifically, using "target" and "source" consistently will mean the Python API will need to change (ex: `ToolSettings.snap_target` is not `ToolSettings.snap_source`). If the API is going to change, it would be good to make sure that the used terms are descriptive enough. For example, `bpy.ops.transform.translate` uses a `snap` argument to determine if snapping should be enabled while transforming. Perhaps `use_snap` might be an improvement that's more consistent with other conventions.
This patch is (mostly) a subset of D14591, as suggested by @mano-wii.
Task T69342 proposes to separate the `Absolute Grid Snap` option out from `Increment` snapping method into its own method. Also, there might be reason to create additional snapping methods or options. (Indeed, D14591 heads in this direction). This patch can work along with these suggestions, as this patch is trying to clarify the snapping code and to prompt more work in this area.
Reviewed By: mano-wii
Differential Revision: https://developer.blender.org/D15037
Scaling handles while dragging could be distracting, especially at
extreme values where handles could become large on-screen.
Now all gizmos are shown while scaling.
GIZMO_GT_arrow_3d now now support changing their length while being
dragged as well as negative lengths.
A snap state can be replaced by another snap state of a gizmo or cursor.
The snap gizmo should only change its state, not the current state.
It's not really a problem currently.
Split 'ED_view3d_cursor_snap_data_get' into 'update' and 'get' functions
Sometimes we just want to update and sometimes we just get the result.
Make it clear.
Prefer using immVertex3f when 3D shaders are used for 2D rendering due to overhead of vertex padding in hardware. CPU overhead is negligible.
Authored by Apple: Michael Parkin-White
Ref T96261
Reviewed By: fclem
Maniphest Tasks: T96261
Differential Revision: https://developer.blender.org/D14494
Caused by 0cb5eae9d0 which restored
support for 3D depth when selecting gizmos - making it difficult
to select single lines drawn in front of other gizmos.
Previously the first hit was always used.
Resolve by using a margin around arrow stems when selecting
which was already done for 2D arrows.
So far it was needed to declare a new RNA struct to `RNA_access.h` manually.
Since 9b298cf3db we generate a `RNA_prototypes.h` for RNA property
declarations. Now this also includes the RNA struct declarations, so they don't
have to be added manually anymore.
Differential Revision: https://developer.blender.org/D13862
Reviewed by: brecht, campbellbarton
- Rename ED_view3d_win_to_delta `mval` argument to `xy_delta` as it
as it was misleading since this is an screen-space offset not a region
relative cursor position (typical use of the name `mval`).
Also rename the variable passed to this function which also used the
term `mval` in many places.
- Re-order the output argument of ED_view3d_win_to_delta last.
use an r_ prefix for return arguments.
- Document how the `zfac` argument is intended to be used.
- Split ED_view3d_calc_zfac into two functions as the `r_flip` argument
was only used in some special cases.
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
Error introduced in rB69d6222481b4 and partially fixed in rB24310441ddc8.
When gizmo was turned on but the scene has more than one 3D viewport, one of them the snap cursor did not appear.
Avoid using underscore prefix since these typically mean the variable
shouldn't be accessed directly (it may be accessed from a macro,
or memory on the stack which is assigned to a pointer).
In this case a more meaningful name can be used for the argument
that was shadowed.
Use arrays for wmEvent coordinates, this quiets warnings with GCC11.
- `x, y` -> `xy`.
- `prevx, prevy` -> `prev_xy`.
- `prevclickx, prevclicky` -> `prev_click_xy`.
There is still some cleanup such as using `copy_v2_v2_int()`,
this can be done separately.
Reviewed By: campbellbarton, Severin
Ref D12901
Make the snap system consistent with the placement tool and leak-safe.
**Changes:**
- Store `SnapCursorDataIntern` in a `static` variable;
- Initialize (lazily) `SnapCursorDataIntern` only once (for the keymap).
- Move setup members of `V3DSnapCursorData` to a new struct `V3DSnapCursorState`
- Merge `ED_view3d_cursor_snap_activate_point` and `ED_view3d_cursor_snap_activate_plane` into `state = ED_view3d_cursor_snap_active()`
- Merge `ED_view3d_cursor_snap_deactivate_point` and `ED_view3d_cursor_snap_deactivate_plane` into `ED_view3d_cursor_snap_deactive(state)`
- Be sure to free the snap context when closing via `ED_view3d_cursor_snap_exit`
- Use RNA properties callbacks to update the properties of the `"Add Primitive Object"` operator
Move most of the gizmo snap and placement code to `view_cursor_snap.c`.
Simplify and extend the snap API.
Differential Revision: https://developer.blender.org/D12868
This is caused by removing `gizmo_cage2d_modal()` code in 482806c816.
Some areas use cage gizmo to modify RNA properties without using
transform operator like area light, image empty, and compositor preview.
This functionality is implemented in code that was removed.
Add this code back.
Reviewed By: zeddb, campbellbarton
Differential Revision: https://developer.blender.org/D12859
Make the "xform" tool/gizmo available for strip transformations in the
sequencer preview window.
Because of the amount of hacks needed to make the gizmo work nicely with
multiple strips at the same time, it was decided to only show the
translate gizmo when multiple strips are selected.
This is because the transforms with multiple strips would appear buggy
because of our lack of shearing support in the transform system.
There is also currently no way to properly sync the gizmo drawing with
the transform when using multiple strips.
Reviewed By: Richard Antalik, Campbell Barton
Differential Revision: http://developer.blender.org/D12729
