The spec for .usdz permits only a small handful of file formats to be
contained in the archive, and HDR is not among those supported[1]. This
also causes validation errors with the `usdchecker` tool (will be
properly tested in a follow up change).
Ignoring the potential for a user to export a .usdz file with materials
referencing unsupported file formats, Blender itself should use only
the supported formats for its business.
[1] https://openusd.org/release/spec_usdz.html#usdz-specification
Pull Request: https://projects.blender.org/blender/blender/pulls/144101
Replaces the `FPS` macro with `scene->frames_per_second()`.
The macro has two major issues:
* It hides that it depends on a `Scene *` variable named `scene`.
* It makes debugging harder.
This is now replaced with a member function on the scene.
Pull Request: https://projects.blender.org/blender/blender/pulls/144127
For cases where we've already checked that the property is holding a
particular type, use UncheckedGet to ensure the type isn't checked a
second time. This matches all the other call sites doing similar.
Pull Request: https://projects.blender.org/blender/blender/pulls/144084
This refactors the code for world to dome light to be shared between USD and
Hydra, and makes rotations work for Hydra the same way they do in USD.
One small behavior change is that missing image files now render black,
matching Cycles and EEVEE more closely.
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/143035
Use the form "Processing something..." (gerund, sentence case,
ellipsis) for running jobs progress label, according to Blender's
Human Interface Guidelines.
Pull Request: https://projects.blender.org/blender/blender/pulls/141573
Part of https://projects.blender.org/blender/blender/pulls/141278
Blend files compatibility:
If a World exists and "Use Nodes" is disabled, we add new nodes to the
existing node tree (or create one if it doesn't) that emulates the
behavior of a world without a node tree. This ensures backward and
forward compatibility.
Python API compatibility:
- `world.use_nodes` was removed from Python API => **Breaking change**
- `world.color` is still being used by Workbench, so it stays there,
although it has no effect anymore when using Cycles or EEVEE.
Python API changes:
Creating a World using `bpy.data.worlds.new()` now creates a World with
an empty (embedded) node tree. This was necessary to enable Python
scripts to add nodes without having to create a node tree (which is
currently not possible, because World node trees are embedded).
Pull Request: https://projects.blender.org/blender/blender/pulls/142342
All supported versions of Blender are capable of handling the Unicode
prim and property names now.
It's difficult to determine how much of the USD ecosystem is using
version 24.03 or greater so there is some risk of our files (when they
make use of Unicode names) not loading correctly for other DCC
applications.
Pull Request: https://projects.blender.org/blender/blender/pulls/142747
Use `BLI_strncpy_utf8` & `BLI_snprintf_utf8` for fixed size buffers in
DNA and screen data structures such as panels, menus & operators.
This could be considered a fix as copying a UTF8 string into a smaller
buffer without proper truncation can create an invalid UTF8 sequence.
However identifying which of these users are likely to run into would
be time consuming and not especially useful.
Ever since [0], ReportList is not actually used in any DNA structs.
That makes sense, since reports are conceptually only necessary
at runtime. Move the definition of the struct to BKE_report.hh, and
fix a bunch of include errors where types were previously available
transitively. Besides adding some clarity, theoretically this change
could reduce compile times because of less header parsing.
[0]: 1bf6d8b0b9
Pull Request: https://projects.blender.org/blender/blender/pulls/138872
The call to `BKE_keyblock_convert_from_mesh` can leave the KeyBlock's
data field null if the passed in mesh has no verts.
Continue to allow the shape keys to be created, but do not attempt to
actually fill them in with data. This seems to match the old FBX
importer's behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/142995
**How to reproduce the bug:**
Load the attached Blend File OR
1. Create a new World in python: bpy.data.worlds.new("Test")
2. Switch to this new world in the UI (but do nothing else to it)
3. Import in a USD file with a DomeLight (see attached file in PR)
4. Close Blender
5. Observe assert `BLI_assert(ELEM(owner_id, nullptr, id));`
The issue was caused by a assigning a regular node tree
`World->nodetree` whereas an embedded one is expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/142367
This rename creates separation between USD primvars/Blender geometry
attributes - which are not controlled with this setting - and the
concept of USD attributes+userProperties/Blender custom object
properties - that this option deals with.
Ref #134012
Pull Request: https://projects.blender.org/blender/blender/pulls/142301
The repro file in question contained invalid paths for the USD Skeleton.
This was not detected in our import code which proceeded to create bones
with empty (`""`), incorrect, names and subsequently allowed the
rest-pose setup to use non-existent bones during processing.
The primary fix here is to ensure that all incoming joint paths are both
valid and unique[1]. A secondary fix is made to the rest-pose function
to use our joint-to-bone map to ensure we are using the correct bone
names.
[1] https://openusd.org/release/api/class_usd_skel_skeleton.html#aa6bf8297f4aae6de9fbf1b784c524d30
Pull Request: https://projects.blender.org/blender/blender/pulls/142133
Due to ambiguity when decomposing the incoming skeleton joint matrix,
it's possible for the returned quaternion rotation to be "flipped" from
the perspective of prior/future frames due to the quaternion
double-cover property. This would manifest as glitchy animations and
subtly incorrect motion blur results during render.
This PR implements the traditional mitigation of comparing with the
prior frame's rotation data and negating the quat if necessary. An
alternate method to instead compare with the rest positions was
attempted but it still allowed flipped/discontinuous rotations for
spinning objects like wheels and propellers.
Pull Request: https://projects.blender.org/blender/blender/pulls/142026
Use `std::string` rather than raw char arrays for `root_prim_path` and
`prim_path_mask`. This is a more natural fit for these arbitrary length
strings and it simplifies downstream consumers of the values.
Pull Request: https://projects.blender.org/blender/blender/pulls/141801
Standardize on using `pxr::UsdTimeCode time` rather than the assortment
of other uses we had including:
- double motionSampleTime
- double motion_sample_time
- float time (!)
- pxr::UsdTimeCode timecode
This matches what the USD API itself uses.
The only exception is for the APIs and types defined in usd.hh that need
to be useable inside Blender itself. Those will remain unchanged and
continue to use "double motion_sample_time".
Pull Request: https://projects.blender.org/blender/blender/pulls/141756
The numeric levels have no obvious meaning. This removes the distinction
between severity and levels, instead there is a single list of named levels
with defined meaning.
Debug means information that's mainly useful for developers, and trace is for
very verbose code execution tracing.
Pull Request: https://projects.blender.org/blender/blender/pulls/140244
The mesh importer was only checking for animated positions, velocities,
and primvars when determining if a cache modifier needed to be used.
Extend this to crease values (and normals) too.
The added test ensures a base level of coverage here.
Related to: #141633
Pull Request: https://projects.blender.org/blender/blender/pulls/141643
Change `eCustomDataType` to `bke::AttrType` for uses of the attribute
API (the `AttributeAccessor` one anyway). I didn't touch any values that
might be saved in files; those should be handled on a case by case basis.
Part of #122398
Pull Request: https://projects.blender.org/blender/blender/pulls/141301
Notably, there were several code paths which could end up converting to
strings, sometimes multiple times, when passing data into USD APIs.
Reduce the use of raw `char *` in the asset interface and use
`std::string` instead to match what will be passed into USD. Using
string views, of any variety, will not help here since the APIs don't
natively support those.
Pull Request: https://projects.blender.org/blender/blender/pulls/140997
Incoming string attributes from USD have never been fully processed yet
they were added to our list of convertible types. This list originally
came from the Mesh reader before it was made common, but for Meshes the
string type was being skipped elsewhere so there was no harm. Now that
Point Clouds and Curves use this common code, it does matter.
Files containing string attributes for these object types will hit the
`BLI_assert_unreachable` call inside `copy_primvar_to_blender_attribute`
and trace an error to the console requesting the user to file bugs. This
was discovered while looking into the old Moana scene.
Remove the string entry for now as there's no regression in behavior and
it prevents the assert from firing (functionally harmless in Release
builds but the output to the terminal is unnecessary).
Pull Request: https://projects.blender.org/blender/blender/pulls/140681
Some USD files have the displacement input specified in the shader but
do not have it marked as an output in either the shader or the material.
Skip processing if we do not have a valid displacement source.
Pull Request: https://projects.blender.org/blender/blender/pulls/140619
