Blender Git Loki

Enable motion curve update for armatures as well.

This is currently brute force updating, also disabled object copies
but it's likely that we'll need those to do threaded update of the
motionpaths.

Motion Paths real time update WIP

Merge branch 'master' into gooseberry

Conflicts:
source/blender/physics/intern/BPH_mass_spring.cpp

Merge branch 'master' into gooseberry

Conflicts:
source/blender/physics/intern/BPH_mass_spring.cpp

Merge branch 'cycles_memory' into gooseberry

Fix blenderplayer

Merge branch 'cycles_memory' into gooseberry

Add argument to DM_to_mesh() function to take ownership over the DM

The idea is pretty simple: instead of making temporary copy of all the
related custom data layers just pass the ownership from the DM to the
mesh.

This is really handy in cases when you've got DM which you need to
convert to Mesh datablock and wouldn't need that DM after conversion
anyway.

Foe example, render database conversion, exporters and even Modifier
Apply will benefit from this option.

Reviewers: campbellbarton

Differential Revision: https://developer.blender.org/D1127

Merge branch 'cycles_memory' into gooseberry

Merge branch 'master' into gooseberry

Add an option to mesh.calc_tessface() to get rid of polygons and loops

The purpose of this change is to add extra possibility to render engines and
export scripts to reduce peak memory footprint during their operation.

This new argument should be used with care since it'll leave mesh in not really
compatible with blender format, but it's ok to be used on temp meshes.

Unfortunately, it's hard to get scene where it'll show huge benefit because
in my tests with cycles peak memory is reached in MEM_printmemlist_stats().

However, in the file with sintel dragon it gives around 1gig of memory benefit
after removing the polys which would allow other heavy to compute stuff such as
hair (or even pointiness calculation) to not be a peak memory usage.

In any case, this change is nice to have IMO, and only means more parts of
scene export code should be optimized memory-wise.

Reviewers: campbellbarton

Differential Revision: https://developer.blender.org/D1125

Cycles: Free caches used by the synchronized objects

Issue this commit is addressed to is that particle system and particle modifier
will contain caches once derived mesh was requested and this cached data will
never be freed.

This could easily lead to unwanted memory peaks during synchronization stage
of rendering.

The idea is to have RNA function in object which would free caches which can't
be freed otherwise. This function is not intended to deal with derived final
since it might be used by other objects (for example by object with boolean
modifier).

This cache freeing is only happening in the background rendering and locked
interface rendering.

From quick tests with victor file this change reduces peak memory usage by
command line rendering by around 6% (1780MB vs. 1883MB). For rendering from
the interface it's about 12% (1763MB vs. 1998MB).

Reviewers: campbellbarton, lukastoenne

Differential Revision: https://developer.blender.org/D1121

Fix for child particle clumping noise, using the orco parent location
for clumping instead of deformed location.

The orco location must be used for roughness to ensure a stable shape,
but for moving child keys toward the parent (clumping) the deformed
location must be used.

RNA: correct limits

Pointer property for selecting particle systems in the particle instance
modifier.

Internally the property is still an integer index, but using a pointer
with a dropdown is much more convenient.

Removed stupid limit of 10 on particle instance modifier psys index.

Fix for clumping noise randomness being unstable under deformation.

This randomisation was using the deformed parent coordinates for
calculating noise vectors, which causes unwanted movement as the parent
hair deforms. Instead the `orco` coordinates must be used for all noise
vectors, since these are from the undeformed mesh.

Merge branch 'master' into gooseberry

Fix T43770, we were doing multiplication with object matrix and not
reverting the GL state.

Experimental hair shape key control with textures.

Rationale for this feature goes like this:

In meshes the influence of shape keys can be limited to certain vertex
groups. This allows shapes to be applied selectively on parts of the
mesh and possibly even be animated by changing vertex group weights over
time.

With hair shape keys there is no equivalent feature to vertex groups
(defining a vertex group on hair keys would be rather tedious anyway).
It would be possible to use the emitter mesh vgroups to assign a
per-strand blending weight, but since hairs usually are much more dense
than mesh vertices this would sacrifice accuracy.

A better option is to allow textures to influence the hair shape key
blending. For this purpose there is now a new texture influence.
A shape key name needs to be assigned to the MTex in addition to a
factor. It will then act as a multiplier for the shape key weight,
i.e. the base shapekey value still works as an overall control.