Difference between revisions of "Amira Quirks"

Latest revision as of 19:41, 17 June 2009

Root Directory Saving Problem

You SHOULD NOT save any network under the root directory of a drive.

For example, if your USB drive is located at E:\ do not save at E:\ directly but in a folder beneath E:\ like E:\Amira\ or any other name.

Why is this happening?

You need to understand Amira network structure first.

...so what happen if you do save it there?

Let's say you have a network called "test.hx" that loads three files a.am, b.am, c.am that are located in the data directory of the same network ("test-files" folder)

Well, when you save at NON-ROOT directory, you get correct relative referencing of the .hx network by loading the data modules at the proper RELATIVE locations. Eg. "test.hx" will load "test-files\a.am" "test-files\b.am" "test-files\c.am" with REFERENCE relative to the .hx file location PROPERLY.

However, if you save at the ROOT directory, you will only get PRECISE definition of the .hx network. Eg. "test.hx" will now attempt to load "C:\test-files\a.am", "C:\test-files\b.am", "C:\test-files\c.am" with ABSOLUTE path definition and result in file problem once you copy the networks around since it will always look for the file in those SPECIFIC locations (C:\test-files\).

Save Network

Another key issue you need to be careful is how you save your network. ALWAYS save as "Pack and Go".

Why is this happening?

All data modules are saved seperately. However, if you loaded the data module from elsewhere (eg. recycling an existing .surf or .am file from other networks), you need to save your OWN copies of it instead of relying on the reference to the source.

...so what happen if you don't save it as pack and go?

Let's say you have a network called "test.hx" that loads three files a.am, b.am, c.am that are located in the data directory somewhere else in the master database in server (eg. Z:\Database\).

Well, when you save without using "pack and go", every time you load up the network, you are still attempting to load the data from Z:\Database. This is even worse when you might accidentally mess up the source data by overwriting them (hopefully, i should already placed READO NLY there). So when you move your network around, you will get error and no data loaded if the new location does not have access to Z:\Database. Eg. "test.hx" will load "test-files\a.am" "test-files\b.am" "test-files\c.am" with REFERENCE relative to the .hx file location PROPERLY.

However, if you save using "pack and go", all externally loaded data file will be saved at "test-files" folder and hence not absolutely loading from any other places. This ensures you have proper portability of the file and will not run into problem when loading it on the presentation machine (Shuttle, or cube)

Amira 5 Raw Data Read Problem

If you try to open up slice based RAW file in Amira 5, good luck. It will attempt to load individual RAW file as a GREEN data module and give you nightmare over segmentation and etc etc. Avoid at all cost

Why is this happening?

Since Amira 5, the loading function within Amira was re written probably and this key feature was either immediately forgoten or integrated into specific loading functions that I have not yet found out about yet.

Work Around

Load the slice based RAW .dat file (can actually have any extension. .dat is common) in Amira 4. Amira will load all the raw data first before attempting to ask for dimension, coordinate etc etc. Save the raw data as a .am file and load the whole thing again in Amira 5 to minimize problem. Small issue, just annoying as hell.

Broken Surface Problem

Ever produced a surface and only realize that it is SO broken just because it is touching other surface generated?

Two ways to fix them for two different purposes:

1. If you are just using Amira: Attach a new surface view module. Ensure selection mode is "Material". Ensure that the first box of port "Materials" is selected to the structures you WANT. For the second box, make sure it is listed as ALL. Now, you should SEE your structures highlighted in RED. If not, try click on "Show/Hide" button once. Now once it's shown, click ADD to show those in clear surface renderings.

2. If you are using these surfaces for any kinds of rendering purposes: In the console window, type in: "XXXX.surf makeOnePatch" replace XXXX.surf with your own Surface file name with extension (the green module name). This puts all triangles of the surface into a single patch but may NOT be the original color you have planned. HOWEVER, since export, you rarely do your coloring in Amira so that is usually not an issue (recolor texture in Maya, etc).