Need to make sure node factories are initialized prior to the dependency
graph allocation.
The regression was initially introduced in 5b021dff41
Thanks Brecht for testing!
Split the depsgraph allocation into a separate function
`BKE_scene_ensure_depsgraph()`. Parameters are only passed to those
functions that actually need them. This removes the the "if that boolean
is `false` this pointer is allowed to be `NULL`" logic and more cleanly
decouples code.
No functional changes.
The fix for T75936 made it possible to export invisible objects to
Alembic. This commit applies the same approach to the USD exporter.
The USD and Alembic code is slightly different in terms of where in the
exported file the visibility attribute is stored. In USD the visibility
is used to prune the scene graph, and thus there are only two options:
"hidden" and "inherited". Setting the visiblity of a node in the scene
graph to "hidden" immediately hides all its children. To allow hidden
parents with visible children, the visibility is stored on the object
data (so the geometry/camera/lamp/etc) instead.
Add a test that checks invisible objects are iterated over by the
`IO::AbstractHierarchyIterator` class, when a suitable depsgraph is given.
No functional changes.
Add a new depsgraph builder class that includes invisible objects and
use that in the Alembic exporter.
Alembic supports three options for visibility, "visible", "inherited",
and "hidden". This means that parents can be hidden and still have
visible children (contrary to USD, where invisibility is used to prune
an entire scene graph subtree). Because of this, the visibility is
stored on the transform node, as that represents the Object in Blender
and thus keeps the Alembic file as close to Blender's own structure as
possible.
Reviewed By: Sergey
Differential Revision: https://developer.blender.org/D8595
And make them part of the blender_test runner. The one exception is blenlib
performance tests, which we don't want to run by default. They remain in their
own executable.
Differential Revision: https://developer.blender.org/D8498
This replaces header include guards with `#pragma once`.
A couple of include guards are not removed yet (e.g. `__RNA_TYPES_H__`),
because they are used in other places.
This patch has been generated by P1561 followed by `make format`.
Differential Revision: https://developer.blender.org/D8466
The data member `new` was conflicting with the `new` keyword
when `BKE_screen.h` was included in C++ files.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D8459
This patch adds the ability to render motion blur from Alembic caches.
The motion blur data is derived from a velocity attribute whose name has
to be defined by the user through the MeshSequenceCache modifier, with a
default value of ".velocities", which is the standard name in Alembic
for the velocity property, although other software may ignore it and
write velocity with their own naming convention (e.g. "v" in Houdini).
Furthermore, a property was added to define how the velocity vectors
are interpreted with regard to time : frame or second. "Frame"
means that the velocity is already scaled by the time step and we do not
need to modify it for it to look proper. "Second" means that the unit
the velocity was measured in is in seconds and so has to be scaled by
some time step computed here as being the time between two frames (1 /
FPS, which would be typical for a simulation). This appears to be
common, and is the default behavior.
Another property was added to control the scale of the velocity to
further modify the look of the motion blur.
Reviewed By: brecht, sybren
Differential Revision: https://developer.blender.org/D2388
The abbreviation 'init' is brief, unambiguous and already used
in thousands of places, also initialize is often accidentally
written with British spelling.
The root cause was that `BKE_object_moves_in_time()` incorrectly returns
`false` when an object is moved by the physics system.
This also fixes the same issue in the USD exporter.
Setting the environment variable `PXR_PATH_DEBUG` non-empty will make the
USD library print the directories it uses to find its JSON files. This can
aid in debugging when this unit test fails. Now the failure message also
tells you about this.
No functional changes.
The function is called for all writers, not just 'object' writers.
Furthermore, it's called by the function `release_writers()`, so now the
name is consistent with that as well.
No functional changes.
The unit tests for `bf_io_common` didn't actually link against
`bf_io_common`, so when both USD and Alembic were disabled, nothing
would link against that library and building the tests would fail.
This commit is a followup of {D7649}, and ports the USD tests to the new
testing approach. It moves test code from `tests/gtests/usd` into
`source/blender/io/common` and `source/blender/io/usd`, and adjusts the
use of namespaces to be consistent with the other tests.
I decided to put one test into `io/usd/tests`, instead of
`io/usd/intern`. The reason is that this test does not correspond with a
single file in that directory; instead, it tests Blender's integration
with the USD library itself.
There are two new CLI arguments for the Big Test Runner:
- `--test-assets-dir`, which points to the `lib/tests` directory in the
SVN repository. This allows unit tests to find test assets.
- `--test-release-dir`, which points to `bin/{BLENDER_VERSION}` in the
build directory. At the moment this is only used by the USD test.
The CLI arguments are automatically passed to the Big Test Runner when
using `ctest`. When manually running the tests, the arguments are only
required when there is a test run that needs them.
For more info about splitting some code into 'common', see
rB084c5d6c7e2cf8.
No functional changes to the tests themselves, only to the way they are
built & run.
Differential Revision: https://developer.blender.org/D8314
Reviewed by: brecht, mont29
Each duplicated (a.k.a. instanced) object has a Persistent ID, which
identifies a dupli within the context of its duplicator. This ID
consists of several numbers when there are nested duplis (for example a
mesh instancing empties on its vertices, where each empty instances a
collection). When exporting to Alembic/USD, these are used to uniquely
name the duplicated objects in the export.
This commit reverses the order of the persistent ID numbers, so that the
first number identifies the first level of recursion. This produces
trees like this:
ABC
`--Triangle
|--Triangle
|--Empty-1
| `--Pole-1-0
| |--Pole
| `--Block-1-1
| `--Block
|--Empty
| `--Pole-0
| |--Pole
| `--Block-1
| `--Block
|--Empty-2
| `--Pole-2-0
| |--Pole
| `--Block-2-1
| `--Block
`--Empty-0
`--Pole-0-0
|--Pole
`--Block-0-1
`--Block
It is now clearer that `Pole-2-0` and `Block-2-1` are instanced by
`Empty-2`. Before this commit, they would have been named `Pole-0-2` and
`Block-1-2`.
Exporting a scene to USD or Alembic would fail when there are multiple
duplicates of parent & child objects, duplicated by the same object. For
example, this happens when such a hierarchy of objects is contained in a
collection, and that collection is instanced multiple times by mesh
vertices. The problem here is that the 'parent' pointer of each
duplicated object points to the real parent; Blender would not figure
out properly which duplicated parent should be used.
This is now resolved by keeping track of the persistent ID of each
duplicated instance, which makes it possible to reconstruct the
parent-child relations of duplicated objects. This does use up some
memory for each dupli, so it could be heavy to export a Spring scene
(with all the pebbles and leaves), but it's only a small addition on top
of the USD/Alembic writer objects that have to be created anyway. At
least with this patch, they're created correctly.
Code-wise, the following changes are made:
- The export graph (that maps export parent to its export children) used
to have as its key (Object, Duplicator). This is insufficient to
correctly distinguish between multiple duplis of the same object by
the same duplicator, so this is now extended to (Object, Duplicator,
Persistent ID). To make this possible, new classes `ObjectIdentifier`
and `PersistentID` are introduced.
- Finding the parent of a duplicated object is done via its persistent
ID. In Python notation, the code first tries to find the parent
instance where `child_persistent_id[1:] == parent_persistent_id[1:]`.
If that fails, the dupli with persistent ID `child_persistent_id[1:]`
is used as parent.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D8233
This is just a change in `AbstractHierarchyIterator::debug_print_export_graph()`
to aid in debugging. It'll make it possible to distinguish between
different duplicates of the same object.
No functional changes to Blender itself.
