# Widening Our 3D Graphics Capabilities under FOSS

Just so that I can say that my 3D Graphics / Model Editing capabilities are not strictly limited to “Blender”, I have just installed the following Model Editors on the Linux computer I name ‘Klystron’, that are not available through my package-manager:

I felt that it might help others for me to note the URLs above, since correct and useful URLs can be hard to find.

In addition, I installed the following Ray-Tracing Software-Rendering Engines, which do not come with their own Model Editors:

Finally, the following was always available through my package manager:

• Blender
• K-3D
• MeshLab
• Wings3D

• PovRay

In order to get ‘Ayam’ to run properly – i.e., be able to load its plugins and therefore load ‘Aqsis’ shaders, I needed to create a number of symlinks like so:

( Last Updated on 10/31/2017, 7h55 )


dirk@Klystron:/usr/local/ayam/bin/plugins$ls -l libboost* lrwxrwxrwx 1 root root 48 Aug 17 09:20 libboost_filesystem.so.1.49.0 -> /usr/lib/x86_64-linux-gnu/libboost_filesystem.so lrwxrwxrwx 1 root root 47 Aug 17 09:21 libboost_iostreams.so.1.49.0 -> /usr/lib/x86_64-linux-gnu/libboost_iostreams.so lrwxrwxrwx 1 root root 43 Aug 17 09:21 libboost_regex.so.1.49.0 -> /usr/lib/x86_64-linux-gnu/libboost_regex.so lrwxrwxrwx 1 root root 44 Aug 17 09:19 libboost_system.so.1.49.0 -> /usr/lib/x86_64-linux-gnu/libboost_system.so dirk@Klystron:/usr/local/ayam/bin/plugins$




Whenever installing binaries out-of-tree, having to make such adaptations is not uncommon, under 64-bit Debian Linux, and given where that puts certain libraries.

(Edit 10/31/2017 :

Because I’m working on upgrading some of my computers from Debian / Jessie to Debian / Stretch, I’m also doing experiments to see whether I can get ‘Ayam’ and ‘Aqsis’ running together, under Debian / Stretch again, as well as they worked under Debian / Jessie.

Debian / Stretch is still a bit unstable, and under development.

It seems that the programmers of Aqsis have specifically improved it, so that certain bugs which I had noticed under Jessie, are fixed under Stretch. However, the way in which the upgrade has taken place has also damaged the compatibility strongly, with old software, such as Ayam. Ayam really counts as quite old by now.

Some of the fixes below would break Aqsis under Debian / Stretch, but are thankfully also no longer required.

But because its automation is now broken, when invoked by Ayam, the procedure to get Ayam to output actual images has changed for now.

What we must do under Debian / Stretch, is first instruct Ayam to Create All Shadow Maps, after exporting our View to an .RIB File. And then, we must click on the actual .RIB-File itself, to get Aqsis to run outside Ayam, at which point it might render the final image, if we’re really lucky.

The biggest problem with all this is, that we would not just be rendering one image. Every Shadow-Map is a distinct rendering, which Ayam expects to receive both as a Z-File from the perspective of the camera light-source, as well as in TIFF-File Format, but to receive as .SHD-Files, in the perspective of the final view, which are then used to render the final image. I.e., if the automation is broken, in many cases there may be no way just to click on one RIB-File, to obtain one final, rendered image.

Oops.

In practical tests, what I found was that if I clicked on the main RIB-File, which Ayam had exported with Aqsis as its rendering engine, Aqsis would also render the .SHD-Files recursively, which the final rendering – a .TIF-File – depended on. But I cannot be certain that this will always work, because for the moment, I was running into multiple errors that needed to be identified, just to get a basic exercise working. )

But in addition, once able to run the application through its GUI, I also needed to tell the application to auto-load a plug-in, by going in to:

Edit -> Preferences

And specifying the Script to auto-run, which I’ve identified above on Line 9. And, so that Ayam would know to look for the shaders supplied with Aqsis specifically, I also had to define in the Preferences – again, through the GUI – the location of 46 Aqsis shaders in total, by stating each subdirectory separately, defined on Line 11 above.

These are all software-shaders, the file-names of which end in ‘.slx’ .

Furthermore, I have carried out a random exercise with Ayam, which I wrote about in This Page.

Sincerely,

Dirk

(Edit 08/19/2017 : )

During my experiments with ‘Ayam’, in connection with the software ray-tracer ‘Aqsis’, I discovered three bugs, essentially:

1. The corrupted TIFF Files when Rendering To File.
2. The Incorrect PWD Bug, when Opening a Project directly from the Most-Recents List.
3. When rendering Shadow-Maps, by default, Aqsis was not applying any Bias, to prevent Self-Shadowing Artifacts.

The first problem was the most-difficult to pinpoint. It would seem that every time I told Ayam to render the scene directly to an Image File, it would start Aqsis, a TIFF File would apparently be generated successfully, but no software that I possessed could view this basic Image File Format (corrupted). My first workaround was, to output the scene to an RIB (Renderman) File, and then to edit that file with a text-editor, to generate a .BMP Image File instead, which could be viewed, once I told Aqsis to render the RIB File.

The real culprit behind this problem seemed to be, that according to the Preferences controlled within Ayam, the rendering of the scene To a File was set to show me a GUI – A Progress Indicator – using full graphics. When I deselected this feature within Ayam – to show a Progress GUI – Aqsis started to produce TIFF Files that were correct and not corrupted. I don’t really know where in the code such an error could take place, but this simple measure put an end to corrupted TIFF Files coming out of Aqsis, for me (under Debian / Jessie).

(Edit 10/31/2017 :

Under Debian / Stretch, due to updates made to ‘Aqsis’, the behavior seems to be the reverse. Here, the Progress-GUI-Box must be shown, in order for any of the software renderings to succeed, including actual renderings as well as shadow-maps. Again, this can be arranged in ‘Ayam’ Preferences.

And additionally, rendering to a ‘piqsl’ preview window no longer works. The need to render the scene to an image-file, seems to be due to an omission of some sort, on the part of Aqsis developers, still to support this preview-window instead. )

This same bug also prevented me from doing my first Shadow-Mapping Exercises, because Shadow-Maps are also rendered, by Aqsis, directly To a Z-File, while Showing the Progress-GUI, so that later attempts to show the scene correctly, would not find any shadow-maps.

The solution to both problems was to un-check the GUI boxes next to the FRender and SMRender Options, within Ayam.

2 ) When selecting the Most-Recently Opened Projects from the Menu within Ayam, Shadow-Maps were also generated but not found. This would happen because Ayam did not have an accurate record, of which project-folder the Most-Recent Project was in, for the purpose of rendering its Shadow-Maps to that folder. What I need to do, is navigate to the project folder at least once, using the message-box within Ayam, and to click on the .AY File from there, and the Shadow-Maps would once-again be saved to the correct PWD – Directory.

3 ) Apparently, Aqsis was defaulting to applying Bias of zero, when rendering Shadow-Maps, which resulted in apparent dimples in the flat surfaces of models, due to those surfaces casting shadows on themselves (Apparently, this problem was solved under Debian / Stretch, without requiring any measures from the user.)

(Edited 10/31/2017 : )

This needed to be corrected with the following Aqsis settings, under Debian / Jessie, in the file ‘.aqsisrc’ :


dirk@Klystron:~$cat ~/.aqsisrc Option "display" "string file" ["file_dspy.so"] Option "display" "string framebuffer" ["piqsl_dspy.so"] Option "display" "string zfile" ["file_dspy.so"] Option "display" "string zframebuffer" ["piqsl_dspy.so"] Option "display" "string shadow" ["file_dspy.so"] Option "display" "string tiff" ["file_dspy.so"] Option "display" "string xpm" ["xpm_dspy.so"] Option "display" "string exr" ["exr_dspy.so"] Option "display" "string bmp" ["bmp_dspy.so"] Option "display" "string debugdd" ["debugdd"] Option "display" "string piqsl" ["piqsl_dspy.so"] Option "defaultsearchpath" "string shader" ["/usr/share/aqsis/shaders/displacement:/usr/share/aqsis/shaders/imager:/usr/share/aqsis/shaders/light:/usr/share/aqsis/shaders/surface:/usr/share/aqsis/shaders/volume"] Option "defaultsearchpath" "string display" ["/usr/lib/aqsis"] Option "defaultsearchpath" "string procedural" ["/usr/lib/aqsis"] Option "shadow" "float bias0" [0.01] Option "shadow" "float bias1" [0.05] Option "shadow" "float bias" [0.01] dirk@Klystron:~$ 


One fact which could frustrate the initial attempt to change the Aqsis configuration, was that the newest versions do not even try to read the configuration file, located in ‘/etc/aqsis/aqsisrc’. The best solution is, to copy the file provided there, directly to ‘~/.aqsisrc’, as user, and then to add the values 0.01, 0.05 and 0.01 , in square-brackets, for ‘bias0′, ‘bias1′ and ‘bias’ .

This configuration file actually needs to be located directly in our home-folder, with the dot in front of its name, in order for Aqsis to bother scanning it. Apparently, the source-code of Aqsis now sets the defaults without their being defined in the config file, so that according to some programmers, scanning-in the default-config from ‘/etc/aqsis’ seems unnecessary.

But Under Debian / Stretch, this fix should not be applied. It would break Aqsis.

## 4 thoughts on “Widening Our 3D Graphics Capabilities under FOSS”

This site uses Akismet to reduce spam. Learn how your comment data is processed.