The node was using sampler from the callee node and passed
it to the input nodes. Since the fact that compositor output
node uses NEAREST interpolation (why it uses nearest is the
whole separate story) it's not possible to have subpixel
precision in such cases:
<image> -> <translate> -> <output>
For now solving by hard-coding translate node to use BILINEAR
interpolation. It can't become worse in this node anyway and
the sampling pipeline is to be re-visited from scratch.
Seems to be caused by the way how the most bottom strip in the stack
used to apply effect. Just rendering strip in this cases will not give
proper results.
Made it so effect is applying between empty imbuf and actual strip.
Seems to work by tests, but more intense testing is required.
Changes were made in Stroke::Resample(int) in C++ to prevent a potential infinite loop
caused by an inconsistency between Stroke::_Length and the stroke length computed
based on stroke vertices. Such a stroke length inconsistency is usually caused by missing
calls of Stroke::UpdateLength() (i.e., API implementation bugs), but also may occur due
to scripting errors in user-defined style modules. This commit is meant to help script
writters to identify the latter error cases. Now Stroke.resample(int) may raise a runtime
error to signal an error condition.
They were using INPUT_SPRING in a way which didn't allow
it to easily redo the operator because INPUT_SPRING internally
is stored as a ration between old value and new one and crease
and bevel were converting this to value delta.
Now made it special input type INPUT_SPRING_DELTA which is
storing delta of the spring, meaning now values in the redo
panel kind of makes sense -- they mean how much to add/remove
to the crease/bevel weight.
Expect to be no functional changes from interactive transform
POV, just a bit more convenient to use redo panel.
The replace mesh actuator was reconverting the mesh data which causes
conflicts with the LoD code. Instead, we just look for an already
converted mesh, which should already be in the scene.
This commit pretty much reverts all the changes related on tile-ability
of the fast gaussian blur. It's not tilable by definition and would almost
always give you seams on the tile boundaries.
Atmind already met the issue and tried to solve it by increasing some
magic constant, which is pretty much likely simply made it so compositor
switched to full-frame calculation in that particular .blend file.
Fast gaussian is really not a production thing and need to be avoided.
We're to improve speed of normal gaussian blur instead.
This check prevents using empty (no faces) meshes as rigid bodies.
While the idea makes sense, it also prevents using modifier-constructed
meshes, where faces are added only by the modifiers.
Further the check is very easy to circumvent, by removing faces after
making the rigid body, or by assigning a different mesh datablock
afterward.
Suggested by Fabian Emmes (@der_fab).
The helper function `make_freestyle_edge_mark_hash()` was referring to the
original mesh to determine Freestyle edge marks for individual derived mesh edges.
This is no longer necessary now that derived meshes deliver CD_FREESTYLE_EDGE
and CD_FREESTYLE_FACE layers of their own. The reference of the original mesh
was also inappropriate since the edges coming from one of the operands of a boolean
modifier don't have proper CD_ORIGINDEX values but ORIGINDEX_NONE's.
Many thanks to Sergey Sharybin for patch contributions and discussions.
