Changelog: https://developer.blender.org/docs/release_notes/4.2/
- Since we are using `srcs` instead of `src`, now need to use `fetchzip`
instead of `fetchurl`
- Bundled assets are no longer included in source tarball, but they are
in the built-release tarball, so fetch them and move them into place.
- fetchpatch-ed commit is now included
- clew is removed upstream, so no need to patch it
- EEVEE is replaced by EEVEE Next
- Addons have been relocated
Upstream builds and tests with a specific Python version. Further, the
Blender addon ecosystem generally expects that version to be used, so
ensure that the correct version is used when upstream changes. Python
often makes backwards-incompatible changes in “minor” releases.
To quote upstream source code:
> Blender only supports a single Python version at the moment.
Perform the check during preConfigure since we can check it then and so
it avoids wasting time configuring+building and then failing.
An unwrapped check for `nix run`-ing on the host platform,
instead of `nix build`-ing in the sandbox
E.g.:
```
❯ nix run -f ./. --arg config '{ cudaSupport = true; cudaCapabilities = [ "8.6" ]; cudaEnableForwardCompat = false; allowUnfree = true; }' -L blender.gpuChecks.cudaAvailable.unwrapped
Blender 4.0.1
Read prefs: "/home/user/.config/blender/4.0/config/userpref.blend"
CUDA is available
Blender quit
❯ nix build -f ./. --arg config '{ cudaSupport = true; cudaCapabilities = [ "8.6" ]; cudaEnableForwardCompat = false; allowUnfree = true; }' -L blender.gpuChecks
blender> Blender 4.0.1
blender> could not get a list of mounted file-systems
blender> CUDA is available
blender> Blender quit
```
currently builds on aarch64-darwin, but not on x86_64-darwin.
Blender (specifically the ghost window library) depends on "metal" on
apple devices.
(For details see source/intern/ghost/intern/GHOST_System.cc line 416ff)
It cannot build without it. Metal support should be
introduced by apple sdk 11_1 (?) onward. Once this has been updated in
nixpkgs, this derivation can be revised.
Signed-off-by: Florian Brandes <florian.brandes@posteo.de>
Co-authored-by: Alexis Hildebrandt <afh@surryhill.net>
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.
