Blender Git Commits

Mesh storage and reading in child objects for dupligroups.

The layout of the Alembic files resembles the DNA structure in Blender:
- On the top level (under the top/root node) there are Abc::Objects for
Blender ID datablocks (currently Object and Group)
- Objects store final data (DerivedMesh) and later simulation results
etc.
- Groups store their full duplilists for instancing. Currently there is
no recursive nesting of groups, since this would limit duplis to
dupligroups and exclude e.g. duplifaces.

On reading the duplilist gets reconstructed and stored in the DupliCache
for a duplicator empty (the group instance). DerivedMesh data is stored
in a hash table for each instanciated object and can later replace
finalDM in drawing and rendering.

Simplification of the archive init functions in writers and readers.

Now the base types for readers/writers are not nominally forming the
interface any more (they may be removed entirely later). This makes
possible a cleaner init method directly in the Abc Writer/Reader
classes.

Further work may be required in this area.

Moved the dupli cache reading code into a AbcDupligroupReader class.

This is more in line with how readers work in the Blender Alembic
implementation elsewhere.

Generally, readers are less persistent than writers: they are created
whenever cache results need to be updated (e.g. on frame changes) and
discarded afterward. Writers OTOH stay alive during the whole baking
job, since they keep the references to Alembic Writer instances and can
only be deleted once the writing for that part is done.

Store and apply dupli object transforms in the Alembic cache.

Note that the cache stores dupli matrices without the final parent
transform, since it only knows about the group itself. The duplicator
obmat is applied to the duplis after reading the cache.

Handle dupli cache on object copy and freeing.

Updated cache reading function for the new duplilist structure.

Now we store duplilists entirely inside a single alembic object for the
group. This allows using all the generated duplis, which would be
difficult if the alembic file had to define all the possible recursive
dupli relations that Blender allows, beside straightforward Group duplis.

Use a nested Object writer to store the Object ID blocks used by dupli
lists.

Better dupligroup Alembic writer.

Uses the duplilist generated by Blender to define instances, instead of
recreating the group layout. This omits some information about actual
structure of the DNA, which might be useful later on. The main problem
is that the duplilist itself does not encode this, so it's a tradeoff
between either including the Group structure or omitting the other
dupli types, like face, vertex, particle duplis.

Alternative dupli generator function for creating duplis in a group
without a specific parent.

Some disabled code to enable automatic cache updates on every duplilist
creation call.

This is executed *a lot* (even for simple things such as viewport
panning), so the code is probably not suitable in this form. At least
it could do a frame comparison to avoid unnecessary updates.

Use a cached group only when a CacheLibrary is actually available.

Otherwise the regular duplilist generator is used.

Replace usage of the procedural duplilist generation by cached duplilist.

Store object pointers for the dupli objects we generate from caches.

This is necessary for the current viewport drawing and rendering code,
which expected each dupli instance to represent a copy of data in the
DNA.

The code maps base-level objects in the cache to DNA Objects inside the
dupligroup by name. Only objects that can be found in the blend data
will be allowed for DupliObjects.

Moved the DupliCache struct into DNA, it will be needed for drawing and
RNA access later.

Simple operator to force rebuilding of a dupligroup cache.

This is a placeholder for proper depsgraph integration. Eventually frame
changes and some other updates should rebuild dupligroup caches
automatically using the depsgraph. Until then this operator is a quick
way to test the IO from caches and the further drawing and rendering
(TODO).

Cache reading functions for constructing a nested dupligroup list based
on Alembic cache data.

Include mesh writers in the cache writers list.

Removed unused code.

Removed current implementation of cache reading from various parts of
BKE (DerivedMesh, particles, cloth).

The new cache implementation will be used for constructing dupli data
instead, bypassing the complexities of the modifier stack.

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

Initial code to support dupli group instancing and overrides through
Alembic caches.

This creates representations (Abc::Object) for Blender Object and Group
datablocks in the Alembic files and uses Alembic instancing to define
the dupligroup hierarchy. This leads to a relatively flat hierarchy in
Alembic files:

Top -> Object/Group -> DerivedMesh/Particles/Hair/Cloth/Smoke/...

The dupligroup structure can not be represented by a hierarchical
structure such as the Alembic object nesting, because of the
many-to-many relationship between objects and groups (a group can
contain multiple objects, multiple objects can instance the same group).
Instead we use the instancing feature of Alembic to represent
dupligroups. This is created in 2 stages to ensure all the main ID
blocks have been serialized before creating references.