Now Alt+RMB,RMB will select all connected boundaries.
There are times when you just want to select an entire boundary loop
ignoring face topology, previously there was no way to do this.
Dyntopo detail in object space. This allows to set the detail in
percentage of blender units and sculpt in this detail constantly,
regardless of the distance to the mesh.
This commit just enables the functionality, which is really trivial.
There will be some more commits like detail flood fill and
detail sampling in the future.
The problem here is that the redraw rectangle can be calculated many
times before actual redraw (for instance due to repetitive calls to the
paint step function for space strokes). Those redraw rectangles need to
be accumulated and finally flushed when the draw call is done.
Also, it is this accumulated rectangle that must account for the
previously drawn rectangle to avoid artifacts due to drawing.
Now all looks like it works correctly :)
after the stroke so that it can be unioned with current rect correctly
during the draw update. For some reason dyntopo clipping misbehaved
before that.
For very thin faces, knife sometimes missed cutting a few.
Problem was that a test for edges being totally inside a face
was being applied in inappropriate circumstances. An assumed
invariant about the knife hit structure is not true when
actually in the middle of making cuts.
Also make a 'big epsilon' a little smaller, though don't think
that was the problem in this bug.
* Do union with previous partial redraw before overwriting with self and
store unmodified new rect to avoid rect getting bigger.
* Make rect one pixel wider instead of smaller so edges do not get left
outside. Overall this looks quite better.
Basically proxy colorspace didn't work well enough.
It is still a bit weird and mainly:
- Proxies for image sequences are built in the image color space.
- Proxies for movies are built in the movie color space.
This could be unified but would need some work in proxy build
to make it not just pipe frames from one FFmpeg context to
another but also apply OCIO on it.
Testing for custom data availability with getVertData and index 0 fails
on assert for empty meshes (the index must be in valid range). Better
use getVertDataArray which has no requirement for specific index.
The problem is that comparisons involving the constants Nature.POINT (for vertices) and
Nature.NO_FEATURE (for edges) were evaluated in a wrong way. It is recalled that the
Nature class is a subclass of Python's built-in int type, and that these two constants are zero
when evaluated as numbers. The issue was caused by the implementation of the constants
in an incompatible way for comparison with Python int (and boolean) values. Specifically,
the zero of Python int is represented by an empty array of digits, whereas the zero-valued
Nature constants were represented by an array of size 1. Python int comparison operators
first check the lengths of the arrays of two operands, and then start comparing the digits
only when the array length is the same. For this reason, the two Nature constants were
not properly compared with int values (and thus with boolean values). It is noted that the
zero-valued Nature constants may result from bitwise operations on other Nature constants
(e.g., Nature.SILHOUETTE & Nature.BORDER), so this issue must have affected many
existing style modules.
The problem was reported by Folkert de Vries (flokkievids) through personal communications.
Thanks a lot!
Last change to bevel had a check for what was supposed
to be an "on edge" new vertex being off the edge.
The test tolerance was too small. This fixes that.
This made loops in linked lists of uvedges from duplicate members
causing a hang. Now check all previous links before adding a new one. It
is not much slower in practice because non-manifolds are not that
frequent.
to wrong obmats of nested dupli objects.
Restoring obmats after BI nested dupli object rendering has to happen
in reverse order, so higher level omats are applied last.
If you have two overlapping NLA strips it automatically blends between them.
However it was also blending between the first strip and the rest pose
(e.g. 0,0,0 for locations and 1,1,1 for scale).
This is ok if the blend mode is Add or Multiply since then you are adding onto
the rest pose, but for Replace you want to be able to mix between two poses
and not take the rest pose into account at all.
What this does is that to not do any blending for the first strip if it has
blend mode Replace. If someone wants the old behavior (from bugfix commit
27d792fa9c) they can still make an action with the rest pose and use that
as the first strip.
