In this section, we highlight the latest additions to map3d in the (vain?) hope that people will read at least this much of the manual and be able to quickly make use of the latest and greatest that the program offers.
This is the first major revision of the ``new'' map3d and we are getting close to the functionality of the old GL based version. There are also some features unique to the OpenGL version like the lighting model and excellent mouse controls of rotation.
Some of the specific things that you should notice over the version 5.1 include:
A small sampler of things that are in the works:
This document describes the function and usage of the program map3d, a scientific visualization application developed at the Nora Eccles Harrison Cardiovascular Research and Training (CVRTI) and the Scientific Computing and Imaging Institute (SCI) at the University of Utah. The original purpose of the program was to interactively view scalar fields of electric potentials from measurements and simulations in cardiac electrophysiology. Its present utility is much broader but continues to focus on viewing three-dimensional distributions of scalar values associated with an underlying geometry consisting of node points joined into surface or volume meshes.
map3d has been the topic of some papers [1,2,3,4] and a technical report [5] and we'd love it if you would reference at least one of them (perhaps [3] or [4] are the easiest ones to get copies of) as well as this manual when you publish results using it.
The history of map3d goes back to 1990 and the first few hundred lines of code were the product of a few hours work by Mike Matheson, an inspired visualization specialist, now with SGI, Salt Lake City. This was my introduction to GL and C and this program became my personal sand box to play in. Along the way, Phil Ershler made valuable contributions in figuring out the magic of Formslib for some user interface controls and developing with me graphicsio, the geometry and data file library that supports map3d.
This is a new``new'' version of map3d, the first to use the OpenGL library and thus become truly portable. It marks a new beginning for the program and the result of a collaborative effort from a new cast of contributors. The largest credit must go to Chris Moulding, an ace graphics programmer and general software whiz who surveyed my sand box architecture, pulled together the essential walls, created new ways to make rooms, and still left lots of the sand box around so I could continue to play. Guo Tang has recently added his prodigious programming skills to the project and is working on a few of his own rooms. From version 5.2 onward, Bryan Worthen deserves special notice as he has provided the energy and time to continue developing map3d.
The largest thanks must go to the users of map3d, who provided the real inspiration and identified the needs and opportunities of such a program. Among the most supportive and helpful are Bruno Taccardi, Bonnie Punske, and Bob Lux, all colleagues of mine at the CVRTI. Dana Brooks and his students from Northeastern University are also regular users who have provided many suggestions and great enthusiasm. The first user and long time collaborator and friend was Chris Johnson and this new version of map3d is possible because of the success he and I have had in creating the SCI Institute and specifically the NIH/NCRR Center for Geometric Modeling, Simulation, and Visualization in Bioelectric Field Problems.
We gratefully acknowledge the financial support that has come from the NIH, National Center for Research Resources (NCRR) the Nora Eccles Treadwell Foundation, and the University of Utah, which provides us with space and materials to create this sand box.
Rob MacLeod, July 23, 2001
map3d is written in standard C/C++ and uses the OpenGL library, both choices made to ensure broad portability of the program. This first OpenGL version of map3d targets three platforms and we list the requirements and recommendations for each below. Additional platforms will follow--and follow even faster if you send us a machine to play on.
Requirements for all systems | |
OpenGL libraries (GL and GLU) | version 1.1 + 1 |
OpenGL/window interface library (GLX) | |
Glut | version 3.7 + |
Requirements | |
Operating System | Irix 6.5+ |
Architecture | mips3 or mips4 (maybe mips2) |
Applications Binary Interface | n32 or 64 |
Recommendations | |
Hardware | Texture mapping hardware |
128 MB main memory |
Requirements | |
Operating System | kernel 2.2.x |
Architecture | i386 (+ maybe PPC) |
Applications Binary Interface | libc2.1 |
Recommendations | |
Window system | XFree86 version 4.0 + |
Hardware | 3D graphics card (nVidia, 3dfx, ati) |
128 MB main memory |
Requirements | |
Operating System | kernel 2.2.x |
Architecture | PowerPC (PPC) |
Applications Binary Interface | libc |
Recommendations | |
Window system | XFree86 version 3.3 + |
Hardware | 3D graphics card) |
128 MB main memory |
Requirements | |
Operating System | W2K/NT4.0/9x |
Architecture | i386 |
Applications Binary Interface | win32 |
Recommendations | |
Hardware | 3D graphics card (nVidia, 3dfx, ati) |
128 MB main memory |
The process of installing map3d is quite simple and we provide the steps in README files that comes with the downloaded installation files.
To test the installation, use the test files that accompany this distribution. Each has some script files included that show how to call and execute map3d.
To download the software, use the URL
www.sci.utah.edu/software/map3d.html
This document should have reached you either as a pdf file or via the map3d
web site. If you would like more copies or the latest version, go to the
web site
www.sci.utah.edu/software/map3d.html
We want to hear your response to using map3d and especially to learn about any bugs you may find. They may be features, rather than bugs, but if so, we will be happy to hear your impressions.
To submit a bug report please send email to map3d@cs.utah.edu or point your browser at software.sci.utah.edu/research/software/bugzilla/ with the following information:
We have established an email address for map3d,
map3d@cs.utah.edu, and
web pages within the website www.sci.utah.edu/ncrr
dedicated to map3d. There is also a
majordomo mailing list for map3d users called
map3d-users@cs.utah.edu. To subscribe to this list, send email to
majordomo@cs.utah.edu with the content
subscribe map3d-users
Please let us know how you use map3d and how we can make it better for your purposes. We can only develop this program with continued support and the best way to achieve this is to show that others use the program and find it helpful.
map3d -b -nw -f geomfilename -as xmin xmax ymin ymax -at xmin xmax ymin ymax -t time-signal-number -c mesh colour -p scalar data (potentials) filename -s num1 num2 -i increment -ph maxpotval -pl minpotval -cs contour-spacing -ps scaling_value -ch channels-filename
Here are some typical examples of using map3d:
map3d -f geomfilename.pts map3d -f geomfilename.fac map3d -f geomfilename.geom
map3d -f geomfilename.fac -p datafilename.pot
map3d -f geomfilename.fac -p datafilename.pot -ch thefile.channels
map3d -f geomfilename.fac -p datafilename.tsdf
map3d -f geomfilename.geom -p datafilename.tsdf
map3d -f geomfilename.fac -p datafilename.tsdf -s 1 100 -i 2
map3d -f geomfilename.fac -p mapdata -s 1 9
map3d -f geomfilename.geom@2 -p datafilename.tsdf
map3d -f geomfile1.fac -p thedata1 -f geomfile2.fac -p thedata2However, you can include all the regular features for each of the surfaces so that things can get much more complex. For multi-surface displays, it is often better to use script files (see Section 5) below.
This version of map3d does not provide an interactive means of specifying geometry numbers from a .geom file or time instants from a time series data file. If this information is not in the command line, the program takes the first surface and the entire time series, respectively. We will have this fixed soon, real soon...
The following general parameters affect the entire display:
The basis for display in map3d are one or more geometry descriptions, which are usually in the form of surfaces, but can also be a set of line segments or tetrahedra; hence we can picture each set of nodes and connectivities as a ``meta-surface'', which we generally refer to as a ``surface''. For each such surface, map3d needs the set of node locations in three-dimensional space and usually some connectivity information that defines the (meta) surface. The geometries must exist in discrete form and be stored in files that map3d can read (see Section 6.1.3 for details of the file formats). There is no provision at present for analytically defined geometries.
To tell map3d where to look for this geometry information, each occurrence of -f in the command line indicates that beginning of a new surface. All parameters that follow before the next occurrence of -f refer to the current surface.
255 0 0 | red |
0 255 0 | green |
0 0 255 | blue |
255 255 0 | yellow |
255 0 255 | magenta |
0 255 255 | cyan |
255 255 255 | white |
To display scalar data values on the geometry, we must specify the source of the data and how to link them to the geometry. As with the geometry, all arguments specified between two occurrences of -f in the command line refer to the currently valid surface. Within pairs of -f options, there can be only a single instance of any of the following options:
Using script files to control map3d has numerous advantages, for example:
A script files are simple programs written in the language of the Unix shell. There are actually several languages, one for each type of shell, and the user is free to select. At the CVRTI we have decided to use the Bourne shell for script programming (and the Korn shell for interactive use) and so all scripts will assume the associate language conventions. The shell script language is much simpler to use and learn than a complete, general purpose language such as C or Fortran, but is very well suited to executing Unix commands; in fact, the script files consist mostly of lists of commands as you might enter them at the Unix prompt. Even more simply, a script file can consist of nothing more than the list of commands you would need to type to execute the same task from the system prompt.
Script files are simple text files and so are usually created with an editor such as emacs. You can, however, also generate a script file from a program, or even another script. But all script files can be read and edited by emacs and this is the way most are composed.
To learn about the full range of possibilities in script files requires some study of a book such as ``Unix Shell Programming'' by Kochan and Wood but the skills needed to make map3d script files are much more modest; any book on Unix will contain enough information for this. The instructions and examples below may be enough for many users.
Here are some rules and tips that apply to script files:
map3d -f geomfilename.fac \ -p potfilename.data \ -cl channelsfilename
Make sure that there are no characters (even blank spaces) after the continuation character!!! This has to be the most frequent error when the script file fails to run or stops abruptly.
chmod 755 script_filename
varname=2 varname="some text" varname=a_name
Do not leave any spaces around the ``='' sign or the command will fail and set the variable to an empty string.
Once defined, the variables can be used elsewhere in the script as follows:
geomdir=/u/macleod/torso/geom geomfile=datorso.fac datafile=dipole.data map3d -f ${geomdir}/${geomfile} -p $datafile
The curly braces are required when the variable name is concatenated with other text of variable names but is optional otherwise. To concatneate text and variables you simply write them together (e.g., geomdir/geomfile.pts comcatenates the two variables with a ``/'' and the extension ``.pts''.
All the environment variables are available and can be set in the script. For example:
mydir=${HOME}sets the variable $mydir equal to the user's home directory. Likewise,
MAP3D_DATAPATH=/scratch/bt2feb93/ export MAP3D_DATAPATHdefines and ``exports'' the environment variable used by map3d to find .pak files.
Below are some sample scripts, from simple, to fairly complex:
map3d -f ${HOME}/torso/geom/dal/daltorso.fac \ -as 100 500 300 700 \ -p ${HOME}/maprodxn/andy3/10feb95/data/cooling.data \ -s 1 1000
MAP3D=../map3d GEOM=../geom/tank DATA=../data/tank $MAP3D -nw -f ${GEOM}/25feb97_sock.fac \ -p ${DATA}/cool1-atdr_new.data@1 -s 1 1000 \ -ch ${GEOM}/sock128.channels \ -f ${GEOM}/25feb97_sock_closed.geom \ -p ${DATA}/cool1-atdr_new.data@2 -s 1 1000\ -ch ${GEOM}/sock128.channels
MAP3D=../map3d GEOM=../geom/tank DATA=../data/tank $MAP3D -nw -f ${GEOM}/25feb97_sock.fac \ -as 200 600 400 800 \ -p ${DATA}/cool1-atdr_new.data@1 -s 1 476 \ -at 200 600 200 420 -t 9\ -ch ${GEOM}/sock128.channels \ -f ${GEOM}/25feb97_sock_closed.geom \ -as 590 990 400 800 \ -p ${DATA}/cool1-atdr_new.data@2 -s 1 476 \ -at 590 990 200 420 -t 126 \ -ch ${GEOM}/sock128.channels
MAP3D=../map3d GEOM=../geom/torso DATA=../data/torso $MAP3D -f ${GEOM}/daltorso.geom -p ${DATA}/dipole2.data -s 1 6
MAP3D=../map3d GEOM=../geom/torso DATA=../data/torso $MAP3D -f ${GEOM}/daltorsoepi.geom@1 \ -p ${DATA}/p2_3200_77_torso.data -s 1 200 \ -f ${GEOM}/daltorsoepi.geom@2 \ -p ${DATA}/p2_3200_77_epi.data -s 1 200
#!/bin/sh # A script for the spmag 1996 article # ###################################################################### map3d=/usr/local/bin/map3d map3d=${ROBHOME}/gl/map3d/map3d.sh MAP3D_DATAPATH=/scratch/bt26mar91pack/ export MAP3D_DATAPATH echo "MAP3D_DATAPATH = $MAP3D_DATAPATH" basedir=/u/macleod/maprodxn/plaque/26mar91 $map3d -b -nw \ -f $basedir/geom/525sock.geom \ -as 150 475 611 935 \ -at 150 475 485 610 -t 237 \ -p $basedir/data/pace-center.data@1 \ -s 65 380 \ -f $basedir/geom/525sock.geom \ -as 476 800 611 935 \ -at 476 800 485 610 -t 237 \ -p $basedir/data/pace-center.data@1 \ -s 65 380 \ -f $basedir/geom/525sock.geom \ -as 150 475 176 500 \ -at 150 475 50 175 -t 237 \ -p $basedir/data/pace-center.data@1 \ -s 65 380 \ -f $basedir/geom/525sock.geom \ -as 476 800 176 500 \ -at 476 800 50 175 -t 237 \ -p $basedir/data/pace-center.data@1 \ -s 65 380
In this section, we describe the contents and formats of all the input files that map3d uses to get geometry, data, and much more.
The input of geometric data may occur via a family of simple ASCII files used to describe geometry. These include the points or nodes of the geometry--stored in a file with the extension .pts--and the connectivities that described polygonal links between nodes--stored as line segments (.seg files), triangles (.fac files), and tetrahedra (.tetra files). To satisfy a need for more comprehensive and compact storage of geometry information, we have developed a binary file format and created the graphicsio library to manage these files. Below, we describe each of these files and how map3d uses them.
The characteristics of a .pts file are as follows:
The characteristics of a .fac file are as follows:
At the CVRTI we have developed a binary file system for efficient storage of complex geometry and associated attributes, a part of the graphicsio library. Extensive documentation of this format is available from Rob MacLeod (macleod@cvrti.utah.edu) (www.cvrti.utah.edu/~macleod/docs) and from the CVRTI web site under the heading graphicsio library at www.cvrti.utah.edu/computing.shtml.
Briefly, each graphicsio geometry file contains one or more sets of node locations and, optionally, connectivities for polygonal elements composed from those nodes. It is possible in graphicsio files to associate scalar, vector, and tensor values to nodes or elements, the most relevant example of which are channel pointers, stored as a set of scalar values associated with the nodes of the geometry. Each graphicsio geometry file can contain any number of sets of geometries, each with different nodes and connectivities.
map3d is capable of reading surface geometry from the graphicsio .geom files, at present only from single surfaces specified in the command line. Soon we will add support for reading more than one surface from a multi-surface .geom file.
In map3d the -f option determines in which files the geometry is to be found. Starting from the filename that follows -f, which may or may not include a file extension, the program looks for all possible candidate geometry files and queries the user for resolution of any ambiguities. Thus, with the arguments map3d -f myfile, map3d3d looks for myfile.geom, myfile.pts, myfile.fac, etc, and tries to resolve things so that a valid geometry description is found. It is possible to direct this process by typing the geometry filename with an extension according to the following rules:
Extension | Effect |
none | look for files with the extensions .pts, .fac, .tetra, and .geom and if an incompatible set are present (e.g., both .pts and .geom), ask user which to take |
.pts | take only the .pts file and ignore any connectivity or .geom file |
.fac | take .pts and .fac and ignore any .geom files present. |
.geom | take the .geom file and ignore any others present. |
A further way to read geometry into map3d is to use the geometry filename that can be optionally contained within the time series file (see Section 6.3) that contains the potentials. This requires that the .tsdf file be created with the geometry filename included; adding this after the fact is difficult. Note that even if a geometry filename is found in the .tsdf file, it can be overridden by the geometry file name specified in the argument list of map3d.
There are two ways of storing scalar values (typically electric potential in our applications) so that map3d can recognize and read them. One is a simple ASCII file and the other a binary format developed at the CVRTI.
One way to package the scalar data values that are assigned to the points in the geometry is the .pot file. In the default condition, the scalar values in the .pot files are ordered in the same way as the node points in the geometry file with simple one-to-one assignment. With a channels file, it is possible to remap this assignment, as described in Section 6.4).
The rules for .pot files are:
The more efficient and flexible way to store scalar values is by means of the time-series data file format developed at the CVRTI, also as part of the graphicsio library. These files (.tsdf files) are capable of holding an entire sequence, or time series of scalar data in a single file, along with information about the contents, type, units, and temporal fiducials from the time series. For more details on this file format see www.cvrti.utah.edu/~macleod/docs or the information under the graphicsio library at www.cvrti.utah.edu/computing.shtml.
Here are some concepts of the time series data file structure that are relevant to the different modes of operation described in this manual.
map3d -w -f geomfile.geom@1 -p datafile.tsdf -s 10 130 -i 2specifies that surface 1 from the geometry file geomfile.geom should be used to display frames 10 to 130, taking every second frame, from run 2 of the time series data file datafile.tsdf.
The graphicsio library also defines a container file format that can describe a set of time series data (.tsdf) files, and can contain parameters extracted from the associated time series. At present, map3d does not read such container files, but this will change soon...
Channels and leadlinks files 2, and the arrays they contain, are identical in structure, but they have important functional differences. A run of map3d may require both, either, or neither of these, depending on the structure of the data files and geometries. The basic function of both channels and leadlinks information is to offer linkages between nodes in the geometry and the data that is to be associated with those nodes. The first file type, the channels file, links the nodes in the geometry to specific time signals in a data file; without channel mapping, the only possible assumption is that each node i in the geometry corresponds to the same time signal i in the data file. Any other linkage of geometry and data channel requires there to be channel information, typically either from a separate .channels file or stored with the binary .geom file as an associated scalar value for each node.
Leadlinks are purely for visualization and describe the connection between ``leads'', a measurement concept, with ``nodes'', a geometric location in space. In electrocardiography, for example, a lead is the algebraic difference between two measured potentials, one of which is the reference; ``unipolar'' leads have a reference composed of the sum of the limb electrode potentials. It is often useful to mark the locations of these leads on the geometry, which often contains many more nodes than there are leads. The most frequent use to date has been to mark the locations of the standard precordial ECG leads within the context of high resolution body surface mapping that uses from 32-192 electrodes. Another common application is to mark subsets of a geometry that correspond to measurement sites (values at the remaining nodes are typically the product of interpolation). In summary, leadlinks allow map3d to mark specific nodes that may have special meaning to the observer.
Figure 1 shows an example of lead and channels information and their effect on map3d. See the figure caption for details.
![]() |
map3d handles this information in the following manner:
Note that map3d uses the channels arrays when loading scalar data into the internal storage arrays! Hence, the action of the channel mapping is not reversible. Should geometry nodes and data channels match one-to-one, there is no need for a channels array. It is also possible to define via a channels array the situation in which a single data channel belongs to two (or more) nodes in the geometry. The most frequent example of this occurs when three-dimensional geometries are ``unwrapped'' into surfaces in which what was a single edge is split and thus present at both ends of the surface.
In the leadlinks array each entry refers, by its location in the array, to a particular lead #; the value at that location in the array gives the number of the node in the geometry file to be associated with this lead. For example if lead 4 has a leadlinks entry of 22 ( leadlinks(4) = 22), then map3d will display node 22 in the geometry as ``4'', not ``22'' whenever node marking with leads is selected).
Hence we have the situation of a node number K in the geometry displaying time signals from channel L in the scalar data, but labeled with string ``XXX''.
The sources of channels, leadlinks, and channellinks information are files, or parts of files, as outlined in the following paragraphs.
Information for the channels array is stored as an associated scalar with the information in the standard .geom files. At present, there is no leadlinks array stored in the .geom file but this could change in the future.
A .leadlinks file is an ASCII file, the first record of which
contains a line nnn leads, where nnn is the number of leads to
be described in the file (and also one less than the total number of lines
in the file). Each following record contains two integer values:
32 Leads 1 1 2 42 4 31 7 65 . . . . . . 32 11 <---- 32nd entry in the file, at line 33 of the file.indicates that there are 32 leads to be linked (the geometry can, often does, contain more than 32 nodes), and that lead #1 is called lead ``1'' and is node 1 in the geometry file. Lead #2 is at node 42, lead #3 is called ``4'' and is found at node 31. Likewise, lead #4 is called ``7'', and is located at node 65, and so on, up to lead #32, called ``32'', at node 11.
Nodes listed in a leadlinks file that is passed to map3d with the -ll option can be marked in a number of ways, described more fully in Table 8 in Section 8.2.3.
A channels file is an ASCII file, the first record of which contain a
line nnn nodes, where nnn is the number of nodes to be
described in the file (and also one less than the total number of lines in
the file). There is one line in the file for each node of the geometry to
which we wish to associate scalar data. Each following record contains
two integer values:
352 Nodes 1 123 2 632 . . . . 22 -1 23 432 . . . . 352 12indicates that there are 352 leads to be linked, and that the data value for the first node is located at location 123 of the data file. For node 2, the data value is to be found at location 632, and so on. Node 22 does not have any scalar data associated with it.
To see how map3d can display the node and lead information, see Sections 7.7 and 8.
This section describes the displays that map3d generates and what they mean; for specific information on how to control map3d and the displays, see Section 8.
The idea of map3d has always been to display multiple sets of data on multiple surfaces; the limitation has been how much flexibility to included into a single invocation of the program. At present, map3d will handle either multiple surfaces in a single window, or multiple windows with a single surface in each, but not multiple windows with more than one surface in each.
When map3d displays multiple surfaces, each can exist in its own full window with its own border and window title bar, or, map3d can build a single main window with multiple sub-windows inside the main window. The user can lay out and edit the shape and location of each of these sub-windows using the Alt(Meta) key and the left and middle mouse buttons. To create this layout of main window and frameless sub-windows, use the -b (borderless windows) option when launching map3d as described in Section 4.3.
The basic forms of display of the surfaces are
Display option for the time signal are very modest in this version of map3d. This will change...
Figure 2 shows the layout and labeling of the scalar window. Font sizes adjust with the window size and the type of units may be explicit if the time series data (.tsdf) files contain this information.
![]() |
For directions on how to control the time signal window, see Section 8.3.
Often the purpose of map3d is to render a geometry consisting of nodes and connectivities and there are several basic modes of rendering this information.
A significant addition to this version of map3d is the ability to render all elements with a lighting model. This is especially useful for displaying the elements of the mesh. Addition controls to note are depth cueing, which can reveal the depth relationships between elements of the mesh.
The main use of map3d is to display scalar data associated with geometry and there are numerous options and controls to facilitate this. The two basic ways of conveying scalar value information are as shaded surfaces and contour lines and map3d supports each separately, as well as in combination. For surface shading, there are several basic rendering modes:
There is a wide variety of options available for mapping scalar values to colour and contour levels. One can picture the process as based on four facets:
map3d can adjust all four facets of the scaling to create a wide range of displays. We chose to limit some of these options, however, in an effort to create reproducible displays that reflect standard within the field. Of course, we chose our field, electrocardiography, as the basis, a fact for which we make no apologies and simply encourage others to make similar choices for their own field and implement map3d accordingly. Subsequent versions of map3d will support this flexibility.
Below are the specific choices that map3d offers to control data scaling and display
Clipping planes allow you to remove from view certain parts of the display so that you can better see what is left. So everything on one side of the clipping plane is visible and everything on the other is not.
We have two clipping planes in map3d and their position and alignments are adjustable as well as their relation to each other--we can lock the clipping planes together so they work like a data slicer, always showing a slice of constant thickness.
The controls for clipping planes are adjustable from the menus (see Section 8.2.3) and also via keyboard controls (see Section 8.2.2. The basic controls turn the two clipping planes on and off, lock them together, and lock their position relative to the objects in the surface display. By unlocking the last control, you can select that part of the display you want to clip; the default clipping planes are along the z-axis of the object (up and down). To control position of the planes along their normal direction, just keep hitting the bracket keys ([] and {}).
Node markings are just additional information added to the display of the nodes. This may be as simple as drawing spheres at the nodes to make them more visible, or as elaborate as marking each node with its associated scalar data value. Section 8.2.3 describes these options in detail.
This section describes all the means of controlling the function of map3d, at least all the ones we are willing to tell you about.
There is an ever growing number of parameters that the user can alter for displaying the surfaces in map3d. Some of the more important (and stable) include the following:
Since this level of control is provided for each surface, it is possible to have points showing on one surface, mesh on another, and rendered potential shading on a third, and so on.
To control the display of each surface, be that a surface in its own window or sharing a single window with other surfaces, a user must select that surface. Otherwise, display options will affect all the surfaces. There are two different multi-surface situations and each has its own method of selecting the surface:
Selecting surfaces for display controls | |
Multi-surface layout | Selection method |
One surface per window | Mouse location establishes currently active window. |
All surface in one window | Up/down arrows selects the surface. Hitting the up-arrow key after selecting the last surface selects all surface. |
Note that in the surface window, the lock icons in the lower left corner indicate if parameter settings act on all surface (locks visible) or just single surfaces (locks invisible). Each lock controls a different aspect of map3d:
Note: in the case where all surfaces are in the same window, unlocking the general lock by means of the up or down arrow keys selects the single surface to display. However, when the general lock is active and either of the other locks is disabled, the active surface mesh appears in a different color (blue by default). This identifies the selected surface and all modifications apply to this surface. To select the desired surface use the +/- keys; ``+'' selects the next surface and ``-'' selects the previous.
Direct interactive control of map3d is by the keyboard, mouse, and dials. Many option are available via the menus controlled with the right mouse button, while others can be activated or toggled with single keystrokes. Variable (non-binary) adjustments usually occur with the dials, if they are present, through dialogues, or by repeating keystrokes. Below are tables of all the current control devices and their function. When the program launches, the user sets one or more windows which can be resized and moved at any time. When launching the program with the -b option, the resulting borderless sub-window(s) can still be moved within a main window using the Alt-key together with the left and middle mouse buttons.
The mouse can be used for different purposes depending on the current mode. This is especially important when picking is selected. To shift between modes requires simultaneous pressing of the various modifier keys, shift, control, alt. Figure 3 shows the various actions of the mouse buttons.
![]() |
Mouse Actions | ||
Control Key | Button | Action |
None | Left | rotation objects |
Middle | scale objects (downwards increases size, upwards decreases size) | |
Right | activate pull-down menu | |
Cntrl | Left | pick a node (and if time series data is present, select the channel to display in the time series window) |
Middle | no action | |
Right | no action | |
Shift | Left | translate objects |
Middle | scale objects (rotates clipping planes - more info later) | |
Right | no action |
Mouse Actions | ||
Control Key | Button | Action |
Alt | Left | Move a single surface subwindow (no indication of motion; release to see effect) |
Middle | Resize single surface subwindow (no indication of change until release of mouse button). | |
Right | no action |
Note: if map3d does not respond as described in these tables, it could be that your window manager is grabbing the mouse/key combinations for its own purpose. This will require some setting changes for the window manager. To make such changes under IRIX, examine the .4Dwmrc file; in Linux there is usually a control panel or utility application to manage all window system interactions.
Each key of the regular keyboard, the function keys, and the keypad may be mapped to some function of the map3d. Some keyboard keys serve as toggles to change between a mode being on or off, e.g., ``n'' toggles the display of node markings. Others cycle through a set of choices, e.g., ``m'' runs through a series of display options for the mesh. A list of the keyboard keys and their functions is shown in table 1 and table 2 describes the action for each of the function and arrow keys.
|
|
Access to the menus is by means of the right mouse button, as per the usual OpenGL convention. Below is a series of tables of the menu layout for map3d.
|
|
|
|
|
|
|
|
|
There are two ways to create a time signal window:
The format of the scalar display is fairly simple , with a vertical bar moving along the time axis as the frame number is advanced. map3d derives the time axis label from the frame numbers of the signal relative to the time series data file, not relative to the subset of frame read in, i.e., if frames (or pot file numbers) 10-20 are read in with an increment of 2, then frame number will begin at 10, and go through 12, 14, 16, 18 and end at 20 rather then beginning at 0 or 1 and going to 10 (the number of frames of data actually read).
There is also a menu item for adjusting the time base of the signal, manually aligning time across multiple windows, and setting the time increment between frames of data.
In order to facilitate rapid movement through large datasets, the user can control the frame number being displayed by interacting with the scalar window itself. If the user moves the cursor to the scalar window and pushes the left mouse button, the vertical time bar will jump to the nearest sample to the cursor location. The user can then hold the left button down and slide the time marker left and right and set a desired frame. Once the mouse button is released,map3d updates the map display. The left and right arrow keys also shift the frame marker back and forth. The only other command allowed when the cursor is within the scalar window is the ``q''-key, to shut down just the scalar window, or the ``f'' key, to toggle the frame lock. Any other attempt at input will not be accepted.
By ``picking'' we mean selecting some piece of the display in the current window using the mouse (with buttons). map3d will eventually support selection of a number of different elements of the display: nodes, triangles, scalar leads, etc, all of which either return some information, or affect the display, or even the geometry of the display. In version 5.0Beta, the choices are limited to node information and a time signal. To control picking, use the top-level ``Picking'' menu. See Table 9 for the available options.
This mode simple returns the location, in the same coordinates in which the point data was originally read into the program (the points are shifted to keep the object at the center of the screen's coordinate system).
The only means of getting output from map3d at the moment is by capturing the image directly from the monitor, for example, with the Irix ``snapshot'' utility, or by direct photography. This will change soon...
To many to even begin to contemplate. But if there are any you would like exterminated, please send email to map3d@cs.utah.edu (we accept all foreign currency in large denominations, bicycle parts, assorted outdoor gear, but no credit cards).
Here is a short list of those we know about and are addressing:
This document was generated using the LaTeX2HTML translator Version 99.2beta6 (1.42)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -split 3 -no_white -link 3 -no_navigation -no_math -html_version 3.2,math -show_section_numbers manual
The translation was initiated by Rob MacLeod on 2001-07-23