Away3D offers the CompositeMaterial class that allows to combine different material layers into one, using different compositing modes. (Note that this applies to Away3D 3.4; in version 2.4, the concept is split so that you have a class BitmapMaterialContainer additionally, which is only for cached materials, that is those that are not changed once applied.)

In my experiments I found that one can get some surreal, crazy materials by combining a texture with a “shade” in strange ways:

var textureMaterial : BitmapFileMaterial = new BitmapFileMaterial(imageUri, {precision: 0, repeat: true, smooth: true, blendMode: BlendMode.NORMAL});

var shadeMaterial1 : PhongColorMaterial = new PhongColorMaterial(0xffffff, {shininess: 5, specular: 0.5, alpha: 1, blendMode: BlendMode.DIFFERENCE});

var shadeMaterial2 : PhongColorMaterial = new PhongColorMaterial(0xffffff, {shininess: 5, specular: 0.5, alpha: 1, blendMode: BlendMode.LIGHTEN});

var crazyMaterial1 : CompositeMaterial = new CompositeMaterial({alpha: 1, color: 0xFFFFFF});

crazyMaterial1.addMaterial(textureMaterial);

crazyMaterial1.addMaterial(shadeMaterial1);

var crazyMaterial1 : CompositeMaterial = new CompositeMaterial({alpha: 1, color: 0xFFFFFF});

crazyMaterial1.addMaterial(textureMaterial);

crazyMaterial1.addMaterial(shadeMaterial2);

Task

I had to run existing ActionScript code on a headless Linux server and decided to do it by running an AIR application with the Xvfb virtual X server, as reasoned for in my article “How to run ActionScript in headless mode (on Linux without X server)?“.

Problem

I did not think that running an AIR application on a headless server would be that large a problem. Here is why it is:

• The normal Adobe AIR 1.5 runtime installer is a GUI-based installer, no RPM oder DEB packages are available.
• The normal process of installing an AIR application is also a GUI-based process, so not apt for a Linux headless server.
• AIR applications itself are GUI-based, always needing an X server. See more on that in this article already linked above.

Discussion

In theory, installing the AIR 1.5 runtime and the AIR application would be possible via VNC or some Xvfb hacking to enable a remote desktop. In practice, I searched for a better solution.

There are two options; first, the headless installation of Adobe AIR 1.5 Runtime if you grab the version you get after applying to distribute AIR. Second, Adobe AIR 2.0 (in beta as of 2010-05-10) offers installation packages for various Linux systems. You can download Adobe AIR 2 Runtime beta Linux packages from Adobe labs. This enables headless installation with ease. The exception is if you are on a 64bit Linux system, in which case you need to follow along the well-done article “Install Adobe AIR 2 on 64-bit Linux distributions” from Adobe.

However, this approach faces another problem: AIR applications normally come in .air files, and these files cannot be installed on a headless server with a AIR Runtime – normally. The only exception is when using a special installer made available by Adobe after successfully applying for a AIR Runtime redistribution licence [source]. You can apply to distribute AIR (as already linked above). The bad thing is that, at least currently (2010-05-10), a redistribution installer is not available for Linux, and it is not allowed to modify another redistribution installer for that purpose; see the Adobe AIR Runtime distribution FAQ on “Can I distribute the Adobe AIR Runtime on an operating system if a version specific to that OS is not provided?“. So the “Adobe AIR Application Installer -silent file.air” option is not possible on Linux. (If you try that with the standard AIR installer, it says “install failed (see log)”, but even after enabling AIR logging, the log stays empty.)

The solution that I found is to deploy not the .air file but the .swf file and application .xml file that are generated during development in the bin/ output folder. These can be launched with the Adobe debug launcher (the adl command). And adl comes within the Adobe AIR SDK, which is installed by just unpacking, very apt for a headless server. Note: you do not need to install the Flex SDK also if you just want to run an AIR application this way.

By deploying the compiler output directly, we also get around the process of creating the and signing .air installation file. In case you need to do that anyway:

• First try out the FlexBuilder integrated wizard along the Adobe instructions “Creating your first Flex AIR application in Flash Builder or Flex Builder: Package, sign, and run your AIR application“.
• If that fails and you are given a strange error code, have a look at the ADT error messages.
• If that didn’t help either, follow instead the Adobe instructions “Creating your first AIR application with the Flex SDK: Create the AIR installation file“. That finally worked for me.

The last problem is that running an AIR application on a headless server needs an X server in any case. We want to use the Xvfb virtual X server, as already reasoned for in my article “How to run ActionScript in headless mode (on Linux without X server)?“. Brett Adam designed and shared a simple Xvfb wrapper for running an AIR application with Xvfb. It turned out however that the program xvfb-run, coming with Xvfb at least in the Ubuntu 9.10 package, does exactly the same job and offers also more options; so we stick with that.

Solution

Here is a combined list of instructions how to get all this to work, according to the decisions outlined in the discussion section:

1. Download the Adobe AIR SDK to your server. Download the Adobe AIR SDK manually and upload to your server, or better use:

   wget http://airdownload.adobe.com/air/lin/download/latest/AdobeAIRSDK.tbz2;

2. Install Xvfb. On Ubuntu systems, install the packages xvfb and xauth for that.
3. Install the Adobe AIR SDK on your server:

   mkdir /usr/local/share/applications/air-sdk-1.5;
   cd /usr/local/share/applications/air-sdk-1.5;
   tar xjvf AdobeAIRSDK.tbz2;
   ln -s /usr/local/share/applications/adobe-air-sdk-1.5/bin/adl /usr/local/bin/;
   ln -s /usr/local/share/applications/adobe-air-sdk-1.5/bin/adt /usr/local/bin/;

4. Upload your AIR application to your server (just the .swf and .xml file in you project’s bin/ folder).
5. Launch you application with xvfb-run:

   xvfb-run -e log.txt --auth-file Xauth --server-num=99 adl Application-app.xml

6. If you need to run your applications with arguments, do it like this:

   xvfb-run -e log.txt --auth-file Xauth --server-num=99 adl Application-app.xml -- --arg val

7. If you need to keep Xvfb running (e.g. because you need to start the AIR application many times and want to get rid of the 3s delay to start Xvfb every time to improve performance), here is a technique for that. It is re-using xvfb-run, letting it run a command that never returns, and then lets other applications connect to the started X server:

   xvfb-run -e log.txt --auth-file Xauth --server-num=99 sleep 1000d &;
   DISPLAY=:99 XAUTHORITY=Xauth adl Application-app.xml -- --arg val

The compiler is not able to do incremental compilation (at least not when used by Flex Builder 3.0 Alpha for Linux). So it compiles all project sources on every build, including all included classes. The only exception is classes that are included from SWC libraries: SWC libraries are not re-compiled on every build. So if you compile all external referenced third-party classes into SWC libraries, and also perhaps the already finished components of your own project, you can greatly increase build speed. Just remember, if file size of the final SWF file matters to you, do the last build before real-world deployment with including classes from ActionScript source files instead of libraries, as including a whole library will include many unused classes.

When using these instructions, Flex Builder for Linux 3.0 Alpha might temporarily not be able to present code suggestions (like code completion on Ctrl+space) to you from the code that you now include as a library. But it is able to do so without regard to how you add third-party code to use in completion (library or source path). To correct this issue, in the project properties in “ActionScript Build Path: Library Path”, delete the library entry and add it again (as a ActionScript Library Project or SWC, last position is fine).