The goal is to make it easy to import gsplats in geometry nodes,
without extra manual setup. Ideally, it should be possible to
drop PLY file into the node editor and it would import as either
mesh or gsplat depending on the actual file content.
The easiest way of doing so is to make the existing PLY node a
bit more flexible: name the output socket "Geometry" and detect
the PLY type automatically. This mimics the behavior when the
PLY file is imported via the File menu (or by dropping the file
into the viewport).
The alternative of either using separate node or an explicit
import type on the node was considered, but both approaches have
a downside due to the way how the import currently works: there is
currently no way to analyze the file before creating node, so it
will be quite tricky to implement logic which creates proper node
or sets the import type. There are also ease-of-use concerns.
The Mesh output was renamed to Geometry, but kept its old Mesh as
an identifier so that old files keep working without extra
versioning, and scripts do not break.
An utility was added to the PLY module to return result as a
GeometrySet component, making it easier to integrate into the
node.
Pull Request: https://projects.blender.org/blender/blender/pulls/163624
These output directories are intended to be idempotent & not shared
across test runs. While typically users will call the script via `ctest`
commands, it is still better to enforce the callee to pass in the
desired temporary directory so that cleanup steps avoid deleting
unintended data.
For a number of `bl_animation` tests, no arguments are passed to the
underlying test script, so the entire scaffolding for `argparse` has
been removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/157970
Abusing once again the 'blendfile_versioning' tests.
These are now doing three different tests on (almost) all test blendfiles:
* Basic open/save/reload
* Basic link/append.
* Basic memfile undo/redo.
At some point we probably want to refactor this into something better
organized? maybe with a test API that can apply some generic
operation(s) on all test blendfiles?
Pull Request: https://projects.blender.org/blender/blender/pulls/155637
This new file can parse the file header (first few bytes) as well as the block
headers.
Right now, this is used by two places:
* `blendfile.py` which is used by `blend2json.py`
* `blend_render_info.py`
This new module is shipped with Blender because it's needed for
`blend_render_info.py` which is shipped with Blender too. This makes using it in
`blendfile.py` (which is not shipped with Blender) a bit more annoying. However,
this is already not ideal, because e.g. `blend2json` also has to add to
`sys.path` already to be able to import `blendfile.py`.
This new file could also be used by blender-asset-tracer (BAT).
The new `BlendFileHeader` and `BlockHeader` types may be subclassed by code
using it, because it wants to store additional derived data (`blendfile.py` and
BAT need this).
New tests have been added that check that the file and block header is parsed
correctly for different kinds of .blend files.
Pull Request: https://projects.blender.org/blender/blender/pulls/140341
Caused by changes in da4eda148b. Did not realized we have a few
duplicate blend-file names in `tests/files`, these ended up stepping on
each other's toes at random during testing.
Now ensure that the generated temporary 'save & reload' blend-file names
are unique, by adding a hash of the whole file path.
This commit implements #125759.
It removes:
* Blender does not build on big endian systems anymore.
* Support for opening blendfiles written from a big endian system is
removed.
It keeps:
* Support to generate thumbnails from big endian blendfiles.
* BE support in `extern` or `intern` libraries, including Cycles.
* Support to open big endian versions of third party file formats:
- PLY files.
- Some image files (cineon, ...).
Pull Request: https://projects.blender.org/blender/blender/pulls/140138
This change moves the tests data files and publish folder of assets
repository to the main blender.git repository as LFS files.
The goal of this change is to eliminate toil of modifying tests,
cherry-picking changes to LFS branches, adding tests as part of a
PR which brings new features or fixes.
More detailed explanation and conversation can be found in the
design task.
Ref #137215
Pull Request: https://projects.blender.org/blender/blender/pulls/137219
In case the process creashes, the prints about blendfiles being
processed could fail to be captured by the test framework.
And split these tests in 32 slices now, 8 was becomming way too slow to
complete for each test.
This makes the logs fairly verbose, but it is not displayed by default
anyway, and it is the only easy way to find out exactly which file or ID
is breaking the test.
In preparation for adding big-endian tests, disable them on macOS
where many are failing, although it looks like the cause of failure
may not relate to endian conversion, it needs further investigation.
These are really basic testing as well, merely linking or appending the
first collection or object in all processed blendfiles. But it should
help catching 'rare' issues in linking/appending from older blendfiles.
The `io_blendfile_versioning` test is currently one of the slowest
(excluding Cycles ones) in debug builds, it can easily take several
minutes to complete.
This commit split it into several instances, each processing a subset of
all the blendfiles.
This gives a strong speed-up when only running that specific test.
As expected, speedup is neglectable when running the whole test suite
though.
| instances | debug | release | debug all* | release all |
| --------- | ------ | ------- | ---------- | ----------- |
| 1 | 190.95 | 19.39 | 439.54 | 63.51 |
| 4 | 61.80 | 6.81 | N/A | N/A |
| 8 | 38.33 | 5.14 | 435.00 | 58.93 |
| 16 | 33.97 | 4.16 | N/A | N/A |
| 32 | 46.54 | 5.14 | N/A | N/A |
Times are in seconds.
`instances` are the number of tests generated (1 is same as before this
commit).
The first two columns are timings for running the versioning test only,
the last two are timings for the full test suite (excluding Cycles tests
in the debug build case).
This is fairly brute force and rough, but there are quite a few old
files in there, helps a bit with versioning and readfile code testing.
Note: Five files are currently excluded since failing in debug builds
at least, most of the time for memleaks issues. The two other 'errors'
may also not be actual issues, but this needs to be investigated further.
Also, in the future, when time allows, it may be better to generate a
set of dedicated testing files, with as many official releases versions
as possible?
Re. #112649.
