How To Install Yafaray Under Linux

One of the computing subtopics I dabble in, is the acquisition of 3D-graphics software. Therefore, I already have “Blender 2.78a”, which has its own built-in software-rendering engine, and I have several other rendering engines installed on my Linux-based computers.

Further, the rendering engines by themselves can be useless, unless they integrate well with a GUI (such as with Blender). And so one undertaking which I’ll typically reach with a given computer, is to install “Yafaray”, which used to be ‘Yafray’, which stood for ‘Yet Another Free Ray-Tracer’. If it’s installed properly, Blender can render its scenes, using Yafaray, but from within Blender.

Yafray used to be a much simpler piece of software to install than it has become. But I’m sure the effort I put into it this evening, will be well-worth it eventually. What I’m used to doing is to download a source-tree, and if it’s CMake-based, to run ‘cmake-gui‘ on it, to custom-pick my build options, and to go. But as it happens with Yafaray, this approach led to near chaos. What this did, was to compile all the source-code properly into libraries, but then to install those libraries to nonsensical locations within my system folders. One reason was the fact that a part of the project was to create Python 3 bindings, and another was the need for the Blender-integration, where modern Blender versions are based on Python 3. In any case I was sure to install all the build dependencies via my package-manager, but doing so was not enough to obtain working outcomes.


Continue reading How To Install Yafaray Under Linux

I’ve just custom-compiled ‘Aqsis’.

To give some context to this proclamation, I had written an earlier posting, about adapting the non-packaged software named ‘Ayam‘ to Debian / Stretch, that had worked just fine under Debian / Jessie. This is a GUI which constructs complex ‘Renderman‘-Compliant rendering instructions, in this case in the form of .RIB-Files, which in turn, ‘Aqsis’ can turn into 2D perspective views of 3D scenes, that have been software-rendered. OTOH, Ayam itself uses OpenGL and H/W rendering, for its GUI.

What I had found before, was that Ayam did not seem stable anymore under Debian / Stretch. I apologize for this assessment. Under close scrutiny, my computer has revealed, that it was really Aqsis giving the problems, not Ayam. Aqsis is a text-based tool in effect.

Ayam does not specifically need to be used with Aqsis to do its rendering. It can be set up to use other rendering-engines, most of which are quite expensive. Aqsis just happens to be the best Open-Source rendering-engine, whose language Ayam speaks. And at this point I’d say that Ayam is still quite stable, after all, under Debian / Stretch.

As is often the case with such troubles, I next sought to custom-compile Aqsis, to see whether doing so could get rid of its quirks. What were its quirks?

Finally, the only problem with Aqsis was and remains, that it cannot produce a real-time preview of the scene being edited, which it used to provide using a component-program named ‘piqsl’. And the reason why the packaged version of Aqsis does not have ‘piqsl’ under Debian / Stretch, is because this distribution of Linux has a very new ‘Boost’ library ( v1.62 ) , and the visual component to Aqsis, that could produce a display, still relies on the Qt4 libraries and their API, which have begun to bit-rot. The Qt4-specific code of Aqsis cannot parse the newest usage of the Boost libraries, and Debian maintainers have long since discovered this. They are shunning the use of ‘libqt4-dev’ and of ‘libqt4-opengl-dev’ to build any of their packages. So they were effectively forced to package a version of Aqsis, which was missing some important components.

(Updated 12/12/2017 … )

Continue reading I’ve just custom-compiled ‘Aqsis’.

UDF-Capable Disk Burning with K3b and Debian / Stretch

According to This earlier posting, I was using a Debian / Jessie laptop, the first part of which is also known as Debian 8, to burn UDF-Capable Blu-ray Disks, given an external Blu-ray burner, and that version of Linux required help. Specifically, I needed to modify the way K3b behaves, by uninstalling the package ‘wodim’, which provides ‘cdrkit’, and by custom-compiling ‘cdrtools’, which is meant to act as a drop-in replacement for ‘cdrkit’, except for the fact that for the moment, ‘cdrtools’ was more powerful than ‘cdrkit’.

Under Debian / Stretch, which is also known as Debian 9, ‘wodim’ is not suggested by ‘K3b’ anymore, but rather a required dependency, for which reason to uninstall ‘wodim’, would also uninstall K3b. And so I needed to know, whether the package-provided version of K3b, and all its dependencies, could still burn Blu-rays via the GUI.

And the short answer is that Indeed, under Debian / Stretch, the packaged software has the required capabilities, so that to try to modify the behavior of K3b ( v2.0.3 ) is not only a bit risky, but totally unnecessary.

I created a Data-DVD Project – which we would also do for Blu-rays, and then burned that onto a DVD+R with 3 sets of options:

  1. File System = “Linux+Windows”, back-end = ‘growsiofs’
  2. File System = “UDF”, back-end = ‘growisofs’
  3. File-System = “UDF”, back-end = ‘cdrecord’

What I next did, was to run the command ‘df -T /dev/sr0′ , after mounting each disk via the GUI, both actions as a regular user. I found that options (2) and (3) both showed up as a “udf” file-system, while option (1) showed up as an “iso9660″ file-system.

This is as much, as custom-compiling ‘cdrtools’ could do for the user. Also, when going into the Programs settings of K3b, the full range of supported back-ends shows up as being available. Using burning-options (3) above, starts out the dialog with “Using Wodim” in the GUI, but all 3 settings still show me in the K3b GUI, “Burning ISO9660 File System”.

(Updated 10/23/2017 :


If this is to be used seriously for burning Blu-rays, then there is something which the user should further know.

Continue reading UDF-Capable Disk Burning with K3b and Debian / Stretch