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

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

## Panda3D Compiled and Installed on ‘Klystron’

I have just completed a project, by which I downloaded, compiled and installed the 3D-game / 3D-application development software named Panda3D, on the powerful Linux laptop I name ‘Klystron’. That laptop is not to be confused with the less-powerful Web-server I name ‘Phoenix’.

This game-development kit started out years ago as a much-simpler project from Carnegie-Mellon University, which at the time I called a toy. But as it stands today, the level of sophistication and power available through Panda3D has grown tremendously. It is no longer a toy by any means, and is also one of the few game-dev platforms I know of, that can be scripted directly in Python.

One of the new features that make it interesting, is the ability to use Bullet Physics, especially since the simpler ODE (Open Dynamics Engine), game-physics engine, is broken on some platforms.

Another new feature is the support for a browser plug-in, that will allow games etc. to be deployed as Web-content, as long as the browser has the run-time plug-in installed. The actual embedded applet will then take the form of a ‘.p3d’ File.

One aspect of compiling this software that takes some getting used to, is that its python-based make-commands accept an ‘–everything’ parameter, which essentially tells the make-script to find all the relevant dependencies on the local computer, and then to configure the version of Panda3D we are compiling, to link only to the dependencies which were found, thereby either including some features or leaving them out.

I found that my only way to process that information, was to run the make command a first time as a dummy-run, and then to interrupt it. At the top of its build-log, it will show the power-user which libraries / dependencies it did not find, as if the intention was not to include those. After having interrupted this first run, I next went through my package-manager and installed all the packages named, which I felt might add some value to my build of Panda3D.

And so, after I checked out the GIT version of the software to a folder named ‘~/Programs/panda3d’ , and after ‘cd’ -ing to that directory, I felt that the following recipes were of use to me:

## IRISNotes Digital Pen

There exist so-called Digital Pens, which will record what they are writing electronically, while writing on paper. These pens belong to two categories:

1. The kind that require special paper.
2. The kind that require a receiver be attached to the top of the sheet, which senses the positions of the pen during writing, but which do not require special paper.

The IRISNotes is a digital pen of the second kind, of which I happen to own one.

In general, I do not find this type of pen very useful, because the need does not arise often, to be writing on paper, yet to be digitizing what is written anyway. However, I have this pen, and have in the past installed Windows software to download its writings onto my PC.

I felt that it would be a challenge to get this relic to work again, while using Linux software to download its data. For that purpose, it was helpful to note, that the hardware is of the ‘Pegasus’ variety, regardless of how it was branded. And then it was easy to find a special, Linux, software-project, the aim of which was to do exactly that.

This software only comes in binary form, packaged for Ubuntu. Using Debian, we do not have a mechanism for PPAs. And so the only way for me to get it running, was to custom-compile it, which I easily did.

Aside from custom-compiling, I needed to create the following file:


/etc/udev/rules.d/50-hidraw.rules :




(Update 04/23/2018 :

Actually, by now I’ve discovered that the project source tree actually has a sub-directory named ‘udev’, which contains the recommended Rules File.

The Rule I created above will certainly work, but by giving user-access to any and every HIDRAW device-file, may not provide the highest level of security. And so I would recommend that readers do what I’ve done myself by now – To use the Rules File supplied with the project. )

I should note that my version of IRISNotes pen is first-generation. I cannot guarantee that any of this will work with an IRIS 2 or an IRIS Executive 2 -type pen. I just happened to own a pen which was collecting dust, with the idle thought of wanting to reactivate it.

The version of this pen which I have, has two modes of operation: USB-mode and Bluetooth-mode. The BT-mode has always been rather pointless, because it would need an active wireless connection while I was writing. It was originally meant to work with Android and iOS devices, but lacked in performance.

The ability to download pages of writing that are saved in the receiver-module, has always been limited to working in USB-mode.

And so I am happy to announce, that my project was a success, and that I am able to use the command-line tool to convert captured data to SVG (image) files.

The ability to do OCR on the writing has always required Windows or OS/X, and under Linux, whatever ability we want, to convert the SVG drawings to text, must be supplied by the user or not at all. I am not that far along with it yet.