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.

Something Discouraging, When Using ‘Ayam’

One of the subjects which I have written about, here and here, is that I seem to like the Open-Source application named ‘Ayam‘, as a potential way to create images, which are 2D perspective views of a virtual 3D scene. This program just might do for me, what the proprietary program ‘Bryce’ once did for me, under Windows.

But obviously it’s harder to use Ayam, to create any meaningful images. And one reason seems to be, that doing so requires we define explicit, simulated light-sources, and the fact that there are no defaults, that would set up these light-sources, with parameters, that lead to good images.

I.e., the program will compute per-pixel color-values, that are derived from the positions, geometries, and intensities of the light-sources, but with no advanced warning to the user, of what intensities he needs to give his light-sources, so that the pixel-brightness values are in-range.

Usually, if we begin by rendering a cube, and we find that it renders, but only as a black outline, against a transparent background, then we may have everything set up correctly, except for the intensity of the light-source. It might just take some trial-and-error, before we set that correctly. And what I have found is that on their arbitrary scale, an intensity of 16 or so, just works well, in experimental scenes I’ve created.

At the same time, ‘Ayam’ has a specific idiosyncrasy to its GUI, which I rather appreciate. Its many numeric parameter-widgets have an arrow to the right of them, and an arrow to their left, which respectively, increase or decrease the value in the numeric field. The way these little buttons work, is either to double or halve the value they alter.

I suppose this could confuse some first-time users, because the numeric value in the field defaults to zero. This means that to click on the buttons does not alter the value, because to double or halve zero, results in zero. But what we can do is type a (+1) or a (-1) into the numeric field, and then, if we find that the parameter in question isn’t even close to where it’s supposed to be, we can repeatedly use the buttons, until we either find that (+16) is approximately correct, or until we find that (+0.0625) is about correct… The users just need to remember that after choosing widget-settings, we must also click to ‘Apply’ those settings before moving on, or else ‘Ayam’ will tend to forget them.



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

An Observation about NURBS

Given that the reader probably understands more about the Math of NURBS than I do, the reader will also understand that in general, true NURBS Curves will not touch their control-points. My own earlier misperception of that subject came through the use of the (now-defunct) application ‘TrueSpace’, which arbitrarily labeled objects as NURBS, which were really not that.

It should also be understood, that classic cubic (Bézier) splines were not NURBS either. According to my own understanding, a classical, cubic Bézier spline had as basis-function:


v = ( 1 - u )
a = a30u3 + 3a21u2v + 3a12uv2 + a03v3


This is different from the basis-function of a NURBS Curve. But for certain types of 3D graphics, an exact curvature and therefore basis function, is not needed(, and the two ways of formulating this curve may even have the same result – which I could not prove).

Given this understanding, a question might arise as to why the actual application “Ayam” is capable of taking an arbitrary CSG-primitive, and converting that into a NURBS-Patch.


And there are really several separate cases, in which this is possible:

(Last Updated 12/02/2017, 13h10 : )

  1. The Order of the NURBS may only be 2, given that the application in question has fully-general Math to work with NURBS. In that case, by default, the position of 1 point along a curve will be determined by 2 adjacent Control-Points, and at one exact parameter-value, will be controlled by only 1 Control-Point. This is a simpler type of NURBS, which will show as straight lines between the CPs, and which touches each CP. It’s useful to convert a Cube.
  2. True NURBS have a Knot-Vector, which states possible repetitions (“Multiplicity”), and Which the application in question does implement. When the Knot has a Multiplicity equal to the Order of the NURBS Curve, it takes over the position of the Curve completely. However, a given set of three NURBS Control Points can form a linear, equidistant sequence, with one Knot having a Multiplicity equal to the Order minus one. The two NURBS CPs that form the endpoints (of this sequence) can correspond to the ICurve Handles, while the NURBS CP in the middle can correspond to the ICurve CP. What will happen is that the NURBS Curve will touch the CP in the middle, but not the ones at the ends. This is similar to how a circle is formed, with an Order of 3.
  3. As an example of the type of spline described in item (2) above, if the Order is 4 – implying a cubic spline – and if it has its minimum of 4 ICurve Control Points, then the corresponding NURBS Curve will have 10 Control Points, and a Knot-Vector of { 0, 0, 0, 0, 1, 1, 1, 2, 2, 2, 3, 3, 3, 3 } . Please bear in mind that in general, the Knot-Vector may be scalar-multiplied by an arbitrary constant, and have the same meaning. ‘Ayam’ tends to scale its -Vectors such, that their range is [ 0.0 … 1.0 ] . Either way, the range corresponds to the range, which the continuous parameter needs to traverse, until the entire Curve is drawn.
  4. A NURBS-Surface – i.e., a -Patch – is a special case derived from a Curve, that has the two parameters U and V, where a Curve only used to have one parameter. The CPs are sometimes conceived to form a grid with rectangular topology. It seems entirely plausible to me, that the Order along U may be different from the Order along V, and then having a linear Order along one parameter, may be the correct way to convert a Cylinder or a Cone. In that case, a Disk may simply be a special case of a Cone, where one parameter forms a circle, and the other, linear parameter defines either the radius or the height – with a single CP defining either the center or the vertex.
  5. Most plausibly, if the NURBS-Patch is to have a different Order along U from its Order along V, it should also have two separate Knot Vectors.
  6. It was a convention of certain software in the past, that a Control-Point which the curve is actually supposed to touch, simply continue to be named a ‘Control-Point’, but that the Control-Points which define the derivative with which the curve passes through these Control-Points, be named ‘Handles’. Certain other references define the CPs which the curve is supposed to touch, as the ‘End-Points’, even if they get reused by two segments of the Spline. In reality, when dealing with NURBS, all forms of such points are still ‘Control-Points’, but in this posting I’ve chosen to name the CPs which the curve is not supposed to touch, ‘Handles’, in keeping with software-conventions I’m familiar with.

‘Ayam’ is an application that will allow its users to edit the Knot-Vector manually, if we switch to the “Custom” Knot-Type. However, if we’re experimenting with this randomly, we may easily create Knot-Vectors which the Ayam can’t render, thereby resulting in some error messages. Finally, I was able to implement my above idea in full:


This screen-shot actually reveals that ‘Ayam’ is not always able to determine what the correct increment is, of its parameter, for the Curve always to appear smooth. However, because this application’s preview panels are just that, and because final rendering is meant to be performed by an external renderer, I don’t mind.

The WiKiPedia article explains, that in order for a 3rd-order NURBS Curve to form a circle, its Knot-Vector should be:


But the same article also explains,

“For the purposes of representing shapes, however, only the ratios of the difference between the knot values matter; in that case, the knot vectors (0, 0, 1, 2, 3, 3) and (0, 0, 2, 4, 6, 6) produce the same curve.” (Both quotations from 08/29/2017. )

So while it may have been important to prove the above Knot-Vector, in ways that involve the constant π, according to the same reference, the entire Knot can be multiplied by ( 1 / 2π ), revealing a linear spacing between Knot-Values.

In my own example with 4th-order NURBS Curves, my only aim was that the handles around each control-point, that would have corresponded to a12 and a21 in the case of a Bézier spline above, and which I tend to denote with the character H, form working handles around each control point, which I tend to denote with the character P. I never aimed to prove that the resulting NURBS Curve forms an exact geometry.


Continue reading An Observation about NURBS