2023-06-14 06:52:36 +00:00
|
|
|
/* SPDX-FileCopyrightText: 2021-2022 Blender Foundation
|
|
|
|
*
|
|
|
|
* SPDX-License-Identifier: Apache-2.0 */
|
Alembic Procedural: refactor data reading
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
2021-05-03 05:00:58 +00:00
|
|
|
|
|
|
|
#pragma once
|
|
|
|
|
|
|
|
#ifdef WITH_ALEMBIC
|
|
|
|
|
|
|
|
# include <Alembic/AbcCoreFactory/All.h>
|
|
|
|
# include <Alembic/AbcGeom/All.h>
|
|
|
|
|
2021-10-24 12:19:19 +00:00
|
|
|
# include "util/vector.h"
|
Alembic Procedural: refactor data reading
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
2021-05-03 05:00:58 +00:00
|
|
|
|
|
|
|
CCL_NAMESPACE_BEGIN
|
|
|
|
|
|
|
|
class AlembicProcedural;
|
|
|
|
class AttributeRequestSet;
|
|
|
|
class Progress;
|
|
|
|
struct CachedData;
|
|
|
|
|
|
|
|
/* Maps a FaceSet whose name matches that of a Shader to the index of said shader in the Geometry's
|
|
|
|
* used_shaders list. */
|
|
|
|
struct FaceSetShaderIndexPair {
|
|
|
|
Alembic::AbcGeom::IFaceSet face_set;
|
|
|
|
int shader_index;
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Data of an IPolyMeshSchema that we need to read. */
|
|
|
|
struct PolyMeshSchemaData {
|
|
|
|
Alembic::AbcGeom::TimeSamplingPtr time_sampling;
|
|
|
|
size_t num_samples;
|
|
|
|
Alembic::AbcGeom::MeshTopologyVariance topology_variance;
|
|
|
|
|
|
|
|
Alembic::AbcGeom::IP3fArrayProperty positions;
|
|
|
|
Alembic::AbcGeom::IInt32ArrayProperty face_indices;
|
|
|
|
Alembic::AbcGeom::IInt32ArrayProperty face_counts;
|
|
|
|
|
|
|
|
Alembic::AbcGeom::IN3fGeomParam normals;
|
|
|
|
|
|
|
|
vector<FaceSetShaderIndexPair> shader_face_sets;
|
|
|
|
|
|
|
|
// Unsupported for now.
|
|
|
|
Alembic::AbcGeom::IV3fArrayProperty velocities;
|
|
|
|
};
|
|
|
|
|
|
|
|
void read_geometry_data(AlembicProcedural *proc,
|
|
|
|
CachedData &cached_data,
|
|
|
|
const PolyMeshSchemaData &data,
|
|
|
|
Progress &progress);
|
|
|
|
|
|
|
|
/* Data of an ISubDSchema that we need to read. */
|
|
|
|
struct SubDSchemaData {
|
|
|
|
Alembic::AbcGeom::TimeSamplingPtr time_sampling;
|
|
|
|
size_t num_samples;
|
|
|
|
Alembic::AbcGeom::MeshTopologyVariance topology_variance;
|
|
|
|
|
|
|
|
Alembic::AbcGeom::IInt32ArrayProperty face_counts;
|
|
|
|
Alembic::AbcGeom::IInt32ArrayProperty face_indices;
|
|
|
|
Alembic::AbcGeom::IP3fArrayProperty positions;
|
|
|
|
|
|
|
|
Alembic::AbcGeom::IInt32ArrayProperty crease_indices;
|
|
|
|
Alembic::AbcGeom::IInt32ArrayProperty crease_lengths;
|
|
|
|
Alembic::AbcGeom::IFloatArrayProperty crease_sharpnesses;
|
|
|
|
|
|
|
|
vector<FaceSetShaderIndexPair> shader_face_sets;
|
|
|
|
|
|
|
|
Alembic::AbcGeom::IInt32ArrayProperty corner_indices;
|
|
|
|
Alembic::AbcGeom::IFloatArrayProperty corner_sharpnesses;
|
Subdivision: add support for vertex creasing
This adds vertex creasing support for OpenSubDiv for modeling, rendering,
Alembic and USD I/O.
For modeling, vertex creasing follows the edge creasing implementation with an
operator accessible through the Vertex menu in Edit Mode, and some parameter in
the properties panel. The option in the Subsurf and Multires to use edge
creasing also affects vertex creasing.
The vertex crease data is stored as a CustomData layer, unlike edge creases
which for now are stored in `MEdge`, but will in the future also be moved to
a `CustomData` layer. See comments for details on the difference in behavior
for the `CD_CREASE` layer between egdes and vertices.
For Cycles this adds sockets on the Mesh node to hold data about which vertices
are creased (one socket for the indices, one for the weigths).
Viewport rendering of vertex creasing reuses the same color scheme as for edges
and creased vertices are drawn bigger than uncreased vertices.
For Alembic and USD, vertex crease support follows the edge crease
implementation, they are always read, but only exported if a `Subsurf` modifier
is present on the Mesh.
Reviewed By: brecht, fclem, sergey, sybren, campbellbarton
Differential Revision: https://developer.blender.org/D10145
2022-01-20 11:20:30 +00:00
|
|
|
|
|
|
|
// Those are unsupported for now.
|
Alembic Procedural: refactor data reading
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
2021-05-03 05:00:58 +00:00
|
|
|
Alembic::AbcGeom::IInt32Property face_varying_interpolate_boundary;
|
|
|
|
Alembic::AbcGeom::IInt32Property face_varying_propagate_corners;
|
|
|
|
Alembic::AbcGeom::IInt32Property interpolate_boundary;
|
|
|
|
Alembic::AbcGeom::IInt32ArrayProperty holes;
|
|
|
|
Alembic::AbcGeom::IStringProperty subdivision_scheme;
|
|
|
|
Alembic::AbcGeom::IV3fArrayProperty velocities;
|
|
|
|
};
|
|
|
|
|
|
|
|
void read_geometry_data(AlembicProcedural *proc,
|
|
|
|
CachedData &cached_data,
|
|
|
|
const SubDSchemaData &data,
|
|
|
|
Progress &progress);
|
|
|
|
|
|
|
|
/* Data of a ICurvesSchema that we need to read. */
|
|
|
|
struct CurvesSchemaData {
|
|
|
|
Alembic::AbcGeom::TimeSamplingPtr time_sampling;
|
|
|
|
size_t num_samples;
|
|
|
|
Alembic::AbcGeom::MeshTopologyVariance topology_variance;
|
|
|
|
|
|
|
|
Alembic::AbcGeom::IP3fArrayProperty positions;
|
|
|
|
|
|
|
|
Alembic::AbcGeom::IInt32ArrayProperty num_vertices;
|
|
|
|
|
|
|
|
float default_radius;
|
|
|
|
float radius_scale;
|
|
|
|
|
|
|
|
// Those are unsupported for now.
|
|
|
|
Alembic::AbcGeom::IV3fArrayProperty velocities;
|
|
|
|
// if this property is invalid then the weight for every point is 1
|
|
|
|
Alembic::AbcGeom::IFloatArrayProperty position_weights;
|
|
|
|
Alembic::AbcGeom::IN3fGeomParam normals;
|
|
|
|
Alembic::AbcGeom::IFloatGeomParam widths;
|
|
|
|
Alembic::AbcGeom::IUcharArrayProperty orders;
|
|
|
|
Alembic::AbcGeom::IFloatArrayProperty knots;
|
|
|
|
|
|
|
|
// TODO(@kevindietrich): type, basis, wrap
|
|
|
|
};
|
|
|
|
|
|
|
|
void read_geometry_data(AlembicProcedural *proc,
|
|
|
|
CachedData &cached_data,
|
|
|
|
const CurvesSchemaData &data,
|
|
|
|
Progress &progress);
|
|
|
|
|
2023-06-15 01:38:16 +00:00
|
|
|
/* Data of a IPointsSchema that we need to read. */
|
2021-12-01 16:30:46 +00:00
|
|
|
struct PointsSchemaData {
|
|
|
|
Alembic::AbcGeom::TimeSamplingPtr time_sampling;
|
|
|
|
size_t num_samples;
|
|
|
|
|
|
|
|
float default_radius;
|
|
|
|
float radius_scale;
|
|
|
|
|
|
|
|
Alembic::AbcGeom::IP3fArrayProperty positions;
|
|
|
|
Alembic::AbcGeom::IInt32ArrayProperty num_points;
|
|
|
|
Alembic::AbcGeom::IFloatGeomParam radiuses;
|
|
|
|
// Those are unsupported for now.
|
|
|
|
Alembic::AbcGeom::IV3fArrayProperty velocities;
|
|
|
|
};
|
|
|
|
|
|
|
|
void read_geometry_data(AlembicProcedural *proc,
|
|
|
|
CachedData &cached_data,
|
|
|
|
const PointsSchemaData &data,
|
|
|
|
Progress &progress);
|
|
|
|
|
Alembic Procedural: refactor data reading
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
2021-05-03 05:00:58 +00:00
|
|
|
void read_attributes(AlembicProcedural *proc,
|
|
|
|
CachedData &cache,
|
|
|
|
const Alembic::AbcGeom::ICompoundProperty &arb_geom_params,
|
|
|
|
const Alembic::AbcGeom::IV2fGeomParam &default_uvs_param,
|
|
|
|
const AttributeRequestSet &requested_attributes,
|
|
|
|
Progress &progress);
|
|
|
|
|
|
|
|
CCL_NAMESPACE_END
|
|
|
|
|
|
|
|
#endif
|