Goes with companion files bevel_regression.blend
and mesh_ops_test.py just added to svn lib/tests/modeling.
Also changed the blender executable path for Apple case:
needed either 'Debug' or 'Release' in the path. I chose
'Debug', because not sure how to add otherwise. At any
rate, what was currently there didn't work at all.
Added some relevant #defines copied from extern\libmv\third_party\msinttypes to BLI_sys_types.h so they can be used in blenlib. Made smallhash.c use the BLI_sys_types.h include rather than including <stdint.h> directly
The revision is concerned with Interface0DIterator and StrokeVertexIterator.
These iterators can be generated by Interface1D::vertices_end() and
Stroke::stroke_vertices_end(), respectively. These methods return an
iterator poinitng the next index of the last 0D element (i.e., iterator's is_end
property is true). When the iterators created in this way are used with
Python's iterator protocol (e.g., in a for-loop), iterations over 0D elements
are automatically performed in the reversed order. This functionality was
broken after recent revisions concerning Freestyle iterators.
Also made minor code cleanup (white space).
- use magic numbers based on uintptr max, not uint max, to avoid possible collisions with real pointer values on 64bit systems.
- comment BLI_smallhash_remove for now, its not used.
- added smallhash_val_is_used replacing ELEM() checks
- updated docs
- remove static array used only for copying (use alloca on resize)
- set SMSTACKSIZE to one of the values in 'hashsizes' since the full available size was never used.
- ensure ~1.5x as many buckets as entries, was 3x which caused malloc's quite early on.
Exported angles for spot size animation is in radians , however Collada expects it to be in degrees.
This patch is for fixing import and export, and also renaming a variable
Reviewers: gaiaclary
Reviewed By: gaiaclary
Differential Revision: https://developer.blender.org/D273
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).
Found while working on snapping issues, confirmed using bisect tool: previous to this commit, inner/outer parts were swapped when switching from otho to persp!
The laplacian modifiers (smooth and deform) use the OpenNL library,
which is not threadsafe due to the use of a global context variable.
Ideally this would be changed so that an explicit context can be
created for every caller of the OpenNL functions, but since OpenNL's
most recent version is from 2010 this is unlikely to happen.
As a workaround for now just use a mutex to prevent conflicting OpenNL
calls. Eventually OpenNL can be replaced by eigen or ceres.
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.
- BLI_smallhash_remove didnt decrement total entries.
- rename vars to match closer to ghash.
- smallhash_lookup returns NULL when no entry found.
- using a zero value key wasn't supported.
- no need to memset or calloc bucket arrays
- add asserts for unsupported conditions.
- added BLI_smallhash_lookup_p
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
