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

(As of 5/21/2021, 14h00: )

This leaves Linux maintainers in the lurch, because the Linux maintainers do not own the software project. If the Aqsis developers want to go closed-source with their next version, for examples, they can simply do so. And then, suddenly, programs such as Ayam become much less useful. In fact, another program becomes less useful, which is called ‘K3d’ – which also just happened to depend on the open-source version of Aqsis, without having any say in turn, about what the Aqsis developers are to do next.

One result this has had is, that the only true, full-featured GUI for 3D Art that remains, seems to be “Blender”. And this is not the fault of either ‘Ayam’ or ‘K3d’ developers, only the fact being their fault, that they both depended so strongly on Aqsis.

(Update 5/21/2021, 17h10: )

Mind you, what any self-respecting Linux user will do in response to such a setback is, to acquire a newer tool, to do what the older tool is no longer able to do. And one form that such a response could take is, to download the latest version of “White Dune”, either from within the package manager, or, from the project’s Web-site. If the user is based on an outdated Linux version like mine, such as Debian 9, then the only option is to custom-compile it, because the binaries will require a higher GLIBC version, than Debian 9 computers have. And, on the assumption that the project would be compiled against the repository version of ‘CGAL’, he or she will find that with Debian 9, that library version is not high enough, therefore having to disable the feature. It would create a bigger mess, if the user additionally custom-compiled that library; it really needs to be consistent with what the repositories have to offer. And then, the penalty for disabling ‘CGAL’ support is, that the modelling program does not have “Constructive Solid Geometry” (‘CSG’).

In other words, with what I just custom-compiled, I’d like to be able to subtract the sphere from the box, but cannot, because of this deficiency. If my reader has an up-to-date computer, then they will be able to do so:

One interesting development in this area has been, that scenes such as these can be uploaded to a Web-server, in the form of relatively compact HTML Files, using ‘X3DOM’ Format. This would have as advantage for smaller users like me, that the uploaded files do not need to be very large, because they will also require that the browser have JavaScript etc. enabled, for the domain ‘x3dom.org’, the operators of which can do the heavy lifting of supplying the WebGL Data File. So, this petty little exercise can be viewed in an up-to-date Web-browser, which additionally has JavaScript enabled from my site:

http://dirkmittler.homeip.net/WebGL/wdune_1.html

One peculiar bug which White Dune still has in this form seems to be, that such an export to an HTML File, only works once per session.

(Update 5/21/2021, 19h15: )

What I should also mention is, that before compiling “White Dune”, I compiled ‘OpenSubdiv’ and installed that to my system folders, after making sure that Debian 9 did not offer a version of it in its repositories. If this library was not installed, White Dune would be compiled without it, and in my case, would lose even more functionality.

Dirk