| Age | Commit message (Collapse) | Author |
|---|
|
mistake in r50086 caused the crash (killing the wrong vertex)
|
|
floating point error.
|
|
was not selected. Now changed it so that the active face must also have its
UVs shown in the image editor to be used as the source of the image shown.
|
|
|
|
var in math_rotation.c
|
|
|
|
|
|
|
|
problem since bmesh merge, new edges were not selected.
|
|
The vertex shapekey index is now no longer copied, and propagation of offsets
in the basis to other shapekeys is disabled if new vertices were added. The
reason being that the propagation will only be done for the old vertices leaving
the new ones behind, and so doing e.g. subdivide + translate on the basis would
create a mess on other shape keys.
|
|
|
|
- bridge-merged now merges edge customdata and flags for verts and edges.
|
|
factor to blend between loops.
|
|
|
|
in some cases, in particular when the the edge loops were not planar.
Now rather than finding the shortest distance between two vertices, one from
each edge loop and using that as a starting point, it now finds the smallest
sum of distances between all vertex pairs that would be connected.
|
|
was already removing unnecessary edges, just not vertices of those edges.
|
|
- ColorBalanceModifierData wasn't aligned on 32bit systems.
- BM_vert_find_first_loop() was missing NULL check.
|
|
a linked list by a pointer.
|
|
|
|
references in bmesh docs.
|
|
|
|
|
|
|
|
- building without python works again
- rename maxi/mini to i_max/i_min (so thay are available for function names)
- some minor edits to IK stretch setting (no functional changes).
|
|
|
|
|
|
|
|
is to respect hidden geometry.
this is useful for bmesh tools that operate in object mode or for modifiers which would previously use hidden faces in some cases.
|
|
|
|
|
|
|
|
|
|
macros which results in calling the function multiple times needlessly.
also added some comments.
|
|
vertex is on.
this doesnt fix all cases but works better then it did.
|
|
|
|
Main problem was in poly_rotate_plane() (which rotates a ngon to make its normal aligned with Z axis), it did not handled the case where the normal was aligned but opposite to the Z axis (which had the consequence that, as with the T mesh of the given blend, all tested new edges inside face were detected as outside, and vice-versa...).
Additionnaly, I made a mistake in previous Triangulate commit (r48243) in bm_face_goodline, which could allow a few invalid triangles in some specific cases, fixed!
And done a bit of cleanup, as I was at it.
|
|
|
|
|
|
also rename BMO_OP_SLOT_PNT to BMO_OP_SLOT_PTR (matches RNA and sounds less like 'point')
|
|
|
|
|
|
|
|
|
|
wrapper,
argument parsing still needs to have support added for vector, matrix and element types.
|
|
keyword which confuses some IDE's.
also added missing BMO_op_vinitf args to comments.
|
|
The bug is related to 31581 and the main cause is the small offset that
BM_loop_interp_from_face introduces before calculating barycentric
weights. Solved by only calculating displacement layer.
|
|
description for WITH_PYTHON_MODULE.
also disable workaround for some linux installs.
|
|
Add an epsilon value to the point-outside-hull test, helps when some
of the input vertices are nearly coplanar.
Fixes bug [#31941] convex hull fails (and depends on vertex order when it shouldn't)
http://projects.blender.org/tracker/index.php?func=detail&aid=31941&group_id=9&atid=498
|
|
|
|
Issue is that all loops of a face adjacent to the sliding verts were
getting project-corrected. Introduced a test to only project the
affected loops.
The projection code introduces a small offset to the boundaries so that
any boundary tests can work as expected, but this leads to shrinking of
the barycentric coordinates of the projection, causing a shrink of the
uvs in turn. This even affects the uvs that -should- be affected though
the unfixed behavior works strangely in a correctish way (my guess is
because the projection uses the same face as the opposite sliding loop).
I fixed the behaviour by taking the mean value of the uvs. This won't
support seams but current code doesn't either. Also, all CustomData to
exhibit this unfixed behaviour. I only fixed the uv case, other data
(Vcolors, etc) will have discontinuities when edge sliding. I expect
that the CorrectUV code I am working on may address some of these
issues.
Also, added NULL checks for utility function (was intended for this bug
but wasn't needed after all)
|
