| Age | Commit message (Collapse) | Author |
|---|
|
|
|
apps (which is stupid but default value isnt so important).
|
|
|
|
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)
|
|
the iterator initialization function.
|
|
|
|
|
|
|
|
convex_hull at the moment.
|
|
arbitrary sized vectors from python args.
Vector.dot() was always leaking memory, and would crash if args sizes didnt match.
These errors were introduced with n-dimensional vector support.
also fixed an error with bmesh py api allocation.
|
|
triangulation generated for tracks setup
|
|
|
|
Issue was caused by loading editNurb into normal nurbs when saving,
this used to set active nurb to NULL.
This isn't actually needed, because active nurb would be set properly
on making editNurb and even if one accessed to active spline via PY API
when object is in object it'll be completely harmless.
|
|
|
|
When creating tile data include only triangles which have got intersection
with tile's rectangle only. This saves quite a lot of per-pixel iterations
through triangles which simply can not affect on current tile.
In fact, it's AABB check is used here. It could be improved further, but
it'll slowdown tile data generation with questionable speedup.
Another major slowdown is in fact caused by voronoi triangulation code.
Currently it's used naive algorithm which is O(N^2) where N is number
of edges. Added few euristics there and removed unused part of code, which
gave quite noticeable speedup already.
This could be improved further, but this node is not ment to be used for
lots of markers. It's also generates wrong triangulation when there're
many sites used. Need to be investigated further.
|
|
dope sheet.
|
|
|
|
|
|
|
|
switch channel
This was caused by a typo, which would end up toggling the expanded status of
the Grease Pencil datablock (gpd->flag & 4) instead of the layer active status
(gpl->flag & 4).
|
|
clip opened
Reported by JumboCoDeC in IRC. Thanks for the report.
|
|
|
|
mutex lock before allocating the gauss array.
also add suspiciously missing call to BlurBaseOperation::initExecution, X had but Y was missing.
|
|
|
|
separate channels
|
|
|
|
|
|
This helps in cases when it's needed to track a feature which
goes out of screen for a while to prevent jump of camera.
|
|
Revert part of r48105 (calling mouse_mesh() in mouse_mesh_loop() is not a good idea, as it might select another element ouside the selected loop, and is anyway overkill!), added lighter code that simply checks for the nearest vertex/face of current edge.
|
|
|
|
draw mode did not draw the 3d view properly.
|
|
in the outliner.
|
|
then an initializer value.
also quiet warning in cycles.
|
|
|
|
Behaves in the same way as feather dilate/erode node, applies
after dilate/erode in node.
Also use distance dilate/erode instead of size.
|
|
allocated and never freed.
|
|
functions with a macro.
|
|
|
|
Separate X and Y passes of blurring like it's done for flat
gaussian blur. This reduces computing difficulty from size^2
to 2*size without any visual changes in matte.
|
|
|
|
When removing a skin or multires modifier, it skips deletion of the
associated CustomData layer if the object has any other modifiers of
that type. This check has been extended to all objects that use the
object's data.
Similarly, deleting higher multires levels and multires subdivision
will not update the maximum level of any other multires modifiers on
objects that link to the same mesh.
Note that modifier_apply_obdata() doesn't need any changes as it
does not allow applying to multi-user data.
Object joining has also been modified to synchronize multires levels
objects that share a mesh. This is needed because joining can
subdivide or delete levels in order to match the maximum level of the
join-from object to the join-to object.
Fixes bug [#31880] instance multiresolution modifier error.
http://projects.blender.org/tracker/index.php?func=detail&aid=31880&group_id=9&atid=498
Reviewed by Sergey:
http://codereview.appspot.com/6332047/
|
|
|
|
|
|
Notes:
*This implements a quite simple algorithm, which simply checks angles (actually, absolute cosines) of created tri and remaining face (which may be a tri, quad, or more NGon), so that both are "best" (ie avoid as much as possible too much narrow/wide corners), and also checks the new edge is OK (i.e. does not goes "out" of original face).
*Incidently, it fixes a typo in that bm_face_goodline() func!
*It's quite performant (a bit quicker than previous code, as far as I have tested it) and prevent creation of completely flat triangles as much as possible, but it's far from being a "best" solution (as it is still a "progressive" one)!
*It also introduces a new math func (in BLI_math_vector.h), cos_v3v3v3, which computes cosine (ie dot product of normalized vectors) and is roughly a quicker replacement for angle_v3v3v3, when real angles are not needed.
|
|
Use AABB check before calculating barycentric coordinates.
In simple tests with FullHD image and 4-9 tracks used for gradient
gave 1.5-2x speedup.
|
|
|
|
Reported by brothermechanic, thanks!
|
|
*BCon 3 - beta.
|
|
|
|
In fact fixed in easiest way -- always re-calculate knots array
on topology changes.
After some discussion with Ton we agreed on that having manually
editable knots is not intuitive and user should only define
cyclic/endpoints flags and knots would be re-calculated based
on this flags.
This means that it's unnecessary to have special logic for knots
manipulating in some topology changing tools and they could just
re-calculate knots for the whole nurb, without worrying that knots
could have been manually edited.
|
