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

I have sad news for the reader. What the professional maintainers cannot do, I cannot do either. So my custom-compiled version of Aqsis, still does not have its Qt-feature enabled, and therefore still does not offer me previews. But, from within Ayam, I can get the ‘Render To File’ feature working, and can view the resulting .TIFF-Files using ‘ImageMagick’, within just a few more mouse-clicks.

(Edit 12/12/2017 : Contrarily to what I first intended, at the bottom of this posting, I’m going to give some details, about how to custom-compile Aqsis… )

But what are the advantages to me, of having done this? I’ve compiled Aqsis with some other features enabled, which are deemed either experimental, or non-essential, by the package-maintainers:

  • OpenEXR‘-Support, which is for Extended Dynamic-Range Images. I.e., for 16-bit, half-precision, floating-point pixel-depth. Ayam won’t invoke this. But for some hypothetical usage, it might be interesting. If the package-maintainers had built this feature, it would have added a dependency.
  • Multi-Threading support, which the maintainers deem Experimental, and which could cause complaints about lack of stability from some users.

Having this installed on an octa-core machine, I can appreciate that the software was somewhat pointless out-of-the-box, because any serious graphics work would benefit from multi-threaded rendering!

And everything works – again. That’s all I have to show for it! :-)

aqsis_1

 

(Edited 18h00 Same Day : )

When users try to render an Ayam-scene to an OpenEXR-File, by editing the RIB-File which gets sent to Aqsis, with a Text-Editor, then there are some difficulties to point out, as I’ve just discovered.

Assuming that the brightness values are correct when the TIFF-File is first rendered, not only does the RIB-File Format line need to be changed to:

 


Display "exr_test_2.exr" "exr" "rgba" 


 

But we can also not assume, that ‘Quantizing’ can just be forgotten. Instead, we must give Aqsis the parameters:

 


Quantize "rgba" 0 0 0 0


 

Thereby switching quantization off explicitly, because we’re using half-precision floating-point numbers, where they used to be

255 0 255 0.5

After that, my attempts to view the EXR-File succeeded, using ‘Krita’. :-)

screenshot_20171207_175502

 

(Edit 12/08/2017 : )

More serious use of OpenEXR-format does not only require that we achieve the basic format, but may also suggest, that we compress the resulting OpenEXR-File in some way. Well, the format allows for RLE (Run-Length Encoding), plus, ‘Aqsis’ specifically offers support for it, with the following extension of the previous example:

 


Display "exr_test_2.exr" "exr" "rgba" "string compression" "lzw"


 

In my experience, the EXR-File which results may be half the length, and ‘Krita’ will display it exactly as above, because under Linux, the library for OpenEXR-support is system-installed. Under Linux, the key question is whether Aqsis offers the semantics, for the correct syntax in the RIB-File.

The success of this exercise suggest, that instead of storing them pixel-by-pixel, the EXR-File stores each channel-plane by itself, and then the values as if characters belonging to the given plane.

If given a much-more-rich type of image-file – i.e., a picture that has fine details filling most of its surface – then RLE will not compress it as much. But in such cases, the Alpha-channel is likely still to contain uniform surfaces, which RLE should compress fine.

(Edit 12/12/2017 : )

When I download and custom-compile source-trees, those source-code archives usually involve one out of two, commonly-used build-types:

  1. They can be prepared for compiling under Linux, by running the command ‘./configure’ in the root of the source-directory-tree, or
  2. They can involve the use of ‘cmake‘.

‘Aqsis’ is an example of a project, whose source-code has been prepared to use ‘cmake’. First of all, to get the most-up-to-date source code, I used the git-repository linked to here, which requires that we have ‘git’ or ‘svn’ installed on our computers. ‘svn’ stands for ‘Subversion‘, and it’s one of several tools which can allow users to download the most-up-to-date version of any source-code.

Next, typically for how cmake works, we create a sub-directory of the main source-directory, and arbitrarily, I name this sub-directory ‘build’. I then ‘cd’ to this directory, and run either ‘ccmake’ or ‘cmake-gui’.

The way cmake works, we can have one version of the source-code, and its cmake configuration, in one source-directory, but when we configure the project with ccmake or cmake-gui, a local configuration of the build process will be stored in another directory, which in my case is usually the ‘build’ sub-directory. Then, building or reconfiguring the project within the sub-directory, has no effect on the source-code stored in the source-directory, and it would even be possible to create several build-configurations, of the same source-directory, but each stored in a different sub-directory. In practice, I only need 1 build-configuration.

The advantage to using ‘ccmake’ or ‘cmake-gui’ over simply using ‘cmake’, is that we can customize certain features of the project to be built, or not to be built, contrarily to how this would be set by default. So in this case, to build with OpenEXR support, with threading-support, but without Qt-support, were options which I specified in ‘cmake-gui’.

In that GUI, I needed to specify that I wanted “Unix Makefiles” to be generated, which we can also do on the command-line with the -G option, like so:

ccmake -G “Unix Makefiles”

If the reader is interested in compiling a Windows version of this project, then he might specify to have the Visual Studio Solution generated instead, like so:

ccmake -G “Visual Studio 12 2013″

or,

ccmake -G “Visual Studio 8 2005″

At that point, our cmake GUI will allow us to give two commands in sequence

  1. Configure
  2. Generate

After Configuring has determined that all our prerequisites are installed, Generating is supposed to generate, either the Makefiles, or the Visual Studio Solution, or whatever else we’ve chosen to generate.

Note: cmake is not a compiler. We need to have, whichever type of compiler installed, so that we can then use the Makefiles, or the Visual Studio Solutions, in order actually to compile the project. After setting up the project in cmake, configuring, and generating, we must therefore either run

  • ‘make’ and ‘make install’
  • …or, run Visual Studio, to compile the project !

With ccmake or cmake-gui, for this project, we actually need to open the Advanced Configuration view, i.e. while Configuring and before Generating, because this project has a glitch, as it was stored in the Git-repository.

Normally, when we next run ‘make’ and then, as root, ‘make install’, the project should be installed and ready-to-run. 95% of the time, that is my experience. But in my example this was not so, and there were two complications which made it not so:

  1. Aqsis needs to have a configuration-file stored in the directory ‘/etc/aqsis’, and
  2. My desktop would only display the file-associations correctly, i.e. offer me to Aqsis-render a RIB-File, just by clicking on it, if its mime-database was updated next, to reflect the new associations.

Problem (1) had as its cause, the fact that in the advanced configuration view, the variable:

SYSCONFDIR

…had mistakenly been set to

etc/aqsis

I assume that this was due to a typo, and it may not stay that way for very long. The problem is, that as long as my Prefix is set to ‘/usr/local’, the above mistake will actually install the configuration-file to

/usr/local/etc/aqsis

Which is completely wrong. What needs to be done correctly, is that this variable needs to be set to

/etc/aqsis

…where, the program has been written, to look for its system-wide configuration-file. In my case, I was able to make up for this error instead, by just creating the directory as part of the root file-system, as root, and then just copying the file ‘aqsisrc’ from the build-directory, where the ‘cmake’ configuration-process created it, to this directory, as root.


 

Problem (2) was a more-universal issue. The desktop-configuration will only be updated, while our newly-installed project has as its prefix ‘/usr/local’, If we next run, as root,

update-mime-database /usr/local/share/mime

This last step is something which the post-install process would normally do, but because we’re not installing anything from the package-manager, we need to do it ourselves, as root, because the package-manager is run as root.

There is a complementary post-install which we’d need to run as root, which is the command:

update-desktop-database

…run on directory:

/usr/local/share/applications

Simply relying on our next use of the package-manager to install software will not take care of this, because package-installed software has as its prefix:

/usr

…and not:

/usr/local


 

If we did everything correctly, then we should be able to use Aqsis, as we configured it to work.

Dirk

 

Print Friendly, PDF & Email

2 thoughts on “I’ve just custom-compiled ‘Aqsis’.”

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>