| Age | Commit message (Collapse) | Author |
|---|
|
Follows existing naming for the most part, also use "num" as a suffix
in some instances (following our naming conventions).
|
|
|
|
|
|
|
|
Note: does not fix the limit in PBVH draw which is
caused by VBO limits not MAX_MCOL.
|
|
In all these cases, it was clear that the layer values were set right
after the layer was created anyway. So there's no point in using
calloc or setting the values to zero first.
See 25237d2625078c6d for more info.
|
|
When allocating new `CustomData` layers, often we do redundant
initialization of arrays. For example, it's common that values are
allocated, set to their default value, and then set to some other
value. This is wasteful, and it negates the benefits of optimizations
to the allocator like D15082. There are two reasons for this. The
first is array-of-structs storage that makes it annoying to initialize
values manually, and the second is confusing options in the Custom Data
API. This patch addresses the latter.
The `CustomData` "alloc type" options are rearranged. Now, besides
the options that use existing layers, there are two remaining:
* `CD_SET_DEFAULT` sets the default value.
* Usually zeroes, but for colors this is white (how it was before).
* Should be used when you add the layer but don't set all values.
* `CD_CONSTRUCT` refers to the "default construct" C++ term.
* Only necessary or defined for non-trivial types like vertex groups.
* Doesn't do anything for trivial types like `int` or `float3`.
* Should be used every other time, when all values will be set.
The attribute API's `AttributeInit` types are updated as well.
To update code, replace `CD_CALLOC` with `CD_SET_DEFAULT` and
`CD_DEFAULT` with `CD_CONSTRUCT`. This doesn't cause any functional
changes yet. Follow-up commits will change to avoid initializing
new layers where the correctness is clear.
Differential Revision: https://developer.blender.org/D15617
|
|
|
|
- CustomDataType -> eCustomDataType
- CustomDataMask -> eCustomDataMask
- AttributeDomain -> eAttrDomain
- NamedAttributeUsage -> eNamedAttrUsage
|
|
|
|
Similar to cf69652618fefcd22b2cde9a2.
|
|
The "PROP" in the name reflects its generic status, and removing
"LOOP" makes sense because it is no longer associated with just
mesh face corners. In general the goal is to remove extra semantic
meaning from the custom data types.
|
|
Follow naming from T85728.
|
|
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
|
|
|
|
|
|
The crash is caused as the data is only for the first frame, but the mesh
changes topology, so reading the data in subsequent frames causes a
buffer overflow. To fix this, we check that the data size matches the
mesh's vertex count.
|
|
Ref T92709
|
|
When enabling or disabling a Mesh Sequence Cache modifier of an Object
with a hair particle system, the hair would switch positions. This is
caused because original coordinates in Blender are expected to be
normalized, and toggling the modifier would cause the usage of different
orco layers: one that is normalized, and the other which isn't.
This bug exposes a few related issues:
- if the Alembic file did not have orco data,
`MOD_deform_mesh_eval_get`, used by the particle system modifier, would
add an orco layer without normalization
- `MOD_deform_mesh_eval_get` would also ignore the presence of an orco
layer (e.g. one that could have been read from Alembic)
- if the Alembic file did have orco data, the data would be read
unnormalized
To fix those various issues, original coordinates are normalized when
read from Alembic and unnormalized when written to Alembic; and a new
utility function `BKE_mesh_orco_ensure` is added to add a normalized
orco layer if none exists on the mesh already, this function derives
from the code used in the particle system.
Reviewed By: brecht
Maniphest Tasks: T92561
Differential Revision: https://developer.blender.org/D13306
|
|
Allow exporting of animated vertex colors to Alembic.
The changes are made to be in line with the way the UV Maps are written.
Each vertex color gets a OC4fGeomParam created and mapped into the
CDStreamConfig to avoid recreating the Param on each frame.
The time sample index is also stored in the config now and set onto the
UV and Vertex Color params each frame. Without this the exports would
get inconsistent timing results where animated UV maps and Vertex Colors
were not playing back at the original speed.
Reviewed By: sybren
Maniphest Tasks: T88074
Differential Revision: https://developer.blender.org/D11278
|
|
No functional changes.
|
|
Add check for the `arbGeomParams` property being valid, before attempting
to access a sub-property from it.
|
|
This adds support for importing UV sets which are defined per vertex,
instead of per face corners. Such UV sets can be generated when the
mesh is split according to UV islands, or when there is only one UV
island, in which cases only a single UV value can be stored per
vertex since vertices will never be on a seam.
Reviewed By: sybren
Differential Revision: https://developer.blender.org/D11584
|
|
|
|
Read and write generated coordinates (also known as "original
coordinates", "reference coordinates", or "orcos") from and to Alembic.
A custom geometry property named "Pref" is used for (hopefully)
interoperability with Maya and Houdini. For now it's only guaranteed for
Blender-to-Blender.
Export: writing generated coordinates is optional (on by default).
Import: generated coordinates are always read whenever the reading of
vertex data is enabled.
Manifest Task: T88081
|
|
Replace nested `namespace blender { namespace io { namespace alembic {`
with `namespace blender::io::alembic {`.
No functional changes.
|
|
|
|
This commit only moves code into the `blender::io::alembic` namespace,
it does not move `static` functions into an anonymous namespace.
No functional changes.
|
|
|
|
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.
|
|
|
|
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
|
|
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.
|
