Updating object IPOs is not currently thread-safe since it also updates
children. This leads to problems when parents and children are both
animated. For now, updating object IPOs is done in its own loop to avoid
threading issues.
Instead of displaying the "tweaking action" status indicator icon on the right hand
side jammed against the mapping/no-mapping toggle (pin), this is now displayed as in
place of the action icon used on the left (as the type indicator). This is less messy
than the previous situation, which was needed partly due to the abuse of an unsuited
icon.
1) The "pushdown" operation is the actual name for the functionality
previously represented by the snowflake. That is, pushing the active
action onto the NLA stack as a new strip.
The icon that is introduced here is the icon I originally wanted to
use here for this purpose (but couldn't at the time the NLA was coded
as we didn't have the master SVG available yet). I'm making this change
now to hopefully make the "animation-layers" intentions behind the NLA
design a lot clearer than they have been so far.
2) Also added a dedicated icon for representing that the active action
is in the "tweaking" state (i.e. we're editing a particular strip's
action). Previously we were abusing an icon designed for an entirely
different purpose, mainly since its identifier looked like it would work.
* The automatically calculated influence was overriding the value we were passing
into the dummy strip, making this seem like it doesn't work
* Made some tweaks to prevent some potential memory-related bugs
- nlastrips_ctime_get_strip() actually saves off references to the list of strips
it gets, so declaring dummy_strip in an inner scope like this could potentially
be quite dangerous
- Prevented a potential memory leak for the early abort when there are no strips
for whatever reason (it shouldn't occur though)
The issue has been introduced in 0985bb4, made it so curves and masks
stick to old behavior.
FCurves are still flaky, namely, grabbing both handles selected would
change the length of one of the handles which is not nice imo.
The issue was caused by the temporary CD layers being allocated for subsurf
meshes, same as we've got back in 881fb43.
In the long run this temporary storage is to be re-considered, but it'll also
imply re-considering of the Derivedmesh interaction as well. For now let's
use a simpler solution which is forbidding modifiers to call getArray for other
objects' derivedMeshes but use an API calls which would allocate local copy of
the data preventing race condition of shared data in DM.
The rendered preview didn't show active layer or wasn't updated if the
layer was disabled. Now the viewport always shows an active layer regardless
of whether it's enabled or disabled.
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
The mask make sure the conversion only happens in a few areas of the
buffer.
New Functions:
* IMB_buffer_byte_from_float_mask
* IMB_buffer_float_from_float_mask
The functions are an adaptation of their maskless counterparts without accepting different profiles for the input and output buffers.
Review: Sergey Sharybin
The issue was caused by the wrong scene used to acquire render result for.
Now made it so render pipeline reports currently rendering scene to the job
via special callback.
This also solves missing tile highlight issue when rendering multiple scenes
in the compositor.
does not work as expected for Viewport and Blender Internal.
As @sergey noticed, this was caused by rBfbf8595, which disabled
rendering for wireframe objects in the viewport. However, the same
function `is_object_hidden` is also used for skipping dupli objects then
which may themselves be renderable.
Now use two variants:
* is_object_restricted is the previous test for general viewport/render visibility (lets wireframe duplicators pass)
* is_object_hidden includes the wireframe check for actual render instances
It was broken in 7544961 and the proper way is to make sure proper obmat is being
copied to object before the draw.
Doing obmat copy in advance doesn't really work because object might appear multiple
times in the duplilist.
