dx-doc 1:4.4.4-9 / usr / share / doc / dx / help / dxall196

#!F-adobe-helvetica-medium-r-normal--18*
#!N 
#!CNavyBlue #!N  #!Rall195 Visual Programming: The 
Basics #!N #!EC #!N #!N The Field description represents a mapping 
between your actual data sampling space and the Data Explorer graphics 
system used to make images of that data space. Given such 
a mapping, the next step is to learn how to visualize 
your data in meaningful ways. Data Explorer provides both a visual 
programming language and a text-based scripting language. The scripting language is 
described in  #!Lusl,dxall495 h Data Explorer Scripting Language  #!EL  . The visual programming language uses a graphically 
oriented editor instead of a traditional text-based editor as in C 
or Pascal. You will be using this graphical programming environment to 
generate graphic images as output; this distinction between graphics as program 
and graphics as output is subtle, but we do not want 
to confuse the two. #!N #!N To build a visual program, 
you physically select, place, and connect functional  #!F-adobe-times-medium-i-normal--18*   modules #!EF ; 
these are represented graphically as labeled rectangular boxes with tabs sticking 
out of them. Each module can be thought of as a 
subroutine in a text-based programming system. You can place multiple instances 
of the same module, analogous to calling a subroutine several times 
in a program. Modules have inputs and outputs (those little tabs 
sticking out) just like the arguments and return values in a 
text language. The inputs and outputs of modules are connected together 
into a  #!F-adobe-times-medium-i-normal--18*   network #!EF , which in some ways resembles 
a flow-chart diagram. (Unlike a flow-chart, you cannot loop back a 
wire to an earlier input in a Data Explorer visual program) 
Note that many modules have "hidden" tabs for less commonly used 
parameters. You can expose hidden parameters by using the  #!F-adobe-times-bold-r-normal--18*   Expand 
#!EF button in the module's Configuration dialog box. #!N #!N Generally 
speaking, you use Data Explorer to visualize your data in the 
following way. First, bring in the data from a disk file 
as a Field (the Import module can read in a Data 
Explorer format file, a General Array Importer file, or netCDF, CDF, 
or HDF files). Next, run the imported data Field through one 
or more modules found in the Realization category. Each of these 
produces a visual object. You may also want to process these 
Realizations through Transformation modules to modify the visual or other characteristics 
of an object. Either one or a collection of visual objects 
is then displayed in an Image window. The Image window provides 
a number of convenient tools for interactively rotating your visual objects, 
zooming in for a closer look at them, and so on. 
There are many different variations of the above scheme: for example, 
modules like Construct allow you to create simple Fields without having 
to import data; Structuring category modules permit you to modify Field 
components in many ways; other types of output are provided so 
you can write image files to disk, and so on. But 
the concept of Import-Realize-Transform-Image is the basic and most common approach 
to using Data Explorer. #!N #!N So what happens inside a 
visual program? The Field with its components flows through one module 
after another. Some modules add new components, others remove or change 
components. However, an essential point to keep in mind is that 
unless a module is designed to operate on a specific component, 
it does not affect any other part of a Field. That 
is to say, if you feed a Field into a module 
that does not operate on the "positions" component, then from the 
output of that module will come a Field with the identical 
(unchanged) positions component. And that means that another module further "downstream" 
in the visual program can operate on that "positions" component if 
need be. This differs in a critical way from traditional languages, 
which explicitly specify all return values from a function. In Data 
Explorer, assume that everything that goes into a module comes out 
(though often changed), whereas in a traditional language, ignoring side-effects (bad 
programming practice, usually), only those values specifically indicated as return values 
are returned when the function exits. The descriptions in IBM Visualization 
Data Explorer User's Reference identify the components that are changed, deleted, 
or added by each module. #!N #!N It is also very 
often useful to "branch" a visual program. Any module input can 
only have one wire ("tab connection") attached to it at a 
time. However, any module output can feed several different module inputs. 
This allows you to run copies of the same Field through 
different "subnets" to perform several different operations on it. To see 
all of these visual outputs in the same scene, you use 
the Collect module to gather all the "subnet" output wires back 
together. The single output from Collect (called a  #!F-adobe-times-medium-i-normal--18*   Group #!EF 
) can be attached to the input of the Image module. 
The Collect module shares a handy feature with some other modules 
in that you can easily add new inputs to it if 
you need more than the two default input tabs. #!N #!N 
See  #!Lappviz,dxall563 h Using Data Explorer: Some Useful Hints  #!EL  for discussions of the following: #!N #!I0 #!N  #!F-adobe-times-medium-r-normal--18*   
#!N #!N #!I30 #!N o Visualization techniques (including animation, color mapping, 
and shading). #!N #!I30 #!N o Creating good visualization programs for 
interactive use. #!N #!I30 #!N o Creating good visualizations for video. 
#!N #!I0 #!N #!EF #!N #!N #!N #!N  #!F-adobe-times-medium-i-normal--18*   Next Topic 
#!EF #!N #!N  #!Ldatmod,dxall197 h Understanding the Data Model  #!EL  #!N  #!F-adobe-times-medium-i-normal--18*   #!N