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
!!! ANIMATORS/RIGGERS PLEASE TEST !!!
I've reduced the size of the threshold for the keyframe lookup here. This threshold
determines the minimum time in frames between keyframes (i.e. "how close" to each
other they can get). Making this too small causes problems like T39207, but it seems
that the threshold we've been using makes it impossible to get accurate behaviour on
driver curves with keyframes, when the driver target only moves 2cm (i.e. 0.02 BU).
So far, all of the test cases from T39207 seem to work fine, as well as Caminandes 2
files, and Kenny the Caterpillar. The Kiribati rigs/shots (thanks jpbouza for helping
to check on these!) also seem to be fine.
When doing a 'weld' type join where there are two non-beveled edges
in the same plane one beveled one but not the other, then there
should be a curved profile; bug was creating a straight one.
No idea why this issue hasn't been spotted before. Took several hours to
figure out where exactly wrong memory access happens..
P.S. I really want to switch ImBuf->rect from int* to unsigned char*...
Issue here is most likely sampler uniforms and textures not being
updated properly when zero binding is created. Solution for now is to
allow zero binding but when this happens use sexy pink invalid texture
instead :p.
We need to 'reset' mouse coordinates to the one it was when the gesture handling started,
else org coords are where the tweak event is created, which gives a noticeable gap
(several pixels) and unwanted behavior like the one retported about file box selection.
Skip doing particle update in object_handle_update if object is in
edit mode.
Object will be re-evaluated on exit from edit mode anyway, so it's
_expected_ to be a safe change.
The root of the issue goes to the fact that we only can
read RGB EXR files, but they could be YCbCr or just Luma.
Added support for this two cases.
Note: internally EXR would still be 3 channels, so no
big memory save would happen here, at least yet.
It's not that trivial to support disapearing tracks in the sequence,
and since we're having ongoing 2D stabilization rework patch wouldn't
want to start doing rather bigger changes here now.
Let's just stick to legacy behavior for this release.
This reverts commits 91429d0, 543ce85
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.
