Support UV Map nodes for determining active UV layer. Now when an image
node is enocuntered, the system will recursively search the node's input
sockets for any UV Map nodes. Obviously this won't fetch any coordinate
transforms into painting, and it will only choose the first UV Map node
encountered if more than one UV Map nodes are combined.
However it should allow custom UV setups per materials and tweaking of
the UV Map node's UV layer from the Slots panel.
This is a per-strip option next to the build proxy size which tells blender
whether to skip building proxy size if the file for it already exists or not.
The option is called "Overwrite" for simplicity.
This option is enabled by default to avoid changes in the file behavior.
TODO: Would be nice to do something like that for movie clips as well.
The issue was caused by the conflict between preview render which would set
R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of
the render pipeline trying to use this flag.
Now the sampler functions accepts extra argument so render pipeline can
still skip image load, but calls outside of the pipeline will nicely load
all the images.
Not cleanest change in the world but good enough to unlock gooseberry team,
and assuming we already had pool passed all over the place it should be all
fine.
Will need to reshuffle arguments into SamplerOptions structure later.
The logic used for determining whether certain keyframing settings (i.e. visual,
only needed, xyz -> rgb) got applied was wonky. The original intention here was
that the Keying Set settings would override the global settings, and the path
settings would override what was used for the Keying Set. However, that was not
happening in all cases previously, as it was only possible to add flags and not
to turn them off.
This commit fixes that by introducing separate toggles to control whether the
Keying Set/Path's settings override the settings inherited from its parent
(i.e. the Keying Set for the Path, and the User Prefs for the Keying Set).
The icons used for these toggles could get revised a bit (we need something
which communicates "override this"; the current one is the closest I could find)
WARNING: If you have old keying sets, this may cause some breakage!
Finally! At long last, I've gotten this working! This ended up being far trickier
to get right than anticipated; the normal remapping API's cannot be used as-is
as they will just clobber over subtleties whenever datablock changes are involved.
So, for now, we have to duplicate the logic a bit.
Currently, when joining two armatures, the drivers of the armatures being merged
in are lost. This commit introduces a new AnimData API function for merging
animation data into another AnimData block.
NOTE:
* For now, this only copies the drivers over. As a result, manual effort will
still be needed to go through and fix the drivers.
I am working on automating that process, but it's more important that the
drivers don't have to be created from scratch for now (since this is needed
for the Goosberry rigging work).
A development addon can be used now to enable the debug drawing, without
the need to add UI code for this in the release files.
The SimDebug feature should also get an overall build flag and use
function stubs unless enabled. That way any possibility of overhead in
releases is eliminated.
This way it doesn't have to be stored as DNA runtime pointers or passed
down as a function argument. Currently there is now no property or
button to enable debugging, this will be added again later.
Code in ccgdm_draw_attrib_vertex() was entirely the same as the top
portion of the code in cddm_draw_attrib_vertex(). Moved this code to a
new function, DM_draw_attrib_vertex().
ccgdm_draw_attrib_vertex() was removed in favor of calling
DM_draw_attrib_vertex(). cddm_draw_attrib_vertex() still does a couple
extra things, so it still exists but calls DM_draw_attrib_vertex().
In the interest of easy code review, no changes made to the code in
DM_draw_attrib_vertex() other than the new name and an added comment.
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1010
The paths for parents and children are generated using the same function
with a rather obscure test to distinguish them. Modifiers (clump, kink,
roughness) should not be applied to parents though.
mode.
This was caused by variation of the number of keys on child hairs due
to shortening of hair curves based on euclidian distances. The other
kink modes also shorten hairs, but use the parametric distance instead,
which does not vary with deformation of hairs.
another, including edit data (grooming).
This uses basically the same method as the existing connect/disconnect
feature. The main difference is that it allows working with multiple
objects and transferring the //particle/hair data// instead of the
//mesh// data (which is what connect/disconnect expects). This is a much
more realistic workflow when rigging, topology etc. changes and
groomed hair has to be transferred to the changed model.
This is BAD code, but the particle kinking does not make it easy to
write a non-local modifier that requires neighboring positions,
curvature, etc. The feature is needed for Gooseberry.
This adds another level of clumping on child hairs. When enabled, child
hairs chose a secondary clumping target using a Voronoi pattern. This
adds visual detail on a smaller scale, which is useful particularly when
the number of parents is relatively small.
Natural fibres behave in a similar way when they become sticky and
intertwined. Hairs close to each other form a first twisted strand, then
combine into larger strands. Similar features can be found in ropes:
http://en.wikipedia.org/wiki/Hair_twistshttp://en.wikipedia.org/wiki/Rope
Conflicts:
source/blender/blenloader/intern/versioning_270.c
This is an alternative method to the current fixed function with a
clump factor and "shape" parameter. This function is quite limited and
does not give the desired result in many cases (e.g. long, parallel
rasta strands are problematic). So rather than trying to add more
parameters there is now a fully user-defined optional curve for setting
the tapering shape.
