| Age | Commit message (Collapse) | Author |
|---|
|
Since the cache is created in one way or another, this flag is not really making a difference
More details here: D2496
|
|
The code looks for the closest element between its centers. In the case of islands, the center of each vertex is the center of the island.
The solution here is to skip the search for islands when the operation is translation
|
|
In obect mode, the rotation matrix need to be restored to the initial value if a snap point is not found
|
|
possible.
Pretty straight forward actually, just do not bother about obdata part
of vgroups in that case, only copy object part of it.
And let's curse once again those stuff spread accross several types of
data-blocks...
|
|
|
|
|
|
transformation
The problem was simple, just transform the global coordinates of t->tsnap.snapTarget to local coordinates.
(Some comments were added to the code)
|
|
Issue was indeed in join operation, mesh in which we join all others
could be re-added to final data after others, leading to undesired
re-ordering of CD layers, and existing vertices etc. being shifted away
from their original indices, etc.
All kind of more or less bad and undesired changes, fixed by always
re-inserting destination mesh first.
Also cleaned up a bit that code, it was doing some rather
non-recommanded things (like allocating zero-sized mem, doing own
coocking to remove a data-block from main, etc.).
|
|
Root of the issue was BM_mesh_bm_to_me() breaking application of basis
offset to 'child' shapekeys, when called more than once from same BMesh.
|
|
|
|
particle modifier + UV material
Tricky issue caused by CDDM_copy() coying MFACE array but not MTFACE which
confused logic later on.
Now we don't copy ANY tessellation unless it is requested to.
Thanks Bastien for help and review!
|
|
This was my own mistake
|
|
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D2378
|
|
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D2379
|
|
scrolling speed.
'page' prop of scroll up/down operators would get stuck once set once by
pageup/down keys... Now only take this prop into account if explicitely
set, not when its value is inherited from previous run.
|
|
perspective view
Strangely this change does not affect the performance very much.
Suzanne subdividide 6x (ortho view):
Before:0.00013983
After :0.00013920
But it makes it easier to read the code
|
|
When the function that tests snap on multiple elements starts from the face and ends at the vertex, the transition between elements becomes much smoother.
|
|
|
|
|
|
|
|
`cd_flag` tends to be used for CustomData flags in mesh area, while for
library_query those are rather callback flags...
|
|
Better to have clear way to tell whether flag is parameter for
BKE_library_foreach_ID_link(), parameter for its callback function, or
return value from this callback function.
|
|
D2492 by @tomjpsun.
|
|
considering the depth variation
Taking advantage of the area, the depth is decreased 0.01 BU to each loop to give priority to elements in order: Vertice > Edge > Face. This increases the threshold and improves the snap to multiple elements
|
|
Ruler only works right this way
The Ruler snaps to the element with the lowest depth.
|
|
The previous solution took arbitrary values to determine if the mouse was near or not to the Bound Box (it simply scaled the Bound Box).
Now the same function that detected the distance from the BVHTree nodes to the mouse is used in the Bound Box
|
|
Use new Main->relations ID usages mapping in BKE_library_make_local().
This allows a noticeable simplification in code, and can be up to twice
quicker as previous code (Make Local: All from 2 to 1 minute e.g. in a
huge production file with thousands of linked data-blocks).
Note that new code has been successfuly tested with several complex cases
(production files from Agent327), as well as some testcases from recent
bug reports related to that function. But as always, nothing beats real
usage by real users, so please check this before we release 2.79. ;)
Main areas that would be affected: Make Local operations (L shortcut in
3DView), and append from libraries.
|
|
Use Main->relations in BKE_library_foreach_ID_link(), when possible
(i.e. IDWALK_READONLY is set), and if the data is available of course.
This is quite minor optimization, no sensible improvements are expected,
but does not hurt either to avoid potentially tens of looping over e.g.
objects constraints and modifiers, or heap of drivers...
|
|
This shall fix both existing code (bpy mapping, and local/lib usages
checks), and new Main->relations generation.
|
|
The new MainIDRelations stores two mappings, one from ID users to ID
used, the other vice-versa.
That data is assumed to be short-living runtime, code creating it is
responsible to clear it asap. It will be much useful in places where we
handle relations between IDs for a lot of them at once.
Note: This commit is not fully functional, that is, the infamous, ugly,
PoS non-ID nodetrees will not be handled correctly when building relations.
Fix needed here is a bit noisy, so will be done in next own commit.
|
|
points to active object
A simple confusion between enums: ~SNAP_NOT_ACTIVE~
|
|
|
|
Please doublecheck ED_transform_snap_object_project_ray_ex() is really
valid, it's weird to have extra arguments here unused.
|
|
This provides a slight improvement in performance in specific cases, such as when the observer is inside a high poly object and executes snap to edge or vertex
|
|
The bug would only be seen in terms of performance
|
|
Error reported by @tomjpsun
Patch D2491
|
|
Remove `BKE_boundbox_ray_hit_check` since it is no longer being used and can be easily replaced by `isect_ray_aabb_v3_simple`
|
|
The new `isect_ray_aabb_v3_simple` function replaces the `BKE_boundbox_ray_hit_check` and can be used in BVHTree Root (first AABB). So it is much more efficient.
|
|
Don't use CamelCase in functions and try to keep area affected first, and action last, in names
|
|
You need to make sure that ray_start is really far away, because even in the Orthografic view, in some cases, the ray can start inside the object
|
|
new struct `SnapData`
In order to simplify the reading of these functions, the parameters: `snap_to`, `mval`, `ray_start`, `ray_dir`, `view_proj` and `depth_range` are now stored in the struct `SnapData`
|
|
viewport.
Caused by rBd6cf28c5e15739f864fbf04614c2a50708b4b152, which forgot to
update the GLSL code for the "Light Path" node.
|
|
|
|
Armature edit mode
|
|
Armature edit mode
|
|
Checking only whether mverts is same as base mesh one is not enough in
all cases, some modifiers (deform ones) can only generate new mvert
data, while keeping others from original mesh.
Now checking both mvert or medge, hopefully this will be enough to catch
all problematic cases this time.
Thanks @gaia for finding that problem. :)
|
|
Custom normals need Autosmooth setting to be enabled, always!
|
|
evaluation.
Those could stay around, and be displayed in 3DView even when autosmooth
was disabled (but would not be 'active').
|
|
'BLI_bvhtree_find_nearest_to_ray' in transform_snap_object
Although the "BLI_bvhtree_find_nearest_to_ray" function is more practical than the generic "BLI_bvhtree_walk_dfs", it does not work to snap in perspective view. This makes it necessary to add "ifs" and functions that make the code difficult to understand
patch: D2474
|
|
We are not bumping file version, but we cannot have the doversion code running twice.
In this particular case it was crashing files, since we were setting node->storage to NULL, and later on accessing it.
|
