Blender Git Loki

Nicer error handling for unimplemented CustomData layer types.

Instead of failing an assert, simply print an error message and return
gracefully. We don't want Blender crashing because of this.

Ugly hack for caching code to deal with quirky modifier stack behavior.

CustomData layers are pruned by the CDDM_copy function when they have
CD_FLAG_NOCOPY set. This is based on later modifiers in the stack, which
can specify that they require certain data layers - but the caching
modifier itself should store only what is needed by later modifiers.
It means we cannot easily keep a full copy of the DM in the cache
modifier to writing into caches later.

For now the hackish solution is to temporarily disable NOCOPY flags when
copying the DM. This is really not nice and needs a better solution.

Support CD_ORIGSPACE layer caching.

This is needed by particles for distributions on meshes with changed
topology (which is of course broken).

Tessface customdata for derived mesh caching.

Support for CustomData in Alembic caches.

This is a skeleton feature that provides a general way of storing
CustomData types. Currently only ORIGINDEX layers are implemented, the
code is designed to make extension easy.

Storing CustomData layers in Alembic is a bit involved because the
complex structs often used as customdata need to be de-interleaved for
Alembic into a set of POD (plain-old-datatype) array properties.

In addition the property names should be unique, so that mapping abc
properties back to customdata layers is safe. This works by using 2
levels of compound properties: the first level stored per CD type
properties, with a number of properties for each layer of this type,
using either a name or index (for unnamed layers). The internal
properties can then in turn be compounds, if structs need to be
serialized into PODs.

Abc property readers/writers are created dynamically for the CustomData
compounds. This is necessary because we don't know in advance what kind
of data layers a DerivedMesh or other CD user will have, and this can
change each frame in theory. Alembic is easier with state data schemes,
but using it this way is possible (if somewhat cumbersome).

Fix for cache item filtering: items can be part of the cache library
but disabled, in that case hide them as well.

Fixed test for "render" eval mode for hair dynamics.

This is totally weird and convoluted, no idea if correct.

Removed the DM writer/reader from hair dynamics again, this is part of
the particle stuff and does not work.

Use a combined class for hair dynamics for cloth and mesh data.

Particles store a copy of the DM internally as the emitter.

Archive Info operator for Cache Library archives.

This creates a string with information about all the objects and
properties contained within a (Alembic) archive, used by a cache
library.

The operator has 3 modes of presenting the info string:
- stdout, ie. printing to the terminal
- popup window (not very useful usually due to size limits and lack of
scrolling)
- clipboard copy

Alembic: Fixes for linux buildbot and scons

Depsgraph tagging function for cached objects.

This is necessary to trigger object data updates for indirectly linked
objects, which would otherwise not be evaluated.

Convenience feature: When linking a cache library, always default it to
'read' mode locally.

Linking a cache library is meant to be used for getting existing cache
data into a file.

Left a comment in DerivedMesh.c explaining why the caching system has
to use the cumbersome cachedm pointer instead of virtual modifiers.

Use a dedicated input_dm pointer in the cache modifier to provide a mesh
result read from the cache.

Mixing this with the output_dm used for writing leads to undefined
situations where the DM was released but should actually be passed on.

Use correct flag enums for checking render/viewport eval mode when
writing derived mesh caches.

Fix for meaningless build error (no return value, can never happen).

Minor fix for UI code showing cache items.

Render/Viewport evaluation mode for cache libraries.

This designates a cache library to be used either for the viewport or
for renders. A "Render" cache library will evaluate modifiers with
render settings and a "Viewport" cache library will use viewport
(realtime) settings.

When reading the cache, the library will only be
used for the assigned purpose, i.e. a Render cache does not work for
viewport caching and vice-versa (although a cache can be baked for one
setting and then switched afterward).

Note that render results will never be visible in the realtime viewport
due to the way object evaluation is handled in Blender at this point
(render settings are only evaluated explicitly during renderer sync).

Allow the cache bake operator to overwrite existing files, using a
confirm dialog.