You should see that the Isosurface has the light blue default color. Where did the color come from, class? Yes, Isosurface added it.

So what does the Color module accomplish? Wire it back up and Execute Once. Why does the "interior" of the isosurface object change color? Hint: Open the Color CDB. Hmm, "back colors"? You know how to get Help for a module so you're on your own for the moment.

Doesn't that Help read like an insurance policy? Great stuff, isn't it.

OK, the short answer for the lazy ones who didn't read the Help and for the brain-stunned who did, is that DX supports a notion of "colors", "front colors", and "back colors". This applies to Objects like Isosurfaces that have polygonal surfaces such as quads and triangles. Which face of a polygon is "front" and which "back" depends on the "connections" ordering. Remember the discussion on how vertices connect to make a connection element? It is that order that makes one face "front" and the other "back". It is then sometimes useful to color these faces differently. In this example, it helps us see the inside of the Isosurface better (of course, it doesn't hurt that there are holes to see through).

So Isosurface assigned its baby blue to the "colors" (which includes both "front" and "back" colors), then Color overrode the color for the "back colors" with yellow. Experiment with the "front" and "back" colors to see how this changes the Image.

Now, another thing I want to point out. How many people remember what the Color module looked like, the last time we used one? Anything different here? To investigate this, get another Transformation: Color and place it on the net.

Lo and behold, it's different! One fewer input tabs. What gives?

Open the new Color you just placed and click on the button labeled "Expand". Oh ho! There's more than meets the eye! Now go back and open the Color with 4 tabs showing and figure out how they did that. Try pushing some buttons at random inside the CDB and watch the module in the net. Getting it?

The Expand button appears in all CDBs, though not every module actually has non-visible inputs or outputs. Generally, the hidden inputs are really obscure features that you may never need to change, but if you do need them, it's nice to know how to get to them (they are all documented in the Help). Once you've Expanded a CDB, then you can click Hide buttons on or off. If you play with this, you'll see that the module in the net changes to show the corresponding "unhidden" tabs. Double-check that the tabs that are showing correspond to the unhidden tabs in the CDB by position and name (remember the trick about holding the mouse down on the module's input tab to see the short name?). Then try the Collapse button inside the CDB. Some modules have so many options that a vertical scroll bar appears inside the CDB. Be aware that even after Expanding, you still may not see them all until you stretch the window or scroll down.

My style is to always unhide tabs that I set values for. You will find that it is very difficult to "read" a net if the programmer opens a CDB, sets values internally, then hides the tabs he or she set. After you work with DX for a while, you don't even need to open most CDBs because you know what the default values are (you know they are default cause the tab ears are sticking up). But if you are reading a net and see a tab turned down, you know that value has been "hard-coded" and you'll probably want to check its value to understand how the net has been modified. If you can't see the tab, you may be very mystified about how it works. My philosophy is this: the DX developers added this feature to hide obscure inputs, not to encourage you to hide "normal" inputs. Of course, you may do that, and you may save a bit of space in the display, but it does take more effort to understand a net in which the programmer hides all tabs that don't have wires connected. And, you cannot connect a wire to a hidden tab!

Now, let's consider the other Image with the mottled colors on the isosurface. For the moment, I'll skip how the data was generated, but you can try to figure it out by using Help, including the Application Comment. The point here is that there is a bit of peculiar looking wiring: Colormap and Color are both fed by the output of Map, but in addition, Colormap feeds its two outputs to two inputs of Color.

Take note that all the wiring is flowing downstream. Use the mouse cursor tip to investigate the names of the inputs and outputs of Colormap. Then, double-click on Colormap (on its label as usual). (If you have trouble double-clicking it, click once to select it, then VPE: Windows: Open Selected Colormap Editor(s).)

This time, something unexpected happens (takes a few seconds usually): a new window opens, rather than a CDB. Behold, the Colormap Editor! This is a user interface tool that permits you to modify the relationship between data and colors (and/or opacities). It does effectively what AutoColor did, but AutoColor doesn't let you fiddle with as many options.

The developer of Color.net has already made some edits on the Hue, Saturation, Value, and Opacity curves. You may do any of the following:

• Double-click on a line segment to add a new control point
• Drag any control point around (watch the colormap as you do)
• Put DX into Execute on Change mode, then repeat the last instruction (watch the Image now, as well)
• Double-click on any control point to delete it

And here's one that really makes Colormap powerful: select Colormap Editor: Options: Axis Display, then either Histogram or Log(Histogram). When you do this, the data histogram is plotted within the Colormap Editor along the vertical axis from the minimum to the maximum (bottom to top). Also note that the data minimum and maximum were found in the data and are displayed along the vertical axis. Take a look at the other menu items in the Colormap Editor and you'll discover that you can change the number of histogram bins, set control points at precise locations, and so on.

Now, a note about the wire that connects from Map to Colormap. This is a very powerful instance of a "data-driven" input, a theme that recurs throughout DX. It is possible to run this net without that connection. In fact, you could disconnect the wire now and the net would still appear to do the same thing. But if you do that, the Colormap Editor can no longer see the data (it has no input, after all). Let's say the data set changes tomorrow, when the next experiment is completed. You import the new data, and expect the program to give you another nice image, but the data range is different in the second experiment. Colormap is no longer getting a data feed, so it cannot find the min and max, nor compute the histogram. You may enter values for min and max (good luck on getting them right!), but you still won't get a histogram. By data-driving the Colormap, no matter what the data range of the input, the colors will map to that range (though you may need to adjust the curves for a good fit if the distribution is quite different from the previously mapped data set).

There are times when you don't want to data-drive Colormap Editor. For example, you may want to set a certain color range and distribution because you know all your data sets will work well with those choices, and you want to preserve the mapping of "red" to the maximum value for all data and "blue" for the minimum. If you let Colormap Editor auto-range to the current data, then each data set's max would be red and min would be blue, but data set 1's max might be very different from data set 2's max in absolute values. This could be very confusing to interpret if the viewer of your visualization didn't realize this was happening.

The point here is that the functionality of the Colormap Editor is greatly enhanced when it can see the data and assist you to find the best color fit to that data. After this assistance has been rendered, you may decide to unhook the input to "lock" the colormap you've designed.

There is sometimes an advantage to letting the current data range data-drive the Colormap range even if your input data sets have different ranges. What is it? Answer

Let's consider the inputs to the right-hand copy of Color now. The first input is the data Object that we plan to color, just like on the left-hand side of this net (though of course, you can see that the two Colors are getting different Objects). Unlike the left side Color, in which we hard-coded a single color value ("yellow"), on the right side, the input for Color's "color" input comes out of Colormap's "rgb" output. In fact, this is a type of Object called a "colormap" which consists of three Components we recognize: "positions", "connections", and "data" (plus some others). I don't want to discuss the Colormap Object in more detail, but wanted to let you know that it is an Object not unlike other types of Objects that DX creates and manipulates. In fact, it is just another Field.

Color understands what to do if it receives such a "colormap" Object instead of a single "string" Object ("yellow"), so the actual "colorizing" of the data is done inside Color (not Colormap!), according to the scheme you designed in the Colormap Editor.

Colormap determines the scheme: Color applies it.

Remember the distinction.

Also, in this case, the "opacity" output hooks to the "opacity" input, and the Opacity curve in the Colormap Editor was tuned to the data according to the whim of the programmer. Because Color's opacity input is fed with a variable opacity map, parts of the object are actually more transparent than others. This can be difficult to see when there is only one object in a scene, but it is easy to see when a semi-transparent object is in front of another object. (You may recall the thundercloud.net example showed an opaque object inside a semi-opaque object.)

I have fooled myself many times by fiddling with the Colormap Opacity curve, then wondering why I don't see the rendered object show variable opacity. You must hook up the two outputs from Colormap to Color: one transmits the RGB colors, the other the opacities. If you only plan to make an opacity map (leaving colors unchanged), just hook up the opacity output to Color's opacity input.

To sum up, in this net, three colorization schemes are employed:

1. Isosurface assigns a default constant color
2. Color (on the left) assigns a user selected color
3. Color (on the right) creates a "colors" Component in which each item varies based on the data and the colormap provided

In all cases, the "colors" (whether constant or varied) reside in the "colors" Component of the output Fields.