A list of some commonly used shape file formats
LONI TM
NAME
tm - LONI triangle surface model format
SYNOPSIS
#include "/usr/local/lib/loni/geom.h"
DESCRIPTION
Files with the tm extension are LONI triangle model files.
These are used to represent surface models in terms of
points and triangles. Points are shared explicitly among
triangles. The triangle model format is a stripped down
version of movie.byu files from a few years ago. The for-
mat for numbers within the file is flexible; where float-
ing point or integer numbers are called for, anything that
would be recognized by the C scanf() functions with a "%f"
or "%d" format respectively is acceptable. The tm file is
an ASCII file representing integers and floating point
numbers. It consists of three sections.
Header line
One line header specifying the number of points in the
model, then the number of triangles. The numbers are sep-
arated by a space.
Point list
The next section, starting on second line of the file,
contains a list of the points contained in the model.
Points are listed with one point per line, three ASCII
floating point numbers per point. The three components,
x, y, and z, of each point are separated by spaces.
Triangle list
The triangle list consists of one line per triangle. Each
line contains three integers specifying the point numbers
as indices in the point list. Indices are 1-indexed
(apologies to C loyalists, this is an old format), and the
last index on each line is negated. So a triangle con-
taining the first three points from the point list could
be specified as
1 2 -3.
DISCUSSION
Sharing Points
The sharing of points within the model is significant. If
each point is respecified for each triangle in which it
occurs, this will incur a significant expense in storage;
there will be three points stored for each triangle, as
opposed to a more nearly one to one ratio with sharing.
This extra expense can be very significant when surface
models may be upwards of 500000 triangles. Perhaps more
importantly, failure to share points where possible will
impair the effectiveness of many renderers, which exploit
such information to produce smooth surface appearance.
Ordering Triangles
The order of points within a triangle is significant,
although some formulations are equivalent. The order of
traversal controls the direction of the surface normal for
that triangle, so 1 2 -3 and 2 3 -1 are equivalent, but 1
3 -2 is the reverse of either. Continuous surfaces should
have a consistent orientation for all component triangles.
EXAMPLES
A model consisting of a single triangle with vertices at
the origin and along the x and y axes would be
3 1
0.000 0.000 0.000
1.000 0.000 0.000
0.000 1.000 0.000
1 2 -3
a cube of dimension one has 8 vertices and 6 square faces,
so 12 triangular faces, thus:
AUTHOR
Brad Payne
LONI UCF
NAME
ucf - LONI Universal Contour File format
SYNOPSIS
#include "/usr/local/lib/loni/ucf.h"
DESCRIPTION
Files with the ucf extension are LONI Universal Contour
Files. These files contain structure outline information
with the following features.
o Outlines are divided into planes called levels.
o Levels may contain any number of closed loops
called contours.
o Each contour contains a list of consecutive points.
o Each point is a floating point 3-tuple.
FIELDS
The fields in a ucf, normally in this order, are
<width=>
image_width_in_pixels
of the image from which the outlines were made.
<height=>
image_height_in_pixels
of the image from which the outlines were made. Nei-
ther width nor height should be needed, but some
older software expects them.
<xrange=>
xlo xhi
the real space coordinates of the extent in x for the
volume used to draw the ucf. Normally this is in
microns.
<yrange=>
ylo yhi
the real space coordinates of the extent in y for the
volume used to draw the ucf. Normally this is in
microns.
<zrange=>
zlo zhi
the real space coordinates of the extent in z for the
volume used to draw the ucf. Normally this is in
microns.
<levels>
number_of_levels
contained in the ucf.
<level_number=>
index_of_level
Normally the distance between the sampling plane of
the level and the origin. The first declaration for
starting a new level.
<point_num=>
number_of_points
the number of points in the ensuing contour. The
first declaration for starting a new contour within
the current level
<contour_data=>
first point x, y, z
second point x, y, z
in all, list of point_num points as set be the previ-
ous declaration.
<end of level>
last line of a level.
<end>
last line of the ucf.
EXAMPLES
This is an example of a ucf output by the program maud.
The outlines were made in the plane of two original images
from the volume. One image had two closed loops, the
other had one.
<width=>
512
<height=>
512
<xrange=>
0.000000 185000.000000
<yrange=>
0.000000 185000.000000
<zrange=>
1200.000000 165613.390625
<levels>
2
<level number=>
83400.000000
<point_num=>
794
<contour_data=>
61498.046875 86935.546875 83400.000000
61895.507813 86935.546875 83400.000000
[ 791 lines deleted ]
62292.968750 87333.007813 83400.000000
<end of level>
<level number=>
141600.000000
<point_num=>
303
<contour_data=>
88127.929688 85743.164063 141600.000000
88525.390625 85345.703125 141600.000000
[ 300 lines deleted ]
90512.695313 90512.695313 141600.000000
<point_num=>
292
<contour_data=>
96474.609375 79383.789063 141600.000000
96474.609375 79781.250000 141600.000000
[ 289 lines deleted ]
96474.609375 78191.406250 141600.000000
<end of level>
<end>
AUTHOR
Brad Payne
LONI "4D" UCF files
These are a mutation of the orignal UCF file format.
The differences are as follows:
- Coordinate lines (points) may be either 3 or 4 tuples. If more than 3 numbers are present on a line, the ShapeTools UCF file readers interpret the additional numbers as the elements of one or more scalar valued per-vertex attributes. Some code written by Dr. Paul Thompson uses UCF files with one scalar attribute (the "4D" UCF variant).
- Comments may preceed the <width> clauses, if the first character is a sharp (#) symbol. At present, only the ShapeTools readers recognize and store these comments. Other applications ignore these.
Minc Polygon files (Obj)
The
MINC (Montreal Neurological Reseach Institute of McGill University, Montreal) Polygon Object
file format
provides several [Software Tools]] that facilitate neurological research.
a file format storing the vertices of triangulated surfaces. These files conventonally are named with an extention of ".obj".
An OBJ file contains:
- The vertices of a set of polygons which collectively define a surface in a three dimensional space.
- The normal vectors to each of theses vertices.
- The polygons (faces) of the surface, defined by the indices of the vertices that compose the polygons.
- Either:
- a single RGBA color associated with the entire surface
or
- an RGBA color defined for each vertex of the surface.
All known examples of Minc OBJ files contain triangular faces exclusively. The file format
implies that non-triangular vertices may be supported by the Minc libraries, however, experiments
to verify this have failed. It is not known whether these failures are due to limitation in the
underlying Minc libraries or in the Minc application programs - a distinction that is academic at best.
For all practical purposes Minc Obj polygons must be triangular, with vertices ordered according to
the right-hand rule.
In OBJ files created by the Minc applications the order in which triangular files are encountered in the
data files non-contiguous and undocumented. Here,
non-contigoous means that faces that share sides in
the surface modelled by the OBJ are not adjacent in the data file. The practical result of this is that
any operations on the faces of a Minc OBJ surface may not expect knowledge of that faces' neighbors, unless
an order is determined separately from reading the file data.
Minc OBJ files come in both an ascii text and a binary version.
Minc Lines format
Note: The following is copied from the MINC web site
http://www.bic.mni.mcgill.ca/users/david/FAQ/lines_format.txt
This is a description of the polygons lines as used by MNI-Display
A file looks like: and means:
L 1 10 # line_width=1 npoints=10
63.7483 -0.0488046 25.3558 # x y z for point 0
-62.3075 0.616629 25.0492 # x y z for point 1
. .
. .
. .
-0.319302 -5.36752 -5.124 # x y z for point n_points-2
-0.277344 -6.09656 -5.0817 # x y z for point n_points-1
3 # number of line curves=3
0 .5 .6 .7 1 # 0 == one colour for entire lines
(r=.5 g=.6 b=.7 a=1)
4 7 11 # end indices of lines
first line has 4 vertices
second line has 3 vertices
third line has 4 vertices
0 1 2 3 # indices of the lines (the number of these
4 5 6 should be the last number of the end_indices,
7 8 9 2 i.e., there are 11 indices)
