| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Snap code may be called with a NULL region, add check about this and assume ray_start is OK in this case!
|
|
|
|
I hope this time we are done!
|
|
Issue partially caused by own errors (glicth in new BKE_boundbox_ray_hit_check() code causing segfault in volume snapping,
and we have to treat ortho and persp differently in case of face snapping, because in persp our ray_start might very well
already be *inside* the boundbox of the checked object), and partly due to the fact that ED_view3d_win_to_vector()
was returning wrong vector (negated one) for ortho views (see previous commit).
|
|
Also allowed me to fine another potential issue, hit.dist was no more initialized correctly - and I had forgotten to take into account Brecht's remark about normalize_v3() also returning the vector's previous length.
|
|
Issue is caused by start point of ray used to detect faces under the mouse is set rather far away in ortho 3dviews.
The loss of precision on the ray location induced by this can lead to face snapping failures.
Solution is to do the raycasting with a temp start point, much closer to the object we check, and add back
to the found distance the diff to the real start point once detection is done (as we need all hit distances
from all tested objects to be relative to a common point!).
Note this commit only addresses the "face snapping on mesh" case, other kind of snapping do not seem to suffer
from this issue.
Reviewers: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D268
|
|
Found three cases where created bvhtree was not freed...
|
|
This was caused by recent change to transform locations being changed
to the upper-left corner of nodes (rBa857a6f).
|
|
Summary:
Made objects update happening from multiple threads. It is a task-based
scheduling system which uses current dependency graph for spawning new
tasks. This means threading happens on object level, but the system is
flexible enough for higher granularity.
Technical details:
- Uses task scheduler which was recently committed to trunk
(that one which Brecht ported from Cycles).
- Added two utility functions to dependency graph:
* DAG_threaded_update_begin, which is called to initialize threaded
objects update. It will also schedule root DAG node to the queue,
hence starting evaluation process.
Initialization will calculate how much parents are to be evaluation
before current DAG node can be scheduled. This value is used by task
threads for faster detecting which nodes might be scheduled.
* DAG_threaded_update_handle_node_updated which is called from task
thread function when node was fully handled.
This function decreases num_pending_parents of node children and
schedules children with zero valency.
As it might have become clear, task thread receives DAG nodes and
decides which callback to call for it.
Currently only BKE_object_handle_update is called for object nodes.
In the future it'll call node->callback() from Ali's new DAG.
- This required adding some workarounds to the render pipeline.
Mainly to stop using get_object_dm() from modifiers' apply callback.
Such a call was only a workaround for dependency graph glitch when
rendering scene with, say, boolean modifiers before displaying
this scene.
Such change moves workaround from one place to another, so overall
hackentropy remains the same.
- Added paradigm of EvaluaitonContext. Currently it's more like just a
more reliable replacement for G.is_rendering which fails in some
circumstances.
Future idea of this context is to also store all the local data needed
for objects evaluation such as local time, Copy-on-Write data and so.
There're two types of EvaluationContext:
* Context used for viewport updated and owned by Main. In the future
this context might be easily moved to Window or Screen to allo
per-window/per-screen local time.
* Context used by render engines to evaluate objects for render purposes.
Render engine is an owner of this context.
This context is passed to all object update routines.
Reviewers: brecht, campbellbarton
Reviewed By: brecht
CC: lukastoenne
Differential Revision: https://developer.blender.org/D94
|
|
constrained)
Currently we don't properly support snapping + axis-constraints, but
there are cases where its handy to project-snap for eg, and constraint
to an axis so re-enable this.
|
|
|
|
addition)
|
|
|
|
This adds vertex snapping capabilities for curves. Snaps to all control points
of other objects, and visible + selected control points and handles in curve
edit mode.
Reviewed By: brecht
Differential Revision: http://developer.blender.org/D3
|
|
instead of using incremental offset (which is not useful for nodes). Increment snapping has been disabled for nodes to avoid
confusion, grid snap is now the default as it seems to be the most wanted and easy to use mode.
Absolute grid snapping happens in a somewhat generic function 'applyGridAbsolute', which could also be used for objects and other transforms later on. It is conceptually similar to the 'project' snapping
option, in that it calculates a delta vector for each element on top of the overall transform, which places each node on the grid.
Node transform now uses the top-left node corner for TransformData->loc. The transform center is still the average of node centers, so that scaling and rotation works nicely.
snapGrid*** functions have been renamed to snapGridIncrement*** to distinguish better between incremental and absolute grid snapping.
|
|
It wasn't enabled in snapping code from the beginning it seems,
but from quick tests snapping for mballs works just fine.
Maybe we could drop out check for edit object type now?
|
|
since enough bmesh operations can also take advantage of direct index lookups on verts/edges/faces.
developers note:
- EDBM_index_arrays_init/ensure/free -> BM_mesh_elem_table_ensure/init/free
- EDBM_vert/edge/face_at_index -> BM_vert/edge/face_at_index
- EDBM_uv_element_map_create/free -> BM_uv_element_map_create/free
- ED_uv_element_get -> BM_uv_element_get
|
|
redraw flag were mixing up types - int/char/bool, add enum type to use instead.
|
|
new files use this field for other flags)
|
|
|
|
This means it's possible now to snap stuff to
reconstructed tracks positions.
|
|
|
|
|
|
lookups.
|
|
|
|
- when in wireframe mode: don't snap to faces, instead snap to the closest edge/vertex.
- when not in wireframe mode: snap to the front-most element (was a problem that it could snap to an edge/vert behind the face)
- reduce the distance for selecting ruler points, was too easy to accidentally drag a ruler.
|
|
(incase its a dupli).
|
|
inefficient (unneeded loops, not breaking out of face loop early).
also correct own oversight - use TRANSFORM_DIST_MAX_RAY rather then when checking for max value in snapDerivedMesh.
|
|
Casting a ray onto an editmesh was building a derivedMesh, raytree, then freeing for every ray-cast.
Noticed while using ruler+snapping in editmode.
Instead of attempting to align the MFace and edit-mesh tessfaces, just use editmesh for ray-casting.
|
|
add clip option to ED_view3d_win_to_ray(), ED_view3d_win_to_segment()
|
|
BKE_editmesh_bvh.h
|
|
the dist, this is to better support multiple calls to ray-cast where only closer distances are accepted.
|
|
EditDerivedBMesh.tc -> em. ('tc' is odd name which isn't used elsewhere).
|
|
snapObjectsRayEx().
|
|
ray cast function, very useful to be able to cast rays into the scene for scripts.
hit_co, hit_no, success = scene.ray_cast(start_co, end_co)
|
|
Individual transformation now works in editmode mesh faces/edge, armature bones and metaballs.
|
|
also expose snapObjectsRayEx() for more convenient ray-casting about the scene.
|
|
|
|
don't do projection when constraints are used.
|
|
|
|
|
|
FLT_MAX.
|
|
|
|
|
|
don't interpolate projection, just project all points within the PET radius.
|
|
when Proportional Editing mode is active, regardless of influence radius
|
|
filling it for verts/edges/faces on every redraw.
this may introduce bugs which I didn't catch, but they are very easy to identify in a debug build which has asserts to ensure the arrays are valid before use.
in my own test drawing ~98,304 quads - this gave an overall ~16% drawing speedup.
|
|
|
|
|
