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 08/19/2017, 19h55 )

 


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$

/usr/local/ayam/bin/plugins/loadayslx.tcl

/usr/local/share/aqsis/shaders/*


 

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.

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

ayam_4

ayam_5

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.

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.

(Edited 08/22/2017 : )

This needed to be corrected with the following Aqsis settings, 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.

 

Print Friendly, PDF & Email

One thought on “Widening Our 3D Graphics Capabilities under FOSS”

Leave a Reply

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

Please Prove You Are Not A Robot *

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>