2022-02-11 09:07:11 +11:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
|
* Copyright 2001-2002 NaN Holding BV. All rights reserved. */
|
2011-02-27 20:29:51 +00:00
|
|
|
|
2019-02-18 08:08:12 +11:00
|
|
|
/** \file
|
|
|
|
|
* \ingroup edtransform
|
2011-02-27 20:29:51 +00:00
|
|
|
*/
|
|
|
|
|
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
#include <float.h>
|
|
|
|
|
|
|
|
|
|
#include "PIL_time.h"
|
|
|
|
|
|
2009-03-29 19:52:53 +00:00
|
|
|
#include "DNA_windowmanager_types.h"
|
|
|
|
|
|
2009-02-24 00:45:40 +00:00
|
|
|
#include "BLI_blenlib.h"
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "BLI_math.h"
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
|
2017-02-02 03:14:52 -02:00
|
|
|
#include "GPU_immediate.h"
|
2022-05-03 10:09:22 -03:00
|
|
|
#include "GPU_matrix.h"
|
2018-06-27 19:07:23 -06:00
|
|
|
#include "GPU_state.h"
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
|
|
|
|
|
#include "BKE_context.h"
|
2013-04-13 20:31:52 +00:00
|
|
|
#include "BKE_editmesh.h"
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "BKE_layer.h"
|
|
|
|
|
#include "BKE_object.h"
|
2020-07-22 12:00:02 -03:00
|
|
|
#include "BKE_scene.h"
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
|
2013-03-07 02:44:55 +00:00
|
|
|
#include "RNA_access.h"
|
|
|
|
|
|
2022-05-03 10:09:22 -03:00
|
|
|
#include "WM_api.h"
|
2013-03-07 02:44:55 +00:00
|
|
|
#include "WM_types.h"
|
|
|
|
|
|
2020-05-27 00:14:11 -03:00
|
|
|
#include "ED_gizmo_library.h"
|
2019-10-28 09:51:53 -03:00
|
|
|
#include "ED_markers.h"
|
2012-06-29 14:34:46 +00:00
|
|
|
#include "ED_node.h"
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "ED_transform_snap_object_context.h"
|
2009-01-28 21:43:43 +00:00
|
|
|
#include "ED_uvedit.h"
|
2021-10-18 00:32:23 -03:00
|
|
|
#include "ED_view3d.h"
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
|
2009-01-10 18:33:16 +00:00
|
|
|
#include "UI_resources.h"
|
2009-01-28 21:43:43 +00:00
|
|
|
#include "UI_view2d.h"
|
2009-01-10 18:33:16 +00:00
|
|
|
|
2021-06-29 20:12:19 +02:00
|
|
|
#include "SEQ_iterator.h"
|
|
|
|
|
#include "SEQ_sequencer.h"
|
|
|
|
|
#include "SEQ_time.h"
|
|
|
|
|
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
|
|
|
|
|
#include "transform.h"
|
2020-06-06 10:30:32 -03:00
|
|
|
#include "transform_convert.h"
|
2019-10-29 00:45:05 +11:00
|
|
|
#include "transform_snap.h"
|
2009-01-10 18:33:16 +00:00
|
|
|
|
2021-06-26 16:57:03 +10:00
|
|
|
static bool doForceIncrementSnap(const TransInfo *t);
|
|
|
|
|
|
2013-04-03 09:48:21 +00:00
|
|
|
/* this should be passed as an arg for use in snap functions */
|
2017-11-09 13:23:01 -02:00
|
|
|
#undef BASACT
|
2013-04-03 09:48:21 +00:00
|
|
|
|
2013-04-11 10:17:06 +00:00
|
|
|
/* use half of flt-max so we can scale up without an exception */
|
2012-10-05 01:34:47 +00:00
|
|
|
|
2019-10-28 09:32:59 -03:00
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
|
/** \name Prototypes
|
|
|
|
|
* \{ */
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
|
2011-11-15 16:38:48 +00:00
|
|
|
static void setSnappingCallback(TransInfo *t);
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
|
2011-11-19 00:52:54 +00:00
|
|
|
/* static void CalcSnapGrid(TransInfo *t, float *vec); */
|
2021-06-29 17:38:34 -03:00
|
|
|
static void snap_calc_view3d_fn(TransInfo *t, float *vec);
|
|
|
|
|
static void snap_calc_uv_fn(TransInfo *t, float *vec);
|
|
|
|
|
static void snap_calc_node_fn(TransInfo *t, float *vec);
|
|
|
|
|
static void snap_calc_sequencer_fn(TransInfo *t, float *vec);
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
|
2011-11-15 16:38:48 +00:00
|
|
|
static void TargetSnapMedian(TransInfo *t);
|
|
|
|
|
static void TargetSnapCenter(TransInfo *t);
|
|
|
|
|
static void TargetSnapClosest(TransInfo *t);
|
|
|
|
|
static void TargetSnapActive(TransInfo *t);
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
|
2019-10-28 09:32:59 -03:00
|
|
|
/** \} */
|
|
|
|
|
|
|
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
|
/** \name Implementations
|
|
|
|
|
* \{ */
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
static bool snapNodeTest(View2D *v2d, bNode *node, eSnapTargetSelect snap_select);
|
|
|
|
|
static NodeBorder snapNodeBorder(eSnapMode snap_node_mode);
|
2012-06-29 14:34:46 +00:00
|
|
|
|
2011-02-07 12:07:26 +00:00
|
|
|
#if 0
|
2008-12-31 22:43:29 +00:00
|
|
|
int BIF_snappingSupported(Object *obedit)
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
{
|
|
|
|
|
int status = 0;
|
2018-05-13 06:44:03 +02:00
|
|
|
|
2014-07-20 01:30:29 +10:00
|
|
|
/* only support object mesh, armature, curves */
|
2022-02-18 09:50:29 -06:00
|
|
|
if (obedit == NULL || ELEM(obedit->type, OB_MESH, OB_ARMATURE, OB_CURVES_LEGACY, OB_LATTICE, OB_MBALL)) {
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
status = 1;
|
|
|
|
|
}
|
2018-05-13 06:44:03 +02:00
|
|
|
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
return status;
|
|
|
|
|
}
|
2011-02-07 12:07:26 +00:00
|
|
|
#endif
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
|
2020-07-22 12:00:02 -03:00
|
|
|
static bool snap_use_backface_culling(const TransInfo *t)
|
|
|
|
|
{
|
|
|
|
|
BLI_assert(t->spacetype == SPACE_VIEW3D);
|
|
|
|
|
View3D *v3d = t->view;
|
|
|
|
|
if ((v3d->shading.type == OB_SOLID) && (v3d->shading.flag & V3D_SHADING_BACKFACE_CULLING)) {
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
if (v3d->shading.type == OB_RENDER &&
|
|
|
|
|
(t->scene->display.shading.flag & V3D_SHADING_BACKFACE_CULLING) &&
|
|
|
|
|
BKE_scene_uses_blender_workbench(t->scene)) {
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
if (t->settings->snap_flag & SCE_SNAP_BACKFACE_CULLING) {
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2018-07-09 17:57:05 +02:00
|
|
|
bool validSnap(const TransInfo *t)
|
2009-12-03 19:18:00 +00:00
|
|
|
{
|
2012-06-10 22:13:17 +00:00
|
|
|
return (t->tsnap.status & (POINT_INIT | TARGET_INIT)) == (POINT_INIT | TARGET_INIT) ||
|
|
|
|
|
(t->tsnap.status & (MULTI_POINTS | TARGET_INIT)) == (MULTI_POINTS | TARGET_INIT);
|
2009-12-01 18:26:18 +00:00
|
|
|
}
|
|
|
|
|
|
2018-07-09 17:57:05 +02:00
|
|
|
bool activeSnap(const TransInfo *t)
|
2009-12-03 19:18:00 +00:00
|
|
|
{
|
2013-10-01 12:35:43 +00:00
|
|
|
return ((t->modifiers & (MOD_SNAP | MOD_SNAP_INVERT)) == MOD_SNAP) ||
|
|
|
|
|
((t->modifiers & (MOD_SNAP | MOD_SNAP_INVERT)) == MOD_SNAP_INVERT);
|
2009-12-03 19:18:00 +00:00
|
|
|
}
|
|
|
|
|
|
2021-06-26 16:57:03 +10:00
|
|
|
bool activeSnap_with_project(const TransInfo *t)
|
|
|
|
|
{
|
|
|
|
|
if (!t->tsnap.project) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!activeSnap(t) || (t->flag & T_NO_PROJECT)) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (doForceIncrementSnap(t)) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2018-12-18 11:54:02 +01:00
|
|
|
bool transformModeUseSnap(const TransInfo *t)
|
2018-12-18 10:03:50 +11:00
|
|
|
{
|
2018-12-18 11:54:02 +01:00
|
|
|
ToolSettings *ts = t->settings;
|
2018-12-18 10:03:50 +11:00
|
|
|
if (t->mode == TFM_TRANSLATION) {
|
2018-12-18 11:54:02 +01:00
|
|
|
return (ts->snap_transform_mode_flag & SCE_SNAP_TRANSFORM_MODE_TRANSLATE) != 0;
|
2018-12-18 10:03:50 +11:00
|
|
|
}
|
|
|
|
|
if (t->mode == TFM_ROTATION) {
|
2018-12-18 11:54:02 +01:00
|
|
|
return (ts->snap_transform_mode_flag & SCE_SNAP_TRANSFORM_MODE_ROTATE) != 0;
|
2018-12-18 10:03:50 +11:00
|
|
|
}
|
|
|
|
|
if (t->mode == TFM_RESIZE) {
|
2018-12-18 11:54:02 +01:00
|
|
|
return (ts->snap_transform_mode_flag & SCE_SNAP_TRANSFORM_MODE_SCALE) != 0;
|
2018-12-18 10:03:50 +11:00
|
|
|
}
|
2021-06-29 20:12:19 +02:00
|
|
|
if (ELEM(t->mode, TFM_VERT_SLIDE, TFM_EDGE_SLIDE, TFM_SEQ_SLIDE)) {
|
2020-06-22 15:28:25 -03:00
|
|
|
return true;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-12-18 10:03:50 +11:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2018-12-18 11:54:02 +01:00
|
|
|
static bool doForceIncrementSnap(const TransInfo *t)
|
|
|
|
|
{
|
2021-11-18 14:19:59 -03:00
|
|
|
return !transformModeUseSnap(t);
|
2018-12-18 11:54:02 +01:00
|
|
|
}
|
|
|
|
|
|
2009-03-28 20:46:38 +00:00
|
|
|
void drawSnapping(const struct bContext *C, TransInfo *t)
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
{
|
2020-04-03 16:21:24 +11:00
|
|
|
uchar col[4], selectedCol[4], activeCol[4];
|
2018-05-13 06:44:03 +02:00
|
|
|
|
2019-04-22 09:19:45 +10:00
|
|
|
if (!activeSnap(t)) {
|
2012-06-29 14:34:46 +00:00
|
|
|
return;
|
2019-04-22 09:19:45 +10:00
|
|
|
}
|
2018-05-13 06:44:03 +02:00
|
|
|
|
2012-06-29 14:34:46 +00:00
|
|
|
if (t->spacetype == SPACE_VIEW3D) {
|
2019-08-23 15:20:25 -03:00
|
|
|
bool draw_target = (t->tsnap.status & TARGET_INIT) &&
|
2021-11-12 15:45:59 -03:00
|
|
|
(t->tsnap.mode & SCE_SNAP_MODE_EDGE_PERPENDICULAR);
|
2019-08-23 15:20:25 -03:00
|
|
|
|
|
|
|
|
if (draw_target || validSnap(t)) {
|
2022-05-03 10:09:22 -03:00
|
|
|
UI_GetThemeColor3ubv(TH_TRANSFORM, col);
|
|
|
|
|
col[3] = 128;
|
|
|
|
|
|
|
|
|
|
UI_GetThemeColor3ubv(TH_SELECT, selectedCol);
|
|
|
|
|
selectedCol[3] = 128;
|
|
|
|
|
|
|
|
|
|
UI_GetThemeColor3ubv(TH_ACTIVE, activeCol);
|
|
|
|
|
activeCol[3] = 192;
|
|
|
|
|
|
2020-05-27 00:14:11 -03:00
|
|
|
const float *loc_cur = NULL;
|
|
|
|
|
const float *loc_prev = NULL;
|
|
|
|
|
const float *normal = NULL;
|
2018-05-13 06:44:03 +02:00
|
|
|
|
2020-08-20 16:38:34 +02:00
|
|
|
GPU_depth_test(GPU_DEPTH_NONE);
|
2018-05-13 06:44:03 +02:00
|
|
|
|
2020-05-27 00:14:11 -03:00
|
|
|
RegionView3D *rv3d = CTX_wm_region_view3d(C);
|
|
|
|
|
if (!BLI_listbase_is_empty(&t->tsnap.points)) {
|
|
|
|
|
/* Draw snap points. */
|
|
|
|
|
|
|
|
|
|
float size = 2.0f * UI_GetThemeValuef(TH_VERTEX_SIZE);
|
|
|
|
|
float view_inv[4][4];
|
|
|
|
|
copy_m4_m4(view_inv, rv3d->viewinv);
|
|
|
|
|
|
|
|
|
|
uint pos = GPU_vertformat_attr_add(
|
|
|
|
|
immVertexFormat(), "pos", GPU_COMP_F32, 3, GPU_FETCH_FLOAT);
|
|
|
|
|
|
|
|
|
|
immBindBuiltinProgram(GPU_SHADER_3D_UNIFORM_COLOR);
|
|
|
|
|
|
|
|
|
|
LISTBASE_FOREACH (TransSnapPoint *, p, &t->tsnap.points) {
|
|
|
|
|
if (p == t->tsnap.selectedPoint) {
|
|
|
|
|
immUniformColor4ubv(selectedCol);
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
immUniformColor4ubv(col);
|
|
|
|
|
}
|
|
|
|
|
imm_drawcircball(p->co, ED_view3d_pixel_size(rv3d, p->co) * size, view_inv, pos);
|
2011-12-26 20:23:07 +00:00
|
|
|
}
|
2018-05-13 06:44:03 +02:00
|
|
|
|
2020-05-27 00:14:11 -03:00
|
|
|
immUnbindProgram();
|
2009-12-01 18:26:18 +00:00
|
|
|
}
|
2018-05-13 06:44:03 +02:00
|
|
|
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
/* draw normal if needed */
|
2012-04-28 06:31:57 +00:00
|
|
|
if (usingSnappingNormal(t) && validSnappingNormal(t)) {
|
2020-05-27 00:14:11 -03:00
|
|
|
normal = t->tsnap.snapNormal;
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
}
|
2017-02-02 03:14:52 -02:00
|
|
|
|
2019-08-23 15:20:25 -03:00
|
|
|
if (draw_target) {
|
2020-05-27 00:14:11 -03:00
|
|
|
loc_prev = t->tsnap.snapTarget;
|
|
|
|
|
}
|
2019-08-23 15:20:25 -03:00
|
|
|
|
2021-11-18 14:19:59 -03:00
|
|
|
if (validSnap(t)) {
|
2020-05-27 00:14:11 -03:00
|
|
|
loc_cur = t->tsnap.snapPoint;
|
2019-08-23 15:20:25 -03:00
|
|
|
}
|
|
|
|
|
|
2021-10-18 00:32:23 -03:00
|
|
|
ED_view3d_cursor_snap_draw_util(
|
2020-05-27 00:14:11 -03:00
|
|
|
rv3d, loc_prev, loc_cur, normal, col, activeCol, t->tsnap.snapElem);
|
2017-02-02 03:14:52 -02:00
|
|
|
|
2020-08-20 16:38:34 +02:00
|
|
|
GPU_depth_test(GPU_DEPTH_LESS_EQUAL);
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
}
|
2012-06-29 14:34:46 +00:00
|
|
|
}
|
|
|
|
|
else if (t->spacetype == SPACE_IMAGE) {
|
|
|
|
|
if (validSnap(t)) {
|
2022-05-03 10:09:22 -03:00
|
|
|
uint pos = GPU_vertformat_attr_add(
|
|
|
|
|
immVertexFormat(), "pos", GPU_COMP_F32, 2, GPU_FETCH_FLOAT);
|
|
|
|
|
|
|
|
|
|
float x, y;
|
|
|
|
|
const float snap_point[2] = {
|
|
|
|
|
t->tsnap.snapPoint[0] / t->aspect[0],
|
|
|
|
|
t->tsnap.snapPoint[1] / t->aspect[1],
|
|
|
|
|
};
|
|
|
|
|
UI_view2d_view_to_region_fl(&t->region->v2d, UNPACK2(snap_point), &x, &y);
|
|
|
|
|
float radius = 2.5f * UI_GetThemeValuef(TH_VERTEX_SIZE) * U.pixelsize;
|
|
|
|
|
|
|
|
|
|
GPU_matrix_push_projection();
|
|
|
|
|
wmOrtho2_region_pixelspace(t->region);
|
|
|
|
|
|
|
|
|
|
immBindBuiltinProgram(GPU_SHADER_2D_UNIFORM_COLOR);
|
|
|
|
|
immUniformColor3ub(255, 255, 255);
|
|
|
|
|
imm_draw_circle_wire_2d(pos, x, y, radius, 8);
|
|
|
|
|
immUnbindProgram();
|
|
|
|
|
|
|
|
|
|
GPU_matrix_pop_projection();
|
2012-06-29 14:34:46 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if (t->spacetype == SPACE_NODE) {
|
|
|
|
|
if (validSnap(t)) {
|
2020-03-06 16:56:42 +01:00
|
|
|
ARegion *region = CTX_wm_region(C);
|
2012-06-29 14:34:46 +00:00
|
|
|
TransSnapPoint *p;
|
|
|
|
|
float size;
|
2018-05-13 06:44:03 +02:00
|
|
|
|
2012-06-29 14:34:46 +00:00
|
|
|
size = 2.5f * UI_GetThemeValuef(TH_VERTEX_SIZE);
|
2018-05-13 06:44:03 +02:00
|
|
|
|
2020-08-16 15:38:34 +02:00
|
|
|
GPU_blend(GPU_BLEND_ALPHA);
|
2018-05-13 06:44:03 +02:00
|
|
|
|
2018-07-18 00:12:21 +02:00
|
|
|
uint pos = GPU_vertformat_attr_add(
|
|
|
|
|
immVertexFormat(), "pos", GPU_COMP_F32, 2, GPU_FETCH_FLOAT);
|
2017-02-02 03:14:52 -02:00
|
|
|
|
2017-02-02 23:17:22 -02:00
|
|
|
immBindBuiltinProgram(GPU_SHADER_2D_UNIFORM_COLOR);
|
2017-02-02 03:14:52 -02:00
|
|
|
|
2012-06-29 14:34:46 +00:00
|
|
|
for (p = t->tsnap.points.first; p; p = p->next) {
|
|
|
|
|
if (p == t->tsnap.selectedPoint) {
|
2017-02-02 03:14:52 -02:00
|
|
|
immUniformColor4ubv(selectedCol);
|
2012-06-29 14:34:46 +00:00
|
|
|
}
|
|
|
|
|
else {
|
2017-02-02 03:14:52 -02:00
|
|
|
immUniformColor4ubv(col);
|
2012-06-29 14:34:46 +00:00
|
|
|
}
|
2018-05-13 06:44:03 +02:00
|
|
|
|
2020-03-06 16:56:42 +01:00
|
|
|
ED_node_draw_snap(®ion->v2d, p->co, size, 0, pos);
|
2012-06-29 14:34:46 +00:00
|
|
|
}
|
2018-05-13 06:44:03 +02:00
|
|
|
|
2012-06-29 14:34:46 +00:00
|
|
|
if (t->tsnap.status & POINT_INIT) {
|
2017-02-02 03:14:52 -02:00
|
|
|
immUniformColor4ubv(activeCol);
|
2018-05-13 06:44:03 +02:00
|
|
|
|
2020-03-06 16:56:42 +01:00
|
|
|
ED_node_draw_snap(®ion->v2d, t->tsnap.snapPoint, size, t->tsnap.snapNodeBorder, pos);
|
2012-06-29 14:34:46 +00:00
|
|
|
}
|
2017-02-02 03:14:52 -02:00
|
|
|
|
|
|
|
|
immUnbindProgram();
|
|
|
|
|
|
2020-08-16 15:38:34 +02:00
|
|
|
GPU_blend(GPU_BLEND_NONE);
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
}
|
|
|
|
|
}
|
2021-06-29 20:12:19 +02:00
|
|
|
else if (t->spacetype == SPACE_SEQ) {
|
|
|
|
|
if (validSnap(t)) {
|
|
|
|
|
const ARegion *region = CTX_wm_region(C);
|
|
|
|
|
GPU_blend(GPU_BLEND_ALPHA);
|
|
|
|
|
uint pos = GPU_vertformat_attr_add(
|
|
|
|
|
immVertexFormat(), "pos", GPU_COMP_F32, 2, GPU_FETCH_FLOAT);
|
|
|
|
|
immBindBuiltinProgram(GPU_SHADER_2D_UNIFORM_COLOR);
|
2021-07-01 22:08:11 +02:00
|
|
|
UI_GetThemeColor3ubv(TH_SEQ_ACTIVE, col);
|
|
|
|
|
col[3] = 128;
|
|
|
|
|
immUniformColor4ubv(col);
|
|
|
|
|
float pixelx = BLI_rctf_size_x(®ion->v2d.cur) / BLI_rcti_size_x(®ion->v2d.mask);
|
|
|
|
|
immRectf(pos,
|
|
|
|
|
t->tsnap.snapPoint[0] - pixelx,
|
|
|
|
|
region->v2d.cur.ymax,
|
|
|
|
|
t->tsnap.snapPoint[0] + pixelx,
|
|
|
|
|
region->v2d.cur.ymin);
|
2021-06-29 20:12:19 +02:00
|
|
|
immUnbindProgram();
|
|
|
|
|
GPU_blend(GPU_BLEND_NONE);
|
|
|
|
|
}
|
|
|
|
|
}
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
}
|
|
|
|
|
|
2013-10-23 06:48:36 +00:00
|
|
|
eRedrawFlag handleSnapping(TransInfo *t, const wmEvent *event)
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
{
|
2013-10-23 06:48:36 +00:00
|
|
|
eRedrawFlag status = TREDRAW_NOTHING;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-11-26 19:47:55 +00:00
|
|
|
#if 0 /* XXX need a proper selector for all snap mode */
|
2022-02-24 22:48:34 +11:00
|
|
|
if (BIF_snappingSupported(t->obedit) && (event->type == EVT_TABKEY) &&
|
|
|
|
|
(event->modifier & KM_SHIFT)) {
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
/* toggle snap and reinit */
|
2009-06-23 00:41:55 +00:00
|
|
|
t->settings->snap_flag ^= SCE_SNAP;
|
2009-03-29 19:52:53 +00:00
|
|
|
initSnapping(t, NULL);
|
2013-10-23 06:48:36 +00:00
|
|
|
status = TREDRAW_HARD;
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
}
|
2009-11-26 19:47:55 +00:00
|
|
|
#endif
|
2012-04-28 06:31:57 +00:00
|
|
|
if (event->type == MOUSEMOVE) {
|
2011-12-26 20:23:07 +00:00
|
|
|
status |= updateSelectedSnapPoint(t);
|
|
|
|
|
}
|
2018-05-13 06:44:03 +02:00
|
|
|
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
return status;
|
|
|
|
|
}
|
|
|
|
|
|
2009-10-22 23:22:05 +00:00
|
|
|
void applyProject(TransInfo *t)
|
|
|
|
|
{
|
2021-06-26 16:57:03 +10:00
|
|
|
if (!activeSnap_with_project(t)) {
|
2021-01-18 10:57:35 -03:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
float tvec[3];
|
|
|
|
|
int i;
|
|
|
|
|
|
2009-10-22 23:22:05 +00:00
|
|
|
/* XXX FLICKER IN OBJECT MODE */
|
2021-01-18 10:57:35 -03:00
|
|
|
FOREACH_TRANS_DATA_CONTAINER (t, tc) {
|
|
|
|
|
TransData *td = tc->data;
|
|
|
|
|
for (i = 0; i < tc->data_len; i++, td++) {
|
|
|
|
|
float iloc[3], loc[3], no[3];
|
|
|
|
|
float mval_fl[2];
|
|
|
|
|
if (td->flag & TD_SKIP) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-01-18 10:57:35 -03:00
|
|
|
if ((t->flag & T_PROP_EDIT) && (td->factor == 0.0f)) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-01-18 10:57:35 -03:00
|
|
|
copy_v3_v3(iloc, td->loc);
|
|
|
|
|
if (tc->use_local_mat) {
|
|
|
|
|
mul_m4_v3(tc->mat, iloc);
|
|
|
|
|
}
|
2021-02-05 11:56:43 -03:00
|
|
|
else if (t->options & CTX_OBJECT) {
|
2021-01-18 10:57:35 -03:00
|
|
|
BKE_object_eval_transform_all(t->depsgraph, t->scene, td->ob);
|
|
|
|
|
copy_v3_v3(iloc, td->ob->obmat[3]);
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-01-18 10:57:35 -03:00
|
|
|
if (ED_view3d_project_float_global(t->region, iloc, mval_fl, V3D_PROJ_TEST_NOP) ==
|
|
|
|
|
V3D_PROJ_RET_OK) {
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
eSnapMode hit = ED_transform_snap_object_project_view3d(
|
|
|
|
|
t->tsnap.object_context,
|
|
|
|
|
t->depsgraph,
|
|
|
|
|
t->region,
|
|
|
|
|
t->view,
|
|
|
|
|
SCE_SNAP_MODE_FACE,
|
|
|
|
|
&(const struct SnapObjectParams){
|
|
|
|
|
.snap_target_select = t->tsnap.target_select,
|
|
|
|
|
.edit_mode_type = (t->flag & T_EDIT) != 0 ? SNAP_GEOM_EDIT : SNAP_GEOM_FINAL,
|
|
|
|
|
.use_occlusion_test = false,
|
|
|
|
|
.use_backface_culling = t->tsnap.use_backface_culling,
|
|
|
|
|
},
|
|
|
|
|
mval_fl,
|
|
|
|
|
NULL,
|
|
|
|
|
0,
|
|
|
|
|
loc,
|
|
|
|
|
no);
|
|
|
|
|
if (hit != SCE_SNAP_MODE_FACE) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-16 17:54:33 +02:00
|
|
|
#if 0
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
if (tc->use_local_mat) {
|
|
|
|
|
mul_m4_v3(tc->imat, loc);
|
|
|
|
|
}
|
2018-04-16 17:54:33 +02:00
|
|
|
#endif
|
|
|
|
|
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
sub_v3_v3v3(tvec, loc, iloc);
|
2018-04-16 17:54:33 +02:00
|
|
|
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
mul_m3_v3(td->smtx, tvec);
|
2018-04-16 17:54:33 +02:00
|
|
|
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
add_v3_v3(td->loc, tvec);
|
2014-07-31 17:02:03 +02:00
|
|
|
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
if (t->tsnap.align && (t->options & CTX_OBJECT)) {
|
|
|
|
|
/* handle alignment as well */
|
|
|
|
|
const float *original_normal;
|
|
|
|
|
float mat[3][3];
|
2014-07-31 17:02:03 +02:00
|
|
|
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
/* In pose mode, we want to align normals with Y axis of bones... */
|
|
|
|
|
original_normal = td->axismtx[2];
|
2018-04-16 17:54:33 +02:00
|
|
|
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
rotation_between_vecs_to_mat3(mat, original_normal, no);
|
2018-04-16 17:54:33 +02:00
|
|
|
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
transform_data_ext_rotate(td, mat, true);
|
2018-04-16 17:54:33 +02:00
|
|
|
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
/* TODO: support constraints for rotation too? see #ElementRotation. */
|
2012-10-05 03:20:14 +00:00
|
|
|
}
|
2021-01-18 10:57:35 -03:00
|
|
|
}
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
}
|
2018-04-16 17:54:33 +02:00
|
|
|
|
2021-02-05 16:23:34 +11:00
|
|
|
#if 0 /* TODO: support this? */
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
constraintTransLim(t, td);
|
2020-10-10 18:19:55 +11:00
|
|
|
#endif
|
2009-10-22 23:22:05 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2013-11-06 17:46:32 +00:00
|
|
|
void applyGridAbsolute(TransInfo *t)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-22 09:19:45 +10:00
|
|
|
if (!(activeSnap(t) && (t->tsnap.mode & (SCE_SNAP_MODE_INCREMENT | SCE_SNAP_MODE_GRID)))) {
|
2013-11-06 17:46:32 +00:00
|
|
|
return;
|
2019-04-22 09:19:45 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-10-08 09:45:45 -03:00
|
|
|
float grid_size = (t->modifiers & MOD_PRECISION) ? t->snap_spatial[1] : t->snap_spatial[0];
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-11-06 17:46:32 +00:00
|
|
|
/* early exit on unusable grid size */
|
2019-04-22 09:19:45 +10:00
|
|
|
if (grid_size == 0.0f) {
|
2013-11-06 17:46:32 +00:00
|
|
|
return;
|
2019-04-22 09:19:45 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-21 04:40:16 +10:00
|
|
|
FOREACH_TRANS_DATA_CONTAINER (t, tc) {
|
2018-04-16 17:54:33 +02:00
|
|
|
TransData *td;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-04-16 17:54:33 +02:00
|
|
|
for (i = 0, td = tc->data; i < tc->data_len; i++, td++) {
|
|
|
|
|
float iloc[3], loc[3], tvec[3];
|
2019-04-22 09:19:45 +10:00
|
|
|
if (td->flag & TD_SKIP) {
|
2018-04-16 17:54:33 +02:00
|
|
|
continue;
|
2019-04-22 09:19:45 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-22 09:19:45 +10:00
|
|
|
if ((t->flag & T_PROP_EDIT) && (td->factor == 0.0f)) {
|
2018-04-16 17:54:33 +02:00
|
|
|
continue;
|
2019-04-22 09:19:45 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-04-16 17:54:33 +02:00
|
|
|
copy_v3_v3(iloc, td->loc);
|
2018-05-04 14:41:51 +02:00
|
|
|
if (tc->use_local_mat) {
|
|
|
|
|
mul_m4_v3(tc->mat, iloc);
|
2018-04-16 17:54:33 +02:00
|
|
|
}
|
2021-02-05 11:56:43 -03:00
|
|
|
else if (t->options & CTX_OBJECT) {
|
2018-04-06 12:07:27 +02:00
|
|
|
BKE_object_eval_transform_all(t->depsgraph, t->scene, td->ob);
|
2018-04-16 17:54:33 +02:00
|
|
|
copy_v3_v3(iloc, td->ob->obmat[3]);
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-04-16 17:54:33 +02:00
|
|
|
mul_v3_v3fl(loc, iloc, 1.0f / grid_size);
|
|
|
|
|
loc[0] = roundf(loc[0]);
|
|
|
|
|
loc[1] = roundf(loc[1]);
|
|
|
|
|
loc[2] = roundf(loc[2]);
|
|
|
|
|
mul_v3_fl(loc, grid_size);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-04-16 17:54:33 +02:00
|
|
|
sub_v3_v3v3(tvec, loc, iloc);
|
|
|
|
|
mul_m3_v3(td->smtx, tvec);
|
|
|
|
|
add_v3_v3(td->loc, tvec);
|
2013-11-06 17:46:32 +00:00
|
|
|
}
|
2018-04-16 16:27:55 +02:00
|
|
|
}
|
2013-11-06 17:46:32 +00:00
|
|
|
}
|
|
|
|
|
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
void applySnapping(TransInfo *t, float *vec)
|
|
|
|
|
{
|
2021-11-18 14:19:59 -03:00
|
|
|
/* Each Trans Data already makes the snap to face */
|
|
|
|
|
if (doForceIncrementSnap(t)) {
|
2020-08-31 10:14:40 -03:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (t->tsnap.project && t->tsnap.mode == SCE_SNAP_MODE_FACE) {
|
2021-11-12 15:53:36 -03:00
|
|
|
/* A similar snap will be applied to each transdata in `applyProject`. */
|
2018-06-04 13:33:19 -03:00
|
|
|
return;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-04-28 06:31:57 +00:00
|
|
|
if (t->tsnap.status & SNAP_FORCED) {
|
2009-03-29 19:52:53 +00:00
|
|
|
t->tsnap.targetSnap(t);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-03-29 19:52:53 +00:00
|
|
|
t->tsnap.applySnap(t, vec);
|
|
|
|
|
}
|
2018-05-22 15:30:26 +02:00
|
|
|
else if (((t->tsnap.mode & ~(SCE_SNAP_MODE_INCREMENT | SCE_SNAP_MODE_GRID)) != 0) &&
|
|
|
|
|
activeSnap(t)) {
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
double current = PIL_check_seconds_timer();
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-02-13 17:44:51 +11:00
|
|
|
/* Time base quirky code to go around find-nearest slowness. */
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
/* TODO: add exception for object mode, no need to slow it down then. */
|
2012-05-20 19:49:27 +00:00
|
|
|
if (current - t->tsnap.last >= 0.01) {
|
2021-12-16 13:45:27 -03:00
|
|
|
if (t->tsnap.calcSnap) {
|
|
|
|
|
t->tsnap.calcSnap(t, vec);
|
|
|
|
|
}
|
2021-06-29 20:12:19 +02:00
|
|
|
if (t->tsnap.targetSnap) {
|
|
|
|
|
t->tsnap.targetSnap(t);
|
|
|
|
|
}
|
|
|
|
|
|
2021-12-22 16:11:05 -03:00
|
|
|
t->tsnap.last = current;
|
|
|
|
|
}
|
2021-06-29 20:12:19 +02:00
|
|
|
|
2021-06-29 18:08:41 -03:00
|
|
|
if (validSnap(t)) {
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
t->tsnap.applySnap(t, vec);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void resetSnapping(TransInfo *t)
|
|
|
|
|
{
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
t->tsnap.status = SNAP_RESETTED;
|
|
|
|
|
t->tsnap.snapElem = SCE_SNAP_MODE_NONE;
|
2013-04-04 09:20:46 +00:00
|
|
|
t->tsnap.align = false;
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
t->tsnap.project = false;
|
|
|
|
|
t->tsnap.mode = SCE_SNAP_MODE_NONE;
|
|
|
|
|
t->tsnap.target_select = SCE_SNAP_TARGET_ALL;
|
|
|
|
|
t->tsnap.source_select = SCE_SNAP_SOURCE_CLOSEST;
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
t->tsnap.last = 0;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
t->tsnap.snapNormal[0] = 0;
|
|
|
|
|
t->tsnap.snapNormal[1] = 0;
|
|
|
|
|
t->tsnap.snapNormal[2] = 0;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-29 14:34:46 +00:00
|
|
|
t->tsnap.snapNodeBorder = 0;
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
}
|
|
|
|
|
|
2018-07-09 17:57:05 +02:00
|
|
|
bool usingSnappingNormal(const TransInfo *t)
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
{
|
2009-03-29 19:52:53 +00:00
|
|
|
return t->tsnap.align;
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
}
|
|
|
|
|
|
2018-07-09 17:57:05 +02:00
|
|
|
bool validSnappingNormal(const TransInfo *t)
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
{
|
2012-04-28 06:31:57 +00:00
|
|
|
if (validSnap(t)) {
|
2014-03-29 22:23:27 +11:00
|
|
|
if (!is_zero_v3(t->tsnap.snapNormal)) {
|
2013-04-04 09:20:46 +00:00
|
|
|
return true;
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
}
|
|
|
|
|
}
|
2018-05-13 06:44:03 +02:00
|
|
|
|
2013-04-04 09:20:46 +00:00
|
|
|
return false;
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
}
|
|
|
|
|
|
2016-05-06 07:44:07 +10:00
|
|
|
static bool bm_edge_is_snap_target(BMEdge *e, void *UNUSED(user_data))
|
|
|
|
|
{
|
|
|
|
|
if (BM_elem_flag_test(e, BM_ELEM_SELECT | BM_ELEM_HIDDEN) ||
|
|
|
|
|
BM_elem_flag_test(e->v1, BM_ELEM_SELECT) || BM_elem_flag_test(e->v2, BM_ELEM_SELECT)) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2016-05-06 07:44:07 +10:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool bm_face_is_snap_target(BMFace *f, void *UNUSED(user_data))
|
|
|
|
|
{
|
|
|
|
|
if (BM_elem_flag_test(f, BM_ELEM_SELECT | BM_ELEM_HIDDEN)) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2016-05-06 07:44:07 +10:00
|
|
|
BMLoop *l_iter, *l_first;
|
|
|
|
|
l_iter = l_first = BM_FACE_FIRST_LOOP(f);
|
|
|
|
|
do {
|
|
|
|
|
if (BM_elem_flag_test(l_iter->v, BM_ELEM_SELECT)) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
} while ((l_iter = l_iter->next) != l_first);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2016-05-06 07:44:07 +10:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
static eSnapFlag snap_flag_from_spacetype(TransInfo *t)
|
2022-03-10 18:33:04 -03:00
|
|
|
{
|
|
|
|
|
ToolSettings *ts = t->settings;
|
|
|
|
|
if (t->spacetype == SPACE_NODE) {
|
|
|
|
|
return ts->snap_flag_node;
|
|
|
|
|
}
|
2022-03-23 23:24:54 -05:00
|
|
|
if (t->spacetype == SPACE_IMAGE) {
|
2022-03-10 18:33:04 -03:00
|
|
|
return ts->snap_uv_flag;
|
|
|
|
|
}
|
2022-03-23 23:24:54 -05:00
|
|
|
if (t->spacetype == SPACE_SEQ) {
|
2022-03-10 18:33:04 -03:00
|
|
|
return ts->snap_flag_seq;
|
|
|
|
|
}
|
|
|
|
|
return ts->snap_flag;
|
|
|
|
|
}
|
|
|
|
|
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
static eSnapMode snap_mode_from_spacetype(TransInfo *t)
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
{
|
2009-06-23 00:41:55 +00:00
|
|
|
ToolSettings *ts = t->settings;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-29 14:34:46 +00:00
|
|
|
if (t->spacetype == SPACE_NODE) {
|
2022-03-28 13:01:08 -03:00
|
|
|
return ts->snap_node_mode;
|
2012-06-29 14:34:46 +00:00
|
|
|
}
|
2022-03-28 13:01:08 -03:00
|
|
|
|
|
|
|
|
if (t->spacetype == SPACE_IMAGE) {
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
eSnapMode snap_mode = ts->snap_uv_mode;
|
2022-03-28 13:01:08 -03:00
|
|
|
if ((snap_mode & SCE_SNAP_MODE_INCREMENT) && (ts->snap_uv_flag & SCE_SNAP_ABS_GRID) &&
|
2021-09-29 17:47:32 +10:00
|
|
|
(t->mode == TFM_TRANSLATION)) {
|
2022-03-28 13:01:08 -03:00
|
|
|
snap_mode &= ~SCE_SNAP_MODE_INCREMENT;
|
|
|
|
|
snap_mode |= SCE_SNAP_MODE_GRID;
|
2021-09-29 17:47:32 +10:00
|
|
|
}
|
2022-03-28 13:01:08 -03:00
|
|
|
return snap_mode;
|
2012-12-03 12:03:16 +00:00
|
|
|
}
|
2022-03-28 13:01:08 -03:00
|
|
|
|
|
|
|
|
if (t->spacetype == SPACE_SEQ) {
|
|
|
|
|
return SEQ_tool_settings_snap_mode_get(t->scene);
|
2021-06-29 20:12:19 +02:00
|
|
|
}
|
2022-03-28 13:01:08 -03:00
|
|
|
|
2022-03-28 13:40:28 -03:00
|
|
|
if (t->spacetype == SPACE_VIEW3D) {
|
|
|
|
|
if (t->options & (CTX_CAMERA | CTX_EDGE_DATA | CTX_PAINT_CURVE)) {
|
|
|
|
|
return SCE_SNAP_MODE_INCREMENT;
|
2020-08-31 10:14:40 -03:00
|
|
|
}
|
2022-03-28 13:40:28 -03:00
|
|
|
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
eSnapMode snap_mode = ts->snap_mode;
|
2022-03-28 13:40:28 -03:00
|
|
|
if ((snap_mode & SCE_SNAP_MODE_INCREMENT) && (ts->snap_flag & SCE_SNAP_ABS_GRID) &&
|
|
|
|
|
(t->mode == TFM_TRANSLATION)) {
|
|
|
|
|
/* Special case in which snap to increments is transformed to snap to grid. */
|
|
|
|
|
snap_mode &= ~SCE_SNAP_MODE_INCREMENT;
|
|
|
|
|
snap_mode |= SCE_SNAP_MODE_GRID;
|
|
|
|
|
}
|
|
|
|
|
return snap_mode;
|
2009-03-29 19:52:53 +00:00
|
|
|
}
|
2022-03-28 13:01:08 -03:00
|
|
|
|
|
|
|
|
if (ELEM(t->spacetype, SPACE_ACTION, SPACE_NLA)) {
|
2021-08-18 11:02:24 -03:00
|
|
|
/* No incremental snapping. */
|
2022-03-28 13:01:08 -03:00
|
|
|
return 0;
|
2021-08-18 11:02:24 -03:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-03-28 13:01:08 -03:00
|
|
|
return SCE_SNAP_MODE_INCREMENT;
|
2021-11-12 16:22:10 -03:00
|
|
|
}
|
2020-06-18 09:08:27 -03:00
|
|
|
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
static eSnapTargetSelect snap_select_type_get(TransInfo *t)
|
2021-11-12 16:22:10 -03:00
|
|
|
{
|
|
|
|
|
ViewLayer *view_layer = t->view_layer;
|
|
|
|
|
Base *base_act = view_layer->basact;
|
|
|
|
|
if (ELEM(t->spacetype, SPACE_VIEW3D, SPACE_IMAGE) && !(t->options & CTX_CAMERA)) {
|
2021-08-06 11:44:15 -03:00
|
|
|
if (t->options & (CTX_GPENCIL_STROKES | CTX_CURSOR | CTX_OBMODE_XFORM_OBDATA)) {
|
|
|
|
|
/* In "Edit Strokes" mode,
|
|
|
|
|
* snap tool can perform snap to selected or active objects (see T49632)
|
|
|
|
|
* TODO: perform self snap in gpencil_strokes.
|
|
|
|
|
*
|
|
|
|
|
* When we're moving the origins, allow snapping onto our own geometry (see T69132). */
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
return SCE_SNAP_TARGET_ALL;
|
2021-08-06 11:44:15 -03:00
|
|
|
}
|
2022-03-28 13:01:08 -03:00
|
|
|
|
|
|
|
|
const int obedit_type = t->obedit_type;
|
|
|
|
|
if (obedit_type != -1) {
|
2020-06-18 09:08:27 -03:00
|
|
|
/* Edit mode */
|
2022-04-25 12:31:13 -03:00
|
|
|
if (ELEM(obedit_type,
|
|
|
|
|
OB_MESH,
|
|
|
|
|
OB_ARMATURE,
|
|
|
|
|
OB_CURVES_LEGACY,
|
|
|
|
|
OB_SURF,
|
|
|
|
|
OB_LATTICE,
|
|
|
|
|
OB_MBALL)) {
|
2022-03-28 13:01:08 -03:00
|
|
|
/* Temporary limited to edit mode meshes, armature, curves, lattice and metaballs. */
|
2020-06-18 09:08:27 -03:00
|
|
|
|
2022-03-28 13:01:08 -03:00
|
|
|
if ((obedit_type == OB_MESH) && (t->flag & T_PROP_EDIT)) {
|
|
|
|
|
/* Exclude editmesh if using proportional edit */
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
return SCE_SNAP_TARGET_NOT_EDITED;
|
2022-03-28 13:01:08 -03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!t->tsnap.snap_self) {
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
return SCE_SNAP_TARGET_NOT_ACTIVE;
|
2022-03-28 13:01:08 -03:00
|
|
|
}
|
|
|
|
|
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
return SCE_SNAP_TARGET_NOT_SELECTED;
|
2022-02-12 16:13:28 -03:00
|
|
|
}
|
2022-03-28 13:01:08 -03:00
|
|
|
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
return SCE_SNAP_TARGET_ALL;
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
2022-03-28 13:01:08 -03:00
|
|
|
|
|
|
|
|
if (base_act && (base_act->object->mode & OB_MODE_PARTICLE_EDIT)) {
|
2020-06-18 09:08:27 -03:00
|
|
|
/* Particles edit mode. */
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
return SCE_SNAP_TARGET_ALL;
|
2009-11-01 00:06:53 +00:00
|
|
|
}
|
2022-03-28 13:01:08 -03:00
|
|
|
|
|
|
|
|
/* Object or pose mode. */
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
return SCE_SNAP_TARGET_NOT_SELECTED;
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
2022-03-28 13:01:08 -03:00
|
|
|
|
|
|
|
|
if (ELEM(t->spacetype, SPACE_NODE, SPACE_SEQ)) {
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
return SCE_SNAP_TARGET_NOT_SELECTED;
|
2021-11-12 16:22:10 -03:00
|
|
|
}
|
|
|
|
|
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
return SCE_SNAP_TARGET_ALL;
|
2021-11-12 16:22:10 -03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void initSnappingMode(TransInfo *t)
|
|
|
|
|
{
|
|
|
|
|
ToolSettings *ts = t->settings;
|
2022-03-10 18:33:04 -03:00
|
|
|
t->tsnap.mode = snap_mode_from_spacetype(t);
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
t->tsnap.target_select = snap_select_type_get(t);
|
2021-11-12 16:22:10 -03:00
|
|
|
|
|
|
|
|
if ((t->spacetype != SPACE_VIEW3D) || !(ts->snap_mode & SCE_SNAP_MODE_FACE)) {
|
|
|
|
|
/* Force project off when not supported. */
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
t->tsnap.project = false;
|
2021-11-12 16:22:10 -03:00
|
|
|
}
|
|
|
|
|
|
2021-11-18 14:19:59 -03:00
|
|
|
if (ELEM(t->spacetype, SPACE_VIEW3D, SPACE_IMAGE, SPACE_NODE, SPACE_SEQ)) {
|
|
|
|
|
/* Not with camera selected in camera view. */
|
|
|
|
|
if (!(t->options & CTX_CAMERA)) {
|
|
|
|
|
setSnappingCallback(t);
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2016-05-09 15:21:53 +10:00
|
|
|
if (t->spacetype == SPACE_VIEW3D) {
|
|
|
|
|
if (t->tsnap.object_context == NULL) {
|
2020-07-22 12:00:02 -03:00
|
|
|
t->tsnap.use_backface_culling = snap_use_backface_culling(t);
|
2021-10-12 17:05:56 -03:00
|
|
|
t->tsnap.object_context = ED_transform_snap_object_context_create(t->scene, 0);
|
2021-11-18 14:19:59 -03:00
|
|
|
|
|
|
|
|
if (t->data_type == TC_MESH_VERTS) {
|
|
|
|
|
/* Ignore elements being transformed. */
|
|
|
|
|
ED_transform_snap_object_context_set_editmesh_callbacks(
|
|
|
|
|
t->tsnap.object_context,
|
|
|
|
|
(bool (*)(BMVert *, void *))BM_elem_cb_check_hflag_disabled,
|
|
|
|
|
bm_edge_is_snap_target,
|
|
|
|
|
bm_face_is_snap_target,
|
|
|
|
|
POINTER_FROM_UINT((BM_ELEM_SELECT | BM_ELEM_HIDDEN)));
|
|
|
|
|
}
|
2022-01-03 11:51:41 -03:00
|
|
|
else {
|
|
|
|
|
/* Ignore hidden geometry in the general case. */
|
|
|
|
|
ED_transform_snap_object_context_set_editmesh_callbacks(
|
|
|
|
|
t->tsnap.object_context,
|
|
|
|
|
(bool (*)(BMVert *, void *))BM_elem_cb_check_hflag_disabled,
|
|
|
|
|
(bool (*)(BMEdge *, void *))BM_elem_cb_check_hflag_disabled,
|
|
|
|
|
(bool (*)(BMFace *, void *))BM_elem_cb_check_hflag_disabled,
|
|
|
|
|
POINTER_FROM_UINT(BM_ELEM_HIDDEN));
|
|
|
|
|
}
|
2016-04-21 11:29:32 +10:00
|
|
|
}
|
|
|
|
|
}
|
2021-06-29 20:12:19 +02:00
|
|
|
else if (t->spacetype == SPACE_SEQ) {
|
|
|
|
|
if (t->tsnap.seq_context == NULL) {
|
|
|
|
|
t->tsnap.seq_context = transform_snap_sequencer_data_alloc(t);
|
|
|
|
|
}
|
|
|
|
|
}
|
2009-12-03 19:18:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void initSnapping(TransInfo *t, wmOperator *op)
|
|
|
|
|
{
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
resetSnapping(t);
|
2022-03-10 18:33:04 -03:00
|
|
|
t->tsnap.flag = snap_flag_from_spacetype(t);
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
eSnapSourceSelect snap_source = t->settings->snap_target;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-11-27 16:15:34 +00:00
|
|
|
/* if snap property exists */
|
2021-12-08 13:56:13 -03:00
|
|
|
PropertyRNA *prop;
|
|
|
|
|
if (op && (prop = RNA_struct_find_property(op->ptr, "snap")) &&
|
|
|
|
|
RNA_property_is_set(op->ptr, prop)) {
|
|
|
|
|
if (RNA_property_boolean_get(op->ptr, prop)) {
|
2009-11-27 16:15:34 +00:00
|
|
|
t->modifiers |= MOD_SNAP;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-12-08 13:56:13 -03:00
|
|
|
if ((prop = RNA_struct_find_property(op->ptr, "snap_target")) &&
|
|
|
|
|
RNA_property_is_set(op->ptr, prop)) {
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
/* TODO(@gfxcoder): Rename `snap_target` to `snap_source` to avoid
|
|
|
|
|
* previous ambiguity of "target" (now, "source" is geometry to be moved and "target" is
|
|
|
|
|
* geometry to which moved geometry is snapped). */
|
|
|
|
|
snap_source = RNA_property_enum_get(op->ptr, prop);
|
2009-11-27 16:15:34 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-12-08 13:56:13 -03:00
|
|
|
if ((prop = RNA_struct_find_property(op->ptr, "snap_point")) &&
|
|
|
|
|
RNA_property_is_set(op->ptr, prop)) {
|
|
|
|
|
RNA_property_float_get_array(op->ptr, prop, t->tsnap.snapPoint);
|
2012-06-10 22:13:17 +00:00
|
|
|
t->tsnap.status |= SNAP_FORCED | POINT_INIT;
|
2009-11-27 16:15:34 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-03-29 19:52:53 +00:00
|
|
|
/* snap align only defined in specific cases */
|
2021-12-08 13:56:13 -03:00
|
|
|
if ((prop = RNA_struct_find_property(op->ptr, "snap_align")) &&
|
|
|
|
|
RNA_property_is_set(op->ptr, prop)) {
|
|
|
|
|
t->tsnap.align = RNA_property_boolean_get(op->ptr, prop);
|
2009-03-29 19:52:53 +00:00
|
|
|
RNA_float_get_array(op->ptr, "snap_normal", t->tsnap.snapNormal);
|
2009-11-10 20:43:45 +00:00
|
|
|
normalize_v3(t->tsnap.snapNormal);
|
2009-03-29 19:52:53 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-12-08 13:56:13 -03:00
|
|
|
if ((prop = RNA_struct_find_property(op->ptr, "use_snap_project")) &&
|
|
|
|
|
RNA_property_is_set(op->ptr, prop)) {
|
|
|
|
|
t->tsnap.project = RNA_property_boolean_get(op->ptr, prop);
|
2009-10-12 22:33:32 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-12-08 13:56:13 -03:00
|
|
|
if ((prop = RNA_struct_find_property(op->ptr, "use_snap_self")) &&
|
|
|
|
|
RNA_property_is_set(op->ptr, prop)) {
|
|
|
|
|
t->tsnap.snap_self = RNA_property_boolean_get(op->ptr, prop);
|
2011-06-17 13:02:23 +00:00
|
|
|
}
|
2009-03-29 19:52:53 +00:00
|
|
|
}
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
}
|
2009-11-27 16:15:34 +00:00
|
|
|
/* use scene defaults only when transform is modal */
|
2012-03-07 04:53:43 +00:00
|
|
|
else if (t->flag & T_MODAL) {
|
2022-03-10 18:33:04 -03:00
|
|
|
if (transformModeUseSnap(t) && (t->tsnap.flag & SCE_SNAP)) {
|
2021-06-29 20:12:19 +02:00
|
|
|
t->modifiers |= MOD_SNAP;
|
|
|
|
|
}
|
2022-03-10 18:33:04 -03:00
|
|
|
|
|
|
|
|
t->tsnap.align = ((t->tsnap.flag & SCE_SNAP_ROTATE) != 0);
|
|
|
|
|
t->tsnap.project = ((t->tsnap.flag & SCE_SNAP_PROJECT) != 0);
|
|
|
|
|
t->tsnap.snap_self = !((t->tsnap.flag & SCE_SNAP_NO_SELF) != 0);
|
|
|
|
|
t->tsnap.peel = ((t->tsnap.flag & SCE_SNAP_PROJECT) != 0);
|
2009-10-12 22:33:32 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
t->tsnap.source_select = snap_source;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-12-03 19:18:00 +00:00
|
|
|
initSnappingMode(t);
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
}
|
|
|
|
|
|
2016-04-21 11:29:32 +10:00
|
|
|
void freeSnapping(TransInfo *t)
|
|
|
|
|
{
|
2021-06-29 20:12:19 +02:00
|
|
|
if ((t->spacetype == SPACE_SEQ) && t->tsnap.seq_context) {
|
|
|
|
|
transform_snap_sequencer_data_free(t->tsnap.seq_context);
|
|
|
|
|
t->tsnap.seq_context = NULL;
|
|
|
|
|
}
|
|
|
|
|
else if (t->tsnap.object_context) {
|
2016-04-21 11:29:32 +10:00
|
|
|
ED_transform_snap_object_context_destroy(t->tsnap.object_context);
|
|
|
|
|
t->tsnap.object_context = NULL;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2011-11-15 16:38:48 +00:00
|
|
|
static void setSnappingCallback(TransInfo *t)
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
{
|
2021-06-29 17:38:34 -03:00
|
|
|
if (t->spacetype == SPACE_VIEW3D) {
|
|
|
|
|
t->tsnap.calcSnap = snap_calc_view3d_fn;
|
|
|
|
|
}
|
2021-12-16 13:45:27 -03:00
|
|
|
else if (t->spacetype == SPACE_IMAGE) {
|
|
|
|
|
SpaceImage *sima = t->area->spacedata.first;
|
|
|
|
|
Object *obact = t->view_layer->basact ? t->view_layer->basact->object : NULL;
|
|
|
|
|
|
|
|
|
|
const bool is_uv_editor = sima->mode == SI_MODE_UV;
|
|
|
|
|
const bool has_edit_object = obact && BKE_object_is_in_editmode(obact);
|
|
|
|
|
if (is_uv_editor && has_edit_object) {
|
|
|
|
|
t->tsnap.calcSnap = snap_calc_uv_fn;
|
|
|
|
|
}
|
2021-06-29 17:38:34 -03:00
|
|
|
}
|
|
|
|
|
else if (t->spacetype == SPACE_NODE) {
|
|
|
|
|
t->tsnap.calcSnap = snap_calc_node_fn;
|
|
|
|
|
}
|
|
|
|
|
else if (t->spacetype == SPACE_SEQ) {
|
|
|
|
|
t->tsnap.calcSnap = snap_calc_sequencer_fn;
|
2021-06-29 20:12:19 +02:00
|
|
|
/* The target is calculated along with the snap point. */
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
switch (t->tsnap.source_select) {
|
|
|
|
|
case SCE_SNAP_SOURCE_CLOSEST:
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
t->tsnap.targetSnap = TargetSnapClosest;
|
|
|
|
|
break;
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
case SCE_SNAP_SOURCE_CENTER:
|
2020-06-19 09:44:57 +10:00
|
|
|
if (!ELEM(t->mode, TFM_ROTATION, TFM_RESIZE)) {
|
2020-06-18 09:08:27 -03:00
|
|
|
t->tsnap.targetSnap = TargetSnapCenter;
|
|
|
|
|
break;
|
|
|
|
|
}
|
2020-06-19 09:44:57 +10:00
|
|
|
/* Can't do TARGET_CENTER with these modes,
|
|
|
|
|
* use TARGET_MEDIAN instead. */
|
|
|
|
|
ATTR_FALLTHROUGH;
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
case SCE_SNAP_SOURCE_MEDIAN:
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
t->tsnap.targetSnap = TargetSnapMedian;
|
|
|
|
|
break;
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
case SCE_SNAP_SOURCE_ACTIVE:
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
t->tsnap.targetSnap = TargetSnapActive;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-01 18:26:18 +00:00
|
|
|
void addSnapPoint(TransInfo *t)
|
|
|
|
|
{
|
2014-07-28 17:10:33 +06:00
|
|
|
/* Currently only 3D viewport works for snapping points. */
|
|
|
|
|
if (t->tsnap.status & POINT_INIT && t->spacetype == SPACE_VIEW3D) {
|
2009-12-01 18:26:18 +00:00
|
|
|
TransSnapPoint *p = MEM_callocN(sizeof(TransSnapPoint), "SnapPoint");
|
|
|
|
|
|
2011-12-26 20:23:07 +00:00
|
|
|
t->tsnap.selectedPoint = p;
|
|
|
|
|
|
2011-09-12 04:14:12 +00:00
|
|
|
copy_v3_v3(p->co, t->tsnap.snapPoint);
|
2009-12-01 18:26:18 +00:00
|
|
|
|
|
|
|
|
BLI_addtail(&t->tsnap.points, p);
|
|
|
|
|
|
|
|
|
|
t->tsnap.status |= MULTI_POINTS;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2013-10-23 06:48:36 +00:00
|
|
|
eRedrawFlag updateSelectedSnapPoint(TransInfo *t)
|
2011-12-26 20:23:07 +00:00
|
|
|
{
|
2013-10-23 06:48:36 +00:00
|
|
|
eRedrawFlag status = TREDRAW_NOTHING;
|
|
|
|
|
|
2011-12-26 20:23:07 +00:00
|
|
|
if (t->tsnap.status & MULTI_POINTS) {
|
|
|
|
|
TransSnapPoint *p, *closest_p = NULL;
|
2014-02-03 02:46:45 +11:00
|
|
|
float dist_min_sq = TRANSFORM_SNAP_MAX_PX;
|
2013-04-03 07:36:37 +00:00
|
|
|
const float mval_fl[2] = {t->mval[0], t->mval[1]};
|
|
|
|
|
float screen_loc[2];
|
2011-12-26 20:23:07 +00:00
|
|
|
|
2012-06-10 22:13:17 +00:00
|
|
|
for (p = t->tsnap.points.first; p; p = p->next) {
|
2014-02-03 02:46:45 +11:00
|
|
|
float dist_sq;
|
2011-12-26 20:23:07 +00:00
|
|
|
|
2020-03-06 16:56:42 +01:00
|
|
|
if (ED_view3d_project_float_global(t->region, p->co, screen_loc, V3D_PROJ_TEST_NOP) !=
|
2013-04-03 07:36:37 +00:00
|
|
|
V3D_PROJ_RET_OK) {
|
2012-10-04 17:52:12 +00:00
|
|
|
continue;
|
|
|
|
|
}
|
2011-12-26 20:23:07 +00:00
|
|
|
|
2014-02-03 02:46:45 +11:00
|
|
|
dist_sq = len_squared_v2v2(mval_fl, screen_loc);
|
2011-12-26 20:23:07 +00:00
|
|
|
|
2014-02-03 02:46:45 +11:00
|
|
|
if (dist_sq < dist_min_sq) {
|
2011-12-26 20:23:07 +00:00
|
|
|
closest_p = p;
|
2014-02-03 02:46:45 +11:00
|
|
|
dist_min_sq = dist_sq;
|
2011-12-26 20:23:07 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (closest_p) {
|
2013-10-23 06:48:36 +00:00
|
|
|
if (t->tsnap.selectedPoint != closest_p) {
|
|
|
|
|
status = TREDRAW_HARD;
|
|
|
|
|
}
|
|
|
|
|
|
2011-12-26 20:23:07 +00:00
|
|
|
t->tsnap.selectedPoint = closest_p;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return status;
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-01 18:26:18 +00:00
|
|
|
void removeSnapPoint(TransInfo *t)
|
|
|
|
|
{
|
|
|
|
|
if (t->tsnap.status & MULTI_POINTS) {
|
2011-12-26 20:23:07 +00:00
|
|
|
updateSelectedSnapPoint(t);
|
|
|
|
|
|
2014-02-08 06:07:10 +11:00
|
|
|
if (t->tsnap.selectedPoint) {
|
2011-12-26 20:23:07 +00:00
|
|
|
BLI_freelinkN(&t->tsnap.points, t->tsnap.selectedPoint);
|
|
|
|
|
|
|
|
|
|
if (BLI_listbase_is_empty(&t->tsnap.points)) {
|
|
|
|
|
t->tsnap.status &= ~MULTI_POINTS;
|
|
|
|
|
}
|
2009-12-01 18:26:18 +00:00
|
|
|
|
2011-12-26 20:23:07 +00:00
|
|
|
t->tsnap.selectedPoint = NULL;
|
2009-12-01 18:26:18 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
2009-12-01 18:26:18 +00:00
|
|
|
}
|
|
|
|
|
|
2018-07-09 17:57:05 +02:00
|
|
|
void getSnapPoint(const TransInfo *t, float vec[3])
|
2009-12-01 18:26:18 +00:00
|
|
|
{
|
|
|
|
|
if (t->tsnap.points.first) {
|
|
|
|
|
TransSnapPoint *p;
|
|
|
|
|
int total = 0;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-12-01 18:26:18 +00:00
|
|
|
vec[0] = vec[1] = vec[2] = 0;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-12-01 18:26:18 +00:00
|
|
|
for (p = t->tsnap.points.first; p; p = p->next, total++) {
|
|
|
|
|
add_v3_v3(vec, p->co);
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-12-01 18:26:18 +00:00
|
|
|
if (t->tsnap.status & POINT_INIT) {
|
|
|
|
|
add_v3_v3(vec, t->tsnap.snapPoint);
|
|
|
|
|
total++;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-12-01 18:26:18 +00:00
|
|
|
mul_v3_fl(vec, 1.0f / total);
|
2012-03-24 06:38:07 +00:00
|
|
|
}
|
|
|
|
|
else {
|
2011-09-12 04:14:12 +00:00
|
|
|
copy_v3_v3(vec, t->tsnap.snapPoint);
|
2009-12-01 18:26:18 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-10-28 09:32:59 -03:00
|
|
|
/** \} */
|
|
|
|
|
|
|
|
|
|
/* -------------------------------------------------------------------- */
|
2021-06-29 17:38:34 -03:00
|
|
|
/** \name Calc Snap
|
2019-10-28 09:32:59 -03:00
|
|
|
* \{ */
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
|
2021-06-29 17:38:34 -03:00
|
|
|
static void snap_calc_view3d_fn(TransInfo *t, float *UNUSED(vec))
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
{
|
2021-06-29 17:38:34 -03:00
|
|
|
BLI_assert(t->spacetype == SPACE_VIEW3D);
|
|
|
|
|
float loc[3];
|
|
|
|
|
float no[3];
|
|
|
|
|
float mval[2];
|
|
|
|
|
bool found = false;
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
eSnapMode snap_elem = SCE_SNAP_MODE_NONE;
|
2021-06-29 17:38:34 -03:00
|
|
|
float dist_px = SNAP_MIN_DISTANCE; /* Use a user defined value here. */
|
|
|
|
|
|
|
|
|
|
mval[0] = t->mval[0];
|
|
|
|
|
mval[1] = t->mval[1];
|
|
|
|
|
|
2021-11-12 15:41:45 -03:00
|
|
|
if (t->tsnap.mode & SCE_SNAP_MODE_GEOM) {
|
2021-06-29 17:38:34 -03:00
|
|
|
zero_v3(no); /* objects won't set this */
|
|
|
|
|
snap_elem = snapObjectsTransform(t, mval, &dist_px, loc, no);
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
found = (snap_elem != SCE_SNAP_MODE_NONE);
|
2021-06-29 17:38:34 -03:00
|
|
|
}
|
|
|
|
|
if ((found == false) && (t->tsnap.mode & SCE_SNAP_MODE_VOLUME)) {
|
|
|
|
|
found = peelObjectsTransform(
|
|
|
|
|
t, mval, (t->settings->snap_flag & SCE_SNAP_PEEL_OBJECT) != 0, loc, no, NULL);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-06-29 17:38:34 -03:00
|
|
|
if (found) {
|
|
|
|
|
snap_elem = SCE_SNAP_MODE_VOLUME;
|
2011-05-11 09:28:00 +00:00
|
|
|
}
|
2021-06-29 17:38:34 -03:00
|
|
|
}
|
2019-08-23 15:20:25 -03:00
|
|
|
|
2021-06-29 17:38:34 -03:00
|
|
|
if (found == true) {
|
|
|
|
|
copy_v3_v3(t->tsnap.snapPoint, loc);
|
|
|
|
|
copy_v3_v3(t->tsnap.snapNormal, no);
|
|
|
|
|
|
|
|
|
|
t->tsnap.status |= POINT_INIT;
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
t->tsnap.status &= ~POINT_INIT;
|
|
|
|
|
}
|
|
|
|
|
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
t->tsnap.snapElem = snap_elem;
|
2021-06-29 17:38:34 -03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void snap_calc_uv_fn(TransInfo *t, float *UNUSED(vec))
|
|
|
|
|
{
|
2021-12-16 13:45:27 -03:00
|
|
|
BLI_assert(t->spacetype == SPACE_IMAGE);
|
2021-06-29 17:38:34 -03:00
|
|
|
if (t->tsnap.mode & SCE_SNAP_MODE_VERTEX) {
|
|
|
|
|
uint objects_len = 0;
|
|
|
|
|
Object **objects = BKE_view_layer_array_from_objects_in_edit_mode_unique_data_with_uvs(
|
|
|
|
|
t->view_layer, NULL, &objects_len);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-05-03 10:09:22 -03:00
|
|
|
float dist_sq = square_f((float)SNAP_MIN_DISTANCE);
|
|
|
|
|
if (ED_uvedit_nearest_uv_multi(&t->region->v2d,
|
|
|
|
|
t->scene,
|
|
|
|
|
objects,
|
|
|
|
|
objects_len,
|
|
|
|
|
t->mval,
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
t->tsnap.target_select == SCE_SNAP_TARGET_NOT_SELECTED,
|
2022-05-03 10:09:22 -03:00
|
|
|
&dist_sq,
|
|
|
|
|
t->tsnap.snapPoint)) {
|
2021-06-29 17:38:34 -03:00
|
|
|
t->tsnap.snapPoint[0] *= t->aspect[0];
|
|
|
|
|
t->tsnap.snapPoint[1] *= t->aspect[1];
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-02-24 00:45:40 +00:00
|
|
|
t->tsnap.status |= POINT_INIT;
|
|
|
|
|
}
|
2012-03-06 18:40:15 +00:00
|
|
|
else {
|
2009-02-24 00:45:40 +00:00
|
|
|
t->tsnap.status &= ~POINT_INIT;
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
2021-06-29 17:38:34 -03:00
|
|
|
MEM_freeN(objects);
|
2009-02-24 00:45:40 +00:00
|
|
|
}
|
2021-06-29 17:38:34 -03:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-06-29 17:38:34 -03:00
|
|
|
static void snap_calc_node_fn(TransInfo *t, float *UNUSED(vec))
|
|
|
|
|
{
|
|
|
|
|
BLI_assert(t->spacetype == SPACE_NODE);
|
|
|
|
|
if (t->tsnap.mode & (SCE_SNAP_MODE_NODE_X | SCE_SNAP_MODE_NODE_Y)) {
|
|
|
|
|
float loc[2];
|
|
|
|
|
float dist_px = SNAP_MIN_DISTANCE; /* Use a user defined value here. */
|
|
|
|
|
char node_border;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-06-29 17:38:34 -03:00
|
|
|
if (snapNodesTransform(t, t->mval, loc, &dist_px, &node_border)) {
|
|
|
|
|
copy_v2_v2(t->tsnap.snapPoint, loc);
|
|
|
|
|
t->tsnap.snapNodeBorder = node_border;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-06-29 17:38:34 -03:00
|
|
|
t->tsnap.status |= POINT_INIT;
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
t->tsnap.status &= ~POINT_INIT;
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
}
|
2021-06-29 17:38:34 -03:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-06-29 18:08:41 -03:00
|
|
|
static void snap_calc_sequencer_fn(TransInfo *t, float *UNUSED(vec))
|
2021-06-29 17:38:34 -03:00
|
|
|
{
|
|
|
|
|
BLI_assert(t->spacetype == SPACE_SEQ);
|
2021-06-29 18:08:41 -03:00
|
|
|
if (transform_snap_sequencer_calc(t)) {
|
2021-06-29 17:38:34 -03:00
|
|
|
t->tsnap.status |= (POINT_INIT | TARGET_INIT);
|
2012-06-29 14:34:46 +00:00
|
|
|
}
|
2021-06-29 17:38:34 -03:00
|
|
|
else {
|
|
|
|
|
t->tsnap.status &= ~(POINT_INIT | TARGET_INIT);
|
2021-06-29 20:12:19 +02:00
|
|
|
}
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
}
|
|
|
|
|
|
2019-10-28 09:32:59 -03:00
|
|
|
/** \} */
|
|
|
|
|
|
|
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
|
/** \name Target
|
|
|
|
|
* \{ */
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
|
2021-02-05 11:01:30 -03:00
|
|
|
static void snap_target_median_impl(TransInfo *t, float r_median[3])
|
|
|
|
|
{
|
|
|
|
|
int i_accum = 0;
|
|
|
|
|
|
|
|
|
|
zero_v3(r_median);
|
|
|
|
|
|
|
|
|
|
FOREACH_TRANS_DATA_CONTAINER (t, tc) {
|
|
|
|
|
TransData *td = tc->data;
|
|
|
|
|
int i;
|
|
|
|
|
float v[3];
|
|
|
|
|
zero_v3(v);
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < tc->data_len && td->flag & TD_SELECTED; i++, td++) {
|
|
|
|
|
add_v3_v3(v, td->center);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (i == 0) {
|
|
|
|
|
/* Is this possible? */
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
mul_v3_fl(v, 1.0 / i);
|
|
|
|
|
|
|
|
|
|
if (tc->use_local_mat) {
|
|
|
|
|
mul_m4_v3(tc->mat, v);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
add_v3_v3(r_median, v);
|
|
|
|
|
i_accum++;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
mul_v3_fl(r_median, 1.0 / i_accum);
|
|
|
|
|
|
|
|
|
|
// TargetSnapOffset(t, NULL);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void snap_target_grid_ensure(TransInfo *t)
|
|
|
|
|
{
|
|
|
|
|
/* Only need to calculate once. */
|
|
|
|
|
if ((t->tsnap.status & TARGET_GRID_INIT) == 0) {
|
|
|
|
|
if (t->data_type == TC_CURSOR_VIEW3D) {
|
|
|
|
|
/* Use a fallback when transforming the cursor.
|
|
|
|
|
* In this case the center is _not_ derived from the cursor which is being transformed. */
|
|
|
|
|
copy_v3_v3(t->tsnap.snapTargetGrid, TRANS_DATA_CONTAINER_FIRST_SINGLE(t)->data->iloc);
|
|
|
|
|
}
|
|
|
|
|
else if (t->around == V3D_AROUND_CURSOR) {
|
|
|
|
|
/* Use a fallback for cursor selection,
|
|
|
|
|
* this isn't useful as a global center for absolute grid snapping
|
|
|
|
|
* since its not based on the position of the selection. */
|
|
|
|
|
snap_target_median_impl(t, t->tsnap.snapTargetGrid);
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
copy_v3_v3(t->tsnap.snapTargetGrid, t->center_global);
|
|
|
|
|
}
|
|
|
|
|
t->tsnap.status |= TARGET_GRID_INIT;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2012-06-29 14:34:46 +00:00
|
|
|
static void TargetSnapOffset(TransInfo *t, TransData *td)
|
|
|
|
|
{
|
|
|
|
|
if (t->spacetype == SPACE_NODE && td != NULL) {
|
|
|
|
|
bNode *node = td->extra;
|
|
|
|
|
char border = t->tsnap.snapNodeBorder;
|
2012-09-15 11:48:20 +00:00
|
|
|
float width = BLI_rctf_size_x(&node->totr);
|
|
|
|
|
float height = BLI_rctf_size_y(&node->totr);
|
2018-05-13 06:44:03 +02:00
|
|
|
|
2014-01-21 13:13:41 +01:00
|
|
|
#ifdef USE_NODE_CENTER
|
2019-04-22 09:19:45 +10:00
|
|
|
if (border & NODE_LEFT) {
|
2012-06-29 14:34:46 +00:00
|
|
|
t->tsnap.snapTarget[0] -= 0.5f * width;
|
2019-04-22 09:19:45 +10:00
|
|
|
}
|
|
|
|
|
if (border & NODE_RIGHT) {
|
2012-06-29 14:34:46 +00:00
|
|
|
t->tsnap.snapTarget[0] += 0.5f * width;
|
2019-04-22 09:19:45 +10:00
|
|
|
}
|
|
|
|
|
if (border & NODE_BOTTOM) {
|
2012-06-29 14:34:46 +00:00
|
|
|
t->tsnap.snapTarget[1] -= 0.5f * height;
|
2019-04-22 09:19:45 +10:00
|
|
|
}
|
|
|
|
|
if (border & NODE_TOP) {
|
2012-06-29 14:34:46 +00:00
|
|
|
t->tsnap.snapTarget[1] += 0.5f * height;
|
2019-04-22 09:19:45 +10:00
|
|
|
}
|
2014-01-21 13:13:41 +01:00
|
|
|
#else
|
2019-04-22 09:19:45 +10:00
|
|
|
if (border & NODE_LEFT) {
|
2014-01-21 13:13:41 +01:00
|
|
|
t->tsnap.snapTarget[0] -= 0.0f;
|
2019-04-22 09:19:45 +10:00
|
|
|
}
|
|
|
|
|
if (border & NODE_RIGHT) {
|
2014-01-21 13:13:41 +01:00
|
|
|
t->tsnap.snapTarget[0] += width;
|
2019-04-22 09:19:45 +10:00
|
|
|
}
|
|
|
|
|
if (border & NODE_BOTTOM) {
|
2014-01-21 13:13:41 +01:00
|
|
|
t->tsnap.snapTarget[1] -= height;
|
2019-04-22 09:19:45 +10:00
|
|
|
}
|
|
|
|
|
if (border & NODE_TOP) {
|
2014-01-21 13:13:41 +01:00
|
|
|
t->tsnap.snapTarget[1] += 0.0f;
|
2019-04-22 09:19:45 +10:00
|
|
|
}
|
2014-01-21 13:13:41 +01:00
|
|
|
#endif
|
2012-06-29 14:34:46 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2011-11-15 16:38:48 +00:00
|
|
|
static void TargetSnapCenter(TransInfo *t)
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
{
|
2012-04-28 06:31:57 +00:00
|
|
|
/* Only need to calculate once */
|
|
|
|
|
if ((t->tsnap.status & TARGET_INIT) == 0) {
|
2015-06-26 16:19:39 +10:00
|
|
|
copy_v3_v3(t->tsnap.snapTarget, t->center_global);
|
2012-06-29 14:34:46 +00:00
|
|
|
TargetSnapOffset(t, NULL);
|
2018-05-13 06:44:03 +02:00
|
|
|
|
2012-10-21 05:46:41 +00:00
|
|
|
t->tsnap.status |= TARGET_INIT;
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2011-11-15 16:38:48 +00:00
|
|
|
static void TargetSnapActive(TransInfo *t)
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
{
|
2012-04-28 06:31:57 +00:00
|
|
|
/* Only need to calculate once */
|
|
|
|
|
if ((t->tsnap.status & TARGET_INIT) == 0) {
|
2014-05-09 16:52:09 +10:00
|
|
|
if (calculateCenterActive(t, true, t->tsnap.snapTarget)) {
|
|
|
|
|
TargetSnapOffset(t, NULL);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
t->tsnap.status |= TARGET_INIT;
|
|
|
|
|
}
|
|
|
|
|
/* No active, default to median */
|
2012-03-06 18:40:15 +00:00
|
|
|
else {
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
t->tsnap.source_select = SCE_SNAP_SOURCE_MEDIAN;
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
t->tsnap.targetSnap = TargetSnapMedian;
|
|
|
|
|
TargetSnapMedian(t);
|
2012-10-21 05:46:41 +00:00
|
|
|
}
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2011-11-15 16:38:48 +00:00
|
|
|
static void TargetSnapMedian(TransInfo *t)
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
{
|
|
|
|
|
/* Only need to calculate once. */
|
2012-04-28 06:31:57 +00:00
|
|
|
if ((t->tsnap.status & TARGET_INIT) == 0) {
|
2021-02-05 11:01:30 -03:00
|
|
|
snap_target_median_impl(t, t->tsnap.snapTarget);
|
2012-10-21 05:46:41 +00:00
|
|
|
t->tsnap.status |= TARGET_INIT;
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2011-11-15 16:38:48 +00:00
|
|
|
static void TargetSnapClosest(TransInfo *t)
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
{
|
|
|
|
|
/* Only valid if a snap point has been selected. */
|
2012-04-28 06:31:57 +00:00
|
|
|
if (t->tsnap.status & POINT_INIT) {
|
2016-01-18 13:15:38 +11:00
|
|
|
float dist_closest = 0.0f;
|
2018-04-16 16:27:55 +02:00
|
|
|
TransData *closest = NULL;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
/* Object mode */
|
2021-02-05 11:56:43 -03:00
|
|
|
if (t->options & CTX_OBJECT) {
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
int i;
|
2019-04-21 04:40:16 +10:00
|
|
|
FOREACH_TRANS_DATA_CONTAINER (t, tc) {
|
2021-06-13 14:47:22 +10:00
|
|
|
TransData *td;
|
2018-04-16 17:54:33 +02:00
|
|
|
for (td = tc->data, i = 0; i < tc->data_len && td->flag & TD_SELECTED; i++, td++) {
|
2019-08-24 21:22:30 +10:00
|
|
|
const BoundBox *bb = NULL;
|
|
|
|
|
|
2019-08-28 13:42:22 +10:00
|
|
|
if ((t->options & CTX_OBMODE_XFORM_OBDATA) == 0) {
|
2019-08-24 21:22:30 +10:00
|
|
|
bb = BKE_object_boundbox_get(td->ob);
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-04-16 17:54:33 +02:00
|
|
|
/* use boundbox if possible */
|
|
|
|
|
if (bb) {
|
|
|
|
|
int j;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-04-16 17:54:33 +02:00
|
|
|
for (j = 0; j < 8; j++) {
|
|
|
|
|
float loc[3];
|
|
|
|
|
float dist;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-04-16 17:54:33 +02:00
|
|
|
copy_v3_v3(loc, bb->vec[j]);
|
|
|
|
|
mul_m4_v3(td->ext->obmat, loc);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-04-16 17:54:33 +02:00
|
|
|
dist = t->tsnap.distance(t, loc, t->tsnap.snapPoint);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-04-16 17:54:33 +02:00
|
|
|
if ((dist != TRANSFORM_DIST_INVALID) &&
|
|
|
|
|
(closest == NULL || fabsf(dist) < fabsf(dist_closest))) {
|
|
|
|
|
copy_v3_v3(t->tsnap.snapTarget, loc);
|
|
|
|
|
closest = td;
|
|
|
|
|
dist_closest = dist;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
/* use element center otherwise */
|
|
|
|
|
else {
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
float loc[3];
|
|
|
|
|
float dist;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-04-16 17:54:33 +02:00
|
|
|
copy_v3_v3(loc, td->center);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
dist = t->tsnap.distance(t, loc, t->tsnap.snapPoint);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-10-16 14:45:05 +11:00
|
|
|
if ((dist != TRANSFORM_DIST_INVALID) &&
|
2016-01-18 13:15:38 +11:00
|
|
|
(closest == NULL || fabsf(dist) < fabsf(dist_closest))) {
|
2011-09-12 04:14:12 +00:00
|
|
|
copy_v3_v3(t->tsnap.snapTarget, loc);
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
closest = td;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2018-04-16 17:54:33 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
2019-04-21 04:40:16 +10:00
|
|
|
FOREACH_TRANS_DATA_CONTAINER (t, tc) {
|
2018-04-16 17:54:33 +02:00
|
|
|
TransData *td = tc->data;
|
|
|
|
|
int i;
|
|
|
|
|
for (i = 0; i < tc->data_len && td->flag & TD_SELECTED; i++, td++) {
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
float loc[3];
|
|
|
|
|
float dist;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-09-12 04:14:12 +00:00
|
|
|
copy_v3_v3(loc, td->center);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-05-04 14:41:51 +02:00
|
|
|
if (tc->use_local_mat) {
|
|
|
|
|
mul_m4_v3(tc->mat, loc);
|
2018-04-16 17:54:33 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
dist = t->tsnap.distance(t, loc, t->tsnap.snapPoint);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-10-16 14:45:05 +11:00
|
|
|
if ((dist != TRANSFORM_DIST_INVALID) &&
|
2016-01-18 13:15:38 +11:00
|
|
|
(closest == NULL || fabsf(dist) < fabsf(dist_closest))) {
|
2011-09-12 04:14:12 +00:00
|
|
|
copy_v3_v3(t->tsnap.snapTarget, loc);
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
closest = td;
|
2018-04-16 17:54:33 +02:00
|
|
|
dist_closest = dist;
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-29 14:34:46 +00:00
|
|
|
TargetSnapOffset(t, closest);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
t->tsnap.status |= TARGET_INIT;
|
|
|
|
|
}
|
|
|
|
|
}
|
2009-02-24 21:25:36 +00:00
|
|
|
|
2019-10-28 09:32:59 -03:00
|
|
|
/** \} */
|
|
|
|
|
|
|
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
|
/** \name Snap Objects
|
|
|
|
|
* \{ */
|
|
|
|
|
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
eSnapMode snapObjectsTransform(
|
2016-06-03 16:54:58 +10:00
|
|
|
TransInfo *t, const float mval[2], float *dist_px, float r_loc[3], float r_no[3])
|
2009-03-20 18:00:51 +00:00
|
|
|
{
|
2019-12-03 12:20:27 -03:00
|
|
|
float *target = (t->tsnap.status & TARGET_INIT) ? t->tsnap.snapTarget : t->center_global;
|
2021-10-18 00:32:23 -03:00
|
|
|
return ED_transform_snap_object_project_view3d(
|
2017-08-11 11:23:39 +10:00
|
|
|
t->tsnap.object_context,
|
2020-03-09 10:02:11 -03:00
|
|
|
t->depsgraph,
|
2021-10-12 17:05:56 -03:00
|
|
|
t->region,
|
|
|
|
|
t->view,
|
2021-11-12 15:45:59 -03:00
|
|
|
t->tsnap.mode,
|
2016-04-21 11:29:32 +10:00
|
|
|
&(const struct SnapObjectParams){
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
.snap_target_select = t->tsnap.target_select,
|
2021-04-17 14:09:41 -03:00
|
|
|
.edit_mode_type = (t->flag & T_EDIT) != 0 ? SNAP_GEOM_EDIT : SNAP_GEOM_FINAL,
|
2020-07-22 12:00:02 -03:00
|
|
|
.use_occlusion_test = t->settings->snap_mode != SCE_SNAP_MODE_FACE,
|
|
|
|
|
.use_backface_culling = t->tsnap.use_backface_culling,
|
2016-04-21 11:29:32 +10:00
|
|
|
},
|
2018-05-16 23:04:28 -03:00
|
|
|
mval,
|
2019-12-03 12:20:27 -03:00
|
|
|
target,
|
2018-05-16 23:04:28 -03:00
|
|
|
dist_px,
|
|
|
|
|
r_loc,
|
2021-10-18 00:32:23 -03:00
|
|
|
r_no);
|
2013-04-03 09:48:21 +00:00
|
|
|
}
|
2009-03-20 18:00:51 +00:00
|
|
|
|
2019-10-28 09:32:59 -03:00
|
|
|
/** \} */
|
|
|
|
|
|
|
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
|
/** \name Peeling
|
|
|
|
|
* \{ */
|
2009-02-24 00:45:40 +00:00
|
|
|
|
2020-03-09 10:02:11 -03:00
|
|
|
bool peelObjectsTransform(TransInfo *t,
|
|
|
|
|
const float mval[2],
|
|
|
|
|
const bool use_peel_object,
|
|
|
|
|
/* return args */
|
|
|
|
|
float r_loc[3],
|
|
|
|
|
float r_no[3],
|
|
|
|
|
float *r_thickness)
|
2009-02-24 00:45:40 +00:00
|
|
|
{
|
2016-05-11 19:59:02 +10:00
|
|
|
ListBase depths_peel = {0};
|
2020-03-09 10:02:11 -03:00
|
|
|
ED_transform_snap_object_project_all_view3d_ex(
|
|
|
|
|
t->tsnap.object_context,
|
|
|
|
|
t->depsgraph,
|
2021-10-12 17:05:56 -03:00
|
|
|
t->region,
|
|
|
|
|
t->view,
|
2020-03-09 10:02:11 -03:00
|
|
|
&(const struct SnapObjectParams){
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
.snap_target_select = t->tsnap.target_select,
|
2021-04-17 14:09:41 -03:00
|
|
|
.edit_mode_type = (t->flag & T_EDIT) != 0 ? SNAP_GEOM_EDIT : SNAP_GEOM_FINAL,
|
2020-03-09 10:02:11 -03:00
|
|
|
},
|
|
|
|
|
mval,
|
|
|
|
|
-1.0f,
|
|
|
|
|
false,
|
|
|
|
|
&depths_peel);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2016-05-11 19:59:02 +10:00
|
|
|
if (!BLI_listbase_is_empty(&depths_peel)) {
|
|
|
|
|
/* At the moment we only use the hits of the first object */
|
|
|
|
|
struct SnapObjectHitDepth *hit_min = depths_peel.first;
|
|
|
|
|
for (struct SnapObjectHitDepth *iter = hit_min->next; iter; iter = iter->next) {
|
|
|
|
|
if (iter->depth < hit_min->depth) {
|
|
|
|
|
hit_min = iter;
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
2009-02-24 00:45:40 +00:00
|
|
|
}
|
2016-05-11 19:59:02 +10:00
|
|
|
struct SnapObjectHitDepth *hit_max = NULL;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2016-05-11 19:59:02 +10:00
|
|
|
if (use_peel_object) {
|
|
|
|
|
/* if peeling objects, take the first and last from each object */
|
|
|
|
|
hit_max = hit_min;
|
|
|
|
|
for (struct SnapObjectHitDepth *iter = depths_peel.first; iter; iter = iter->next) {
|
|
|
|
|
if ((iter->depth > hit_max->depth) && (iter->ob_uuid == hit_min->ob_uuid)) {
|
|
|
|
|
hit_max = iter;
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
|
|
|
|
}
|
2016-05-11 19:59:02 +10:00
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
/* otherwise, pair first with second and so on */
|
|
|
|
|
for (struct SnapObjectHitDepth *iter = depths_peel.first; iter; iter = iter->next) {
|
|
|
|
|
if ((iter != hit_min) && (iter->ob_uuid == hit_min->ob_uuid)) {
|
|
|
|
|
if (hit_max == NULL) {
|
|
|
|
|
hit_max = iter;
|
|
|
|
|
}
|
|
|
|
|
else if (iter->depth < hit_max->depth) {
|
|
|
|
|
hit_max = iter;
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
|
|
|
|
}
|
2016-05-11 19:59:02 +10:00
|
|
|
}
|
2021-10-18 11:16:24 +11:00
|
|
|
/* In this case has only one hit. treat as ray-cast. */
|
2016-05-11 19:59:02 +10:00
|
|
|
if (hit_max == NULL) {
|
|
|
|
|
hit_max = hit_min;
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
2016-05-06 04:49:21 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2016-05-11 19:59:02 +10:00
|
|
|
mid_v3_v3v3(r_loc, hit_min->co, hit_max->co);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2016-05-11 19:59:02 +10:00
|
|
|
if (r_thickness) {
|
|
|
|
|
*r_thickness = hit_max->depth - hit_min->depth;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2016-05-11 19:59:02 +10:00
|
|
|
/* XXX, is there a correct normal in this case ???, for now just z up */
|
|
|
|
|
r_no[0] = 0.0;
|
|
|
|
|
r_no[1] = 0.0;
|
|
|
|
|
r_no[2] = 1.0;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2016-05-11 19:59:02 +10:00
|
|
|
BLI_freelistN(&depths_peel);
|
|
|
|
|
return true;
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
}
|
2016-05-11 19:59:02 +10:00
|
|
|
return false;
|
2009-03-20 18:00:51 +00:00
|
|
|
}
|
|
|
|
|
|
2019-10-28 09:32:59 -03:00
|
|
|
/** \} */
|
|
|
|
|
|
|
|
|
|
/* -------------------------------------------------------------------- */
|
2019-10-28 09:51:53 -03:00
|
|
|
/** \name snap Nodes
|
2019-10-28 09:32:59 -03:00
|
|
|
* \{ */
|
2012-06-29 14:34:46 +00:00
|
|
|
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
static bool snapNodeTest(View2D *v2d, bNode *node, eSnapTargetSelect snap_target_select)
|
2012-06-29 14:34:46 +00:00
|
|
|
{
|
|
|
|
|
/* node is use for snapping only if a) snap mode matches and b) node is inside the view */
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
return ((snap_target_select == SCE_SNAP_TARGET_NOT_SELECTED && !(node->flag & NODE_SELECT)) ||
|
|
|
|
|
(snap_target_select == SCE_SNAP_TARGET_ALL && !(node->flag & NODE_ACTIVE))) &&
|
2012-06-29 14:34:46 +00:00
|
|
|
(node->totr.xmin < v2d->cur.xmax && node->totr.xmax > v2d->cur.xmin &&
|
|
|
|
|
node->totr.ymin < v2d->cur.ymax && node->totr.ymax > v2d->cur.ymin);
|
|
|
|
|
}
|
|
|
|
|
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
static NodeBorder snapNodeBorder(eSnapMode snap_node_mode)
|
2012-06-29 14:34:46 +00:00
|
|
|
{
|
2018-05-22 08:58:56 -03:00
|
|
|
NodeBorder flag = 0;
|
|
|
|
|
if (snap_node_mode & SCE_SNAP_MODE_NODE_X) {
|
|
|
|
|
flag |= NODE_LEFT | NODE_RIGHT;
|
|
|
|
|
}
|
|
|
|
|
if (snap_node_mode & SCE_SNAP_MODE_NODE_Y) {
|
|
|
|
|
flag |= NODE_TOP | NODE_BOTTOM;
|
2012-06-29 14:34:46 +00:00
|
|
|
}
|
2018-05-22 08:58:56 -03:00
|
|
|
return flag;
|
2012-06-29 14:34:46 +00:00
|
|
|
}
|
|
|
|
|
|
2015-12-02 18:08:48 +11:00
|
|
|
static bool snapNode(ToolSettings *ts,
|
|
|
|
|
SpaceNode *UNUSED(snode),
|
2020-03-06 16:56:42 +01:00
|
|
|
ARegion *region,
|
2015-12-02 18:08:48 +11:00
|
|
|
bNode *node,
|
|
|
|
|
const int mval[2],
|
|
|
|
|
float r_loc[2],
|
|
|
|
|
float *r_dist_px,
|
|
|
|
|
char *r_node_border)
|
2012-06-29 14:34:46 +00:00
|
|
|
{
|
2020-03-06 16:56:42 +01:00
|
|
|
View2D *v2d = ®ion->v2d;
|
2012-06-29 14:34:46 +00:00
|
|
|
NodeBorder border = snapNodeBorder(ts->snap_node_mode);
|
2013-03-08 18:28:26 +00:00
|
|
|
bool retval = false;
|
2012-06-29 14:34:46 +00:00
|
|
|
rcti totr;
|
|
|
|
|
int new_dist;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-04-21 16:47:16 +10:00
|
|
|
UI_view2d_view_to_region_rcti(v2d, &node->totr, &totr);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-29 14:34:46 +00:00
|
|
|
if (border & NODE_LEFT) {
|
|
|
|
|
new_dist = abs(totr.xmin - mval[0]);
|
2013-04-03 07:36:37 +00:00
|
|
|
if (new_dist < *r_dist_px) {
|
2012-06-29 14:34:46 +00:00
|
|
|
UI_view2d_region_to_view(v2d, totr.xmin, mval[1], &r_loc[0], &r_loc[1]);
|
2013-04-03 07:36:37 +00:00
|
|
|
*r_dist_px = new_dist;
|
2012-06-29 14:34:46 +00:00
|
|
|
*r_node_border = NODE_LEFT;
|
2013-03-08 18:28:26 +00:00
|
|
|
retval = true;
|
2012-06-29 14:34:46 +00:00
|
|
|
}
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-29 14:34:46 +00:00
|
|
|
if (border & NODE_RIGHT) {
|
|
|
|
|
new_dist = abs(totr.xmax - mval[0]);
|
2013-04-03 07:36:37 +00:00
|
|
|
if (new_dist < *r_dist_px) {
|
2012-06-29 14:34:46 +00:00
|
|
|
UI_view2d_region_to_view(v2d, totr.xmax, mval[1], &r_loc[0], &r_loc[1]);
|
2013-04-03 07:36:37 +00:00
|
|
|
*r_dist_px = new_dist;
|
2012-06-29 14:34:46 +00:00
|
|
|
*r_node_border = NODE_RIGHT;
|
2013-03-08 18:28:26 +00:00
|
|
|
retval = true;
|
2012-06-29 14:34:46 +00:00
|
|
|
}
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-29 14:34:46 +00:00
|
|
|
if (border & NODE_BOTTOM) {
|
|
|
|
|
new_dist = abs(totr.ymin - mval[1]);
|
2013-04-03 07:36:37 +00:00
|
|
|
if (new_dist < *r_dist_px) {
|
2012-06-29 14:34:46 +00:00
|
|
|
UI_view2d_region_to_view(v2d, mval[0], totr.ymin, &r_loc[0], &r_loc[1]);
|
2013-04-03 07:36:37 +00:00
|
|
|
*r_dist_px = new_dist;
|
2012-06-29 14:34:46 +00:00
|
|
|
*r_node_border = NODE_BOTTOM;
|
2013-03-08 18:28:26 +00:00
|
|
|
retval = true;
|
2012-06-29 14:34:46 +00:00
|
|
|
}
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-29 14:34:46 +00:00
|
|
|
if (border & NODE_TOP) {
|
|
|
|
|
new_dist = abs(totr.ymax - mval[1]);
|
2013-04-03 07:36:37 +00:00
|
|
|
if (new_dist < *r_dist_px) {
|
2012-06-29 14:34:46 +00:00
|
|
|
UI_view2d_region_to_view(v2d, mval[0], totr.ymax, &r_loc[0], &r_loc[1]);
|
2013-04-03 07:36:37 +00:00
|
|
|
*r_dist_px = new_dist;
|
2012-06-29 14:34:46 +00:00
|
|
|
*r_node_border = NODE_TOP;
|
2013-03-08 18:28:26 +00:00
|
|
|
retval = true;
|
2012-06-29 14:34:46 +00:00
|
|
|
}
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-29 14:34:46 +00:00
|
|
|
return retval;
|
|
|
|
|
}
|
|
|
|
|
|
2015-12-02 18:08:48 +11:00
|
|
|
static bool snapNodes(ToolSettings *ts,
|
|
|
|
|
SpaceNode *snode,
|
2020-03-06 16:56:42 +01:00
|
|
|
ARegion *region,
|
2017-10-17 13:43:10 +11:00
|
|
|
const int mval[2],
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
eSnapTargetSelect snap_target_select,
|
2015-12-02 18:08:48 +11:00
|
|
|
float r_loc[2],
|
|
|
|
|
float *r_dist_px,
|
|
|
|
|
char *r_node_border)
|
2012-06-29 14:34:46 +00:00
|
|
|
{
|
|
|
|
|
bNodeTree *ntree = snode->edittree;
|
|
|
|
|
bNode *node;
|
2013-03-08 18:28:26 +00:00
|
|
|
bool retval = false;
|
2018-05-13 06:44:03 +02:00
|
|
|
|
2012-06-29 14:34:46 +00:00
|
|
|
*r_node_border = 0;
|
2018-05-13 06:44:03 +02:00
|
|
|
|
2012-06-29 14:34:46 +00:00
|
|
|
for (node = ntree->nodes.first; node; node = node->next) {
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
if (snapNodeTest(®ion->v2d, node, snap_target_select)) {
|
2020-03-06 16:56:42 +01:00
|
|
|
retval |= snapNode(ts, snode, region, node, mval, r_loc, r_dist_px, r_node_border);
|
2015-12-02 18:08:48 +11:00
|
|
|
}
|
2012-06-29 14:34:46 +00:00
|
|
|
}
|
2018-05-13 06:44:03 +02:00
|
|
|
|
2012-06-29 14:34:46 +00:00
|
|
|
return retval;
|
|
|
|
|
}
|
|
|
|
|
|
2015-12-02 18:08:48 +11:00
|
|
|
bool snapNodesTransform(
|
|
|
|
|
TransInfo *t, const int mval[2], float r_loc[2], float *r_dist_px, char *r_node_border)
|
2012-06-29 14:34:46 +00:00
|
|
|
{
|
2017-08-16 14:16:30 -03:00
|
|
|
return snapNodes(t->settings,
|
2020-04-03 13:25:03 +02:00
|
|
|
t->area->spacedata.first,
|
2020-03-06 16:56:42 +01:00
|
|
|
t->region,
|
2017-08-16 14:16:30 -03:00
|
|
|
mval,
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
t->tsnap.target_select,
|
2015-12-02 18:08:48 +11:00
|
|
|
r_loc,
|
|
|
|
|
r_dist_px,
|
|
|
|
|
r_node_border);
|
2012-06-29 14:34:46 +00:00
|
|
|
}
|
|
|
|
|
|
2019-10-28 09:51:53 -03:00
|
|
|
/** \} */
|
|
|
|
|
|
|
|
|
|
/* -------------------------------------------------------------------- */
|
2021-08-19 09:52:09 -03:00
|
|
|
/** \name snap Grid
|
2019-10-28 09:51:53 -03:00
|
|
|
* \{ */
|
|
|
|
|
|
2020-09-11 22:59:21 -03:00
|
|
|
static void snap_grid_apply(
|
2020-08-31 10:14:40 -03:00
|
|
|
TransInfo *t, const int max_index, const float grid_dist, const float loc[3], float r_out[3])
|
2011-09-28 05:53:40 +00:00
|
|
|
{
|
2020-09-11 22:59:21 -03:00
|
|
|
BLI_assert(max_index <= 2);
|
2021-02-05 11:01:30 -03:00
|
|
|
snap_target_grid_ensure(t);
|
|
|
|
|
const float *center_global = t->tsnap.snapTargetGrid;
|
2020-08-31 10:14:40 -03:00
|
|
|
const float *asp = t->aspect;
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
|
2020-09-11 22:59:21 -03:00
|
|
|
float in[3];
|
|
|
|
|
if (t->con.mode & CON_APPLY) {
|
Refactor: Snap-related. Clarified attribute names and refactored #defines into enums
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
2022-06-06 10:28:14 -04:00
|
|
|
BLI_assert(t->tsnap.snapElem == SCE_SNAP_MODE_NONE);
|
2020-09-11 22:59:21 -03:00
|
|
|
t->con.applyVec(t, NULL, NULL, loc, in);
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
copy_v3_v3(in, loc);
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
}
|
|
|
|
|
|
2020-08-31 10:14:40 -03:00
|
|
|
for (int i = 0; i <= max_index; i++) {
|
2020-09-11 22:59:21 -03:00
|
|
|
const float iter_fac = grid_dist * asp[i];
|
|
|
|
|
r_out[i] = iter_fac * roundf((in[i] + center_global[i]) / iter_fac) - center_global[i];
|
2020-08-31 10:14:40 -03:00
|
|
|
}
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
}
|
|
|
|
|
|
2020-09-11 22:59:21 -03:00
|
|
|
bool transform_snap_grid(TransInfo *t, float *val)
|
2014-11-24 18:18:35 +01:00
|
|
|
{
|
2020-09-11 22:59:21 -03:00
|
|
|
if (!activeSnap(t)) {
|
|
|
|
|
return false;
|
2019-04-22 09:19:45 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-08-31 10:14:40 -03:00
|
|
|
if ((!(t->tsnap.mode & SCE_SNAP_MODE_GRID)) || validSnap(t)) {
|
|
|
|
|
/* Don't do grid snapping if there is a valid snap point. */
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-09-29 17:47:32 +10:00
|
|
|
/* Don't do grid snapping if not in 3D viewport or UV editor */
|
|
|
|
|
if (!ELEM(t->spacetype, SPACE_VIEW3D, SPACE_IMAGE)) {
|
2020-08-31 10:14:40 -03:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (t->mode != TFM_TRANSLATION) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-08 09:45:45 -03:00
|
|
|
float grid_dist = (t->modifiers & MOD_PRECISION) ? t->snap[1] : t->snap[0];
|
2020-09-11 22:59:21 -03:00
|
|
|
|
|
|
|
|
/* Early bailing out if no need to snap */
|
|
|
|
|
if (grid_dist == 0.0f) {
|
2020-09-12 13:42:12 +10:00
|
|
|
return false;
|
2020-09-11 22:59:21 -03:00
|
|
|
}
|
2020-08-31 10:14:40 -03:00
|
|
|
|
2020-09-11 22:59:21 -03:00
|
|
|
snap_grid_apply(t, t->idx_max, grid_dist, val, val);
|
|
|
|
|
t->tsnap.snapElem = SCE_SNAP_MODE_GRID;
|
2020-08-31 10:14:40 -03:00
|
|
|
return true;
|
2014-11-24 18:18:35 +01:00
|
|
|
}
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
|
2021-06-29 20:13:55 +10:00
|
|
|
static void snap_increment_apply_ex(const TransInfo *UNUSED(t),
|
2020-08-31 10:14:40 -03:00
|
|
|
const int max_index,
|
|
|
|
|
const float increment_val,
|
|
|
|
|
const float aspect[3],
|
|
|
|
|
const float loc[3],
|
|
|
|
|
float r_out[3])
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
{
|
2020-08-31 10:14:40 -03:00
|
|
|
/* relative snapping in fixed increments */
|
|
|
|
|
for (int i = 0; i <= max_index; i++) {
|
|
|
|
|
const float iter_fac = increment_val * aspect[i];
|
|
|
|
|
r_out[i] = iter_fac * roundf(loc[i] / iter_fac);
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-06-29 20:13:55 +10:00
|
|
|
static void snap_increment_apply(const TransInfo *t,
|
|
|
|
|
const int max_index,
|
2020-08-31 10:14:40 -03:00
|
|
|
const float increment_dist,
|
|
|
|
|
float *r_val)
|
|
|
|
|
{
|
|
|
|
|
BLI_assert((t->tsnap.mode & SCE_SNAP_MODE_INCREMENT) || doForceIncrementSnap(t));
|
2015-06-26 15:45:09 +10:00
|
|
|
BLI_assert(max_index <= 2);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-06-26 15:45:09 +10:00
|
|
|
/* Early bailing out if no need to snap */
|
2020-08-31 10:14:40 -03:00
|
|
|
if (increment_dist == 0.0f) {
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
return;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-08-31 10:14:40 -03:00
|
|
|
float asp_local[3] = {1, 1, 1};
|
|
|
|
|
const bool use_aspect = ELEM(t->mode, TFM_TRANSLATION);
|
|
|
|
|
const float *asp = use_aspect ? t->aspect : asp_local;
|
|
|
|
|
|
2015-06-26 15:45:09 +10:00
|
|
|
if (use_aspect) {
|
|
|
|
|
/* custom aspect for fcurve */
|
2019-02-16 16:42:11 +11:00
|
|
|
if (t->spacetype == SPACE_GRAPH) {
|
2020-03-06 16:56:42 +01:00
|
|
|
View2D *v2d = &t->region->v2d;
|
Refactor grid and scale indicator text drawing
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
2019-05-02 12:00:12 +02:00
|
|
|
Scene *scene = t->scene;
|
2020-04-03 13:25:03 +02:00
|
|
|
SpaceGraph *sipo = t->area->spacedata.first;
|
Refactor grid and scale indicator text drawing
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
2019-05-02 12:00:12 +02:00
|
|
|
asp_local[0] = UI_view2d_grid_resolution_x__frames_or_seconds(
|
|
|
|
|
v2d, scene, sipo->flag & SIPO_DRAWTIME);
|
|
|
|
|
asp_local[1] = UI_view2d_grid_resolution_y__values(v2d);
|
2015-06-26 15:45:09 +10:00
|
|
|
asp = asp_local;
|
2014-11-20 17:44:47 +01:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
|
|
|
|
|
2020-08-31 10:14:40 -03:00
|
|
|
snap_increment_apply_ex(t, max_index, increment_dist, asp, r_val, r_val);
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-06-29 20:13:55 +10:00
|
|
|
bool transform_snap_increment_ex(const TransInfo *t, bool use_local_space, float *r_val)
|
2020-08-31 10:14:40 -03:00
|
|
|
{
|
2020-10-08 09:45:45 -03:00
|
|
|
if (!activeSnap(t)) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-31 10:14:40 -03:00
|
|
|
if (!(t->tsnap.mode & SCE_SNAP_MODE_INCREMENT) && !doForceIncrementSnap(t)) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-08-31 10:14:40 -03:00
|
|
|
if (t->spacetype != SPACE_VIEW3D && validSnap(t)) {
|
|
|
|
|
/* Only do something if using absolute or incremental grid snapping
|
|
|
|
|
* and there is no valid snap point. */
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-01-10 20:24:46 -03:00
|
|
|
if (use_local_space) {
|
|
|
|
|
BLI_assert(t->idx_max == 2);
|
|
|
|
|
mul_m3_v3(t->spacemtx_inv, r_val);
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-08 09:45:45 -03:00
|
|
|
float increment_dist = (t->modifiers & MOD_PRECISION) ? t->snap[1] : t->snap[0];
|
2021-01-10 20:24:46 -03:00
|
|
|
snap_increment_apply(t, t->idx_max, increment_dist, r_val);
|
|
|
|
|
|
|
|
|
|
if (use_local_space) {
|
|
|
|
|
mul_m3_v3(t->spacemtx, r_val);
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-08-31 10:14:40 -03:00
|
|
|
return true;
|
2.5
Transform:
First working port of the transform code:
- Object mode only (other conversions need to be ported)
- Contraints (global and local only) working
- Snap (no edit mode, obviously) working
- Numinput working
- Gears (Ctrl and Shift) working
- Only grap, rotate, scale, shear, warp and to sphere have been added as hotkey, but the rest should work too once accessible
- No manipulator
- No drawn feedback other than moving stuff and header print (no constraint line, snap circle, ...)
- No NDOF support
I've only tested Scons support, though Makefil *should* work, I *think*.
Misc:
-QuatIsNull function in arith
-Exporting project_* and view[line|ray] functions from view3d
2008-12-29 01:41:28 +00:00
|
|
|
}
|
2019-10-28 09:32:59 -03:00
|
|
|
|
2021-06-29 20:13:55 +10:00
|
|
|
bool transform_snap_increment(const TransInfo *t, float *r_val)
|
2021-01-10 20:24:46 -03:00
|
|
|
{
|
|
|
|
|
return transform_snap_increment_ex(t, false, r_val);
|
|
|
|
|
}
|
|
|
|
|
|
2022-06-06 22:59:32 -03:00
|
|
|
float transform_snap_increment_get(const TransInfo *t)
|
|
|
|
|
{
|
|
|
|
|
if (activeSnap(t) && (!transformModeUseSnap(t) ||
|
|
|
|
|
(t->tsnap.mode & (SCE_SNAP_MODE_INCREMENT | SCE_SNAP_MODE_GRID)))) {
|
|
|
|
|
return (t->modifiers & MOD_PRECISION) ? t->snap[1] : t->snap[0];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0.0f;
|
|
|
|
|
}
|
|
|
|
|
|
2019-10-28 09:32:59 -03:00
|
|
|
/** \} */
|
2020-06-22 09:07:51 -03:00
|
|
|
|
|
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
|
/** \name Generic callbacks
|
|
|
|
|
* \{ */
|
|
|
|
|
|
2020-06-24 14:23:54 +10:00
|
|
|
float transform_snap_distance_len_squared_fn(TransInfo *UNUSED(t),
|
|
|
|
|
const float p1[3],
|
|
|
|
|
const float p2[3])
|
2020-06-22 09:07:51 -03:00
|
|
|
{
|
|
|
|
|
return len_squared_v3v3(p1, p2);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/** \} */
|