Update to Computer Phosphene Last Night

Yesterday evening, a major software update was received to the computer which I name ‘Phosphene’, putting its Debian version to 9.9 from 9.8. One of the main features of the update was, an update to the NVIDIA graphics drivers, as installed from the standard Debian repositories, to version 390.116.

This allows the maximum OpenGL version supported by the drivers to be 4.6.0, and for the first time, I’m noticing that my hardware now limits me to OpenGL 4.5 .

The new driver version does not come with an update to the CUDA version, the latter of which merits some comment. When users install CUDA to Debian / Stretch from the repositories, they obtain run-time version 8.0.44, even though the newly-updated drivers support CUDA all the way up to version 9. This is a shame because CUDA 8.0 cannot be linked to, when compiling code on the GCC / CPP / C++ 6 framework, that is also standard for Debian Stretch. When we want code to run on the GPGPU, we can just load the code onto the GPU using the CUDA run-time v8.0.44, and it runs fine. But if we want to compile major software against the headers, we are locked out. The current Compiler version is too high, for this older CUDA Run-Time version. (:1) (:4)

But on the other side of this irony, I just performed an extension of my own by installing ‘ArrayFire‘ v3.6.3 , coincidentally directly after this update. And my first attempt to do so involved the binary installer that ships with its own CUDA run-time libraries, those being of version 10. Guess what, Driver version 390 is still not high enough to accommodate Run-Time version 10. This resulted in a confusing error message at first, stating that the driver was not high enough, apparently to accommodate the run-time installed system-wide, which would have been bad news for me, as it would have meant a deeply misconfigured setup – and a newly-botched update. It was only after learning that the binary installer for ArrayFire ships with its own CUDA run-time, that I was relieved to know that the┬ásystem-installed run-time, was fine…

Screenshot_20190429_104916

(Updated 4/29/2019, 20h20 … )

Continue reading Update to Computer Phosphene Last Night

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.

funbutterflysphere3-0001

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

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:

Continue reading Panda3D Compiled and Installed on ‘Klystron’