Blender Git Commits

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 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).

Tessface customdata for derived mesh caching.

Fix for name collisions in compound properties when writing CustomData.

This is not clearly documented for Alembic, but apparently properties
inside compounds still need to be name uniquely for the whole object.
This is somewhat involved for Blender's CustomData, because we have
5 different customdata elements for meshes (vert, edge, face, poly,
loop) and each of these can have the same types and multiple layers of
the same type ...

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

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

Conflicts:
source/blender/blenkernel/intern/particle_system.c

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

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

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

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

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

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

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.

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

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.

Alembic: Fixes for linux buildbot and scons

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).

Conflicts:
source/blender/blenkernel/intern/particle_system.c

Moved functions for constructing readers/writers based on cache library
out of pointcache into blenkernel.

This is quite simple and repetitive and there is not need to have this
in the main pointcache/Alembic API. The code is mostly concerned with
logic of DNA data, so pointcache shouldn't have to deal with it.

Ported archive filename constructor from pointcache library to BKE.

The pointcache library is now pretty much independent from ID blocks and
should not be responsible for handling file paths. The path construction
is also fairly straightforward now compared to the old point cache
system, with only basic conversion of relative to absolute paths for
loading archive files.