This comes out of considering a one-dimensional transition in weight
on a rectangular cloth grid. At the transition face loop, one side
of each rectangular face would be scaled by k1, and the opposite one
by k2, thus turning the rectangle into a trapezoid. Averaging would
be used to choose the scale factor for the remaining two sides.
If Geometrical Mean, i.e. sqrt(k1*k2) is used, it so happens that the
diagonals of the trapezoid also end up scaled by sqrt(k1*k2) compared
to the original rectangle. This means that the same scale factor is
correct for both structural and shear springs, which is not the case
with simple average.
Previously it was all over the place: without a vertex group it was
always enabled, and with it it depended on the Self Collision option
due to a likely editing mistake. Now it should be in sync with what
disables the fields in the UI.
The verts->shrink_factor field is changed to just cache the vertex
weight, with the shrink_min/shrink_max interpolation done later.
This is because cloth_apply_vgroup only runs if there are vertex
groups, and thus the factor may not update after property changes.
In addition, bending springs are now also affected by the shrink
factor to avoid visible distortion in object shape at high shrink.
From description, Use Coordinates evaluates the texture using
target coordinates in the local space of the force field object.
2D is supposed to ignore the Z coordinate. Thus one would assume
that if both are enabled, the force field effect would move with
the force field object, and Z would be 0.
However, instead first the 2D option projects points onto a plane
passing through the global zero and orthogonal to the local Z,
and only then the resulting point is transformed into local space.
Z is not locked at 0, so procedural textures like Spherical Blend
don't work as expected.
To fix this, apply local transform first, and then just clear Z if 2D.
Separate the creation of trees from EditMesh from the creation of trees from DerivedMesh.
This was meant to simplify the API, but didn't work out so well.
`bvhtree_from_mesh_*` actually is working as `bvhtree_from_derivedmesh_*`.
This is inconsistent with the trees created from EditMesh. Since for create them does not use the DerivedMesh.
In such cases the dm is being used only to cache the tree in the struct DerivedMesh. What is immediately released once
bvhtree is being used in functions that change(tag) the DM cleaning the cache.
- Use a filter function so users of SnapObjectContext can define how edit-mesh elements are handled.
- Remove em_evil.
- bvhtree of EditMesh is now really cached in the snap functions.
- Code becomes organized and easier to maintain.
This is an important patch for future improvements in snapping functions.
Using SSE2 intrinsics when available for this kind of conversions.
It's not totally accurate, but accurate enough for the purposes where
we're using direct colorspace conversion by-passing OCIO.
Partially based on code from Cycles, partially based on other online
articles:
https://stackoverflow.com/questions/6475373/optimizations-for-pow-with-const-non-integer-exponent
Makes projection painting on hi-res float textures smoother.
This commit also enables global SSE2 in Blender. It shouldn't
bring any regressions in supported hardware (we require SSE2 since
2.64 now), but should keep an eye on because compilers might have
some bugs with that (unlikely, but possible).
FSAA sample files in EXR format are no longer always updated (after some
changes between 2.73 and 2.74 releases), and the reported bug was caused
by old samples from a previous frame that were being merged by mistake.
The present revision addresses the documented issue by entirely skipping
the rendering of auto-generated scenes when there are no Freestyle strokes
to render, which suppresses sample merging of the render layers that were
not rendered.
Just avoid some unneeded initialization functions when the threaded
processor is simple enough to only depend on current chunk start
scanline and number of scanlines.
