Suggestion by Andy Davies (metalliandy) to conform with industry standard (custom cage is something else apparently)
Note: this is the last bake related commit I plan for 2.71/rc (unless
everyone agrees that we could squeeze in D546 - custom UVs, which would
be really nice to add for 2.71 scripters)
Note 2: I'll update the wiki docs shortly
slightly outside the mesh.
Reported by Thomas Beck on irc. Issue here is that the mesh bounding box
changes as we are transforming the vertices. Solution is to collide
against the initial bounding box. Unfortunately the snapping functions
are made in a way that a lot of code needed to be tweaked here, but the
change should be straightforward and harmless (famous last words, I
know).
Ideally we might want to even increase the size of the bounding box a
little (as seen in screen space) to allow snapping even in cases where,
cursor is slightly outside the bounding box, but since this is not so
straightforward to do for all cases, at least for me, leaving this as
a TODO.
There is a new option to select whether you want to use cage or not.
When not using cage the results will be more similar with Blender
Internal, where the inwards rays (trying to hit the highpoly objects)
don't always come from smooth normals. So if the active object has sharp
edges and an EdgeSplit modifier you get bad corners.
This is useful, however, to bake to planes without the need of adding
extra loops around the edges.
When cage is "on" the user can decide on setting a cage extrusion or to
pick a Custom Cage object. The cage extrusion option works in a
duplicated copy of the active object with EdgeSplit modifiers removed to
inforce smooth normals. The custom cage option takes an object with the
same number of faces as the active object (and the same face ordering).
The custom cage now controls the direction and the origin of the
rays casted to the highpoly objects. The direction is a ray from the
point in the cage mesh to the equivalent point to the base mesh. That
means the face normals are entirely ignored when using a cage object.
For developers:
When using an object cage the ray is calculated from the cage mesh to
the base mesh. It uses the barycentric coordinate from the base mesh UV,
so we expect both meshes to have the same primitive ids (which won't be
the case if the cage gets edited in a destructive way).
That fixes T40023 (giving the expected result when 'use_cage' is false).
Thanks for Andy Davies (metalliandy) for the consulting with normal
baking workflow and extensive testing. His 'stress-test' file will be
added later to our svn tests folder. (The file itself is not public yet
since he still has to add testing notes to it).
Many thanks for the reviewers.
More on cages:
http://wiki.polycount.com/NormalMap/#Working_with_Cages
Reviewers: campbellbarton, sergey
CC: adriano, metalliandy, brecht, malkavian
Differential Revision: https://developer.blender.org/D547
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.
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.
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.
