Greetings,
I'm using Blender occasionally (I'm not a 3D designer but I do need to edit some 3D models, sometimes) and always pestered against its totally retard UI. I then discovered Bforartists and breathed out a sigh of relief: great job on the UI, guys, it's at least (and at last) manageable ! 
So I compiled Bforartists v1.0.0 for PCLinuxOS which is the Linux distro I am currently using, and the RPM packages for it are available here.
The feature table is as follow:
Blender Configuration
=====================
Build Options:
- WITH_GAMEENGINE ON
- WITH_PLAYER OFF
- WITH_BULLET ON
- WITH_IK_SOLVER ON
- WITH_IK_ITASC ON
- WITH_OPENCOLLADA ON
- WITH_FFTW3 ON
- WITH_INTERNATIONAL OFF
- WITH_INPUT_NDOF ON
- WITH_CYCLES OFF
- WITH_FREESTYLE ON
- WITH_OPENCOLORIO OFF
- WITH_OPENVDB OFF
- WITH_ALEMBIC OFF
Compiler Options:
- WITH_BUILDINFO ON
- WITH_OPENMP ON
- WITH_RAYOPTIMIZATION ON
System Options:
- WITH_INSTALL_PORTABLE ON
- WITH_X11_ALPHA ON
- WITH_X11_XF86VMODE ON
- WITH_X11_XFIXES ON
- WITH_X11_XINPUT ON
- WITH_MEM_JEMALLOC OFF
- WITH_MEM_VALGRIND OFF
- WITH_SYSTEM_GLEW OFF
- WITH_SYSTEM_OPENJPEG OFF
Image Formats:
- WITH_OPENIMAGEIO OFF
- WITH_IMAGE_CINEON ON
- WITH_IMAGE_DDS ON
- WITH_IMAGE_HDR ON
- WITH_IMAGE_OPENEXR ON
- WITH_IMAGE_OPENJPEG ON
- WITH_IMAGE_TIFF ON
Audio:
- WITH_OPENAL ON
- WITH_SDL OFF
- WITH_SDL_DYNLOAD OFF
- WITH_JACK OFF
- WITH_JACK_DYNLOAD OFF
- WITH_CODEC_AVI ON
- WITH_CODEC_FFMPEG ON
- WITH_CODEC_SNDFILE ON
Compression:
- WITH_LZMA ON
- WITH_LZO ON
Python:
- WITH_PYTHON_INSTALL ON
- WITH_PYTHON_INSTALL_NUMPY ON
- WITH_PYTHON_MODULE OFF
- WITH_PYTHON_SAFETY OFF
Modifiers:
- WITH_MOD_REMESH ON
- WITH_MOD_FLUID ON
- WITH_MOD_OCEANSIM OFF
OpenGL:
- WITH_GLEW_ES OFF
- WITH_GLU ON
- WITH_GL_EGL OFF
- WITH_GL_PROFILE_COMPAT ON
- WITH_GL_PROFILE_CORE OFF
- WITH_GL_PROFILE_ES20 OFF
Note that the internationalization support fails to compile while it did compile fine in bforartists v0.9.7 ("syntax error" message when 'make' tries to turn the .po files into .mo files, while they do compile fine by hand with 'msgfmt': I suspect that 'make' tries to use something else than 'msgfmt' to compile them, due to a bug in the cmake files), but since I did not have time to investigate (and do not really care about menu languages: the native English is usually better anyway, due to translations "fuzziness"), I had to turn WITH_INTERNATIONAL off.
The RPMS source file also contains a couple of patches of mine to allow the compilation and use of OpenCollada (tested and working) and PCLinuxOS' FFMeg v4.0 (the latter is untested however: I do not produce movies with Bforartists).
Thanks
And thanks for the rpm file. Great effort. I have unfortunately close to zero knowledge about Linux. I have just a Ubuntu in a VM here. And Ubuntu and Debian can't deal with rpm. So i can't check.
Now for the bad thing. I noticed in your list above that some vital things are missing in your build. Jack, Player. And lots of other things. The most important one is Cycles. That's the renderer. This one you should definitely not leave away. No wonder the rmp file is so small
To check what options should be on for a release version go to build_files\cmake\config\ and open the blender_release.cmake file in a text editor. Here you can read the points that should be activated. There must also be a way to use this file directly to feed Cmake with. But i have never found out how. Most probably a linux thing ...
I was told that "with international" also makes trouble with Blender at Linux. Windows works fine. So it seems that for now we simply have to live with it.
Kind regards
Reiner
EDIT says, "With international" works under Linux. Somebody was so kind to test it. I have no idea why it fails at your os
Free gamegraphics, Freeware Games http://www.reinerstilesets.de
Well, as I wrote, I'm only using blender/bforartists occasionally, and it worked fine for me that way
Also, Blender's build system is just as messy as Blender's UI, lol ! Why the Hell don't they setup the *default* build options to the release ones ??? Plus lot's off stuff that does not get enabled is not listed as being OFF in the options output at the build stage, making missing things hard to spot.
Thanks for your pointer to the blender_release.cmake file: I could add the missing defines based on it.
Anyway... I produced a second release, this time with a lot more stuff enabled, and I found a way to work around the msgfmt bug in the cmake file that caused a failure to build the internationalized *.mo files (I patched the cmake file to just use the *.mo files that I produce in the *.spec file script before the build stage). I also had to create the Alembic library rpm packages since PCLinuxOS did not have them.
Here is the new feature table for the new release:
Blender Configuration
=====================
Build Options:
- WITH_GAMEENGINE ON
- WITH_PLAYER ON
- WITH_BULLET ON
- WITH_IK_SOLVER ON
- WITH_IK_ITASC ON
- WITH_OPENCOLLADA ON
- WITH_FFTW3 ON
- WITH_INTERNATIONAL ON
- WITH_INPUT_NDOF ON
- WITH_CYCLES ON
- WITH_FREESTYLE ON
- WITH_OPENCOLORIO ON
- WITH_OPENVDB OFF
- WITH_ALEMBIC ON
Compiler Options:
- WITH_BUILDINFO ON
- WITH_OPENMP ON
- WITH_RAYOPTIMIZATION ON
System Options:
- WITH_INSTALL_PORTABLE ON
- WITH_X11_ALPHA ON
- WITH_X11_XF86VMODE ON
- WITH_X11_XFIXES ON
- WITH_X11_XINPUT ON
- WITH_MEM_JEMALLOC OFF
- WITH_MEM_VALGRIND OFF
- WITH_SYSTEM_GLEW ON
- WITH_SYSTEM_OPENJPEG OFF
Image Formats:
- WITH_OPENIMAGEIO ON
- WITH_IMAGE_CINEON ON
- WITH_IMAGE_DDS ON
- WITH_IMAGE_HDR ON
- WITH_IMAGE_OPENEXR ON
- WITH_IMAGE_OPENJPEG ON
- WITH_IMAGE_TIFF ON
Audio:
- WITH_OPENAL ON
- WITH_SDL ON
- WITH_SDL_DYNLOAD ON
- WITH_JACK ON
- WITH_JACK_DYNLOAD ON
- WITH_CODEC_AVI ON
- WITH_CODEC_FFMPEG ON
- WITH_CODEC_SNDFILE ON
Compression:
- WITH_LZMA ON
- WITH_LZO ON
Python:
- WITH_PYTHON_INSTALL ON
- WITH_PYTHON_INSTALL_NUMPY ON
- WITH_PYTHON_MODULE OFF
- WITH_PYTHON_SAFETY OFF
Modifiers:
- WITH_MOD_REMESH ON
- WITH_MOD_FLUID ON
- WITH_MOD_OCEANSIM ON
OpenGL:
- WITH_GLEW_ES OFF
- WITH_GLU ON
- WITH_GL_EGL OFF
- WITH_GL_PROFILE_COMPAT ON
- WITH_GL_PROFILE_CORE OFF
- WITH_GL_PROFILE_ES20 OFF
Note that jemalloc is disabled on purpose (useless for such programs: the glibc malloc() performs just as good).
Also, I tried WITH_GL_PROFILE_CORE=ON but it causes the program to crash with a "trap divide error", not sure why...
There are still a few things missing (in excess of OpenVDB):
-- Could NOT find OSL (missing: _osl_LIBRARIES OSL_INCLUDE_DIR OSL_COMPILER)
-- OSL not found, disabling it from Cycles
-- Could NOT find OpenSubdiv (missing: _opensubdiv_LIBRARIES OPENSUBDIV_INCLUDE_DIR)
-- OpenSubdiv not found
CUDA_TOOLKIT_ROOT_DIR not found or specified
-- Could NOT find CUDA (missing: CUDA_TOOLKIT_ROOT_DIR CUDA_NVCC_EXECUTABLE CUDA_INCLUDE_DIRS CUDA_CUDART_LIBRARY)
-- CUDA compiler not found, disabling WITH_CYCLES_CUDA_BINARIES
But well, I think it's a decent release already (certainly more than what I personally need).
That's better. Linux Bforartists users will love you for this :)
Hehe, yes, it's under the hood as messy as at the surface. Just curious, do you even have Cuda installed? That could explain the error. And for the libraries, have you downloaded the libs from Blender?
The different build options makes sense. For development you want a fast compiling. For the release version you want all the bells and whistles.
Free gamegraphics, Freeware Games http://www.reinerstilesets.de
I beg to differ: first of all, while developing such a large software, you do not recompile everything every time you change a source file: 'make' will sort out what needs to be recompiled based on the file(s) you changed, so using a smaller set of features does not lower (or only very marginally) the recompile time anyway. Second, you'd better make sure that your changes won't impact negatively release builds, so you do want to test your changes on a release feature set each time.
I confirm: definitely a messy build system !
Got only the runtime libraries (the proprietary ones, straight from NVIDIA's drivers download site). The build message about missing CUDA was therefore not much of a surprise to me, and I would need to install the (huge: over 1Gb) CUDA devel toolkit from NVIDIA (no such package in PCLinuxOS repository either).
Riddle solved. No Cuda. Since you need of course the dev kit to build it with Cuda ^^
Free gamegraphics, Freeware Games http://www.reinerstilesets.de
Have you called build_files/build_environment/install_deps.sh previously to build BFA? This script would install OSL and OSD and contains rpm install routines.
Doesn't indicate anything, on my arch and deb systems that's also always undefined while the library-paths are correct. But would be interesting if there is Cuda included
I'm btw currently in the process o f making Arch AUR packages and *.deb packages for Debian based systems, but a *.rpm package would of course be very nice.
It is not designed for Mandrake/Mandriva forks such as PCLinuxOS (or Mageia, OpenMandriva, Rosa, etc), so it plain does not work.
Funnily enough, it also got DOS (CR/LF) line endings, so it cannot be run "as is" under Linux (bash hates CRs) and needs to be first converted into LF-line-ending file... Did someone (rather overzealous) convert that file to a DOS file ?
The only proper way to add the missing features is to create packages for the missing libraries (like I did for Alembic) or to compile and use static versions of the libraries during the bforartists package building (like I do for OpenCOLLADA, because PCLinuxOS does not provide a *static* library for it, which blender needs).
Time permitting, I may create the missing OpenVDB, OSL and OSD packages (but they depend on yet other missing packages, thus why I skipped them for now).
Interesting, my system does not complain about CR/LF endings.
Oh yeah, I know that problems. Maybe one can introduce submodules again, containing all needed third party libraries in an extra directory. I know, will need lots of memory and time for compilation, but that could be made as an extra toolchain file for cmake for static compilation,packaging and deployment. I could take a look into that in the next days.
I just uploaded release #3, with OpenVDB support.
Thanks for your effort
I could upload and link it here in the download section if you want
Free gamegraphics, Freeware Games http://www.reinerstilesets.de
I just uploaded release #4, with OpenSubdiv and Open Shading Language support (and packages).
Apart from CUDA support, everything is now implemented.
Your best bet would be to simply link to http://linux.developer.free.fr/#bforartists since this is not a monolithic package (its bforartists binary is not fully statically linked but uses the system dynamic libraries) and therefore requires ancillary packages (Alembic, Blosc OpenVDB, OSD, OSL) that are not part of PCLinuxOS official repositories, but are provided on my site (the latter being usable as a rpm auxiliary repository for PCLinuxOS).
Also, please keep in mind that this release was largely untested: it does what I need from it (and much more), but I did not perform an exhaustive testing of all of its features and it could just as well blow in your face when using some specific feature... It should be considered beta software.
At least, it got the merit to provide a recipe for other RPM-based distros packagers: the .spec files of the various packages could be reused (with only minor alterations, such as the package names in the BuildRequires and Requires dependencies) for RedHat/Fedora, (Open)Suse, and of course all Mandrake forks.
Okay, then i'll put a link to your page into the downloads section
Free gamegraphics, Freeware Games http://www.reinerstilesets.de
Thanks !
However, you made a slight mistake in the description;
"There is a deb package for Version 1.0.0 available here"
It's, of course, a *rpm* package.
I also tested my build of Bforartiss (v1.0.0) against Blender's (v2.79) and rendered the "Blendman" scene (as available on Blender's demo files site): my build is almost 50% faster (both builds ran in the exact same conditions, with no other software running). Here are screen-shots (with the time to render shown): Bforastists, Blender.
The optimization options I used in gcc did really make a difference...
Yikes!
Thanks for reporting. Will change it
Free gamegraphics, Freeware Games http://www.reinerstilesets.de
Awesome work guys, I was trying to build the linux version also since I notice there wasn't any linux maintainer no more, but I haven't compiled a program before and was getting errors, any chance you could teach me linuxdev via Discord or similar?
Not at my end, sorry. Hardcore Windows user here. I am happy when i can start my Ubuntu
But maybe you can tell us the error that you get
Free gamegraphics, Freeware Games http://www.reinerstilesets.de
Issues with Open Shading but I am a very very noob when compilign something in Linux, something I wouldn't mind learning though.....
I just added the "bforartists2" package to http://linux.developer.free.fr/
Given its alpha status, bforartists2 may coexist with bforartists (v1).
So far, I noticed just one (but annoying) problem: it does not seem to recognize my graphics card for "Cycles render devices", while the card is properly detected and used with v1...
Thanks
So you can't render? Or does it not keep the setting?
Free gamegraphics, Freeware Games http://www.reinerstilesets.de
I can render with the CPU. It's just that, unlike Bforartists v1, v2 does not "see" (*) the GPU and cannot therefore use it.
(*) In Edit -> Preferences -> System -> Cycles Render Devices, I got "No compatible GPUs found" for either CUDA or OpenCL.
Thanks for the information. Have you installed Cuda at your system, and enabled Cuda in Cmake before compiling?
Cuda and quite a few other compiling heavy options are off in the default cmake configuration. Have a look in the build_files\cmake\config\ directory for the blender_release.cmake file. There you can read what features are enabled for the release version.
Free gamegraphics, Freeware Games http://www.reinerstilesets.de
This is not the problem: no, the CUDA toolkit was not installed (and the corresponding -D option not passed to cmake in my .spec file), but neither was it when I built Bforartists v1, and it yet does not prevent Cycles to detect and use the GPU in the latter, as a CUDA device...
That's impossible ^^
No Cuda means no GPU rendering with Cuda. Can it be that you mean the OpenCL device instead? This one also renders at the gpu if available. But that's nothing where i can be of help, sorry. I have a Nvidia card with Cuda. Just curious, does Blender 2.80 work for you with either Cuda or OpenCL?
Free gamegraphics, Freeware Games http://www.reinerstilesets.de
Have a look by yourself... Spec (rpm package build script) file, installed rpm, screen shot with settings window and splash screen...
So, yes, maybe you are right on the fact that the GPU was actually used in OpenCL mode in Bforartists1 despite what it pretends to use (CUDA) in its preferences window, but anyway, Bforartists2 does not recognize my GPU in either of the CUDA or OpenCL modes... That's a bug, I'm afraid...
Note that I may be able to install the CUDA 9 toolkit and build Bforatists2 with it, since blender 2.80 might build against it (unlike v2.79, that required CUDA 8, but the latter requiring gcc 5.5... that OSL could not be built with... lol !). Time permitting, I may give it a try (but don't hold your breath on it: I'm not using Bforartists to render stuff anyway, but only for creating/editing Collada meshes)...
Blender v2.80 (beta) is indeed seeing the CUDA device but not finding OpenCL while the proprietary NVIDIA driver, with OpenCL libraries, is installed on my system...
The comment is funny. Bforartists 1 for Windows compiled in fact just fine with Cuda 9 and 10. Yes, we are at Cuda 10 already
It is linux, i am lost, sorry. It can be everything :)
Free gamegraphics, Freeware Games http://www.reinerstilesets.de
I uploaded the RPM packages for Bforartists 2 alpha 2 on my site.
Note to developers: I had to re-add files (from alpha 1 sources) that are missing from alpha 2 sources and cause a build failure: they are *.dat files in release/datafiles/blender_icons16 and release/datafiles/blender_icons32, that cause, when missing, a failure to build the png icons.
Huh? There shouldn't be missing anything.
Could be a linux specific problem, which i cannot even reproduce then. Anyways, thanks for your effort
Free gamegraphics, Freeware Games http://www.reinerstilesets.de
Greetings,
I uploaded the RPM packages for Bforartists 2 alpha 3 on my site.
Note to developers: I *still* had to re-add files (from alpha 1 sources) that are missing from alpha 2 sources and cause a build failure: they are *.dat files in release/datafiles/blender_icons16 and release/datafiles/blender_icons32, that cause, when missing, a failure to build the png icons.
cmake error sample:
make[2]: *** No rule to make target '../release/datafiles/blender_icons16/icon16_decorate_library_override.dat', needed by 'release/datafiles/blender_icons16.png'. Stop.
Also, and while built in the same way and on the same build system as bforartists 1, the resulting binary is still unable to detect my GPU with bforartists 2 while it is properly detected as a CUDA device with bforartists 1 and blender v2.80... If you made any change to the GPU code when compared to blender's, I'd recommend that you look into the corresponding commits because something got apparently (or rather, obviously) broken there...
Following my last message, I tried something: I ran bforartsist2 from the command line, so to see any warning printed to the stderr output, and it did pay !
When opening the Preferences panel, I get:
which: no nvcc in (/usr/local/bin:/usr/local/sbin:/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/games:/usr/games)
Meaning bforartsist2 is searching for the NVIDIA CUDA compiler and, not finding it (which is normal, since I don't have the CUDA toolkit installed), prints an empty list of CUDA devices in the Preferences panel... This does not happen with either blender v2.80 or bforartsist1.
So, I created a fake nvcc (I created a /usr/local/bin/nvcc link to /bin/true), and, miracle, bforartsist2's Preferences panel now does find my graphics card, as well as my CPU (it did not even find the latter with nvcc missing while it's not related in any way with it !)...
So there. Something went amiss in the Preferences panel UI code, that causes this useless check (since Cycles can still use CUDA devices without the help of the CUDA nvcc compiler anyway)...
Good catch. I am still lost here though what is missing and what we could do. I have no linux :/
EDIT, have you ticked WITH_CUDA_DYNLOAD in cmake? MoxFulder guesses that this could be related here. But could be also totally unrelated.
I wish i would have a bit more clue about Linux :'3
Free gamegraphics, Freeware Games http://www.reinerstilesets.de
Yes, I have the following Cycles-related options in the cmake command line:
-DWITH_CUDA_DYNLOAD=ON -DWITH_CYCLES=ON -DWITH_CYCLES_OSL=ON -DWITH_CYCLES_DEVICE_CUDA=ON -DWITH_CYCLES_DEVICE_OPENCL=ON
I also do observe that the nvidia-uvm module gets loaded as soon as I select CUDA in the "Cycles render devices" radio-buttons of the Preferences panel in bforartists2 (and 1, and blender), even without the fake nvcc trick. So, it does seem to dynamically load CUDA.
Note however that the fake nvcc trick is still insufficient for rendering with the GPU (bforartists2 complains it cannot get the nvcc version, which is normal since it's just /bin/true that is actually executed) which, again, does not happen with v1 or blender.
So, I also 'grep'ped the sources for "nvcc" and found an option that might have explained it and I recompiled, adding -DWITH_CYCLES_CUBIN_COMPILER=ON, but to no avail (it does not change anything at all)...
Greetings,
I uploaded the RPM packages for Bforartists 2 alpha 4 on my site.
Like for former Bforartists2 alpha releases, CUDA-capable devices are still not detected/usable (see my former messages about it: same problem with alpha 4).
Thanks a bunch
Free gamegraphics, Freeware Games http://www.reinerstilesets.de
I just talked to my linux friends that use Blender. Blender won't run the CUDA GPU right up automatically like Windows. They run a code: primusrum in the executable to make the machine startup the GPU. Maybe that is why it's not really activatin CUDA in linux?
-Draise
This is required for a specific setup, where you have an Intel and a Nvidia GPU.
@linuxdev: Is that the case for your hardware setup?
No, my main computer got the IGP disabled at Linux kernel level, so it's plain CPU + NVIDIA GPU: no mix-up (plus, the CPU is a 2500K which got an IGP that is too old to use with OpenCL Intel drivers).
Note also that neither blender v2.80 nor Bforartists1 got any trouble to find and use my NVIDIA GPU as a CUDA device. There is a bug in Bforartists2, obviously (read my former messages for my findings)...
Ah. Maybe I'll do a virtual machine and install Manjaro or something and give it a whirl. i've been curious of Linux, but haven't had a need to use it. What does the crash feel like? It just.. hangs when trying to render on GPU?
-Draise
What crash ?... There is no crash. Bforartists 2 simply fails to find and use the GPU.
Ah, so you can select the GPU but it does nothing? Or you can't even activate the GPU via the UI because it just won't show?
It seems my drivers for Nvivida is a bit difficult to make it work in my Virtual Box, and so I've got limited driver troubleshooting... hmm.. what other way could I trouble shoot.
-Draise
Please... Read my previous posts, where I describe the issue in details (and even with screen shots)... The CUDA backend is not detected by bforartists2 while it is for bforartists1 (when compiled in the exact same way on the same machine) and blender.
I also found out why; read my previous post "Hint about the GPU detection bug" about the bogus call to nvcc (nvcc, which is part of the CUDA toolkit used by developpers should not be needed at all and is certainly not needed with blender and bforartist1).
As for using a Linux VM to diagnose the bug, it is a bad idea since those VMs do not give access to the bare metal GPU (which is virtualized instead). You should try and boot from live Linux DVD (or USB key). You could even use a PCLinuxOS DVD and install the RPM packages both bforartists 1 and 2 from my site to reproduce the issue.
Yeah. I came late to the party. I'll try a live USB drive next time.
-Draise
I just uploaded Bforartists 2 alpha 5 for PCLinuxOS on my site together with some updated libraries (OpenColorIO, OpenVDB and OSL) which needed a recompilation since the boost libraries they depend upon have been updated in PCLinuxOS. I also recompiled Bforartist v1, for the same reason.
Note: the CUDA device detection bug is still present in Bforartists 2 alpha 5.
And we have still no idea where this comes from, sorry :/
Free gamegraphics, Freeware Games http://www.reinerstilesets.de
I just uploaded Bforartists 2 alpha 6 for PCLinuxOS on my site.
Note: the CUDA device detection bug is still not solved while Blender v2.80 and Bforartists 1 got no problem with it.
We are still lost with it, sorry. I have compared the code several times now. And couldn't find the difference that causes this bug.
Free gamegraphics, Freeware Games http://www.reinerstilesets.de
I too had a look at it a few months ago now, but I alas don't have enough time to investigate seriously.
My guess would be a change in the build system (cmake files) that causes it (and that's what I looked for in the first place, but did not find the actual problem).
I have investigated more than once. Also in the Cmake files. My biggest hurdle is that i don't have linux. I can't even reproduce or check the error. I really wish i could help :/
Free gamegraphics, Freeware Games http://www.reinerstilesets.de
I just uploaded Bforartists 2 alpha 7 for PCLinuxOS on my site.
Note: the CUDA device detection bug is still not solved.
Thanks
Yes, i expected it. We have still no way to repeat it. And we don't have a linux maintainer at the moment. Sorry.
Free gamegraphics, Freeware Games http://www.reinerstilesets.de
Pages