Separate the creation of trees from EditMesh from the creation of trees from DerivedMesh.
This was meant to simplify the API, but didn't work out so well.
`bvhtree_from_mesh_*` actually is working as `bvhtree_from_derivedmesh_*`.
This is inconsistent with the trees created from EditMesh. Since for create them does not use the DerivedMesh.
In such cases the dm is being used only to cache the tree in the struct DerivedMesh. What is immediately released once
bvhtree is being used in functions that change(tag) the DM cleaning the cache.
- Use a filter function so users of SnapObjectContext can define how edit-mesh elements are handled.
- Remove em_evil.
- bvhtree of EditMesh is now really cached in the snap functions.
- Code becomes organized and easier to maintain.
This is an important patch for future improvements in snapping functions.
This introduces a snap-context that can be re-used for casting rays into the scene
(by operators such as walk-mode, ruler and transform code).
This can be used to cache data between calls too.
Same causes as when snapping to faces, so same solution: in case of ortho view,
offset start of ray to be just slightly outside of the target's bbox, to avoid
too much far away start point that generate floating point computation instability
in BVH raycasting.
Note that this lead to some refactoring, to avoid duplicating too much of code.
For now, edge snapping seems to behave OK (uses different logic), so not touched.
Based on patch by Germano Cavalcante (@mano-wii), thanks!
In some cases transform modes would use the custom-data pointer,
other times the transform conversion functions would.
However with some combinations (bone mirror + bend for eg),
both conversion & transform mode would use this pointer causing a crash.
Fix this by having 2 custom-data pointers:
one for the mode, another for the data-type.
This also simplifies time-slide which was conditionally mixing mode/type data in the one array.
Checking for 'Closest' here isn't needed since
TransSnap.snapTarget callback is already ensuring the selected target is the closest.
Also don't reuse the pre-calculated distance,
since its only valid to do this when there are no snap points
and this isn't a significant gain to avoid the extra calculation - run once per update.
We cannot use FLT_MAX as initi distance for raycast...
Renamed TRANSFORM_DIST_MAX_RAY to BVH_RAYCAST_DIST_MAX, moved it into BLI_kdopbvh,
and use in RNA raycast callbacks (and all other places using that API).
This was getting very hard to follow,
- mixing input/output args.
- mixing arg order between functions.
- arg names (mode, snap_mode) rename to (snap_to, snap_select)
Added a helper that ensures a bbox has some non-NULL dimension along all its axes.
Also, fixed some (rather unlikely) NULL dereference cases (though it should not in this context,
`BKE_object_boundbox_get()` can return NULL).
Was performing ray-tri intersection checks on all faces.
Note, this isn't using isect_ray_tri_threshold_v3
which was used to prevent ray-casts slipping through between faces.
Instead we'll move to using watertight intersections by default.
Excuse the trashing here, but seems users prefer this most (though both can be useful).
Note that the UI remains the same,
so this is an option for 'Incremental' snapping instead of a new snapping mode.
New 'strip' snapping was simply not computed in case of constrained transform, hence init
'0' value was used as frame offset in this case.
This commit reorganizes a bit that snapping, to keep it more 'confined' into `snapSequenceBounds()`
dedicated function. It still needs a minor hack (setting snapping mode to something else than
defualt `SCE_SNAP_MODE_INCREMENT`, to avoid this snapping to be called by contraint code).
Thanks to Antony for review and enhancements.
This fix should be backported to 2.74.
This patch includes the work done in the terrible consequencer branch
that hasn't been merged to master minus a few controversial and WIP
stuff, like strip parenting, new sequence data structs and cuddly
widgets.
What is included:
* Strip extensions only when slipping. It can very easily be made an
option but with a few strips with overlapping durations it makes view
too crowded and difficult to make out.
* Threaded waveform loading + code that restores waveforms on undo (not
used though, since sound_load recreates everything. There's a patch for
review D876)
* Toggle to enable backdrop in the strip sequence editor
* Toggle to easily turn on/off waveform display
* Snapping during transform on sequence boundaries. Snapping to start or
end of selection depends on position of mouse when invoking the operator
* Snapping of timeline indicator in sequencer to strip boundaries. To
use just press and hold ctrl while dragging.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D904
Basically, get the grid increments and reuse them when snapping. System
is slightly crappy here, we should calculate those factors only once,
but leaving as todo for later.
Use BLI's `rotation_between_vecs_to_mat3` helper instead of own custom code,
both simplifies the code and fixes wrong handling when snapped normal was exactly
opposed to org one (i.e. 180° rot case).
