The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/135976
WM_report was originally added for special cases however new code
has been using this in operators for example, where reports should be
sent to the operator via BKE_report, so the caller can handle,
and so Python can catch the errors.
Rename the functions to make them less easily confused with BKE_report
and add a code-comment on why their use should be avoided.
The Alembic file in the issue had 0 points, and 4 widths, defined for
frame 33 which is certainly incorrect from whichever software produced
said file. However, our import code should have proper guards in place
to more gracefully handle the situation.
Pull Request: https://projects.blender.org/blender/blender/pulls/135548
The general idea is to keep the 'old', C-style MEM_callocN signature, and slowly
replace most of its usages with the new, C++-style type-safer template version.
* `MEM_cnew<T>` allocation version is renamed to `MEM_callocN<T>`.
* `MEM_cnew_array<T>` allocation version is renamed to `MEM_calloc_arrayN<T>`.
* `MEM_cnew<T>` duplicate version is renamed to `MEM_dupallocN<T>`.
Similar templates type-safe version of `MEM_mallocN` will be added soon
as well.
Following discussions in !134452.
NOTE: For now static type checking in `MEM_callocN` and related are slightly
different for Windows MSVC. This compiler seems to consider structs using the
`DNA_DEFINE_CXX_METHODS` macro as non-trivial (likely because their default
copy constructors are deleted). So using checks on trivially
constructible/destructible instead on this compiler/system.
Pull Request: https://projects.blender.org/blender/blender/pulls/134771
These were reading in "widths" and not adjusting the values when setting
Blender's "radius" properties.
Found while cleaning up the radius API usage as part of another change.
Pull Request: https://projects.blender.org/blender/blender/pulls/134709
Though "Point Cloud" written as two words is technically correct and should be used in the UI, as one word it's typically easier to write and parse when reading. We had a mix of both before this patch, so better to unify this as well.
This commit also renames the editor/intern/ files to remove pointcloud_ prefix.
point_cloud was only preserved on the user facing strings:
* is_type_point_cloud
* use_new_point_cloud_type
Pull Request: https://projects.blender.org/blender/blender/pulls/134803
In order to better interop with the broader Alembic/USD ecosystem, align
the crease values we export with what we believe is expected by native
OpenSubdiv, a 0-10 range.
On import we will translate the native OpenSubdiv range back into
Blender's 0-1 range.
To account for SubD assets produced by Blender before this change, a
compat check is put in place for both Alembic and USD to use the old
methodology when encountering such files. The compat check makes use
of the Blender version we place inside the format's metadata fields. Old
assets loaded into a new Blender will look ok. New assets loaded into an
old Blender would need to be reworked.
Pull Request: https://projects.blender.org/blender/blender/pulls/132582
Conversion from [0-1] float value ranges to [0-255] integer char ones
was left in Alembic importer, when the internal Blender storage for
these values was converted from a char in the old `MEdge` struct to a
regular float attribute.
Provide an appropriate fallback during Import of some incorrect Alembic
curve data and write out valid data during our Export as well.
The buggy file in question has 2 problems:
- The curve data is marked as being `kVariableOrder` but provides no
actual `order` data. This is invalid according to Alembic code [1]
- The curve data is also marked as being `kBezierBasis` but the actual
values are most likely not bezier judging from how many elements are
in each curve array
This PR focuses on the first problem and allows the file to load
"correctly" - or at least as correctly as it did prior to Blender 4.2.
If we encounter such a file, we will fallback to interpreting the data
as linear POLY curves. It also ensures that we only use `kVariableOrder`
when needed during Export.
[1] 23f1c76d7c/lib/Alembic/AbcGeom/ICurves.h (L91)
Pull Request: https://projects.blender.org/blender/blender/pulls/126378
Similar to !124267 and !124261
This normal data is eventually passed into `BKE_mesh_set_custom_normals`
and through to `mesh_normals_corner_custom_set` which expects normals to
actually be normalized per its documentation.
Not doing so would yield meshes with incorrect "sharp" data for affected
edges.
Thx @OmarEmaraDev for the initial patch
Pull Request: https://projects.blender.org/blender/blender/pulls/124336
The callback-based identification was introduced before job types were added in
7b60529517. The job type should be a more predictable/sane way to identify jobs
that should be exclusive. Using anything else is confusing and non-obvious from
the API usage side. In fact it really confused me when working on #123027.
Checked all existing jobs to make sure behavior is unchanged. Found
two issues:
- `WM_JOB_TYPE_OBJECT_SIM_FLUID` is used for both
`fluid_bake_startjob()` and `fluid_free_startjob()`. It makes sense to
me that they would be exclusive though, so leaving it this way
(meaning they are exclusive now).
- Alembic and USD job types were reused, split them up now to not change
behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/123033
The attribute API defined in `attribute.cc` was dependent on
the assumption that `ID`s are always the "direct" owners of attributes.
For Grease Pencil drawings, this is not the case. The Grease Pencil ID
stores the attributes for layers, and the attributes for drawings are stored
in `CurvesGeometry` on the drawings themselves.
In order to make use of `rna_attribute.cc`, we need that API to handle
other types of attribute owners.
This adds an `AttributeOwner` which is basically just a type and a
pointer. We replace the `ID` pointers and pass `AttributeOwner`s instead.
For cases where we have to do a switch based on the type, all the
types are handled and the `default` statment is left out. This ensures
that we get a compiler warning when a new `AttributeOwnerType`
is added.
No functional changes expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/122765
Allows to import multiple alembic files in single operator call.
When importing multiple alembic files as background job, import progress
will be divided by all files, so if `5` files are imported, each file
will make progress of `20%`. This can be improved if the job text can be
customized to display for example `Import Alembic 1/5` and using 100%
progress status display for each file, but that is out of the scope of
this pr.
The Scene min and max frame are set based on the minimum/maximum frame
ranges detected from all files.
Pull Request: https://projects.blender.org/blender/blender/pulls/121492
Support the new Curves object type in Alembic when exporting curve data.
Make corresponding fixes to importing at the same time.
Summary of changes
- Exporter now supports the `Curves` object type during Export
including when using the convert to mesh option
- Exporter will now enforce that only 1 combination of curve type and
periodicity are in a given object [0].
- Catmul-rom basis curves are now supported and will be used for Hair
data [1].
- Bezier curves are exported with their left/right handle data [2].
- Cyclic bezier and nurbs curves should be handled correctly now.
Along the way this required changes on the Import side as well in order
to be complete
- Importer will now load bezier curve handle data correctly
- Importer could fail to set the correct cyclic data on the last spline
of a multi-curve object
See PR for screenshots
[0] See https://github.com/alembic/alembic/blob/master/lib/Alembic/AbcGeom/OCurves.h#L55
Prior to this change the Alembic exporter could write invalid data to
the file in these cases.
[1] Alembics created with the new Curves Hair object with this patch
will not be loadable in prior versions of Blender. The importer does not
handle the curve data correctly and will crash.
[2] There was a long-standing TODO about how to handle bezier curve data
since nothing is documented on Alembic's side. Bezier data wouldn't even
round-trip properly inside Blender itself. On a hunch, because USD was
influenced by certain aspects of Alembic which came before it, I decided
to try writing out the data the same way as USD. That turned out to work
quite well in at least 1 external software so that's what this patch
will use for both import and export.
Pull Request: https://projects.blender.org/blender/blender/pulls/119894
Reduce dependence on Blender headers as much as possible and move closer
to an include-what-you-use setup.
- Removes unnecessary includes
- Replaces some includes with more appropriate, narrower, substitutes
Pull Request: https://projects.blender.org/blender/blender/pulls/119234
Sort the incoming Alembic objects by name before processing them. This
mirrors what is already done in USD to partially side-step Blender's
quadratic behavior when checking object names.
The file contained in issue #118839 contains over 365000 individual
objects. This change allows loading to be ~4x faster; from 2.2 hours
down to 28 minutes.
Additionally, change the progress bar to report in finer-grained steps
to better indicate that progress is still being made.
Pull Request: https://projects.blender.org/blender/blender/pulls/118869
Make both importers work the same way: first building an array
of the new offsets, then comparing the offsets to check if the
topology changed. Previously the USD importer incorrectly
compared curve offsets to USD point counts.
Also:
- Don't unnecessarily set the resolution to the incorrect default.
The default for the curves system is 12. But it's unnecessary to
fill the attribute to the default value anyway.
- Use some helper methods to iterate over all curves.
- Use float literal instead of integer.
- Use cast and `copy_from` for positions copy
- Pass Span by value
Pull Request: https://projects.blender.org/blender/blender/pulls/118829
This rewrites the Alembic and USD data importers to work with and
output GeometrySets instead of Meshes.
The main motivation for this change is to be able to import properly
point clouds, which are currently imported as Meshes, and curves
data, which suffer from a lot of issues due to limitations of
legacy curves structures (fixed by the new curves data-block) and are
also converted to Meshes. Further, for Curves, it will allow importing
arbitrary attributes.
This patch was primarily meant for Alembic, but changes to USD import
were necessary as they share the same modifier.
For Alembic:
There should be no behavioral changes for Meshes
Curves are imported as the new Curves object type
Points are imported as PointClouds
For USD:
There should be no behavioral changes for Meshes
Curves are imported as the new Curves object type
Note that the current USD importer does not support loading PointClouds,
so this patch does not add support for it.
For both Alembic and USD, knots arrays are not read anymore, as the new
Curves object does not expose the ability to set them. Improvements can
be made in the future if and when example assets are provided.
This fixes at least the following:
#58704: Animated Alembic curves don't update on render
#112308: Curves have offset animations (alembic / USD)
#118261: wrong motion blur from usd in cycles and reverting to the first
frame when disabeling motion blur
Co-authored-by: Jesse Yurkovich <jesse.y@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/115623
The depsgraph CoW mechanism is a bit of a misnomer. It creates an
evaluated copy for data-blocks regardless of whether the copy will
actually be written to. The point is to have physical separation between
original and evaluated data. This is in contrast to the commonly used
performance improvement of keeping a user count and copying data
implicitly when it needs to be changed. In Blender code we call this
"implicit sharing" instead. Importantly, the dependency graph has no
idea about the _actual_ CoW behavior in Blender.
Renaming this functionality in the despgraph removes some of the
confusion that comes up when talking about this, and will hopefully
make the depsgraph less confusing to understand initially too. Wording
like "the evaluated copy" (as opposed to the original data-block) has
also become common anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/118338
The `object_to_world` and `world_to_object` matrices are set during
depsgraph evaluation, calculated from the object's animated location,
rotation, scale, parenting, and constraints. It's confusing and
unnecessary to store them with the original data in DNA.
This commit moves them to `ObjectRuntime` and moves the matrices to
use the C++ `float4x4` type, giving the potential for simplified code
using the C++ abstractions. The matrices are accessible with functions
on `Object` directly since they are used so commonly. Though for write
access, directly using the runtime struct is necessary.
The inverse `world_to_object` matrix is often calculated before it's
used, even though it's calculated as part of depsgraph evaluation.
Long term we might not want to store this in `ObjectRuntime` at all,
and just calculate it on demand. Or at least we should remove the
redundant calculations. That should be done separately though.
Pull Request: https://projects.blender.org/blender/blender/pulls/118210
This adds a new `ModifierData.persistent_uid` integer property with the following properties:
* It's unique within the object.
* Match between the original and evaluated object.
* Stable across Blender sessions.
* Stable across renames and reorderings of modifiers.
Potential use-cases:
* Everywhere where we currently use the name as identifier. For example,
`ModifierComputeContext` and `ModifierViewerPathElem`.
* Can be used as part of a key in `IDCacheKey` to support caches that stay
in-tact across undo steps.
* Can be stored in the `SpaceNode` to identify the modifier whose geometry node
tree is currently pinned (this could use the name currently, but that hasn't been
implemented yet).
This new identifier has some overlap with `ModifierData.session_uid`, but there
are some differences:
* `session_uid` is unique within the entire Blender session (except for duplicates
between the original and evaluated data blocks).
* `session_uid` is not stable across Blender sessions.
Especially due to the first difference, it's not immediately obvious that the new
`persistent_uid` can fulfill all use-cases of the existing `session_uid`. Nevertheless,
this seems likely and will be cleaned up separately.
Unfortunately, there is not a single place where modifiers are added to objects currently.
Therefore, there are quite a few places that need to ensure valid identifiers. I tried to catch
all the places, but it's hard to be sure. Therefore, I added an assert in `object_copy_data`
that checks if all identifiers are valid. This way, we should be notified relatively quickly if
issues are caused by invalid identifiers.
Pull Request: https://projects.blender.org/blender/blender/pulls/117347
The term `PIL` stands for "platform independent library." It exists since the `Initial Revision`
commit from 2002. Nowadays, we generally just use the `BLI` (blenlib) prefix for such code
and the `PIL` prefix feels more confusing then useful. Therefore, this patch renames the
`PIL` to `BLI`.
Pull Request: https://projects.blender.org/blender/blender/pulls/117325
The previous commit introduced a new `RPT_()` macro to translate
strings which are not tooltips or regular interface elements, but
longer reports or statuses.
This commit uses the new macro to translate many strings all over the
UI.
Most of it is a simple replace from `TIP_()` or `IFACE_()` to
`RPT_()`, but there are some additional changes:
- A few translations inside `BKE_report()` are removed altogether
because they are already handled by the translation system.
- Messages inside `UI_but_disable()` are no longer translated
manually, but they are handled by a new regex in the translation
system.
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
