Snapping actually was working already, but grid spacing was set to 1.0, which is basically pixel size in the node editor. Increased this to 1x grid step for fine snapping and 5x grid step for rough snapping.
Grid drawing in node editor now draws 2 levels in slightly different shades to indicate the different snapping modes better.
Node editor also supports the general use_snap tool setting to enable automatic snapping during transform. For now only the incremental snapping is supported, in future could be extended to enable alignment between nodes in a number of ways.
the idea of using methods instead of attributes is to avoid users abusing of the system calls.
Thanks Campbell Barton for reviewing and small corrections
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)
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.
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.
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).
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.