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.
It's still gives some slowdown when painting a locked
key in the solid view, but since shape key is now longer
being re-used by DM.
but this change should still give some degree of speedup
propagating delta onto the keyblock if i remember the
code correct.
Avoid filling up buffers when total buffer triangles are zero.
Better still would be to tag a node as hidden when doing recreation of
the PBVH tree by checking for any visible elements. Original bug report
probably has to do with OpenGL doing something funky but hidden nodes
should be tagged as hidden to completely avoid iterating for painting.
This is to be done in a later commit.
Also some naming cleanup for consistency, GPU_build_pbvh_mesh_buffers to
GPU_build_mesh_pbvh_buffers.
* 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.
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
show diffuse option not correctly calculated on opening a file.
Make sure we call pbvh_show_diffuse_color_set after building the pbvh so
vertex data are available to it.
The formula was not consistent across Blender and behaved strangely, now it is
a simple linear blend between color1 and min(color1, color2).
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D489
Usual dupli object issue, sometimes it's needed that all the object in
dupli group have modified obmat.
Made it an utility function now, which is used by convertblender and
dupli draw code now.
This option (alongside the Ease In/Out/InOut options already available) aims to make it
easier to get an initial curve that looks closer to the one you were expecting, by
automatically picking whether Ease In or Ease Out should be used based on the type of
interpolation being used for the curve segment in question.
Notes:
* The types chosen may need some adjustments (e.g. using ease in-out instead of just ease in)
* This does break compatability with files saved in previous dev builds, but only
if you were using Bounce/Elastic/Back with "Ease In"
This commit changes the default strip duplication behaviour (Shift-D) so that it will
create a copy of whatever action it uses. Previously, it was very hard, if not impossible
in some cases to create a new copy of an action to start working on in the NLA.
If you want the old behaviour, you'll need to use ALt-D (Linked Duplicates).
(Note: Although the new Shift-D may not be so optimal in all cases, I've decided to go
with this version since it aligns better with the way this works for objects. Doing the
opposite for NLA would just have added to the confusion)
So that users opening a .blend saved in 2.70.5 and above in an older version
get warning the file might not be 100% compatible (should have been done
already for 2.70, actually).
With the right handle selected, the movement of the left handle appears constrained
to the frame it is currently on, leading to unpredictable and wild overshoots of the
bezier curve. There appears to be little benefit in doing so.
The effect of this patch is that makes it so that instead of trying (initially) to
maintain the same distance between the two handles and then overshooting randomly
later, the handles now try to keep the same distance from each other (i.e. similar
doing a rotation around the keyframe) at all times. While this means that it isn't
possible to set up assymetric handles (i.e. where ease in to the key is less than the
ease out for example) using aligned handles (it's still possible using free; it's just
a lot more work to keep them aligned), the benefits of removing of the random blips and jumps
when things jump outweight the losses.
Patch by Brecht
Note it was already the case for many simulations (cloth, rigidbody, etc.), just doing this
systematically in BKE_ptcache_add() now, will avoid us some recurring bug reports.
Advanced users will know when they can/have to raise this parameter!
