We build openusd without OSL support as we don’t build Blender with OSL
support normally, and so seems unnecessary and adds significantly to the
closure size due to (as noted in Blender drv comments) the inclusion of
LLVM.
This makes them match what the fn param names *would* be, making it
easier to refactor e.g. to `{ python3Packages, ... }: mkDerivation …` in
the future if desired. It also potentially reduces first-glance
confusion that it might be Python 2 in-use.
Leave the passthru names as-is to preserve backwards-compatibility, but
also as there appears to be some precedent for naming them like this.
- Format to draft RFC 0166 style (via nixfmt-rfc-style)
- Alphabetize lists unless there is a somewhat-apparent reason not to
- Reorder attrs based roughly on the order they are used by the builder
As noted in comment, Blender is now using private libdecor APIs not in
the headers, so need to patch to build against it. I think it probably
works when Blender does dynamic loading at runtime since it uses the fn
defs it defines in that case, but we don’t want to do that, it seems (as
we already set `-DWITH_GHOST_WAYLAND_DYNLOAD=OFF`).
Based on #257780, separated since it introduces significant changes.
bpycv: update passthru.tests.render
blender-with-packages: deprecated
it is still backwards compatible, but no longer preferred.
blender: fixup for ROCm 5.7.0
opensycl: fixup for ROCm 5.7.0
magma: fixup for ROCm 5.7.0
torch: fixup for ROCm 5.7.0
cp2k: fixup for ROCm 5.7.0
sirius: fixup for ROCm 5.7.0
spfft: fixup for ROCm 5.7.0
spla: fixup for ROCm 5.7.0
Basic headless render test for Eevee and Cycles CPU. Did this because I
got a bit tired of testing render manually for both renderers (though
it’s not that much work).
Note that `render.threads` config is used only by Cycles. Using 1 thread
chosen because it’s not meaningfully slower than more for this render,
and it simplifies things to just pick 1 instead of making it dynamic.
Have chosen 32 samples since it’s not meaningfully slower than 1 (even
with `--cores 1`), and it’s not so small that maybe it’s not
representative, and too-low a number and there are artifacts that may
make it appear like something is broken.
Cycles denoising needs openimagedenoise and is not currently included in
aarch64 build.
See https://github.com/NixOS/nixpkgs/issues/217921
Blender sets WITH_DRACO=OFF if WITH_PYTHON_INSTALL=OFF, however that’s
not totally necessary. Removing that forced-set then builds with
WITH_DRACO=ON, however Blender fails to launch because this creates
e.g. `share/blender/3.6/python`, and Blender then sets this as Python’s
home dir, so Python fails to init since it expects Python core to be
there (and it’s not). I couldn’t figure out how Blender sets Python’s
home dir, and explicitly setting PYTHONHOME in the env didn’t have any
effect. So instead just rename that dir to python-ext to avoid this
behavior. All that is left then is to adjust where Blender is looking
for the Draco lib.
This functionality may be verified by:
1. Visiting File → Export → glTF 2.0
2. In the right side panel (press the gear icon in top-right if not
visible), expanding “Data”
3. Enabling “Compression”
4. Press “Export glTF 2.0”
5. Verify:
- Blender stdout+stderr shows “Draco mesh compression is available”
- no error or warning message
- exported file exists
Eliminate uses of `config.cudaSupport or false` and alike, since the
option is now declared in config.nix with a default value
fd .nix -t f -x sed 's/config\.cudaSupport or false, cudaPackages [?] [{][}]/config.cudaSupport, cudaPackages ? { }/' '{}' -i
fd .nix -t f -x sed 's/config\.cudaSupport or false/config.cudaSupport/' '{}' -i
fd .nix -t f -x sed 's/cudaSupport = pkgs.config.cudaSupport/inherit (pkgs.config) cudaSupport/' '{}' -i
fd .nix -t f -x sed 's/cudaSupport = config.cudaSupport/inherit (config) cudaSupport/' '{}' -i
Without removing the `rm … FindEmbree`, compilation fails due to various
macros depending on the version of embree. The nixpkgs history provides
no indication of why this patch is done (it has been present since the
addition of embree as a dep in
6b74f99abd), and the build succeeds
without them, so remove.
Blender addons that have native extensions need to be built against the
same Python that Blender was built with. This makes it easier to write
such addon derivations.
Has been broken likely since edcd3849a6.
First failing Hydra: https://hydra.nixos.org/build/211894618
Notes from attempt to fix:
- The initial breakage may be easy to fix, but the upgrade to 3.4 added
a lot more hurdles
- The patch fails to apply, but is trivially naïvely fixable
- At least some of the existing darwin-specific substituteInPlace no
longer find anything
- When building with naïve fix for patch, fails with:
> Could NOT find USD (missing: USD_LIBRARY USD_INCLUDE_DIR)
for reasons that are not clear to me
The package has been broken for two months and no open issues, so
marking as broken as it’s not going to fix itself and if there is will
to fix it, someone can. For now, leaving the darwin conditionals in
place so not as to make a would-be-fixer’s job harder.
with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure
keep a couple of packages "using" openimageio_1 - both are broken
anyway, but as such we have no evidence that they work with 2.x.
all are liable to get removed in the near future anyway.
Enables the WebP image format support in Blender. It has been [supported](https://developer.blender.org/rB4fd0a69d7ba) since Blender 3.2 but was disabled due to libwebp missing from the build inputs.
$ nix build nixpkgs#blender
$ nix log (realpath result)
...
-- Could NOT find WebP (missing: _webp_LIBRARIES WEBP_INCLUDE_DIR)
CMake Warning at build_files/cmake/platform/platform_unix.cmake:407 (message):
WebP not found, disabling WITH_IMAGE_WEBP
Call Stack (most recent call first):
CMakeLists.txt:1058 (include)
