| Age | Commit message (Collapse) | Author |
|---|
|
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 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
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
This moves the `alembic`, `avi`, `collada`, and `usd` modules into a common
`io` directory.
This also cleans up some `#include "../../{somedir}/{somefile}.h"` by
adding `../../io/{somedir}` to `CMakeLists.txt` and then just using
`#include "{somefile}.h"`.
No functional changes.
|
