| Age | Commit message (Collapse) | Author |
|---|
|
Using near far and optionally clipping planes is
involved and not needed in many cases.
Rename so a simpler version of this function can be added.
|
|
This commit actually adds some G.main... but at much, much higher level
than the ones it removes, so should still be better ;)
|
|
Some snap functions already exposed this.
|
|
This will allow greater control of the bvhtrees that are obtained, and helps identify problems.
It is also an additional step to unify the functions.
|
|
identifier type.
Reviewed By: @campbellbarton
Differential Revision: https://developer.blender.org/D3192
|
|
|
|
|
|
a dependent object
The idea of this flag was to prevent snapping onto an object which depends on
currently modifying ones. Using single flag makes more sense here, and also
makes it possible to replace some ob->recalc based magic with depsgraph query
to set those flags.
|
|
It looks stupid to first force some flag being set and then have workaround
to ignore that flag in snapping code. Let's just not set the flag in the first
place.
The only useful situation where such snapping was usable is to move roots of
disconnected hair, which still works just fine. However, there might be some
other hidden corner case where this workaround was needed.
|
|
Convention was only followed loosely,
apply to DNA where changes aren't likely to conflict.
(Skipped ModifierType for eg).
|
|
`depth_get` is called in most of the time. So not worth going through so many conditions
|
|
Caused by own recent changes in handling of verts/edges/etc. arrays storage
for raycasting (rBe324172d9ca6690e8).
Issue was actually even weirder - there is absolutely no reason at all to
release DM here, those finaldm are stored in Object or EditMesh structs and
handled by general update system, other code shall never try to release them!
|
|
arrays again from DM.
This was... horribly wrong, CDDM will often *not* need to allocate
anything to return arrays of mesh items! Just check whether array
pointer is NULL.
Also, remove `DM_get_looptri_array`, that one is useless currently,
`dm->getLoopTriArray` will always return cached array (computing it if
needed).
|
|
|
|
(alt + b) is not bypassed in snap to faces"
This reverts commit 7f09b55d01c248a741e967af597b7519f095983b.
|
|
is not bypassed in snap to faces
The geometry behind the farther clip_plane is not bypassed
|
|
|
|
Moving the ray_start_local to the new position does not lose as much precision as moving the ray_org_local to the corresponding position.
The problem of inaccuracy is within the functions: `bvhtree_ray_cast_data_precalc` and` fast_ray_nearest_hit`. And not directly in the values of the rays.
|
|
|
|
*note: make a complete test scene
|
|
Macro makes debugging difficult. And in that case I was escaping from the style used in Blender
|
|
|
|
This would bring problems with dupli objects
|
|
The macro got a little strange, but it's better than using the MEM_mallocN inside a loop, or repeat the lines
|
|
|
|
|
|
That problem occurs because of the imprecision of `short int` (16 bits).
The 3d coordinates are converted to 2d, and when they are off the screen, their values can exceed 32767! (max short int value)
One quick solution is to use float instead of short
The snap code is actually a little tricky. I want to make some arithmetic simplifications in it
|
|
|
|
The only similarity between these functions is that both serve to snap.
However their codes are totally different from one another.
So by separating these functions, it:
- removes the need to put several conditions;
- simplifies and
- optimizes the code
|
|
Also remove duplicate & mismatching comments from grease-pencil header.
Keep comments close to implementation to avoid getting out of sync.
|
|
|
|
|
|
the `dm->release(dm)`
|
|
The bug T46099 no longer applies since the addition of `dist_squared_to_projected_aabb_simple`
Has also been added comments that relates to an occlusion bug with the ruler. I'll investigate this.
|
|
|
|
`transform_snap_context_project_view3d_mixed` with `dist_px` NULL
|
|
Ray_start and ray_normal values were being ignored
|
|
Looks like `object_map` and `mem_arena` may be NULL sometimes...
Also, cleaned up function pointers declaration of Nearest2dUserData,
those were warning out in gcc. Please, *always* use typdef defined
prototypes for function pointers, it is sooooo much cleaner and clearer
that way. And easy to convert from compatible functions too.
|
|
DerivedMeshs and Bmeshs
Before it was informed the type of object in the `userdata`, and a same function ran between the types to obtain the coordinates of the vertices
|
|
Since the cache is created in one way or another, this flag is not really making a difference
More details here: D2496
|
|
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.
|
|
|
|
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
|
|
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
|
