## 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.

When I custom-compile source-code, which I downloaded, I usually use either one of

• ‘./configure’
• ‘cmake-gui’

In this previous posting, I described how to use ‘CMake’ in detail, especially in a case which entailed complications.

(I should add that this only works, when the source-code has specifically been set up, to use either of the above build-systems, which Open-Source software usually has. And, neither of the above configuration tools is actually a compiler, which anybody needs to provide, to use in conjunction with he configuration tools named above. )

But there is a second question related to CMake, which I feel I need an answer to, before I commit anything I compiled to the root file-system.

Usually, after having created the Makefiles, the course of action might be:


make -j 4
su
(...)

make install




But before I do the last bit, I want to be sure that I could uninstall anything which I might have installed ! So, as root, the way to uninstall would be:


make uninstall




But we might find, that with some Makefiles, there is no longer a target named ‘uninstall’ ! The way I find out about this, is to run:


make uninstall




as user, before running ‘make install’. If we happen to be using ‘CMake’, then we have a graceful way to exit. As root, in the build-directory, we can run the command:


cat install_manifest.txt | while read f; do rm -f "\$f"; done




This will usually uninstall the project again.

Dirk

## 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 … )

## OGRE 1.10 and Geometry Shader Support

On my Debian / Jessie laptop ‘Klystron’, I gave up some time ago, in compiling OGRE 1.10, this just resulting in a mess. Instead, on that platform I was only able to build OGRE 1.9 from source code, which is fully stable, as long as we stick to the OpenGL (2) Render System.

On the Windows 7 desktop ‘Mithral’, my first attempt to build OGRE 1.10 also failed, resulting in a successful compile, but then a silent crash of the Sample Browser, indicating that something was not built right.

If I have OGRE installed on several machines, it makes most sense for them to be the same OGRE version, so next I compiled OGRE 1.9 on ‘Mithral’, successfully, using Visual Studio 2015.

In response to my observation, that I had not set up the dependencies correctly on the ‘Mithral’ build attempt of OGRE 1.10, I now re-attempted that, paying closer attention to all the details, specified within CMake 3.6.2 .

I found that I could not only build OGRE 1.10 on this machine but also run it. And I found, that contrarily to how it was with OGRE 1.9, the OpenGL3+ Render System of OGRE 1.10 is capable of producing working Geometry Shaders. At least this gives me some access to Geometry Shaders, and casts doubt back onto the MESA Drivers of ‘Klystron’, which would cause the X-Server to crash, if I ran the Geometry Shader example of OGRE 1.10 .

What I still cannot do, is build the DirectX 11 Render System that is supposed to work under OGRE 1.10 , due to errors I have not yet pinned down. But what that was supposed to bring me, is now being provided successfully by the OpenGL3+ Render System. Both of these two are stated by the OGRE Team, to be experimental render systems, for version 1.10 still.

I suspect that OGRE 1.10 is being neglected by their team, in favor of OGRE 2.1, which is their effort to port OGRE to Android.

Dirk