This rescales the whole scene by its root transform to match the same
visual size while not forcing the user to wait for scale to be applied to
each object.
This is requested by studios whose main applications / USD scenes are
in CM, because referencing and payloading scenes from disparate scales
can cause issues at resolution time.
If "Apply Unit Scale Conversion" is unchecked on import, the user now
has the ability to bring the objects in with a scale factor of 1.0, so that the
objects may be edited as if Blender's scene units matches the imported
stage's.
At export time, a "Stage Meters Per Unit" value can be chosen from a list
of common measurements, as well as setting a custom value.
Co-authored-by: kiki <charles@skeletalstudios.com>
Co-authored-by: Michael Kowalski <makowalski@nvidia.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/122804
The issue is that certain RNA paths cannot be generated to come
from an ID and `RNA_path_from_ID_to_property` will return no value.
We are using that function in the keyframing code to allow passing
in a pointer to a bone and a path relative to that bone.
Since there is currently no good way to find the path from the ID to an arbitrary
struct pointer (see #122427), this patch is a workaround that uses
the struct_pointer IF that happens to be an ID pointer.
Of course that still has the core limitation in place but until a
better solution is available on the RNA side this is the best we can do.
Pull Request: https://projects.blender.org/blender/blender/pulls/132552
The goal of this test is to try to import some critical py scripts with the
system python of the building machine.
The main target is to ensure that these py scripts remain usable by all
buildbot machines, as some of them are using fairly outdated python
versions.
Current status:
* Scripts in `build_files` and `docs` are checked.
* Some python scripts in `build_files` were 'reverted' to be compatible
with older required python version currently (3.6).
* A few scripts are excluded from the test, mostly because they use Blender's
`bpy` module, which means they are only intended to be ran with Blender's
python anyway.
* The test is only enabled for Linux buildbots currently, as they use the
oldest Python by far.
Notes:
* Some more scripts are likely to be moved around in the future.
* Whether these tests need to be enabled on windows or macos platforms remains
an open question.
Pull Request: https://projects.blender.org/blender/blender/pulls/130746
Importing USD `quatf` types was erroneously left disabled after recent
work this past summer for better attribute support. It is already
correctly enabled and validated for Export.
The `half` and `double` variants must still be skipped for now though.
Pull Request: https://projects.blender.org/blender/blender/pulls/132252
Import edge crease values and properly configure any added subdivision
modifiers with correct UV and boundary settings. These were already
exported so this now completes our subdivision support.
Pull Request: https://projects.blender.org/blender/blender/pulls/131569
This patch disables compositor tests that rely on anisotropic filtering
for GPU testing. This is done until we make sure they pass universally
by not relying on hardware filtering.
Test files that rely on anisotropic filtering were moved to their own
tests to be able to disable them for GPU only.
This patch removes the references for the GPU tests and uses the CPU
references for both CPU and GPU, since they are expected to match. This
also unifies the tests scripts into a single script with an argument
for execution device.
This patch implements Font to Curves, Legacy curves to Grease Pencil and
Font to Grease Pencil conversions.
Note that Font to Grease Pencil is done by converting Font to Curves
then converting Curves to Grease Pencil. Currently we do not have
direct conversion APIs.
Part of #131595 and #130518
Pull Request: https://projects.blender.org/blender/blender/pulls/131612
Contains the following changes:
- Uses new `render_layer` images in test repo
- Excludes known broken tests with Hydra Storm from USD 24.05
- packed float and packed half images show corruption
- USD export doesn't support the current light-tree .blend
- Bump the `image_colorspace` and `image_mapping` thresholds to
account for image filtering differences from OS/drivers
Pull Request: https://projects.blender.org/blender/blender/pulls/132044
Both the draw manager and gpu backend used the same compilation
directive for enablement. This PR seperates them into
`WITH_GPU_DRAW_TESTS` for draw manager related tests and
`WITH_GPU_BACKEND_TESTS` for gpu backend related tests.
Pull Request: https://projects.blender.org/blender/blender/pulls/132018
OptiX OSL tests were previously disabled due to a GPU driver bug
resulting in many tests failing unexpectedly.
The new driver version is now out with the fix so we can now enable
OptiX OSL testing.
This commit also updates the OptiX OSL block list with better comments,
and more tests that are known to fail and need investigating.
Ref: #123012
Pull Request: https://projects.blender.org/blender/blender/pulls/129280
Until the newer Hair Curves system can fully replace particle hair, add
a small test to ensure this continues to work.
Since the hair is exported as cubic bspline curves, we can also use this
same file to test bspline import now too.
Pull Request: https://projects.blender.org/blender/blender/pulls/131997
While adding tests I found that metaball export has been broken since
Blender 3.4. It would export each metaball geometry twice.
This looks to have been a side effect of a change to `object_dupli.cc`
which no longer sets the `no_draw` flag for metaballs[1]. With the flag
unset we would end up visiting this particular object twice.
Use a direct check for Metaballs now and add test coverage for the
scenario in general.
[1] eaa87101cd
Pull Request: https://projects.blender.org/blender/blender/pulls/131984
Render tests can still fail. This change will disable them until they
are in a better shape. Reduces confusion when running cycles GPU render
tests.
Known issues:
- Render in batch can take forever due to a locking issue
- Headless rendering is still in development
- Particle hair rendering is broken.
Pull Request: https://projects.blender.org/blender/blender/pulls/131964
Supporting a new on_material_import() USDHook callback.
Also added support for import_texture() and export_texture()
utility functions which can be called from on_material_import() and
on_material_export() Python implementations, respectively.
Pull Request: https://projects.blender.org/blender/blender/pulls/131559
In a previous commit the Principled BSDF tests were renamed from
`principled_...` to `principled_bsdf_...`. The proposal was made to
also rename the folder these tests were in to `principled_bsdf` for the
sake of consistency. This is what this commit does.
Pull Request: https://projects.blender.org/blender/blender/pulls/131771
When importing an USD, the Blender object names do not necessarily match
Prim names:
```
#usda 1.0
def Xform "xform1"
{
def Mesh "MyObject" # Will be imported as "MyObject"
}
def Xform "xform2"
{
def Mesh "MyObject" # Will be imported as "MyObject.001"
}
def Xform "xform2"
{
def Mesh "MyObject" # Will be imported as "MyObject.002"
}
```
This makes it difficult in the [USD Import Hooks]
(https://docs.blender.org/api/current/bpy.types.USDHook.html) to link a
Blender object back to its source Prim for additional processing. A
typical use cases for games is to generate UVs, create and apply a
material on the fly when importing a collision shape that does not have
a visual representation (hence no materials) based on some Prim
attributes, but that the artist needs to differenciate in Blender's
viewport.
The Import context exposes a new method `get_prim_map()` that returns a
`dict` of `prim path` / `list of Blender ID`.
For example, given the following USD scene,
```
/
|--XformThenCube [def Xform]
| `--Cube [def Cube]
|--XformThenXformCube [def Xform]
| `--XformIntermediate [def Xform]
| `--Cube [def Mesh]
|--Cube [def Cube]
`--Material [def Material]
`--Principled_BSDF [def Shader]
```
the `get_prim_map()` method will return a map as:
```python
@static_method
def on_import(import_context):
pprint(import_context.get_prim_map())
```
```json
{
"/Cube": [bpy.data.objects["Cube.002"], bpy.data.meshes["Cube.002"]],
"/XformThenCube": [bpy.data.objects["XformThenCube"]],
"/XformThenCube/Cube": [bpy.data.objects["Cube"], bpy.data.meshes["Cube"]],
"/XformThenXformCube": [bpy.data.objects["XformThenXformCube"]],
"/XformThenXformCube/XformIntermediate": [bpy.data.objects["XformIntermediate"]],
"/XformThenXformCube/XformIntermediate/Cube": [bpy.data.objects["Cube.001"], bpy.data.meshes["Cube.001"]],
"/Material": [bpy.data.materials["Material"]],
}
```
Co-authored-by: Odréanne Breton <odreanne.breton@ubisoft.com>
Co-authored-by: Sttevan Carnali Joga <sttevan.carnali-joga@ubisoft.com>
Co-authored-by: Charles Flèche <charles.fleche@ubisoft.com>
Some changes to how argparse is used in render tests:
1. Use the common approach of one dash for single-letter options (`-b`)
and two dashes for longer options (`--blender`). In this commit that
just means changing single-dashed (`-testdir`) to double-dashed
(`--testdir`).
2. Remove unnecessary `nargs` arguments. The code was telling `argparse`
to put CLI arguments into a list of one item, and then had code to
turn that one-item list into the item itself. I've just removed the
`nargs` argument altogether, as that just produces the desired
value without requiring more code.
I've also removed `nargs="+"` from the handling of the `--blender`
parameter, as that allowed for multiple occurrences of `--blender
{path}` but was silently ignoring all of those except the first.
To ensure that required arguments are present, the code now uses
`required=True` instead of `nargs`.
3. Add a `description` parameter so that `--help` shows what the
test script actually does. Also it helps people (like me) who want
to figure out which blend file is actually being opened by the
test, without making the test itself more verbose.
No functional changes, except that you now cannot add multiple
`--blender` arguments any more (the CLI invocation will fail). This wasn't
used anywhere I could find, though.
Pull Request: https://projects.blender.org/blender/blender/pulls/131666
While looking into something else, I noticed that the OSL render tests
were not testing the Principled Volume tests.
This is because when running OSL tests, we skip all Principled BSDF
tests by ignoring all tests that start with `principled_`
(this was done due to noise differences between SVM and OSL).
However this had the knock on effect of skipping tests like
- `principled_absorption`
- `principled_blackbody`
- `principled_smoke`
in the volumetric test suite.
This commit fixes this issue by renaming all Principled BSDF tests to
`principled_bsdf_` and updating the block list to use this new name.
Ref: blender/blender-test-data!31
Pull Request: https://projects.blender.org/blender/blender/pulls/131540
Make use of our sparse value writer in more places. Namely, when using
animated Camera or Light properties, this will prevent a needless stream
of unchanging values being written into the USD file [1]. Skeletons and
armatures benefit too but less so as typically the primary benefit only
applies to the comparatively small `scale` transform attribute, which
typically remains unchanged from frame to frame.
The newly added `set_attribute` common code can, and eventually will, be
used to reduce boilerplate elsewhere where we do the same sparse writing
dance.
Ref #130759
Pull Request: https://projects.blender.org/blender/blender/pulls/131333
While adding tests for subd import I discovered that our vertex crease
data was imported incorrectly.
This PR adds tests and fixes:
- We tried to read crease sharpness data as ints instead of floats. This
caused the import process to early-return, meaning we never load any
data at all
- Empty USD data would still cause us to create the `crease_vert`
attribute unnecessarily
- Sharpness data needs clamped to 0-1 to handle USD's SHARPNESS_INFINITE
value of 10.0
- We need to fill the `crease_vert` span with 0's since incoming USD
data may not have values set for all the verts
Pull Request: https://projects.blender.org/blender/blender/pulls/131516
Rather than using a default "Anim" name when exporting armature
animations, use the animation's Action name instead. Likewise use the
UsdSkelAnimation name for the Action's name during import.
Blendshapes/shapekeys still use the default "Anim" name as there's no
action for these situations.
Pull Request: https://projects.blender.org/blender/blender/pulls/131021
This adds a `unit_test_compare` function to `Curves`.
Compares the curves. Curves are the same if:
* The number of points matches.
* The number of curves matches.
* The attribute names are the same and have the same type.
* The point attribute values are within the `threshold`.
* The curve topology matches (e.g. the curve sizes are the same).
* The curve attribute values are within the `threshold`.
* The indices of the points and curves are the same (can be ignored if this should be treated as the same).
The implementation reuses the same functions as the existing
comparison function for meshes.
Pull Request: https://projects.blender.org/blender/blender/pulls/131164
We've had a bunch of inconsistency between `channel_bag` and `channelbag` in the
code base. After discussion with @dr.sybren, we decided to standardize on
`channelbag` and also rename the camelcase `ChannelBag` to `Channelbag` to be
consistent with that.
This PR implements those changes.
Note that the reason we standardized on `channelbag` rather than `channel_bag`
is because it makes things clearer when stringing multiple terms together in
type and function names. For example, in `channelbag_fcurves_move()` it makes
it clear that `channelbag` describes one thing, rather than `channel` and `bag`
being two separate things.
No functional changes intended.
Pull Request: https://projects.blender.org/blender/blender/pulls/130988
`Action.slots.new()` in the Python API previously took either an ID or nothing
as a parameter. In the former case it would create a slot with the appropriate
`id_root` and name for that ID. In the latter case it would create a default
slot with an unspecified `id_root` and default name.
This had several issues:
1. You couldn't create a slot with a specific `id_root` without already having
an ID of that type. In theory this isn't a problem, but in practice in larger
scripts/addons you don't necessarily have such an ID on hand at the call
site.
2. You couldn't directly create a slot with a desired name without an existing
ID with that name. This isn't so important, since you can always just set the
name afterwards. But it's a bit annoying.
3. Most other `new()` APIs in Blender *require* you to specify the name of the
item being created. So calling this with no parameters was violating that
norm.
4. Ideally, we want to eliminate unspecified `id_root`s, since they cause other
weirdness in the API such as slot identifiers changing upon slot assignment.
To resolve these issues, and just generally to make the API more
straightforward, this PR changes `slots.new()` to take two required parameters:
an ID type and a name. For example:
`slots.new(id_type='CAMERA', name="My Camera Data Slot")`.
This fully specifies everything needed for the slot identifier upon creation,
and doesn't require any outside data items to create a slot with the desired
type and name.
In the future if we decide we still want a `for_id`-style slot creation API, we
can reintroduce it as a separate function.
Ref: #130892
Pull Request: https://projects.blender.org/blender/blender/pulls/130970
Adding object conversion tests to verify the refactored object type
conversion code works as intended.
The object conversion operator `exec()` function is restructured by
PR #130668 to clean up code path for better readability, since it's a
relatively big change, this test is put up to verify that:
- For supported object type pairs, converted objects would have the
expected target object type.
- For unsupported/unimplemented type pairs, the test expect the
converted object to have the same type as the source object.
- Verify that the code behaviour stays exactly the same as prior
to the change in #130668, including code logic that are later subject
to change and redesign, in which case this test file/script would need
to be updated accrodingly.
This test added such files:
- `tests/data/modelling/object_conversion.blend`: Sets up differnt types
of input objects and their expected converted object combinations.
- `tests/python/object_conversion.py`: Does mesh equal checks for
objects that are converted to mesh against expected objects in the
blend file, and does object type checks for other target types.
Note:
This test currently does not do topology-level equal check except for
when target object type is `MESH`. Equal check hasn't been implemented
for other object types yet, but ideally in the future we should use
topology check on top of type check for other object types as well.
See https://projects.blender.org/blender/blender/pulls/130668
Pull Request: https://projects.blender.org/blender/blender/pulls/130738
`AnimData`, NLA strips, and action constraints all have an `action_slot_name`
field in RNA. The purpose of this field is to store the identifier of the most
recently assigned slot, so that it can be used for auto-assignment when later
assigning different actions.
However, this field name is misleading in two ways:
1. In accordance with #130740, it's actually the slot *identifier*, not name.
2. It could be mistaken as a way to rename the currently assigned slot, which it
is not.
To resolve both of those issues, we're renaming the field to
`last_slot_identifier`, which better communicates its actual nature.
As a bonus, this also ends up decluttering Python autocomplete when looking
for things related to action_slot.
Ref: #130892
Pull Request: https://projects.blender.org/blender/blender/pulls/130911
This PR renames `ActionSlot::name` to `ActionSlot::identifier` for both DNA and
RNA, and also renames related methods, functions, constants, and comments.
The purpose of this rename is to help make it clear that this is not a "name"
in the traditional sense, but rather is a composite of the slot name + id type
for lookup purposes.
Ref: #130892
Pull Request: https://projects.blender.org/blender/blender/pulls/130740
Previously, it wasn't possible to copy a drawing from one frame to another
if that drawing was in another layer or object.
This allows the `frame.drawing` property to be set to any another drawing.
Setting `drawing` to `None` clears the drawing geometry.
Pull Request: https://projects.blender.org/blender/blender/pulls/130523
This patch makes it so collection assignments of bones are
symmetrized when the "Symmetrize" operator is run.
* Only collections with names that can be symmetrized are modified.
* Collections are created if they don't exist,
they are created under the same parent as the source collection
* In the case of a "left" bone assigned to a "right" collection the
resulting "right" bone will be assigned to a "left" collection.
The system does explicitly not try to be smart here.
Also adds unit tests.
Pull Request: https://projects.blender.org/blender/blender/pulls/130524
When EEVEE next removed the Alpha Threshold option a node graph setup
was used instead. Based on a USD test asset[1] the original code was
designed around only using the Image A channel during import to wire
up the nodes. However, the other channels (R, G, or B) are just as
valid.
We now handle this by wiring up the Separate RGB node, that is already
inserted for the scenario in general, to the shader nodes handling the
threshold calculation. Also adds additional test coverage for both
export and import as well.
The Round and LessThan+OneMinus networks remain the only shapes that
will be recognized for the processing.
[1] https://github.com/usd-wg/assets/tree/main/test_assets/AlphaBlendModeTest
Pull Request: https://projects.blender.org/blender/blender/pulls/130346
The existing point instancer reader is slightly refactored to allow for
animated setups. The primary change is simply to inherit from
`USDGeomReader` rather than `USDXformReader`. This allows access to the
`read_geometry` API used by the cache modifier.
The existing `read_object_data` method is split into two parts with
`read_geometry` loading per-frame USD data and `read_object_data`
coordinating the initial loading process, including creating the GN node
tree just once.
A new test has been added (a variation of the nested point instancer
file) with time samples on various attributes and on both point
instancers. This also fixes#129502 and the file provided in that issue.
----
The already added test file is `tests/data/usd/usd_point_instancer_anim.usda`
Pull Request: https://projects.blender.org/blender/blender/pulls/129881
Adds the option `merge_parent_xform` to the USD export operator and
panels so the transform and shapes are merged into a single USD Prim.
Without the option (existing default), a top-level mesh would be
exported as a top-level `Xform` that has a `Mesh` child:
```
def Xform "MyBlenderMeshObject"
{
matrix4d xformOp:transform = ...
def Mesh "MyBlenderMeshData"
{
}
}
```
This matches the Blender data model, where a transformable object
contains a geometric shape (like a mesh). This structure is also very
valid in USD, where we don't want to directly instantiate geometric
primitives[1]
However, "since number of prims on a stage is one of the primary factors
that governs how USD scale"[2], to reduce the number of prims in a
stage, geometric primitives *are transformable* themselves (see the
inheritence diagram[3]).
As such, the new export option allows to export geometric primitives
without the parent transform:
```
def Mesh "MyBlenderMeshObject"
{
matrix4d xformOp:transform = ...
}
```
This MR adds a the `is_object_data_context` flag to the
`HierarchyContext` context structure. The point of this change is to
make unambiguous in `USDHierarchyIterator::create_usd_export_context`
the fact that an `object` or a `data` is currently being exported: the
new `merge_parent_xform` option is meaningless for `object`. Only `data`
can be exported with a parent `Xform` or as a child of said `Xform`.
Ideally this flag would not be needed at all: the final USD prim path
*could* be computed in an override of the virtual
`AbstractHierarchyIterator::get_object_data_path` method. However, this
would mean that an `object` and a `data` would have the same export path.
This does not currently play well with
`AbstractHierarchyIterator::ensure_writer`, where `writers` are cached
*by their export path*: it would cache a transform writer, but will skip
the subsequent data writer.
Additionally, another new `is_parent` flag is added to handle the case
where merging the Xform is invalid: objects that are parents to other
objects should remain unmerged as otherwise that would yield invalid USD
files.
[1] https://openusd.org/release/glossary.html#usdglossary-gprim
[2] https://openusd.org/release/glossary.html#usdglossary-instancing
[3] https://openusd.org/release/api/class_usd_geom_xformable.html
Co-authored-by: Odréanne Breton <odreanne.breton@ubisoft.com>
Co-authored-by: Sttevan Carnali Joga <sttevan.carnali-joga@ubisoft.com>
Co-authored-by: Charles Flèche <charles.fleche@ubisoft.com>
Tell ffmpeg swscale to do accurate YUV->RGB conversion, instead of
slightly faster but not really accurate one. Fixes banding and some
color shifts in video files, particularly in dark regions.
The accurate conversion is a bit slower though, on 4K resolution video,
time taken to convert video frame from YUV to RGB:
- x64 (Ryzen 5950X): 2.3ms -> 3.7ms
- arm64 (M1 Max): 0.6ms -> 2.9ms
My take is that paying 1-2ms per 4K video playback is acceptable
since the result is obviously "more correct" and matches what VLC/ffplay
produces.
From what I can tell, "accurate conversion" turns off some dedicated
assembly code paths within ffmpeg. Maybe someday ffmpeg would get
accurate and assembly-optimized routines for that.
With more accurate decoding, we can now lower the expected render
test threshold again, since x64 & arm64 decoding is much closer now.
Comparison screenshots in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/130383
While adding test coverage for in-memory and packed texture scenarios, I
found that UDIMs were not being handled correctly in both cases. For
in-memory scenarios the per-tile generated/dirty status was not taken
into account. For packed scenarios the wrong filename substitutions were
being used.
This fixes both of these cases and adds test coverage for these
scenarios now. Both relative and absolute path options are validated.
Note: Both in-memory and packed images behave incorrectly when using the
'KEEP' and 'PRESERVE' texture export modes, so those remain untested
currently. A design on exactly what should happen in these modes is TBD.
Pull Request: https://projects.blender.org/blender/blender/pulls/130391
This new import option will allow users to chose if we merge USD prims
with their Xform parent.
Given a USD like:
```
def Xform "MyObject"
{
def Mesh "MyObject_LOD0"
{
}
}
```
When the option is set to True (existing default), only the mesh will be
imported and its parent Xform transformation will be baked into the
Mesh.
```
# In blender after import
- MyObject_LOD0 (Mesh)
```
When the option is set to False, the parent Xform will always be
imported as an Empty object:
```
# In blender after import
- MyObject (Empty)
├─ MyObject_LOD0 (Mesh)
```
Co-authored-by: Odréanne Breton <odreanne.breton@ubisoft.com>
Co-authored-by: Sttevan Carnali Joga <sttevan.carnali-joga@ubisoft.com>
