Convention was not to but after discussion on 918941483f we agree its
best to change the convention.
Names now mostly follow RNA.
Some exceptions:
- Use 'nodetrees' instead of 'nodegroups'
since the struct is called NodeTree.
- Use 'gpencils' instead of 'grease_pencil'
since 'gpencil' is a common abbreviation in the C code.
Other exceptions:
- Leave 'wm' as it's a list of one.
- Leave 'ipo' as is for versioning.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
C++11 doesn't need the space between '> >' in a nested templated
declaration, so instead of `std::vector<std::pair<a, b> >` we can now
write `std::vector<std::pair<a, b> >`.
It's now possible to export curves and NURBS as mesh data to Alembic.
This allows artists to do any crazy thing on curves and export the
visual result to Alembic for interoperability with other software (or
caching for later use, etc.). It's an often-requested feature.
This works around T60503 and the fixes export part of T51311.
Note that exporting zero-width curves is currently not supported, as
exporting a faceless mesh (e.g. just edges and vertices) is not
supported by the mesh writer at all.
To test, create a curve with thickness (for example extruded), export to
Alembic and check the 'Curves to Mesh' checkbox in the export options.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D4213
I moved most of the `AbcMeshWriter` code to a new class
`AbcGenericMeshWriter`. The latter is an abstract class and does not
make any assumptions about the type of Blender object being written.
This makes it possible to write metaballs, curves, nurbs surfaces, etc.
as mesh to Alembic files.
The `AbcMeshWriter` class now is the concrete implementation of
`AbcGenericMeshWriter` for writing mesh objects.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D4213
If the triangulated mesh was in itself a new mesh that should be freed this
should happen before the function returns (as it only returns a single mesh,
and thus the caller can only free one).
That kind of implicit includes should really only be done when totally,
absolutely necessary, and ideally only with rather simple 'second-level'
headers.
Otherwise not being explicit with includes always end up biting in
unexpected ways...
The depsgraph was always created within a fixed evaluation context. Passing
both risks the depsgraph and evaluation context not matching, and it
complicates the Python API where we'd have to expose both which is not so
easy to understand.
This also removes the global evaluation context in main, which assumed there
to be a single active scene and view layer.
Differential Revision: https://developer.blender.org/D3152
- Only basis balls are exported, as they represent the resulting mesh.
As a result the mesh is written to Alembic using the name of the basis
ball.
- MetaBalls are converted to a mesh on every frame, then an
AbcMeshWriter is used to write that mesh to Alembic.
When the mesh changed topology but kept the vertex count the same, it would
result in a corrupt mesh. By checking the face & loop counts too, this has
become less likely.
I've checked IPolyMeshSchema::isConstant(), but it returns true even when
we see that the mesh changed topology.
When a mesh changes its number of vertices during the animation,
Blender rebuilds the DerivedMesh, after which the materials weren't
applied any more (causing the default to the first material slot).
Note that some little parts of code have been dissabled because eval_ctx
was not available there. This should be resolved once DerivedMesh is
replaced.
This allows you to put any kind of animation data on the mesh, and its
shape will be exported on each timekey. Note that this timekey is unrelated
to the animation data (so we don't export on each keyframe, for example).
A practical example is the addition of an animated custom property to
trigger the export of animated mesh data. The mesh data can then be created
from any source, like Python scripts.
Not only is this useful in itself, it also provides a workaround for one
of the two issues described in T51351.
No longer passing time as float and constructing ISampleSelectors all
over the place. Instead, just construct an ISampleSelector once and
pass it along.
