What’s what with the Aqsis Ray-Tracer, and Qt4 project development under Linux.

One of the subjects I once wrote about was, that I had a GUI installed on a Debian 8 / Jessie computer, which was called ‘Ayam’, and that it was mainly a front-end for 3D / Perspective graphics development, using the Aqsis Ray-Tracer (v1.8). And a question which some of my readers might have by now, could be, why this feature seems to have slipped out of the hands of the Linux software repositories, and therefore, out of the hands of users, of up-to-date Linux systems. Progress is supposed to go forwards and not backwards.

In order to answer that question, I feel that I must provide information, which starts completely from the opposite end. There exists a ‘GUI Library’, i.e., a library of function-calls that can be used by application programmers, to give their applications a GUI, but without having to do much of the coding, that actually generates the GUI itself. The GUI Library in question is called “Qt”. It’s a nice library, but, as with so many other versions of software, there are noticeably the Major Qt versions 4, 5 and 6 by now. While in the world at large, Qt4 is considered to be deprecated, and Qt6 is the bleeding edge under development, Linux software development has largely still been based on Qt4 and Qt5. So, what, you may ask?

Firstly, while it is still possible to develop applications using Qt4 on a Debian 8 or Debian 9 system, switching to using it is not as easy under Linux, as it is under Windows. When using the ‘Qt SDK’ under Windows, one installs whichever ‘Kit’ one wants, and then compiles their Qt project with that Kit. There could be a Qt4, a Qt5 and a Qt6 Kit, and they’d all work. In fact, there is more than one of each…

Under Linux, if one wants to switch to compiling code that was still written with Qt4, one actually needs to switch the configuration of one entire computer to Qt4 development, by installing the package ‘qt4-default‘. This will replace the package ‘qt5-default‘ and set everything up for (backwards-oriented) Qt4 development. Yet, Qt4 code can still be written and compiled.

And So, my reader might ask, what does this have to do with Aqsis, and potentially not being able to use it anymore?

Well, there is another resource known as ‘Boost’, which is a collection of Libraries that do many sophisticated things with data, that do not necessarily involve any sort of GUI. Aqsis happens to depend on Boost. But, there was one component of Aqsis, which was the program ‘piqslr‘, the sole purpose of which was, to provide a quick preview of a small part of a 3D Scene, so that an artist could make small adjustments to this scene, without having to re-render the whole scene every time. Such features might seem minor at first glance, but in fact they’re major, just as it’s major, to have a GUI to gestalt the scene, which in turn controls a ray-tracing program in the background, which may not have a GUI.

Well, ‘piqslr‘ was one program, that requires both Boost and Qt4. And, Qt4 is no longer receiving any sort of development time. Qt4’s present version is final. And, all versions of Qt need to feed their C++ source code through what they call a “Meta-Object Compiler” (its ‘MOC’). And ‘piqslr‘ needed to have both the header files for Boost included in its source code, as well as being programmed in Qt4.

Qt4’s MOC was still able to parse the header files of Boost v1.55 (which was standard with Debian 8) without getting lost in them. But if source code includes the corresponding header files, for Boost v1.62 (which became the standard with Debian 9), the Qt4 MOC just spits out a tangled snarl of error messages. I suppose that that is what one gets, when one wanted to modify the basic way C++ behaves, even in such a minor way.

And so, what modern versions of Aqsis, which are included in the repositories, offer, are the programs that do the actual ray-tracing, but no longer, that previewer, that had the program-name ‘piqslr‘. I suppose this development next invites the question, of who is supposed to do something about it. And the embarrassing answer to that question is, that in the world of Open-Source Software, it’s not the Debian – or any other, Linux – developers who should be patching that problem, but rather, the developers of Aqsis itself. They could, if they had the time and money, just rewrite ‘piqslr‘ to use Qt5, which can handle up-to-date Boost headers just fine. But instead, the Aqsis developers have been showing the world a Web-page for the past 5 years, that simply makes the vague statement, that a completely new version is around the corner, which will then also not be compatible with the old version anymore.

(Updated 5/21/2021, 19h15… )

Continue reading What’s what with the Aqsis Ray-Tracer, and Qt4 project development 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’.