The existing Volume export, which already supports VDB file sequences
and static volumes created inside Blender, is now extended to handle
dynamically created and modified volumes. This allows scenarios where a
Volume Displace modifier is placed over-top an existing VDB sequence or
when Geometry Nodes is used to create animated volumes procedurally.
Detection of what counts as animation is simplistic and mimics what has
been used for Meshes. Essentially if there are any modifiers on the
volume we assume that the volume is "varying" in some way. This can lead
to situations where new volume files are written unnecessarily.
Volume import was also adjusted to correctly set the sequence "offset"
value. This is required to properly handle the case when a VDB sequence
begins animating at a different frame than what's implied by the file
name. For example, a VDB file sequence with file names containing 14-19
but the user wants to animate on frames 8-13 instead.
Tests are added which cover:
- Animated VDB file sequences
- Animated Mesh To Volume where the mesh has been animated
- Animated Volume Displacement where displacement settings are animated
- Animated Volumes created with a Geometry Nodes simulation
----
New test data has been checked in: `tests/data/usd/usd_volumes.blend` and files inside `tests/data/usd/volume-data/`
Pull Request: https://projects.blender.org/blender/blender/pulls/128907
This commit takes the 'Slotted Actions' out of the experimental phase.
As a result:
- All newly created Actions will be slotted Actions.
- Legacy Actions loaded from disk will be versioned to slotted Actions.
- The new Python API for slots, layers, strips, and channel bags is
available.
- The legacy Python API for accessing F-Curves and Action Groups is
still available, and will operate on the F-Curves/Groups for the first
slot only.
- Creating an Action by keying (via the UI, operators, or the
`rna_struct.keyframe_insert` function) will try and share Actions
between related data-blocks. See !126655 for more info about this.
- Assigning an Action to a data-block will auto-assign a suitable Action
Slot. The logic for this is described below. However, There are cases
where this does _not_ automatically assign a slot, and thus the Action
will effectively _not_ animate the data-block. Effort has been spent
to make Action selection work both reliably for Blender users as well
as keep the behaviour the same for Python scripts. Where these two
goals did not converge, reliability and understandability for users
was prioritised.
Auto-selection of the Action Slot upon assigning the Action works as
follows. The first rule to find a slot wins.
1. The data-block remembers the slot name that was last assigned. If the
newly assigned Action has a slot with that name, it is chosen.
2. If the Action has a slot with the same name as the data-block, it is
chosen.
3. If the Action has only one slot, and it has never been assigned to
anything, it is chosen.
4. If the Action is assigned to an NLA strip or an Action constraint,
and the Action has a single slot, and that slot has a suitable ID
type, it is chosen.
This last step is what I was referring to with "Where these two goals
did not converge, reliability and understandability for users was
prioritised." For regular Action assignments (like via the Action
selectors in the Properties editor) this rule doesn't apply, even though
with legacy Actions the final state ("it is animated by this Action")
differs from the final state with slotted Actions ("it has no slot so is
not animated"). This is done to support the following workflow:
- Create an Action by animating Cube.
- In order to animate Suzanne with that same Action, assign the Action
to Suzanne.
- Start keying Suzanne. This auto-creates and auto-assigns a new slot
for Suzanne.
If rule 4. above would apply in this case, the 2nd step would
automatically select the Cube slot for Suzanne as well, which would
immediately overwrite Suzanne's properties with the Cube animation.
Technically, this commit:
- removes the `WITH_ANIM_BAKLAVA` build flag,
- removes the `use_animation_baklava` experimental flag in preferences,
- updates the code to properly deal with the fact that empty Actions are
now always considered slotted/layered Actions (instead of that relying
on the user preference).
Note that 'slotted Actions' and 'layered Actions' are the exact same
thing, just focusing on different aspects (slot & layers) of the new
data model.
The "Baklava phase 1" assumptions are still asserted. This means that:
- an Action can have zero or one layer,
- that layer can have zero or one strip,
- that strip must be of type 'keyframe' and be infinite with zero
offset.
The code to handle legacy Actions is NOT removed in this commit. It will
be removed later. For now it's likely better to keep it around as
reference to the old behaviour in order to aid in some inevitable
bugfixing.
Ref: #120406
Like with NLA strips, Action assignment on Action Constraints needs to
have an extra step (compared to regular assignment to animated
data-blocks).
For the Action Constraint, the auto slot selection gets one more
fallback option (compared to the generic code). This is to support the
following scenario, which used to be necessary as a workaround for a bug
in Blender (#127976):
- Python script creates an Action,
- assigns it to the animated object,
- unassigns it from that object,
- and assigns it to the object's Action Constraint.
The generic code doesn't work for this. The first assignment would see
the slot `XXSlot`, and because it has never been used, just use it. This
would change its name to `OBSlot`. The assignment to the Action
Constraint would not see a 'virgin' slot, and thus not auto-select
`OBSlot`. This behaviour makes sense when assigning Actions in the
Action editor (it shouldn't automatically pick the first slot of
matching ID type), but for the Action Constraint I (Sybren) feel that it
could be a bit more 'enthousiastic' in auto-picking a slot.
Note that this is the same behaviour as for NLA strips, albeit for a
slightly different reason. Because of that it's not sharing code with
the NLA.
Pull Request: https://projects.blender.org/blender/blender/pulls/128892
When creating a new NLA strip for an action, as well as when setting
`strip.action` via RNA, use the generic action-assignment code. This
ensures that the slot selection follows the same logic as other Action
assignments.
If the generic slot selection doesn't find a suitable slot, and there is
a single slot on that Action of a suitable ID type, always assign it.
This is to support the following scenario:
- Python script creates an Action and adds F-Curves via the legacy API.
- This creates a slot 'XXSlot'.
- The script creates multiple NLA strips for that Action.
- The desired result is that these strips get the same Slot assigned as
well.
The generic code doesn't work for this, because:
- The first strip assignment would see the slot `XXSlot` (`XX`
indicating "not bound to any ID type yet"). Because that slot has
never been used, it will be assigned (which is good). This assignment
would change its name to, for example, `OBSlot`.
- The second strip assignment would not see a 'virgin' slot, and thus
not auto-select `OBSlot`. This behaviour makes sense when assigning
Actions in the Action editor (assigning an Action that already
animates 'Cube' to 'Suzanne' should not assign the 'OBCube' slot to
Suzanne), but for the NLA I feel that it could be a bit more
'enthousiastic' in auto-picking a slot to support the above case.
This is preparation for the removal of the 'Slotted Actions'
experimental flag, and getting the new code to run as compatibly as
possible with the legacy code.
The return value of `animrig::nla::assign_action()` has changed a bit.
It used to indicate whether a slot was auto-selected; it now indicates
whether the Action assignment was successful. Whether a slot was
assigned or not can be seen at `strip.action_slot`.
Pull Request: https://projects.blender.org/blender/blender/pulls/128892
Cycle-aware keying on slotted Actions now works the same as on legacy
Actions. In the future this will be improved, but for now it's good enough
to have the same behaviour as before.
Pull Request: https://projects.blender.org/blender/blender/pulls/128892
A new parameter, topology influence, is added that causes the
join_triangles operator to prioritize edge joins that create quads with
sensible geometry relative to existing quads, instead of selecting the
'flattest' and 'squarest' next pair and then leaving leftover triangles
with no partners to merge with.
This produces its best results with the face and shape thresholds set to
180 degrees (no hard limits as a restriction against merging) and
topology influence somewhere between 100-130%, depending on the mesh.
Too low and many parallelograms and triangles are left, too high and the
algorithm tries too hard and starts making errors.
Note that both quads already present in the selection, as well as the
quads that are generated during the operator, will influence the
topology around them. This allows the modeler to manually merge a few
quads in key areas of the mesh, as a hint to the algorithm, indicating
what result they way they want to see, and the algorithm will then take
those quads into account and try to build around them according to the
modeler's guidance.
A new checkbox to leave only the remaining triangles selected has also
been added. This helps users visualize what remains to be fixed.
Ref !128610
EXR DWAA and DWAB are conceptually similar to lossy JPG compression,
with a tunable file size vs image quality parameter. However, previously
Blender always used the fixed default setting, which is kinda similar
to very high quality (like 97) for JPG.
Internally EXR DWA/DWB quality parameter is inverted scale, i.e. 0 is
best/lossless quality, and increased setting value means decreased
quality. However the rest of Blender UI uses 1-100 JPG-like quality
scale, where values above 90 are "visually lossless", 100 is lossless,
and going below something like 50 would be visually quite lossy. So map
that to internal DWA setting:
- blender 100 -> DWA 0
- blender 97 -> DWA 45
The rest is linear relation based on those two points.
Pull Request: https://projects.blender.org/blender/blender/pulls/128790
Instead of running the ComplianceChecker during just one test, run it
for every export test. A common `export_and_validate` local function is
used in all relevant locations now.
Pull Request: https://projects.blender.org/blender/blender/pulls/128513
This adds feature parity with Cycles regarding light and shadow liking.
Technically, this extends the GBuffer header to 32 bits, and uses
the top bits to store the object's light set membership index.
The same index is also added to `ObjectInfo` in place of padding bytes.
For shadow linking, the shadow blocker sets bitmask is stored per
tilemap. It is then used during the GPU culling phase to cull objects
that do not belong to the shadow's sets.
Co-authored-by: Clément Foucault <foucault.clem@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/127514
When using the `create_collection` parameter during import, the newly
created Collection would be assigned a fake user which isn't necessary
and caused the user count to be 2 instead of the more natural 1 here.
Remove the fake user and add test coverage for the scenario in general.
Pull Request: https://projects.blender.org/blender/blender/pulls/128348
Avoid running a Python unit test for layered Actions in non-experimental
builds.
Due to a misunderstanding, enabling the user preference for the 'Slotted
Actions' experimental feature is still possible on release builds, which
caused this test to fail on non-experimental builds (because it's
intentionally missing a chunk of experimental code).
No functional changes to Blender itself.
Pull Request: https://projects.blender.org/blender/blender/pulls/128483
Add support for `rna_struct.keyframe_insert(…, group="name")` parameter,
when inserting keys into a layered Action.
This simply was never implemented, and the default channel group name
was always used.
Pull Request: https://projects.blender.org/blender/blender/pulls/128383
Clean up a keyframe insertion unit test I just committed, as it had some
commented-out code that shouldn't have been commented out. The test
logic could also be simplified, as the complexity was necessary for
replaying the broken test case, but not necessary for testing the actual
underlying behaviour.
No functional changes.
Ref: 2dba943341ce7a7706c3865b4b7b1cfc5d6bb746
Pull Request: https://projects.blender.org/blender/blender/pulls/128379
BaseException was used as a catch-all in situations where it
didn't make sense and where "Exception" is more appropriate
based on Python's documentation & error checking tools,
`pylint` warns `broad-exception-caught` for e.g.
BaseException includes SystemExit, KeyboardInterrupt & GeneratorExit,
so unless the intention is to catch calls to `sys.exit(..)`,
breaking a out of a loop using Ctrl-C or generator-exit,
then it shouldn't be used.
Even then, it's preferable to catch those exceptions explicitly.
Calling `action.fcurves.clear()` would clear the F-Curves, but didn't
update the F-Curve groups. This meant that the groups data still had their
original length & offsets into the F-Curves array, causing subsequent
F-Curve creation to crash Blender.
The unit test for this also covers the previous commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/128375
This includes tests for a "static" mesh where the materials have been
assigned and are expected to remain the same over time.
The test scenario also includes a "dynamic" mesh where both new faces
and new materials are assigned to the same mesh over time (inspired by
#118754). However, that cannot be tested right now due to missing
features of both the MeshSequenceCache and our USD IO code. No testing
will occur for that case until the features are implemented.
Pull Request: https://projects.blender.org/blender/blender/pulls/128341
This implements versioning code to go from legacy to layered action.
The versioning is only triggered when the experimental flag for
Multi-Slot actions is enabled.
All the actions are converted in place, which should be fine because
of backwards and forwards compatibility with layered actions.
Pull Request: https://projects.blender.org/blender/blender/pulls/127842
An additional scenario was added which tests multiple meshes with shape
keys being animated by a single armature. The meshes purposely use the
same shape key name to ensure we also correctly account for that.
Additionally, because the existing shape key and armature test coverage
comes from already written .usd files, this test will first export from
Blender so we can better validate a full Blender-to-Blender roundtrip.
Pull Request: https://projects.blender.org/blender/blender/pulls/128160
Color primvars/attributes were historically treated as a special case
for both import and export. This was mostly done to align with how
painting and viewport display works in Blender. Export would generally
ignore color attributes except when they were found on a Mesh's Point or
FaceCorner domains. And import went out of its way to map incoming color
primvars to the FaceCorner domain in more situations than necessary.
To facilitate better roundtripping in Blender<=>USD workflows, and to
reduce code duplication, this PR teaches the common attribute utilities
how to handle color types. The color attributes will now work on all
relevant Mesh and Curve domains.
There were tests in place for this already but they were set to verify
the inverse state, i.e. the technically broken state, until this could
be fixed.
There remains one special case: "displayColor" primvars and attributes.
The "displayColor" is a special primvar in USD and is the de-facto way
to set a simple viewport color in that ecosystem. It must also be a
color3f type. In order to not regress import, if a "displayColor"
primvar is found on the Face domain we will map it to FaceCorner instead
so it can be displayed in the viewport; which has been the case for the
past several releases. We can drop this special-case if/when Blender can
display Face colors through the Viewport Shading "Attribute" color type.
Additionally, Blender will export this, and only this, color attribute
as a color3f.
Note: As was the case prior to this PR, the following 2 discrepancies
still prevent "perfect" round-trips:
- USD does not have an equivalent to Blender's byte colors; they are
treated as float during IO
- Blender does not have an equivalent to USD's color3 types; they are
treated as color4 during IO
Pull Request: https://projects.blender.org/blender/blender/pulls/127784
This adds a new type of zone to Geometry Nodes that allows executing some nodes
for each element in a geometry.
## Features
* The `Selection` input allows iterating over a subset of elements on the set
domain.
* Fields passed into the input node are available as single values inside of the
zone.
* The input geometry can be split up into separate (completely independent)
geometries for each element (on all domains except face corner).
* New attributes can be created on the input geometry by outputting a single
value from each iteration.
* New geometries can be generated in each iteration.
* All of these geometries are joined to form the final output.
* Attributes from the input geometry are propagated to the output
geometries.
## Evaluation
The evaluation strategy is similar to the one used for repeat zones. Namely, it
dynamically builds a `lazy_function::Graph` once it knows how many iterations
are necessary. It contains a separate node for each iteration. The inputs for
each iteration are hardcoded into the graph. The outputs of each iteration a
passed to a separate lazy-function that reduces all the values down to the final
outputs. This final output can have a huge number of inputs and that is not
ideal for multi-threading yet, but that can still be improved in the future.
## Performance
There is a non-neglilible amount of overhead for each iteration. The overhead is
way larger than the per-element overhead when just doing field evaluation.
Therefore, normal field evaluation should be preferred when possible. That can
partially still be optimized if there is only some number crunching going on in
the zone but that optimization is not implemented yet.
However, processing many small geometries (e.g. each hair of a character
separately) will likely **always be slower** than working on fewer larger
geoemtries. The additional flexibility you get by processing each element
separately comes at the cost that Blender can't optimize the operation as well.
For node groups that need to handle lots of geometry elements, we recommend
trying to design the node setup so that iteration over tiny sub-geometries is
not required.
An opposite point is true as well though. It can be faster to process more
medium sized geometries in parallel than fewer very large geometries because of
more multi-threading opportunities. The exact threshold between tiny, medium and
large geometries depends on a lot of factors though.
Overall, this initial version of the new zone does not implement all
optimization opportunities yet, but the points mentioned above will still hold
true later.
Pull Request: https://projects.blender.org/blender/blender/pulls/127331
More thoroughly test certain image processing behavior of USDZ IO.
Namely that regular and UDIM images are imported back when using either
the packed or the copy import modes. Along the way ensure that we have
coverage for image downscaling on export as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/127985
Export Blender Point Clouds as `UsdGeomPoints` primitives.
Summary
- Adds the `USDPointsWriter` class
- Adds tests to ensure that animated positions, velocities, radii, and
regular attributes are all written correctly (in a sparse format)
- Adds a new `export_points` operator property, mirroring the existing
`import_points` option
Pull Request: https://projects.blender.org/blender/blender/pulls/126389
This commit adds low-level logic in BKE to support three behaviors in
case of name conflict when renaming an ID:
1. Always tweak new name of the renamed ID (never modify the other ID
name).
2. Always set requested name in renamed ID, modifying as needed the
other ID name.
3. Only modify the other ID name if it shares the same root name with the
current renamed ID's name.
It also adds quite some changes to IDTemplate, Outliner code, and
RNA-defined UILayout code, and the lower-level UI button API, to allow
for the new behavior defined in the design (i.e. option three from above list).
When renaming from the UI either 'fails' (falls back to adjusted name) or forces
renaming another ID, an INFO report is displayed.
This commit also fixes several issues in existing code, especially
regarding undo handling in rename operations (which could lead to saving
the wrong name in undo step, and/or over-generating undo steps).
API wise, the bahavior when directly assigning a name to the `ID.name`
property remains unchanged (option one from the list above). But a new
API call `ID.rename` has been added, which offers all three behaviors.
Unittests were added to cover the new implemented behaviors (both at
BKE level, and the RNA/Py API).
This commit implements #119139 design.
Pull Request: https://projects.blender.org/blender/blender/pulls/126996
Clear the entire scene at the start of every test case. Previously this
happened only at the start of the test suite. This should make tests
more independent.
No functional changes to the actual tests.
Add the ability to control whether or not Hardware Ray Tracing (HWRT)
is enabled during render tests.
This is done by adding `-RT` to the end of the device name in the
Cycles device list. E.g. `HIP-RT`. This is supported with HIP, oneAPI,
and Metal.
Change in behaviour:
If you do not specify `-RT`, then HWRT will be disabled. This results
in a change in behaviour:
1. `METAL` device tests on M3 or newer Macs no longer using MetalRT
2. `ONEAPI` device tests no longer use Embree GPU.
Note: Some tests are failing on some platforms/configurations that can
now be easily tested due to this commit. This does not effect the
build bot automated testing as it does not test these configurations.
These tests have not been blocked from running, primarily to help
developers investigate and fix the issues.
Ref #123012
Pull Request: https://projects.blender.org/blender/blender/pulls/125082
