Cleanest way here is not do bounding box collision for editmeshes at
all. Decision is taken because:
* Usually we want to do the snapping to the edited mesh anyway (when we
don't the mesh is skipped completely, so we don't need to worry for
extra checks)
* Bounding box is calculated from derived mesh. This means that for
subsurfed meshes for instance, the bounding box may be significantly
smaller than the size of the edit mesh.
Looks like the cleanest way to handle this is to no do bounding box collision
for edit mode at all. But this is easy to enforce
This reverts commit 7b5fe4f316.
Conflicts:
source/blender/editors/transform/transform_snap.c
When autosnap mode was nearest frame or nearest marker, this was incorrectly
converting the units to seconds, making this display unusable for anything.
slightly outside the mesh.
Reported by Thomas Beck on irc. Issue here is that the mesh bounding box
changes as we are transforming the vertices. Solution is to collide
against the initial bounding box. Unfortunately the snapping functions
are made in a way that a lot of code needed to be tweaked here, but the
change should be straightforward and harmless (famous last words, I
know).
Ideally we might want to even increase the size of the bounding box a
little (as seen in screen space) to allow snapping even in cases where,
cursor is slightly outside the bounding box, but since this is not so
straightforward to do for all cases, at least for me, leaving this as
a TODO.
They were using INPUT_SPRING in a way which didn't allow
it to easily redo the operator because INPUT_SPRING internally
is stored as a ration between old value and new one and crease
and bevel were converting this to value delta.
Now made it special input type INPUT_SPRING_DELTA which is
storing delta of the spring, meaning now values in the redo
panel kind of makes sense -- they mean how much to add/remove
to the crease/bevel weight.
Expect to be no functional changes from interactive transform
POV, just a bit more convenient to use redo panel.
Turned out there was still quite a few cases were indices were set dirty,
but elem_index_dirty was not tagged accordingly (mostly for BM_LOOP,
but a few others as well). So probably this crash was not the only one
hidden here.
Hopefully all possible cases were catched this time!
Sculpt mode drawing fails after deleting a subsurf modifier
in sculpt mode and undoing.
This was quite difficult to spot. Main cause was that mesh data was not
synchronized properly between undo and sculpt code because we generated
a pbvh on derivedmesh invalidation without really refreshing the rest of
the data. This could result in undo and drawing operating on different
data.
To solve this and avoid bad level calls I had to move quite some code
around. Crazyspace is now moved to blenkernel, as did some sculpt calls
that make sure sculpt data are properly refreshed.
Since autosnap was being applied during the flushing step for various practical reasons,
it wasn't possible to restore keyframes and handles to their original values, as these
would always get overwritten before getting a chance to be written back to the keyframes.
Since the NLA was also using the standard transform mode by default, this meant that
no frame/second step-snapping was happening here (i.e. like for the Graph Editor).
The actual differences between doing true stepping vs nearest here are quite small
(and don't really make much sense with NLA Strips), so for now, it should be fine that
these are the same.
The previous behaviour for nearest second meant that transforming the strips often
caused their lengths to change (sometimes drastically), since strip lengths aren't
always uniformly x-seconds long. Now, it only snaps the start frame value, and adjusts
the end of the strip to follow.
This works well for most cases, apart from negatively scaling the strip, where it will
get "stuck" as a 0.001 frame long strip (and the viewport drawing will be a bit weird
during this time). Nevertheless, negative scaling of strips isn't something that's exactly
recommended.
This commit cleans up and fixes some problems related to how the auto-snapping
behaviour in the animation editors works, resolving the issues mentioned in T39819.
1) "Nearest Frame" no longer snaps to the nearest second when time is displayed in seconds.
Instead, there is now also a "Nearest Second" option, so that either can be used
as needed instead of only when a certain time display is used.
2) A similar change has been made for "Time Step" - This is now "Frame Step" and "Second Step"
respectively.
Notes:
* Removed the unneeded getAnimEdit_DrawTime()
* Time Step/Frame Step don't work for Graph Editor yet (and seem to not have worked at all)
* NLA Editor also seems to be showing some weirdness now. Will be checked on.
* Cancelling nearest-second snapping doesn't work nicely, due to another bug with GraphEdit transforms.
View2D had some inconsistencies making it error prone in some cases.
- Inconstant checking for NULL x/y args.
Disallow NULL args for x/y destination pointers, instead add:
- UI_view2d_region_to_view_x/y
- UI_view2d_view_to_region_x/y
- '_no_clip' suffix wasn't always used for non-clipping conversion,
switch it around and use a '_clip' suffix for all funcs that clip.
- UI_view2d_text_cache_add now clips before adding cache.
- '_clip' funcs return a bool to quickly check if its in the view.
- add conversion for rectangles, since this is a common task:
- UI_view2d_view_to_region_rcti
- UI_view2d_region_to_view_rctf
