In cases when the subsurf modifier is the last in the stack and there
are only deformation modifiers before it we can skip doing full orig
vertex lookup.
This is rather common situation here in animatic.
Constraint space conversion ignores object scale, which is OK in most cases. But here,
we are converting a normal from world to local space, and when later converting it
into target space to actually do the BVH raycast, we use TransformSpace which
does applies objects' scaling to normals, as expected.
Best solution here is to also take object's scale into account when converting
from local to world space.
This was never ported to a new tracking pipeline and now it's done using
FrameAccessor::Transform routines. Quite striaghtforward, but i've changed
order of grayscale conversion in blender side with call of transform callback.
This way it's much easier to perform rescaling in libmv side.
The title actually tells it all, this commit switches Blender to use the new
autotrack API from Libmv.
From the user point of view it means that prediction model is now used when
tracking which gives really nice results.
All the other changes are not really visible for users, those are just frame
accessors, caches and so for the new API.
This is only an indirect fix, in fact: this commit adds a public API to check
the maximum number of a given layer type (`CustomData_layertype_layers_max()`),
and uses it to forbid too much layer creation in `CustomData_merge()`.
This only affects UVs/VCol data though, but merge behavior in itself is not a bug
actually, how user managed to get thousands of different UV layer names remain
rather mysterious...
Vertex parent was using original non-modified nurbs list, simply because
it didn't have something else to operate with.
Now we've got deformed by pre-tessellation modifiers nurbs in the curve
cache which might be used y the vertex parent.
Main moving logic is moved to new `BKE_keyblock_move()`, which makes it available from anywhere.
In addition, move code was reworked so that it only loops once on whole keyblocks list,
and it accepts arbitrary org and dest indices, not only neighbor ones.
Partly based on work by revzin (Grigory Revzin) in his soc-2014-shapekey GSoC branch, thanks!
Features:
* Both still image and animation rendering, as well as polygon
fills are supported.
* The exporter creates a new SVG layer for every Freestyle line
set. The different layers are correctly sorted.
* SVG paths use data from line styles, so the base color of a
line style becomes the color of paths, idem for dashes and
stroke thickness.
* Strokes can be split at invisible parts. This functionality is
useful when exporting for instance dashed lines or line styles
with a Blue Print shader
* The exporter can be used not only in the Parameter Editor mode,
but also from within style modules written for the Python
Scripting mode.
Acknowledgements:
The author would like to thank Francesco Fantoni and Jarno
Leppänen for their [[ https://github.com/hvfrancesco/freestylesvg | Freestyle SVG exporter ]].
Differential revision: https://developer.blender.org/D785
Author: flokkievids (Folkert de Vries)
Reviewed by: kjym3 (Tamito Kajiyama)
Just do not use crazyspace correction with childof constraints in this case.
Note this is only a very partial fix (partial use of parent loc on some axes
is still broken in transform), a real fix would probably require a full rewrite
of constraints handling in transform code (a mere static correction matrix
just cannot work in all possible cases, we'd need a full dynamic correction system here).
Anyway, transform code as a whole is horrible. :/
Make sure the 1.0 value is not affected by smoothing, and min/max limits
never go above or below 1.0 respectively. This was a request by
animators since not modifying the mesh in its rest pose is regarded as
crucial.
Currently the volume variation feature in stretch constraints is
unlimited. This has to be compensated by riggers by adding scale limit
constraints, but these are unaware of the stretch orientation and can
lead to flipping. Also the stretch calculation itself is not working
properly and can lead to collapsing volume.
The patch fixes this with several modifications:
- Interpret the volume variation factor as exponent, which works better
with large values for artistic purposes.
- Add integrated limits to the volume "bulge" factor, so secondary
constraints for compensation become unnecessary
- Add a smoothness factor to make limits less visible.
Eventually a generic volume preservation constraint would be nicer,
because multiple constraints currently implement volume variation of
their own. This feature could actually work very nicely independent from
other constraint features.
Differential Revision: https://developer.blender.org/D826
The reported issue was caused by a backward incompatibility due to careless
code changes made when per-material Freestyle line colors were introduced
in rB7915d7277ac8c605f016f30f943080556244fb59. In 2.71 line style
Material color/alpha/thickness modifiers was retrieving alpha transparency
from Material.alpha, whereas in 2.72 Material.line_color[3] was referenced.
The present fix reverts the aforementioned code changes.
This issue is a regression from 2.71, so the fix is appropriate for inclusion in
the 2.72a release.
* Consider non-manifold edges as sharp, as in split normals handling.
* Consider edges from sharp polys as sharp!!!
* Fix returned number of groups (was off-by-one for non-bitflags grouping, could also
be wrong in case of id overflow).
Note about using sharp polys too to define groups: Only current use of this function
(Obj exporter) does not need that, because it does its own check for sharp faces.
However, we might reuse that func in other places in future (e.g. in custom split
normals area), so better to get a consistent behavior!
Two fixes here (only the second one is strictly needed to fix the issue,
but both make the system better).
First is introduction of a random generator array for use with threaded
systems where each thread needs to access its own number generator.
The random texture now uses this so it should not be influenced by other
random generator reseedings of the main random generator like it did
before.
Second, I reshuffled the texture code to resample the upper bits of the
random number first. According to Numerical Recipes, this is where the
most variance can be found, so by sampling those we avoid correlation
issues. Also, multiplying here is not ideal because if a pair of bits
are zero, then the whole result will also be zero.
Overall this is much more random (tm) than before, however result will
also be brighter, since we now have less black spots. Tweaking the
brightness/contrast should somewhat fix that, generally having the same
result as before is not possible anyway if we are to really fix this.
Also, seems like exposing procedural depth might be nice here since it
influences the precision of the texture lookup.
