When an `AttributeSet` is tagged as modified, which happens after the addition or
removal of an `Attribute` from the set, during the following GeometryManager device
update, we update and repack the kernel data for all attribute types. However, if we
only add or remove a `float` attribute, `float2` or `float3` attributes should not
be repacked for efficiency.
This patch adds some mechanisms to detect which attribute types are modified from
the AttributeSet.
Firstly, this adds an `AttrKernelDataType` to map the data type of the Attribute to
the one used in the kernel as there is no one to one match between the two since e.g.
`Transform` or `float4` data are stored as `float3s` in the kernel.
Then, this replaces the `AttributeSet.modified` boolean with a set of flags to detect
which types have been modified. There is no specific flag type (e.g.
`enum ModifiedType`), rather the flags used derive simply from the
`AttrKernelDataType` enumeration, to keep things synchronized.
The logic to remove an `Attribute` from the `AttributeSet` and tag the latter as modified
is centralized in a new `AttributeSet.remove` method taking an iterator as input.
Lastly, as some attributes like standard normals are not stored in the various
kernel attribute arrays (`DeviceScene::attribute_*`), the modified flags are only
set if the associated standard corresponds to an attribute which will be stored
in the kernel's attribute arrays. This makes it so adding or removing such attributes
does not trigger an unnecessary update of other type-related attributes.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D11373
lookups
We use the schema so that we can access top level attributes as well.
This is already done for polygon meshes and curves, so this only
modifies the behavior for subdivision objects.
This splits the data reading logic from the AlembicObject class and moves it to
separate files to better enforce a separation of concern. The goal was to simplify
and improve the logic to read data from an Alembic archive.
Since the procedural loads data for the entire animation, this requires looping
over the frame range and looking up data for each frame. Previously those loops
would be duplicated over the entire code causing divergences in how we might
skip or deduplicate data across frames (if only some data change over time and
not other on the same object, e.g. vertices and triangles might not have the
same animation times), and therefore, bugs.
Now, we only use a single function with callback to loop over the geometry data
for each requested frame, and another one to loop over attributes. Given how
attributes are accessed it is a bit tricky to simplify further and only use a
ingle function, however, this is left as a further improvement as it is not
impossible.
To read the data, we now use a set of structures to hold which data to read.
Those structures might seem redundant with the Alembic schemas as they are
somewhat a copy of the schemas' structures, however they will allow us in the
long run to treat the data of one object type as the data of another object
type (e.g. to ignore subdivision, or only loading the vertices as point clouds).
For attributes, this new system allows us to read arbitrary attributes, although
with some limitations still:
* only subdivision and polygon meshes are supported due to lack of examples for
curve data;
* some data types might be missing: we support float, float2, float3, booleans,
normals, uvs, rgb, and rbga at the moment, other types can be trivially added
* some attribute scopes (or domains) are not handled, again, due to lack of example
files
* color types are always interpreted as vertex colors
Currently the procedural will add an entry to the cache for every frame
even if the data only changes seldomly. This means that in some cases we
will have duplicate data accross frames.
The cached data is now stored separately from the time information, and
an index is used to retrieve it based on time. This decoupling allows
for multiple frames to point to the same data.
To check if two arrays are the same, we compute their keys using the
Alembic library's routines (which is based on murmur3), and tell the
cache to reuse the last data if the keys match.
This can drastically reduce memory usage at the cost of more processing
time, although processing time is only increased if the topology may
change.
Static initialization order was not guaranteed to be correct for node base
types. Now wrap all initialization in accessor functions to ensure the order
is correct.
Did not cause any known bug on Linux/macOS/Windows, but showed up on this
platform.
This type, CacheLookupResult, holds the data for the current time, or an
explanation as to why no data is available (already loaded, or simply
nothing available). This is useful to document the behavior of the code
but also, in future changes, to respond appropriately for missing data.
Inside of the procedural, instances are AlembicObjects which point to
the AlembicObject that they instance.
In Alembic, an instance is an untyped Object pointing to the original
(instanced) one through its source path. During the archive traversal we
detect such instances and, only if the instanced object is asked to be
rendered, set the instance's AlembicObject to point to the original's
AlembicObject.
Cycles Object Nodes are created for each AlembicObject, but only for
non-instances are Geometries created, which are then shared between
Object Nodes. It is supposed, and expected, that all instances share the
same shaders, which will be set to be the ones found on the original
object.
As for caching, the data cache for an AlembicObject is only valid for
non-instances and should not be read to or from as it is implicitly
shared.
This will help support instancing as cache building is now decoupled
from the logic to update the Nodes' sockets as data (and cache) will
need to be shared by different Geometries somehow, and also simplify
implementing different data caching methods by centralizing this
operation.
We need to explicitely tag the Attribute and AttributeSet as modified if
we change or add/remove data. This is more of a bandaid until attributes
handling is refactored to be able to reuse routines from the Attribute
API.
The missing update has two sources:
The TimeSampling used for looking up transformations in the cache was
uninitialized. To fix this, simply use the TimeSampling from the last
transformation in the hierarchy (that is the object's parent), which
should also contain the time information for all of its parents.
The objects are not tagged for update when their trasformations change.
The implementation is currently optimized to load animation sequences once
and then quickly scrubbing through them. Later on an option should be added
to optimize for memory usage and only load the current frame into memory.
Currently mesh and curve objects are supported, including support for UV and
vertex color attributes. Missing still is support for arbitrary attributes and
motion blur, as well as better handling of changing topology. Shader assignments
are made using FaceSets found in the Alembic archive.
The animation (and constant) data of the objects inside the Alembic archive is
loaded at once at the beginning of the render and kept inside a cache. At each
frame change we simply update the right socket of the corresponding Cycles node
if the data is animated. This allows for fast playback in the viewport
(depending on the scene size and compute power).
Note this is not yet exposed in the Blender UI, it's a feature that is still under
development and not ready for general use.
Ref T79174, D3089
