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
When "Selected to Active" is not on, we bake all the selected objects.
This is the same behaviour we have for Blender Internal.
Dev note: I moved most of the validation tests to outside the bake()
routine so the function can be called in loop.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D560
This should be the final fix for the applyrotation issue. It baffles me
that the fix involves discarding the scale transformations for the
normals but it works so I'm happy with it.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D554
before entering the recursion check.
Now use group tags instead of object tags, which could be a little more
efficient and was used before this patch too.
It still warns the user that there may be an error, but the baking goes
on. Also using the new is_uniform_scaled_m4() instead of float comparison.
Reported and fix suggested by Campbell Barton as a concern over 2bfc3deb
The new recursion check for groups duplicating themselves has to un-set the LIB_DOIT flag after each object, otherwise it will prevent duplicating a (non-recursive) group multiple times.
This fixes most of the cases, the only situation not addressed is when
the highpoly object(s) has non-uniform scale.
mul_transposed_mat3_m4_v3() should take care of non-uniform scales so
I'm a bit confused on why it doesn't work. The lowpoly object can have
any transformation, the only issue is if the highpoly object has
non-uniform scale.
Test file of the remaining issue:
https://developer.blender.org/file/info/PHID-FILE-tpw2xgddyzxtpg3e7xzs/
Reference reading:
http://www.unknownroad.com/rtfm/graphics/rt_normals.html
So! First, frame for absolute shape keys: never allow a new key to have the same pos as an
existing one (this does not make sense). This way, the two workflows are possible (create
all keys and then animate ctime, or animate ctime and then create keys where you need them).
Also, fixed UIList for shapekeys, the "absolute" test was wrong, and better to show frame
value, even though not editable, than nothing in case of absolute keys.
And finally, add getter to RNA 'frame' readonly value, so that we output real frame values,
and not dummy internal ones (which are /100) in our API.
rB568f0c7 added a recursion check that is supposed to prevent cyclic
cases where a group includes itself via dupli instancing.
The check function was descending into all groups nested inside the
target group - which works for single level recursion like in the test
case, but does not handle generic recursion. Basically it asked:
"is object X in the group already or in any instanced dupligroup?"
The new check instead asks:
"is group G dupli'd by X or any instanced subgroup thereof?"
which is what we really need to know.
This reverts commit 97823f6047.
I was to push a fix based on Brecht's solution (this commit) when he did
the same.
This fix is correct, but it misses replacing WM_JOB_TYPE_OBJECT_BAKE
with WM_JOB_OBJECT_BAKE_TEXTURE in the rest of the file, which may lead
to problems when calling the operator in a quickly sucession -
WM_jobs_test also tests for the same type of JOB.
I created WM_JOB_TYPE_OBJECT_BAKE elsewhere, may as well use it. Unless we revert 20c90ea and f194da3.
I'm fine with either way, just trying to get master to work again ;)
All image colorspaces should be displaying correctly in the UV/Image Editor.
Viewport may still present an issue, but it was reported separately
anyways (T40055)
Patch reviewed (and corrected) by Sergey Sharybin
Sculpt mode drawing fails after deleting a subsurf modifier
in sculpt mode and undoing.
This was quite difficult to spot. Main cause was that mesh data was not
synchronized properly between undo and sculpt code because we generated
a pbvh on derivedmesh invalidation without really refreshing the rest of
the data. This could result in undo and drawing operating on different
data.
To solve this and avoid bad level calls I had to move quite some code
around. Crazyspace is now moved to blenkernel, as did some sculpt calls
that make sure sculpt data are properly refreshed.
New operator that can calls a bake function to the current render engine when available. This commit provides no feature for the users, but allows external engines to be accessed by the operator and be integrated with the baking api.
The API itself is simple. Blender sends a populated array of BakePixels to the renderer, and gets back an array of floats with the result.
The Blender Internal (and multires) system is still running independent, but we eventually will pipe it through the API as well. Cycles baking will come next as a separated commit
Python Operator:
----------------
The operator can be called with some arguments, or a user interface can be created for it. In that case the arguments can be ommited and the interface can expose the settings from bpy.context.scene.render.bake
bpy.ops.object.bake(type='COMBINED', filepath="", width=512, height=512, margin=16, use_selected_to_active=False, cage_extrusion=0, cage="", normal_space='TANGENT', normal_r='POS_X', normal_g='POS_Y', normal_b='POS_Z', save_mode='INTERNAL', use_clear=False, use_split_materials=False, use_automatic_name=False)
Note: external save mode is currently disabled.
Supported Features:
------------------
* Margin - Baked result is extended this many pixels beyond the border of each UV "island," to soften seams in the texture.
* Selected to Active - bake shading on the surface of selected object to the active object. The rays are cast from the lowpoly object inwards towards the highpoly object. If the highpoly object is not entirely involved by the lowpoly object, you can tweak the rays start point with Cage Extrusion. For even more control of the cage you can use a Cage object.
* Cage Extrusion - distance to use for the inward ray cast when using selected to active
* Custom Cage - object to use as cage (instead of the lowpoly object).
* Normal swizzle - change the axis that gets mapped to RGB
* Normal space - save as tangent or object normal spaces
Supported Passes:
-----------------
Any pass that is supported by Blender renderlayer system. Though it's up to the external engine to provide a valid enum with its supported passes. Normal passes get a special treatment since we post-process them to converted and "swizzled"
Development Notes for External Engines:
---------------------------------------
(read them in bake_api.c)
* For a complete implementation example look at the Cycles Bake commit (next).
Review: D421
Reviewed by: Campbell Barton, Brecht van Lommel, Sergey Sharybin, Thomas Dinge
Normal map pipeline "consulting" by Andy Davies (metalliandy)
Original design by Brecht van Lommel.
The entire commit history can be found on the branch: bake-cycles
