The new, massive, 2.80 RC is out, it'd be nice to have it packaged for testing.
"Blender 2.80 is almost ready! The stable release will be available in the coming days.
A Release Candidate is the final step before the release."
Thank you for the bump request, but please wait at least 48h (past release!) next time.
I wasn't aware of the 48h rule, won't happen again :)
Blender 2.80 has been released on 30 Jul, ~5 days ago.
Requesting version bump please.
Seconding version bump request.
Please see the initial ebuild for blender 2.80 at https://github.com/dracwyrm/gentoo-ebuilds for testing.
It requires python 3.7 to be unmasked on the system (see https://wiki.gentoo.org/wiki/Project:Python/PYTHON_TARGETS).
If used, media-gfx/openvdb also needs to support python 3.7, see the modified version at the same github site.
The gameengine and player USE flags have been removed as blender2.80 no longer supports them.
Alembic support has been added (with the new alembic USE flag, as per bug 667352)
I was working on my own version of an ebuild and noticed that dev-python/numpy also needed to be rebuilt for python3_7 as well.
Thanks for your work Adrian. I too war working on an ebuild for blender-2.80 and have some feedback on yours in addition to comment #6:
* Blender can use openjpeg:2, while the ebuild depends on openjpeg:0. If both slots are installed, it linked against /usr/lib64/openjp2.so (openjpeg:2) on my test.
* What I have seen so far, python support for openvdb isn't needed. The binary links against libopenvdb.so.5.2 but I haven't found a trace, that it's using the python bindings of openvdb. Are you sure about the need for python 3.7 with openvdb?
* According to the output of build_files/build_environment/install_deps.sh --show-deps, blender needs updated opensubdiv (3.4.0) and opencollada (1.6.68) libraries, which are currently not in the tree. I have ebuilds for both in my overlay, if you're interested in integrating those. I tested my build with those updated versions installed, but not with the current in-tree version, so I don't know whether those build and/or run.
* The USE flag colorio should be renamed to color-management, to reflect a recent global change in this USE flag.
* Do you have plans in adding support for currently unsupported features, like draco, embree or a cycles standalone build? For draco and embree, I have ebuilds in my overlay, but both features come with some issues. Draco needs -DWITH_PYTHON_INSTALL=ON defined and embree currently needs a specific setting and be compiled as a static library which my ebuild in its current state isn't able to do. I'm looking into updating the ebuild, and add USE flags to be able to get the desired configuration, but it eventually can interfere with other packages depending on embree in the future. I you want to work on integrating those feature, feel free to ping me anytime if you wish.
* Blender can currently not be installed on a stable tree, due to dev-python/requests having python_targets_python3_7 still masked:
emerge: there are no ebuilds to satisfy "dev-python/requests[python_targets_python3_7(-)?,-python_single_target_jython2_7(-),-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-),python_single_target_python3_7(+)]".
(dependency required by "media-gfx/blender-2.80::dracwyrm" [ebuild])
(dependency required by "=blender-2.80::dracwyrm" [argument])
I have tried to build blender in a ~amd64 chroot environment and it did build without problems with the following USE flags:
(chroot64) artus /var/db/repos/dracwyrm/media-gfx/blender # emerge -pqv =blender-2.80::dracwyrm
[ebuild R ] media-gfx/blender-2.80 USE="alembic bullet collada colorio cuda cycles dds elbeem ffmpeg fftw jack jemalloc jpeg2k llvm ndof nls openal openexr openimageio openmp opensubdiv openvdb osl sndfile tiff -debug -doc -headless -libav -man -opencl -sdl -test -valgrind" PYTHON_TARGETS="python3_7"
Thank you Adrien and Bernd for your feedback.
On my systems, when I unmasked python 3.7 and emerged blender, I found that numpy was rebuilt automatically. The stable version of numpy already includes python 3.7 compatibility in the ebuild. Did you have any issues getting numpy to rebuild?
I found that openvdb still worked without the python bindings, this is probably also true for blender 2.79. I was unable to crash the smoke simulation and dae file import/export using the in tree versions of openvdb and opencollada. However I have upgraded to the versions in your repository, Bernd, to match the minimum requirements reported by install_deps.sh. As well as those that you mentioned, I think that c-blosc also needs to be updated for openvdb.
I am interested on adding support for draco, embree and cycles standalone. With those features integrated, almost all of the flags from cmake will be exposed to the USE flag system to allow the user to completely customise their installation.
So far I have just added USE flags and checked it compiles, but it will take more time to get them to work. I am trying to find documentation of the xml format for cycles standalone to build a test case.
Blender has always been on the forefront with regards to python versions. I think stabilisation of blender 2.80 will be blocked for some time waiting on python 3.7.
Rather than pollute Jonathan's repository further with a large influx of new packages, I will continue development efforts in my own repository at http://github.com/redchillipadi/ebuild-overlay.git
Adrian, regarding my comment on requests, I didn't mean to stabilize blender. I'm well aware, this will probably take some time. In fact this comment wasn't even meant to be targeted to you, it refers to stabilize dev-python/requests for use with python-3.7, which IMO isn't trivial, because of dependencies on sphinx and some other base python packages. But it would enable the installation of blender on mostly stable system, by unmasking it, which isn't currently possible. But this is not due to your blender ebuild.
I've updated my draco ebuild a little bit. I'm trying to improve it further and adding support for missing features. I've also updated my embree ebuild, but then noticed you had it updated in your repo too.
As for c-blosc dependency of openvdb. We don't need it to be updated. In fact, according to https://www.openvdb.org/documentation/doxygen/dependencies.html#depDependencyTable we should it downgrad to c-blosc-1.5*, which isn't available anymore in Gentoo. But as openvdb compiles with 1.11.2 I think we can use this version.
A note on abi4-compat USE flag. IMHO this flag is also not needed for blender-2.80. They disable abi3-compat explicitly with cmake, but according to install-deps.sh script, depend on openvdb-5.1.0. If you take a look in build_files/build)environment/cmake/openvdb.cmake, you notice they don't explicitly ask for OpenVDB ABI 4 (by using -DOPENVDB_ABI_VERSION_NUMBER=4), thus the openvdb build system is using ABI 5 instead.
I think, the dependecy string on embree should also list -ispc and -tutorial. The cmake snippet in build_files/build_environment/cmake/embree.cmake explicitly disables those features. Note, that they also restrict the EMBREE_MAX_ISA option to be equal to AVX2, while embree automatically determines the highest available ISA according to the processor it is built on. I don't think it will hurt, if higher ISAs are built, they IMO only produce additional static libraries, but I'm thinking of re-adding the CPU_FEATURES, so it'd be possible to pass this flag too.
Adding USE flags for openvdb api version 5 (and presumably 6 down the track) forced me to rethink the naming convention. With more versions, the current method of assuming that ABI 5 will be used when ABI 3 and 4 are turned off will no longer work. Blender and openvdb both need the same flag set which explicitly selects the openvdb ABI to compile. I think the abiX-compat USE flags would be clearer if changed to openvdb_abi_X instead. This shows that they refer to openvdb instead of blender. It also avoid the use of compat in the flag for the current version. I feel that compat should only apply to legacy versions. Openvdb currently fails the raymask tests on my machine.
I have looked at backporting as much as possible to blender 2.79, as I feel that with the massive changes to the UI and breaking compatibility with old addons some users may not want to upgrade for some time. While earlier versions of blender may have had experimental support for ABI 3, both blender 2.79 and 2.80 require at least ABI 4 as they require copyGridWithNewTree. While blender 2.80 can use opencollada 1.6.68, blender 2.79 does not implement the new virtual function in its subclass of the opencollada writer and is forced to use 1.6.63.
I want to minimise the demands blender makes on embree to prevent interference with future packages. Otherwise blender with openvdb will prevent any packages using embree with ispc from being installed at the same time. It appears that allowing the user to choose to enable tutorial and ispc does not prevent blender from using the embree library. The tutorials are stored in /usr/build/embree3, and ispc provides an additional api rather than removing the old one. Perhaps they are only disabled upstream to reduce the build size.
The current version of ispc in the tree does not build with clang 6 or 7, so if ispc is permitted, then embree will require a later version of ispc in the tree, such as 1.11 from your repository. Embree does appear to work with blender with ipsc and tutorials enabled, although the tutorials themselves do not run as they are unable to open a display on my machine.
I have confirmed that bug #680624 (the polyfill2d.IssueT40777_colinear test failure) also applies to my 2.80 ebuild so this is something else that needs to be fixed before these changes will be ready to merge.