Age | Commit message (Collapse) | Author |
|
|
|
|
|
Instead of hardcoded pink.
|
|
Since this is no longer mesh only, move out of mesh,
rename next.
|
|
|
|
Redo operator properties weren't being set.
|
|
|
|
D3943 by @Zachman w/ edits
|
|
|
|
|
|
|
|
Without this bugs slip through that don't null check the descriptions
since many were set to empty strings.
|
|
- `BKE_object_scale_to_mat3` was used to get the worldspace scale,
without taking constraints, parenting etc into account.
- Don't pass object's into BMesh API, (prefer matrices instead).
- Avoid matrix invert for each edge-angle calculation.
- Avoid 2x matrix multiplies when looping over edge pairs.
|
|
This makes the operator to work 100% with worldspace similarity:
* SIMFACE_PERIMETER
* SIMFACE_AREA
* SIMEDGE_FACE_ANGLE
Note from revisor (Dalai Felinto):
I'm not sure we want to pass Object * to the bmesh api, though I
personally don't see why not. Either way I group the patches together so
we can more easily roll them back if needs be.
Maniphest Tasks: T56948
Differential Revision: D3908, D3899, D3896
|
|
This should be purely an implementation change,
for end users there should be no functional difference.
The entire key configuration is in one file with ~5000 lines of code.
Mostly avoiding code duplication and preserve comments and utility
functions from the C code.
It's a bit long but for searching and editing it's also convenient to
have it all in one file.
Notes:
- Actual keymap is shared by blender / blender_legacy
and stored in `keymap_data/blender_default.py`
This only generates JSON-like data to be passed into
`keyconfig_import_from_data`, allowing other presets to load and
manipulate the default keymap.
- Each preset defines 'keyconfig_data'
which can be shared between presets.
- Some of the utility functions for generating keymap items still
need to be ported over to Python.
- Some keymap items can be made into loops (marked as TODO).
See: D3907
|
|
Makes it simpler to make some changes...
Also fix order of some includes (use alphabetical please).
|
|
That kind of implicit includes should really only be done when totally,
absolutely necessary, and ideally only with rather simple 'second-level'
headers.
Otherwise not being explicit with includes always end up biting in
unexpected ways...
|
|
Was missing a return of OPERATOR_RUNNING_MODAL for that subcommand.
|
|
Implemented the following methods:
* SIMCURHAND_TYPE
* SIMCURHAND_RADIUS
* SIMCURHAND_WEIGHT
* SIMCURHAND_DIRECTION
Limits:
* DIRECTION does not support surfaces, because `BKE_nurb_bpoint_calc_normal`
does not work with Nurbs of type `CU_CARDINAL`. This also didn't work prior
to this patch, so we wait until surfaces are properly supported in EditMode.
* Also DIRECTION should take scaling into consideration. We need our own
versions of BKE_nurb_bpoint_calc_normal/bezt.
* Threshold default is too large. Not sure if it's better to change the default
or scale the threshold in code.
Differential Revision: https://developer.blender.org/D3846
Changes from committer (Dalai Felinto):
* Moved nurb_bpoint_direction_worldspace_get/bezt to functions.
* Comments hinting at the mode (direction) that require scaling to be
taken into account - to be addressed by patch creator in a future
patch.
|
|
In general prefer API names don't start with adjectives
since it causes grouping of unrelated API's for completion.
|
|
|
|
If the user only needs insertion and removal from top, there is
no need to allocate and manage separate HeapNode objects: the
data can be stored directly in the main tree array.
This measured a 24% FPS increase on a ~50% heap-heavy workload.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D3898
|
|
It is very commonly needed in loop conditions to check if
the items in the heap are good enough to continue.
|
|
- Extruding edges/vertices on normals gave bad/strange results.
- The adjust gizmo used the orientation axis instead of the
last-orientation (which could get out of sync).
|
|
|
|
|
|
|
|
vertices
rB944054fbb61e introduced a sanity check which is not needed and
prevents the operator to run successfully with more than 2 selected
vertices
Reviewed By: dfelinto
Differential Revision: https://developer.blender.org/D3763
|
|
|
|
|
|
|
|
'mp' was a reference to 'manipulator'
|
|
|
|
|
|
|
|
See: T56648
|
|
Was giving errors on each access.
|
|
|
|
The normal and xyz no longer overlap so can be the same size.
|
|
|
|
|
|
Having this setting here wasn't correct (the operator ignores it).
|
|
Prepare for storing different kinds of properties in tools.
|
|
|
|
|
|
Was using 'selected_editable_bases', which used to save a lookup.
This is no longer the case and complicates access from Python
which cant yet easily access Bases.
|
|
Based on D3330 by Falk David
|
|
|
|
I'm storing the name of the vertex groups in a gset. This way
we can select vertex groups with the same name across different
objects.
Also this is the last select similar mode that needs porting o/
|
|
Differential Revision: https://developer.blender.org/D3736
|