2.70 for non Apple systems.
Also refactored the code that restores the previous openmp thread count.
The logic here was weird, mostly due to all the commit madness with
Apple openmp support. The restored thread count though should not depend
on the on/off state of threaded sculpting (since it has to do with
systems other than sculpting only). For OSX threads are restored to the
system thread count but Jens should recheck here.
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.
