* 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.
- Addons and locales now points to v2.70-rc tag
- Also updated hashes for addons_contrib and scons
to make them up-to-date while i'm on updating this
hashes.
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.
There were loads of issues in the code still which are mow likely fixed:
- Hole resolver hook had memory leak -- it didn't free face with holes
when triangulating it.
- Original edge mapping didn't work correct. old code related on the fact
that loop order is not changing when constructing the MeshSet class, but
in fact it does change.
Currently used edge map for this because it was easiest way to do it now,
but after the release we're to change it. Main reason is that face mapping
is not correct as well (and it was never correct actually). So we'll need
to construct Mesh structures by our own to be sure we're using correct
original index mapping.
- Carve might produce faces with ears, which is forbidden in Blender.
it wasn't an issue in old integration because triangulation will remove
the ears. So for now simply added ears removing back as a hook.
But actual reason of the ears is to be investigated really.
This hook will only work for NGons, quads are assumed not be able to
have ears. So this additional hook shouldn't slow down things much.
- Carve's hole resolver produces duplicated faces in some cases. Still not
sure what is the reason of this. Code here is not so much straightforward,
this is to be investigated later.
For now solved the issue as own hole resolver which checks for duplicated
faces after the hole resolving.
The additional checks here will only run if the mesh actually have hole
and wouldn't introduce slowdown for faces which doesn't have holes.
- Made it so if edge user triangulation gets a split (for example, in cases
when this edge intersects with the second operand) it wouldn't be dissolved.
This prevents cases of crappy topology after dissolving in several cases.
- Edge dissolver didn't check for whether edge is a non-manifold. We couldn't
really dissolve open manifold edges.
The bad thing about this is that mesh triangulation might produce non-manifold
edges and they wouldn't be dissolved. Not worst case in the world, but would
be nice to have it solved somehow.
- Exporting mesh form Carve to Blender might have produced duplicated edges
in cases when several non-manifold faces shared the edge. This is also fixed
now.
- Mesh triangulation might have produced duplicated faces, which is really bad.
Fixed by keeping a track on which faces we've created and skipping adding new
triangle if we already have one.
This all might introduce some slowdown, but we're too close to the release now,
so would rather have it slower but robust. After the release we might look into
ways to speed things up.
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.
