Alembic is not a single file format, it can be stored in two different
ways: Ogawa and HDF5. Ogawa replaced HDF5 and is smaller and much faster
(4-25x) to read ([source](http://exocortex.com/blog/alembic_is_about_to_get_really_fast)).
As long as Blender has had Alembic support, it has never supported the
HDF5 format in any release. There is a build option `WITH_ALEMBIC_HDF5`
that can be used to enable HDF5 support in your own build. This commit
removes this build option and the code that it manages.
In the years that I have been maintainer of Blender's Alembic code, I
only remember getting a request to support HDF5 once, and that was to
support very old software that has likely since then been updated to
support Ogawa. Ubuntu and Fedora also seem to bundle Blender without
HDF5 support.
This decision was discussed on
[DevTalk](https://devtalk.blender.org/t/alembic-hdf5-support-completely-remove)
where someone also mentioned that there is a tool available that can
convert HDF5 files to the Ogawa format.
- BKE_lattice_deform_data_create was init_latt_deform.
- BKE_lattice_deform_data_destroy was end_latt_deform.
- BKE_lattice_deform_data_eval_co was calc_latt_deform.
The material binding API that we used was removed in the Universal Scene
Description library version 20.02. Using this new API, the code is
compatible with both USD 19.11 and 20.02.
- ED_object_constraint_list_from_constraint was get_constraint_lb
- ED_object_constraint_list_from_context was get_active_constraints
- ED_object_constraint_active_get was get_active_constraint
- ED_object_constraint_active_set was ED_object_constraint_set_active
The file subversion is no longer used in the Python API or user interface,
and is now internal to Blender.
User interface, Python API and file I/O metadata now use more consistent
formatting for version numbers. Official releases use "2.83.0", "2.83.1",
and releases under development use "2.90.0 Alpha", "2.90.0 Beta".
Some Python add-ons may need to lower the Blender version in bl_info to
(2, 83, 0) or (2, 90, 0) if they used a subversion number higher than 0.
https://wiki.blender.org/wiki/Reference/Release_Notes/2.83/Python_API#Compatibility
This change is in preparation of LTS releases, and also brings us more
in line with semantic versioning.
Fixes T76058.
Differential Revision: https://developer.blender.org/D7748
This was caused by a side-effect of our exporting code's memory
management (Alembic considers data "written" and "final" when its C++
objects go out of scope) in combination with my change in
rB65574463fa2d. I removed an "only export UVs on the first frame" clause
because it was unclear why this restriction was there. As it turns out,
it breaks the export of the 2nd and subsequent UV maps on an animated
mesh. Effectively, on every frame the Alembic library thought we want to
create a new UV map, instead of continuing to write a new frame of data
to the existing one.
This is resolved by keeping a reference to the C++ objects for the UV
maps in memory while the exporter is running.
It is not impossible that the number of knots is stored wrong in the
file (for example, it will be 1 knot only).
This change fixes bad memory allocation and bad memory access in such
cases. It also fixes strict compiler warning which was mentioning that
the allocation size is wrong),
There isn't really the correct way of dealing with such situation, so
simply fall back to Blender's knots calculation.
Differential Revision: https://developer.blender.org/D7765
When auto-smooth enabled, but no custom normals layer present, the Alembic
exporter would incorrectly assume the mesh was shaded smooth. This is now
corrected, and normals are always written when auto-smooth is enabled.
In the Alembic importer, the animation of UVs and normals was
overlooked; when the mesh geometry is not animated, the entire mesh was
considered constant.
T76132 concerns both the exporting and importing of changing UVs. This
commit fixes the importing.
In the Alembic exporter, UVs were only exported on the first frame. This
is an issue, as when exporting an animated mesh the topology can change,
and then the UV coordinates of the first frame are no longer valid.
T76132 concerns both exporting and importing changing UVs. This fixes
the exporting.
Even though {T76514} is caused by invalid geometry, and thus technically
constitutes a bug in the software that created the Alembic file, I would
like Blender not to crash on importing such a file.
The error in the Alembic file consists of invalid mesh loops, where
consecutive loops refer to the same vertex. The `BKE_mesh_validate()`
can actually correct these errors, so this commit focuses on two things:
- Letting Blender survive the situation until the mesh is loaded, and
- Detecting the error so that `BKE_mesh_validate()` can be called only
when necessary. This ensures there is only a minimal impact on
performance when loading actually valid data.
Differential Revision: https://developer.blender.org/D7703
Reviewed By: JacquesLucke
Surrounding includes with an 'extern "C"' block is not necessary anymore.
Also that made it harder to add any C++ code to some headers, or include headers
that have "optional" C++ code like `MEM_guardedalloc.h`.
I tested compilation on linux and windows (and got help from @LazyDodo).
If this still breaks compilation due to some linker error, the header containing
the symbol in question is probably missing an 'extern "C"' block.
Differential Revision: https://developer.blender.org/D7653
Particle systems have two names: the name of the particle system itself,
and the name of the particle system settings. The USD exporter used to
use the latter name, and now switched to the former. This is to be in
line with the Alembic exporter, as well as to give users more freedom in
the naming (the particle system can have a unique name but still share
settings from other particle systems).
The construction of the export graph is now split into a few steps:
- Construct a `HierarchyContext` object for the to-be-exported object.
- Determine the graph index, i.e. the export-parent and the duplicator.
- Update the `HierarchyContext` object for this graph index.
This allows the upcoming new Alembic exporter to override the location of
an object in the export graph, in order to support "flattened" exports.
Aside from that, this also simply makes the code cleaner.
No functional changes.
The long-term goal is to move code out of `abc_util.{h,cc}` into either
files with better, more concrete names, or simply into the one file
where they are used.
No functional changes.
There was a bug in the `connect_loose_objects()` function, which caused
some objects to be exported twice (once for real, and once
transform-only). This is now resolved.
The `BKE_animsys.h` and `anim_sys.c` files already had a an "AnimData
API" section. The code in that section has now been split off, and
placed into `BKE_anim_data.h` and `anim_data.c`.
All files that used to include `BKE_animsys.h` have been adjusted to
only include the animation headers they need (sometimes none).
No functional changes.
The files are now split up into the following sections:
- `BKE_anim_path.h` and `anim_path.c` for path/curve functions.
- `BKE_anim_visualization.h` and `anim_visualizationanim_path.c` for
animation visualization (mostly motion paths).
- `BKE_duplilist.h` for DupliList function declarations. These were
already implemented in `object_dupli.c`, so they were rather out of
place being declared in `BKE_anim.h` in the first place.
No functional changes.
Unlike Linux where fseek/tell will be either 32 or 64 bit
depending on the target platform, it will always be 32 bit
on windows.
We had some macro magic in BLI_winstuff.h that substituted
them for 64 bit versions, but that is upsetting the system
headers if they get included after BLI_winstuff.h which
is problematic for D6811.
This diff adds proper functions in blenlib and updates
all calls that were using the BLI_winstuff.h header to
gain 64 bit file IO.
note: Anything that was using the 32 bit versions (ie not
including BLI_winstuff.h) will still be using the 32 bit
versions, which is perhaps a good code quality Friday project.
Differential Revision: https://developer.blender.org/D7160
Reviewers: brecht dfelinto
The `check_is_animated()` function will be used by the upcoming Alembic
exporter as well. There is nothing USD-specific in the function.
No functional changes.
The code was copied from the Alembic exporter, and some of the options are
no longer used.
Not updating the Alembic exporter itself, as this will be done in a much
larger rewrite.
printf is called for a size_t (64 bit on x64) type
but the formatter is `%lu` (32 bit) leading to a
warning with MSVC.
`%zu` is the appropriate formatter.
I've added a very minimal mesh validation before the Alembic mesh is actually
converted to a Blender mesh. This prevents a specific crash with an example
file attached to T74200.
In rB7c5a44c71f13 I changed the way transform matrices are loaded from
Alembic. Instead of having the Alembic importer convert matrices from
local (in the Alembic file) to World (to pass to the constraint handling
the animation of transforms), I set the constraint space to
`CONSTRAINT_SPACE_LOCAL`.
This worked thanks to rB7728bfd4c45c. However, that commit was reverted,
which meant that for parentless objects `CONSTRAINT_SPACE_LOCAL` no
longer means "local space".
The situation is resolved by setting the constraint to world space
again, and computing the world matrix in the Alembic importer.
